Mark Makary Blog

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. Solution Architects always look for new approaches to accomplish this.

The 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; “Automobile manufacturing”, using the distributed supply chain methodology.

Historically, 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, along 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 component and part of 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 data and functions that you need to compose to create the software products and the parts’ machines considered other encapsulated services producing those data and functions.

In Microservices, you care about the component’s or the service’s specifications 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” or container orchestration such as Kubernetes 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 were the enablers of the Microservices architecture, the remaining question is; how this is differing from the older component based architectures such as -Service Component Architecture- or SOA?

In essence, it’s conceptually the same. However, SOA created another bottleneck called the enterprise service bus or ESB, and it wasn’t fortunate enough to enjoy the current containerization independent deployment model.

Disclaimer

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.