Evolution Of Microservices

Evolution
Evolution

Application Architecture for smaller enterprises

Let us try to understand more from layman’s term, some of you might remember for a long time, Combo TV model was quite popular because it was like one device including everything, you are getting TV, DVD Player & VCR in a single unit.

Image for post
Image for post
Fig 1. Typical Monolith

When anyone says monolith architecture, it is nothing but your application development & packaging is something like combo TV, where all the multiple skillset technologists in three different areas (1 TV,1 VCR,1 DVD)would have come together, would have designed everything together. Later they would have done wiring for all the devices together & try to come up with this Combo TV.

Let us see, how the above combo TV example is applicable in terms of a typical multi-tier web application. Let me elaborate more on this by adding our typical monolith application development team composition roles to the above Combo TV model.

Image for post
Image for post

Fig 2. Typical Monolith application layers & team composition

I didn’t mean to offend any role , I am trying to form analogy to explain it in a better way. Your typical monolith web application from eagle-eye view has Presentation layer/UI Layer, which generally your UI developers takes care of, business modules which you try to connect with your UI by exposing business module through certain pattern, which is generally taken care by your senior developers, who has an idea about massaging raw data from your backend services and converting it into business objects, further you have data layer which will be used for passing or receiving the data thorough certain DTO object & further database designer/developer develop DB tables, part of the team will be developing security module around your web application. You obviously lost the agility here, since you have a lot of disadvantages in above model

What are the problems in the above Combo TV model?

  1. All the devices are interconnected.
  2. During built out everyone is waiting on each other.
  3. If one component is down might cause an issue for other components(TV has issue will make DVD Player,VCR useless)
  4. The repair of TV might have to take the entire unit to repair station.
  5. After repair you have to verify all the devices-testing
  6. You might need to contact multiple technicians for each component.

Typical Multi-tier Monolith

In multi-tier architecture it will be something like below where you are trying to deploy enterprise application on your application server, you have your web-server servicing some of the static web pages & your DB is further on a possibly clustered environment.

You have packaged as well as developed all your internal modules like inventory management, User management, Order Management and Shipping service in a single deployable unit.

Let us find out what are the issues with this approach

Image for post
Image for post

Fig 3. Multi-tier online marketplace architecture

What are the disadvantages in the above approach ?

  1. Low Cohesion- All the components are tightly coupled.
  2. Every module developer as well as developer at each tier is waiting on each other.
  3. Reliability- If one component is down the whole system will collapse.
  4. Low maintainability -Upgrade or issue in one module will bring down the whole application
  5. Cross-cutting concerns like server startup time, difficult to test
  6. You have an army of people in your agile team from the different module in each tier

To last point, you try to skin this cat to prove you are truly agile either you find full stack developers who will play multiple roles or set achievable module development goals, very low, based on your team size & their velocity or arrange sequential development of each module. Your SDLC process really didn’t get agility at least in the development/implementation phase.

It has certain advantages also, that’s why it was followed for a long time,

Advantages

  1. Easier deployment
  2. No need to worry about newer architectural patterns
  3. No brainer scaling
  4. Easy to manage

That’s where over a period of time new architectural way of implementation came to i.e SOA but again SOA has certain limitations & it might not work for smaller enterprises.

Here comes Service Oriented Architecture(SOA)

In Service Oriented Architecture we divide application around mostly around coarse-grained services as per business functionality (Business Services)there are also other types of services like Infrastructure service(logging, Security, etc), Application services(fine-grained around application context).

SOA principles are more around the business as a service & reuse as much as it is possible. This forms a very big monolith around business services, where you have to follow certain common platforms across the services to make seamless communication or avoid any integration issues. Underlying you might end up using the same relational DB for all services.

SOA still didn’t provide the solution for fault tolerance to certain failures, you might still end up in a situation if one system is down causing application is not able to fulfill customer orders in our earlier example of an online marketplace.

Not everyone was able to procure infrastructure for SOA implementation like ESB, when I meant everyone I meant smaller enterprises.

That’s why Microservices Architecture(MSA)

What is Microservices in terms of our Combo TV options?

Image for post
Image for post

Fig 4. Typical Microservices Architectural end products

Here we chose the best product like TV, VCR, Sound System, etc from reliable vendors. We got the best out of everyone & we can selectively use every device. The issue in VCR doesn’t create an issue in other devices. We kind of overcame all our disadvantages

  1. All the devices are separate.
  2. No one is waiting on each other.
  3. If one component is down the rest of the components are working
  4. After repair of one device, you verify only that device

Online marketplace design using MicroServices Architecture(MSA)

Image for post
Image for post

Fig 6. Implementation on the online marketplace using MSA

As you can see our online marketplace application is broken down into multiple services & exposed as individual lightweight rest api to communicate. Also, you would have observed that each application has its own DB, on its own container(VM/Node). UI has separated from back-end service so complete independence.

This gives you provision of procuring best DB for each operation type, like lookup in case of inventory management NoSQL might make best fit other places might RDBMS makes more sense.

Whatever disadvantages were in your typical monolith development model had been overcoming.

Advantages:-

  • No vendor locking like in SOA
  • Diversity in terms of not marrying with any technology
  • True agility since very small functional or infrastructure services
  • Get the best fit for the job to get it done
  • High Cohesion since the separation of responsibility

There are certain disadvantages to Microservices Architecture also

Disadvantages:-

  • Complexity, since each service on its own, became self contained, it raises a lot of concerns related to the handling of data across services, API gateway, Security, aggregation of logs at one place, reporting for datawarehouse, inter-service communication.
  • Security Concern, now that everything is scattered around you might have to take care of security concern
  • Cultural shift, suddenly DevOps becomes primary focus & mindset needs to be adapted.
  • It becomes costlier since you need supporting infrastructure to support MSA.

Conclusion :-

Microservices Architecture is not necessarily fit for all the possible business ask. It clearly needs to be thought before any business ask was considered as a candidate for Microservices. Microservices is not a silver bullet for everything otherwise you will end up in building up and maintaining a large set of services, which became difficult to manage. It adds complexity at multiple places from the development phase until the end of the SDLC life cycle. Some of the cross-cutting concerns need to be addressed before you truly start following MSA, it is a little bit of a bigger lift for initial setup, which might not justify the effort in terms of business ask. Not all the projects have supporting infrastructure to follow this architecture and if you force yourself in that direction you might end up in building pseudo Microservices.

Please look forward to my upcoming write-up on Architectural Patterns in Microservices, if you have decided microservices are the fit for your business need.

Image for post
Image for post

Published by Sachin Kapale

About Sachin

Written by

Sachin Kapale works as a Technical Solution Architect.His articles are available on http://www.sachinkapale.com

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