If you’re working in software architecture or development, there’s one phrase you will have heard repeated over and over for the last six months and that is “Microservices”. What are microservices, and why is everyone so excited by them? To understand this, let’s rewind the clock five years and take a look at the buzzword that everyone was using in 2010 – “Service Oriented Architecture”.
SOA is a set of principles that suggests breaking down your business into a number of services, which can be orchestrated together to provide end to end business processes. These services have defined interfaces and are self-contained, which makes them easily replaceable and scalable. This approach is hardly anything new – in 2005 we were talking about the same ideas as “Enterprise Application Integration”.
The concept of having a big problem and breaking it down into a larger number of smaller problems – each with a well-defined scope – has been “common sense” since at least the times of ancient Greek civilisation. In 2015 however, people will tell you that SOA failed as an approach, that it is irrelevant and “monolithic.” So what went wrong?
The original principles of SOA were generally considered at an enterprise architecture level, and the products that were around at the time supported that. The key product that vendors would tell you embodies the principles of SOA (while also solving world hunger and preventing war) was the Enterprise Service Bus and this is where things began to unravel.
Two things went wrong at this stage – firstly, the vendors over-sold their enterprise service bus offerings, selling them as the solution to many problems where a lighter touch (that still followed SOA principles) was required. ESB products were often some of the most expensive offerings that the vendors sold, so any ESB sale was a win.
Unfortunately, this resulted in ESBs being sold into projects where the problem being solved was not at an “Enterprise” level, and where what they needed wasn’t a “Bus,” but a motorbike. This issue was compounded by the fact that developers like to use the technologies that everyone is talking about, so as a result, many application development projects were built on top of ESB products.
These projects would end up using a full-feature ESB, designed to orchestrate calls between high level business services (such as inventory management and invoicing) to integrate application level services (such as logging and CRUD operations on data). At the time, this was something I referred to as the “Application Service Minibus”. It resulted in an obvious mismatch – the applications ran slowly and were expensive and complex to maintain, but rather than admit that they had made a mistake in product selection or admit that they were duped by an over-zealous vendor, people blame the acronym.
Fast forward a few years, and with SOA now having a bad name, it is almost impossible to sell a SOA project to your finance team. You told them that SOA would solve all your problems last time, and it didn’t, so they aren’t going to be fooled twice. However, the principles are still sound, we just need to make a smarter decision about the type of technology that we use to integrate our application level services. But how do we do this? Simple: we rebrand!
And so here we are, we have microservices, which are SOA principles applied to building applications (rather than integrating business services) and done with a more appropriate set of technologies. Does this mean that SOA is dead? No, the principles behind SOA are the same as those behind microservices. ESBs are also not dead, they are still a very good choice of technology when you want to orchestrate business services. However, the number of businesses that need to integrate their services together with an ESB is quite small, so the market has shrunk to the size it should originally have been.
If we take the bus metaphor to extreme, when we want to connect large cities together, a bus is not always the best way to do this. Rail travel is more efficient and planes are used to connect the largest cities together. ESB products are the railways and airports of integration architecture, and microservices are the local transport infrastructure.
This does leave us with a few questions. How do you know if the appropriate SOA architecture for you is one that uses an ESB or microservices, and what are the best practices for using these technologies together to have a truly Service Oriented Architecture? These will be covered in future articles.