| Monoliths and Microservices I have run into a lot of people in the last few years that love decoupled software and microservices. It seems many people are aiming to move their work in this direction, and while I see some appeal, I also see tremendous additional complexity that has moved out of the software into the operations and debugging space. As I read the book Observability Engineering, I found myself thinking the complexity of setting up more logging and instrumentation in an observability framework as well as the costs of managing a system start. That caused me to think this is overkill for most software. To be clear, I don't think that Uber could have been built as a few monoliths, and there are other examples of such systems, but most of us don't work at that scale. There are lessons to be learned about large, real-time software systems, and certainly Google, Amazon, Spotify, Netflix, etc. can help us understand how certain techniques work better at scale, but most of us don't work at that scale. Scale to me is thousands of connections and terabytes of data. Those companies tend to work at a couple orders of magnitude above that. Those are also companies that must have real time systems up to survive. The vast majority of companies I've worked at might suffer a loss with an outage of a system, but honestly, we could survive a day or two of recovery. Heck, look at all of the companies that have had portions of their digital infrastructure knocked offline from ransomware the last few years. Some failed, but most didn't. The incident sucked for IT staff, but those companies survived. I still remember the SQL Slammer worm forcing us to take our entire network offline for multiple days at a large software company. We still ran sales, and support, and other systems independently or from paper. Granted that was 20 years ago, but I'm sure Redgate and many other organizations could survive a few weeks with no network. Uber on the other hand, that would be a disaster for them. They would likely survive, but at a high cost. How many people would jump to a new service and never look back? I was reading a piece on coupling and complexity, which I'll discuss a bit in another article, but it got my thinking of how often I see people overcomplicating their work by trying to move to a decoupled world instead of hiring and training people to adopt better architectures and communicate better. After all, moving to microservices isn't going to avoid the training issue. You'll still have to teach people more. And while you're at it, force every developer to pass a SQL test every year. That might help you build better systems as well. SQL isn't going away and better SQL coding in will result in much better applications everywhere. Steve Jones - SSC Editor Join the debate, and respond to today's editorial on the forums | 
