We will look at the types of errors in the approaches to the design of large systems, which lead to serious or even catastrophic consequences for business. There will be interesting real-life catastrophe shows and analysis of their causes from people who professionally deal with technical due diligence of companies and work as consultants in the field of fixing problematic architectures.

The world became more complex in the mid-1990s. Companies coveted web applications that ran on the intranet to get rid of desktop deployments. And applications had to serve multiple departments, and sometimes even go beyond the company’s borders. A new paradigm, component-based development, also known as CBD, was established. It promised us reusability, scalability, flexibility, and the ability to extract code (usually written in COBOL). We started breaking down our systems into large functional parts and worked very hard to get these components to start communicating with each other. Java was invented, and suddenly everyone wanted to write code in Java (apparently some still do). Components ran on incredible technologies such as application servers and CORBA (look it up on Wikipedia to impress your colleagues). The good old days of object query brokers!

At the time, I was working at a large international bank trying to create a methodology for component-oriented development. Even with a well-armed team of Andersen consultants, it took us three years to write the damn thing. In the end, both the paradigm and the technology proved too complicated to write decent and well-functioning programs. It just didn’t work that way.

Service-oriented architecture.

At that point, in the early years of the 21st century, I thought we had gotten rid of distributed software development and started building web applications. Everyone seemed to bravely ignore Martin Fowler’s first law of object allocation — not to allocate objects. Gradually we moved on to the next distributed computing paradigm, repackaging the promise of component-oriented development into an updated set of technologies. We now started doing business process modeling (BPM) and implementing those processes on an enterprise service bus (ESB), with components providing services. We were in the era of service-oriented architecture, known as SOA.

After CBD, SOA seemed easier. As long as the components — vendors — were connected to the enterprise service bus, we figured out how to build scalable and agile systems. We now had much smaller components that we could extract from existing systems (written not only in COBOL, but also in PowerBuilder, .NET, and Java). The necessary books on development patterns were written, and the world was ready to get down to business. This time we got to pull it off!

This time I was working for an international transportation company, and we were building software around SAP middleware, supplying tools for both ESB and BPM. Now we didn’t just need Java and .NET developers, we also had middleware developers and SAP consultants working for us. And even though Agile was suggested to speed up development (I know, it’s not the right argument), projects were still too slow, moreover, when all the puzzle pieces fell into place, we started to realize that integration testing and deployment of new releases was getting more difficult by the day.

Finally: microservices!

I hope you’ll forgive me for such a long and confusing introduction to the subject of microservices. You may be thinking, “why do we need another article on microservices, isn’t there already enough literature on the subject?” In general, yes, there is enough. But if you look carefully at the stream of articles that can be found on the Internet, most of them only describe the benefits and features of microservices (sing “hallelujah”), some of them describe the few known examples of innovators (Netflix, Amazon, and Netflix, and Amazon, and Netflix…). And only a few articles actually dig a little deeper, and those tend to consist of a summation of the technologies used in implementing microservices. It’s all just getting started.

And here it doesn’t hurt to take a little history. Interestingly, the benefits and capabilities of the predecessors of microservices are still with us. Microservices seem to promise scalable and flexible systems based on small components that can easily be deployed independently, and thereby promote the best technology option for the component. In other words, the same promises we’ve bought into with CBD and SOA in the past. Nothing new here, but that doesn’t mean that microservices aren’t worthy of close consideration.