History of Micro Services

I will be writing few articles on Micro Services. However I would like to highlight few points on why we needed Micro Services and bit of history about it.

In order to truly understand where did the micro services come from, we must first understand what was before them and why it did not work.

Micro Services are a result of problems with two architecture paradigms.

  1. Monolith
  2. SOA (Service Oriented Architecture)

Monolith

Standalone Monolith ;)

This is the original architecture. The ancestor of all other architectures we have today. Monolith is not necessary a bad thing. Some scenarios are best suited for monolith architecture. There is no reason what so ever not to use it in such scenarios.

In monolith architecture, all the software components are running in a single process. All the components share the same threads, memory and compute power. Its basically a huge chunk or code running happily alone. Also there can be strong coupling between classes.

  1. Easier to design
  2. Performance — If developed correct, are quite good in performance. e.g all calls are in process such that its very fast as no network calls are involved.

SOA (Service Oriented Architecture)

In this case apps are services exposing functionality to the outside world. Services expose metadata to declare their functionality usually implemented using SOAP & WSDL. They are usually implement with ESB (Enterprise Service Bus). ESB are designed to mediate between the clients and the services and between services themselves. The ESB is claimed to provide all the crosscutting concerns of the SOA based application such as Authorization, Authentication, Routing, Validations, Monitoring etc..

  1. Sharing Data and Functionality between Systems.
  2. Polyglot between services -It avoided platform dependency.

Problems with Monolith and SOA

A lot of problems were found in both paradigms. These problems are related to technology, deployment, cost and more.

With monolith, all the components must be developed using the same development platform. Since its by definition a single process, there is no way to develop it using different platforms. What this means is,

  1. Can not use specific platform for specific features.
  2. Future upgrade is a problem as we have to upgrade the whole app.
  3. Whole app upgrade means we have test all the components and this process will become heavy and costly.

With monolith, new deployment is always for the whole app. Even when updating only one component, the whole codebase is deployed. Thus it forces rigorous testing for every deployment and might forces long development cycles.

Imagine you found and a bug and you fixed it by changing one line of code. In an application with about million lines of code, this one line fix will required full application deployment and whole application unit and regression testing.

With monolith, compute resources are divided across components. We have a single process that consumes these resources and uses then for all its internal components. If a specific component needs more resources, there is not way to allocate specific resources to that component. We will have to allocate more compute resources to the whole monolith, which will give them to all the components. This is extremely inefficient.

With monolith, the codebase is large and complex. Since all the software components are part of a single process, we naturally have a very large code base containing a lot of dependencies and coupling. Thus it is difficult to maintain.

With SOA, the ESB is one of the main components and its responsible for all the communication aspect between various apps or services. The ESB is claimed to provide all the crosscutting concerns of the SOA based application such as Authorization, Authentication, Routing, Validations, Monitoring etc..

Therefore this ESB can quickly become bloated and expensive. In addition they are complex and required a lot of dedicated expertise to handle them and very difficult to maintain.

Testing and deployment were mainly manual processes and took a lot of time. Since SOA architecture is complicated and Monolith, the manually testing took longer time.

Conclusion

This is an overview of the problems with monolithic and Service Oriented Architecture. Later lets see what Microservices architecture is and how it deals with these problems.

Passionate Technical Lead, Senior Software Developer and free and open source software advocate

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store