Simplifying the Microservices Architecture.


The Microservices architecture is one of the most used buzz words in the tech industry right now, however there is still some confusion surrounding what that is? 🙂

The Software Development world is constantly looking for ways to speed up the time to market and increase efficiency -produce more for less- and lower maintenance or future expansion cost. Architects always look for new approaches to accomplish this.

Microservices architecture is no exception to the above, it is an old concept capitalizing on new set of technologies where you can build products using independently and separate deployable services.

To simplify and help to understand the traits of the Microservices Architecture; I’m going to borrow an analogy from a different industry; “manufacturing”, using the distributed supply chain methodology.

In old days, producing a car was a monolithic operation, both the assembly line and the parts production are hosted within the same facility, the machines producing the parts are mostly manufactured according to a narrowed specifications and even if the car manufacturer is producing different types of cars, there wasn’t much thought given to share the parts among those different cars, to accomplish this, you need to produce a generic and flexible car design to accommodate assembling and reusing generic parts.

Over the time, with the technology and the logistics advances and the need to scale up operations, the monolithic model changed to distributed model, the car makers focus more on the parts specifications and quality requirements rather than the machines producing those parts, also, those manufacturers try as much as possible to create a flexible design that can allow sharing parts among different car lines, what did the industry gain by doing this?

First, they increased reusability and agility, you can quickly design and create new products using existing parts, which lead to faster time to market, also following this approach you can manage the inventory more efficiently and minimize redundancy.

Also, when you care less about how the machines built or where the machines deployed or hosted, you eliminate a sourcing single point of failure, you can find multiple vendors producing the same spec and quality, it’s even better if those vendors can deliver the parts to the assembly line using unified and standard methods with minimum or no configuration changes required.

So, how the Microservices architecture is mapped to the car manufacturing analogy.

The car is the software product, in Microservices architecture, the team thinks of the development outcome as a product not as a project, even if it’s they’re producing a component, for instance, a car transmission is a product. The design advantage is to see the big picture and create a flexible design that can accommodate future products.

The parts are the functions and the data that you need to compose to create the software services or products and the parts’ machines are the services producing those data and functions.

In Microservices, you care about the component’s or the service’s specifications or spec not where the service deployed or hosted or which technology or frameworks are used to implement and create the services.

This is very helpful in the Cloud or SaaS -Software as a Service- environment, you can use the distributed approach to build products by assembling services offered according to a certain spec, without really caring about how those services were created or deployed.

Currently, the “Container” technology is supporting the flexible service deployment model, the container technology providers such as “Docker” are leading the charge on supporting the concept of containerised service or application deployment.

Ironically, many forget about how the car parts delivered to the assembly line, or in the Microservices world how the orchestration communicates with the services, without the technology advances made in the “API and Restful services” space, we wouldn’t have moved forward that far with Microservices.

Finally, while we now know how the API Development and Restful services and the container technologies are the enablers of the Microservices architecture, the remaining question is; how this is differing from the older component based architectures such as SCA -Service Component Architecture- or SOA?

In essence, SoA and SCA focused on internal integration and centralized governance using the ESB or the Enterprise Service Bus, this is not going to work for the SaaS or the external integration cloud based model. To adapt to the new world, we need to decentralize and separate the services’ spec and delivery concerns from the services’ deployment and the construction concerns.


Those are my personal views and not representing the people I worked with, the companies I worked for, or my/our past and present customers in any shape or form. Any resemblance to real life use cases or situations is accidental and not intentional in any way, shape or form.

Hope this is helping some and again I understand other’s experience and views could be completely different than mine and I completely respect that.

2 thoughts on “Simplifying the Microservices Architecture.

Comments are closed.