|
| Featured Contents |
| Question of the Day |
|
| The Voice of the DBA |
Daily Coping Tip Plan a fun or relaxing activity and make time for it. I also have a thread at SQLServerCentral dealing with coping mechanisms and resources. Feel free to participate. For many of you out there working in a new way, I'm including a thought of the day on how to cope in this challenging time from The Action for Happiness Coping Calendar. My items will be on my blog, feel free to share yours. |
New Old Architectures Many years ago I was starting in a software development role using dBase and Clipper/ I needed to upgrade a DOS based dBase program to Clipper to take advantage of some graphical libraries. Around this time, we were also moving many clients machines from DOS to Windows 3.1, giving them a GUI experience. Also, to the dismay of the management, access to Solitaire. One of our early jobs was to remove that game and Minesweeper from installs. In any case, I started to experiment with compilers that would allow Clipper programs to run in Windows as native apps. This meant moving to a more event-driven style of programming instead of the procedural way that DOS programs worked. This change was a paradigm shift for me and I spent many hours at home experimenting and trying to understand event-driven programming. It's much easier to build a Windows app now, with many frameworks and libraries that handle the low-level events. However, the idea of using event-driven programming can be important in many distributed applications. When we work on the request-response model, it's easy for a failure or problem to create a poor experience for the user, especially if there's an intermediate layer between the client and the data. Certainly, there are retry and error handling techniques, but far too few developers implement them in a comprehensive way. I saw an article that introduces the idea of event-driven architectures as something you would want for microservices applications. It's a good read that helps you gain an understanding of how this architecture would work. I'd recommend this to data professionals, as I expect more of us will encounter developers wanting to implement microservices as a way of magically making your software better. They might even want to implement a broker and queue system in SQL Server. There are many ways in which you might implement this type of system, and many technology choices, but an understanding of the overall concepts might help you guide developers to choosing an architecture that makes your life easier rather than harder. Event-driven architecture and microservices aren't magically going to make your application run better. They could easily create bottlenecks that cause your phone to ring and ticket queue to grow. It's helpful to learn about the things developers want to try and build. They get enamored by new technologies, some of which are amazing. Some aren't, however, and some knowledge can help you point out potential problems and influence decisions. We all want better software, and as data professionals, we want to have intelligent conversations about how to get better software built. Steve Jones - SSC Editor Join the debate, and respond to today's editorial on the forums |
|
| Featured Contents |
