Microservice Architecture

Melvyn Conway, 1967

Any organizations that designs a system will produce a design whose structure is a copy of organization’s communication structure.

Microservices development is often a reflection of how your engineering organization and business units work together.

THE SCALE CUBE:

X-axis: Horizontal duplication: Any application, if we want it to make more available, service more requests cater to very high transactions per second, instead of having a large machine, we produce many small machines i.w horizontal scaling. This consists of running multiple copies of an application behind a load balancer. If there are N copies then each copy handles 1/N of the load. This is a simple, commonly used approach to scaling an application.

Y-axis: Functional decomposition: Instead of having a monolithic application, cut the application into smaller pieces. Scale by splitting different functionality and deploy them separately. Unlike the X-axis and Z-axis, which consist of running multiple, identical copies of the application, Y-axis axis scaling splits the application into multiple, different services

Z-axis: All about data. Instead of having just one humungous data which contains everything why not have multiple databases and data in all these are logically grouped together. Z-axis splits are commonly used to scale databases. Data is partitioned (a.k.a. sharded) across a set of servers based on an attribute of each record.

Nothing comes easy!!!

Accept the “ law of conservation of complexity” i.e If we are making something simpler then something else will become complex.

There will always be some part of the application which will become more complex while making another component simple.

COST- upfront or later??

Microservices have a larger upfront cost in terms of DevOps than monolithic environments.

Table-1

The image on left depicts a monolithic application with some approximate charges/hour.

The table on left depicts per month cost if we are running our website. As we can see clearly it’s approximately 5300 INR or $79.20 / month.

Here, (The picture on left), we have distributed our services into service-A and service-B and the Business logic of these services are independent of each other, separately build and deployed.

Table-2

The cost of running our services as per the above architecture rounds off to $187.20/ INR12550.

From the above tables (table-1 and table-2) we can clearly see the difference in cost if we opt for microservice. You can choose to pay this cost now or late when your monolithic application starts to slow and become a real nightmare in production.

A microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies.

— James Lewis and Martin Fowler (2014)

Where should we not use microservices?

1. If you do not have a reference architecture, it might be risky: → Can end up in a situation where services are extremely fragmented or vice versa.
2. Finance sensitive cases. → We need more compute, more DB resources, each Business unit is hosted simultaneously, underlying structure increase, and costs also increase.
3. If the understanding of distributed systems is unclear.

Microservices can also be implemented on-prem and not just cloud.

Characteristics of microservices:

1. Do one thing and do that thing really really well: E.g take search capability and focus on that and be very good at that. Now, search itself has multiple capabilities like indexing and many more. This is exactly where micro kicks in i.e search further can break into there but it is not required. This is the very definition of microservice kicks in how much micro is our micro.
2. We expect our microservice to be small, easy to manage, and understandable code but how small is small is it based on lines of code, or is it based on time, or is it team size?? There is no silver bullet. There can be some of the above points or all of the above points. When we break big things into small we invariably push the complexity to their interaction.
3. It should be modeled around business capabilities with minimal to no overlap.
4. Should have strong module boundaries.
5. Overall much stronger system resilience than a monolith.
6. Team dynamics: Coordination among different teams in different time zone can be a challenge
7. Component: Same programming language, Never hosted independently Libraries as components.
8. Service: Components that communicate with a mechanism such as a REST service request. Service will force well defined and explicit defination. Services will introduce network latency, so you need a strong network bandwidth to tolerate the latency

A schematic example:

Let me briefly explain the above image. We have two different business units: Biz A and Biz B. we have a web application that is just a front end to our customer, has no business logic, and relies on individual business units i.e Module A, Module B (bidirectional communication), and Module C ( which is an async conversation). It also depends on Module x and Module y from Biz B. Module b communicated with Module x synchronously with REST API and get JSON response. Module C communicates with Module y but the communication is Async. It has two queues q1 and q2 wherein q1 Module c produce and Module Y consumes and in q2 it's vice versa.

Module y is a bunch of instances or VM which is hosting Module y running together having ASG allows it to increase/decrease instances as peruse. Let’s assume module y gets knocked out, at this point of time module x is up but y is gone. This state of y is known as the degraded state which can be because of two reasons infra or code. To deal with infra failure, we have ASG(Autoscaling group) which is a self-healing feature at a high level. Now if there is code failure, we can build immutable infra where we create a parallel deployment with new code and make this one as latest version and another as older version and directs all the traffic to a newer version ( update DNS). If we do immutable infra, the existing set of machines are not touched which contains older code and that’s how we deal with code level degradation.

If we had monolith in this place, even at that point dealing with situations like this is possible however there we got reduced agility and rollback time is taken more and it will impact all the service.

Polyglot means a collection of different aspects of technology coming together and giving us the microservices implementation.