Photo Credit: iStockphoto

What are the Problems with the Monolith and SOA that led to the birth of the Microservices Architecture?

This article is a continuation of my summaries of the microservices course by Memi Lavi. You can find the course here.

You may want to read the article that led to this, How Did Microservices Become a Thing?.

No system is perfect. The old architectural patterns (monolith and SOA) have served and in some cases still serve their purpose as there are instances when building a monolith application beats following the microservices architecture. But what were the problems with the monolith and SOA that led to the birth of the new paradigm?

Monolith

1. Single Technology Platform: The first problem with the monolith is that all components must be developed using the same development platform (e.g Java, JavaScript, PHP). It is like marriage, If you start with one development platform or language, you have to stick with it to the end. You cannot develop various components using different platforms which are more efficient at certain tasks than others.
2. Upgrading the App: Upgrades cannot be done on only sections of the app that require them. If an upgrade must be done, it will need to be done for the whole application as opposed to implementing the upgrade for a small standalone service which would actually be much faster and easier. The consequence of this could be bug fixes in many different areas of the application.
3. Inflexible Deployment: With monolith apps, every deployment is a deployment of the whole application. We have no way of deploying only one part of the application. This forces rigorous testing for every deployment on the whole application which results in long development cycles. A small change somewhere in the application could trigger bugs in another section of the application due to the strong coupling which will require a fix, testing and deployment again.
4. Inefficient Compute Resources: With the monolith, compute resources (CPU and RAM) are divided across all components since everything is a single process. So, if a specific component (e.g the payments component of the application) needs more resources than another (e.g the product listing component), there is no way to allocate more resources to that particular component unless we allocate more resources to the whole application. This means that components that do not actually need more compute resources will still be allocated more resources alongside the component which actually needs more compute resources.
5. Large and Complex: With a monolith, the codebase is naturally large and complex and a little change in one part of the application can affect another component as there is no clear separation between the components.

Problems with the SOA

1. Expensive and Complicated ESB: Because the ESB (Enterprise Service Bus) strived to handle a lot of functionality on its own, the ESB was very complicated and required a lot of dedicated expertise. The complexity of the ESB made it very difficult to maintain. This was a pain for both engineers and the organizations they work for. Secondly, ESBs were very expensive from the start, therefore, smaller companies avoided them at all costs and only larger organizations could use them for a very long time.

2. Lack of Tooling: For the SOA to be effective, short development cycles were needed. The SOA needed to allow for quick testing and deployment but at the time, such tools did not exist as testing and deployment were manual processes that took a lot of time to execute. And since testing an SOA is more difficult than testing a monolith, in the long run, the SOA took longer to build, test and deploy than the monolith system and this lead to the decline of the SOA and the birth of the microservices architecture.