Microservices - Myths and Misunderstanding?

Microservices isn’t micro enough !

While the definition of microservices is clear, interpretation of it is very different within development community.

Some questions are,

1. Is it single entity representation?
2. Is it single service representation?
3. Is it a logical functional group?

Let’s take an example of banking application for the sake of this discussion,

3 - Tier architecture solved the problem of tight coupling between technical components allowing them to change independently. Ex: Web changes shouldn’t affect the backend and so on.

But the 3 – Tier architecture didn’t take into account of functional or feature based grouping of components.

I coined this name “F-Tier” Architecture, to indicate the architecture needs to be compartmentalized by features. This is critical for the success of modern application performance and throughput expectations, I will explain the details further in the article.

Microservices is scalable !

Microservices is a style of architecture which allows you to scale, great how and why? Traditional 3 – tier architecture can also be scaled and proven to be scalable, so what’s so special about microservices?

Ex: In online travel booking, ratio of shopping to booking request is 100:1.

• What does this mean; you get 1 booking if you are able to gracefully handle 100 shopping request.
• Does that ring a bell! Booking would need less resources than shopping, why scale the entire system when the expectation is 100:1 ratio?

Microservices helps maintainability and uptime!

 “Rolling restart”, “Hot Deployment”, “round robin deployment” sounds familiar? Maintenance of applications with very minimal down time is a stated priority in modern applications.

Let’s take an example, application changes across all 3 tiers including database.  Any of the above technique is bound to fail if the data semantic is modified (Ex: ORM sees the change and starts complaining on all the nodes).

How about microservices; f-tier brings in a new dimension of availability and maintenance. You could have the “A/C Statement” microservices down and doesn’t affect the other banking functionality. You will be happy with 90% of the customer who are not looking for “A/C Statement” functionality.

Microservices needs discovery?

Well anything that auto scale (up and down) needs to be discovered.

You have 10 nodes of shopping and 2 nodes of booking microservices.

The inflow of traffic is higher due to holiday season on your shopping microservices.

What do you expect, manual spin-off of shopping instances?

Assuming more instances is spin-off how does the load balancer know about it?

Traditional load balancers are great with static environment, worst case adding a node and running a script to include the new instance. If microservices are going to be scaled up and down they needs to discovered, registered and added to the load balanced.

Well, most of the software problems are solved by introducing a layer of indirection. Each microservice needs to self-register when it’s up or down. Need for a registry keeper, a load balancer that’s sensitive to load. Checkout how, Netflix solved this problem with Eureka on AWS.

Microservices support polyglot programming?

Microservices by definition is a contract driven service implementation with HTTP/REST as the back bone (xml/json data transfer). These well-defined boundary between microservices on a lightweight protocol helps to build a diverse team of programmers, the focus is functionality not the choice programming language.

Microservices and Containers are marriage made in heaven?

The heaviness of the virtual machine and the nature of modern applications to quickly spin-off and tear-down microservices, makes the containers an ideal match.

It’s true DevOps, you package not just microservies the container and the execution environment as a whole. Downside, application teams will become the infrastructure team and need to have a good understanding of containerization.

Microservices adds additional complexity?

A Simple pipeline in Jenkins deploying application to 2 Tomcats would bloat into numerous microservices.

Deployment time is increased significantly as the number of deployments has increased.

Need to have a good container management, deployment and distribution tools and techniques.

You will have more log files (per microservices), stitching transaction for debugging can become a nightmare if not for tools like log stash, splunk in place.

If had 10 connections per tomcat, you would see 100s of database connections from different microservices. Because you can’t share the database connection (definitely no DB connection microservice J ).

Conclusion

Everything comes with a cost so do microservices, not every application are build same or needs same availability, scalability and maintainability requirements.

Done - URL