Microservices Architecture

Problems with monolith and Service Oriented Architecture (SOA) lead to new paradigm. It was clear this new thing has to be modular and should deals with simple API, not complicated ESB based implementations.

Then in 2011, the term “Microservices” emerged and in 2014 Martin Flower and James Lewis published their “Microservices” article. This article became very popular standardize Microservices architecture.

There are 9 major characteristics of Microservices architecture as per them.

1. Componentization via Services

Modular design is always a good idea. We always need our code to be modular so update it requires a small code change in a well-defined part.

Components are the parts that together compose the software. In other words, a modular software is a software that has more than one component and each component is responsible for a specific aspect of the software.

There are basically two methods to implement molecularity in software.

1. Libraries -called directly withing the process.
2. Services -called by our of process mechanism (e.g REST API)

In Microservices we prefer using services for the componentization. Libraries can be used inside the service for common components.

Why would we want to use services for the modularity of our system instead of the simple, faster libraries?

1. It makes our components independently deploy-able.
2. It offer well-defined interface.

2. Organized Around Business Capabilities

In a traditional monolith project, we have teams with horizontal responsibilities such as UI, API, Biz Logic, DB etc..

When designing Microservices architecture, each and every service can be handled by single team which is responsible for all the aspects of the service.

Now when working like that the team has one goal to make the service perform its functionality. Since the team has holistic view of the service, it can make decisions that affect the whole functionality.

How do we decide on the boundaries of the service?

We can do that by looking at business capabilities. We look at the overall functionality of the system and map the various business capabilities it has.

For example, an e-commerce app will probably have order management, inventory management, shopping cart, delivery, payment and so on. Then we might have service for order management which contains all of the technological layers and it is handled by a single team. Thus we have single team responsible for a single business capability.

This will help us to achieve two things.

1. Quick development
2. Well-defined boundaries

3. Products not Projects

In a traditional project, the goal is to deliver the working code. The team is working on a project and the project work plan usually ends when the code is delivered. In this case team will not develop long lasting relationship with the customer and the customer’s involvement with development process is minimal. When a team focuses on delivering the code, then don’t really see the customer and they don’t think like a customer. We have seen many times that projects that have great code and great algorithms and is every effective and clean, but does not deliver the product to the customer actually wanted.

With Microservices, teams will mostly deliver a product not just a working code. A product needs ongoing support and requires close relationship with the customer. The will be responsible for the Microservice even after the delivery. In other words,

“You build it, you run it”.

What is the motivation behind the product, not the projects?

1. It will increase the customer satisfaction
2. Change developer’s mindset

4. Smart Endpoints

Traditional SOA project used two complicated mechanisms,

1. ESB
2. WS-* protocol

This made inter-service communication complicated and difficult to maintain.

In Microservices, we used simple protocols. We strive to use what the Web already offers. The most common one is of course the HTTP protocol.

There are important notes here,

1. Direct connections between services is not a good idea. I will make spider web and couple each other.
2. Better to use discovery service or a gateway.
3. In recent years, new protocols/mechanism were introduced such as GraphQL, gRPC etc..

What is the motivation behind Smart Endpoints?

1. Accelerate development
2. Make the app easier to maintain

5. Decentralized Governance

In traditional projects, there is a standard for almost anything,

1. Which dev platform to use
2. Which database to use
3. How logs are created and so on..

With Microservices, this is quite different. Even though we can have set of standards, each team makes its own decisions. The team has authority to make its own technological decisions and implement them in the service.

The idea behind is that each team is fully responsible for its service. Since services are loosely coupled by definition, a change in one of them will have exactly zero affects on the other service. Using multiple development platform in one system is called polyglot.

What is the motivation behind Decentralized Governance?

1. It enables making the optimal technological decisions for the specific service.

6. Decentralized Data Management

In traditional system, we usually have a single database. It will store all the system data for all the components.

With Microservices, each service has its own database (most of the time).

Actually this is the most controversial attribute of Microservices. There are lots of questions and challenges with that. Sometimes implementing separate database of each service is not the correct way. It will cause problems such as distributed transactions, data duplication and more.

In this case we should not insist on having separate database for each service. This should be decided on case by case basis.

Why we need decentralized data management?

1. It enables us using the right tool for righ task as having the right database is important.
2. It encourages isolation.

7. Infrastructure Automation

SOA paradigm which we talked about earlier suffered with lack of tooling. As a result many operational things ended up very slow and affected project’s schedule.

Automated tooling can greatly help in accelerating deployment.

1. Automated Testing
2. Automated Deployment

As we have lots of moving parts in Microservices, automated testing and deployment is essential. Otherwise it will slow the process substantially and making it extremely inefficient.

So its clear that what is the motivation behind this,

1. It will give us short deployment cycles.

8. Design for Failure

With Microservices, there are a lot of processes and a lot of network traffic which means a log can go wrong. A process can crash, the network can go down where there are a lot of moving parts.

The code have to assume failure can happen and need to handle it gracefully. In addition to this, extensive logging and monitoring should be in place.

1. Catch the exception. Do not allow the un-handled exception to bubble all the way to the client. It might even expose sensitive data.
2. Retry -Perhaps its good idea to retry in case connection failure. It could be temporary hiccup.
3. Log the exception so developers can analyze later.
4. Monitoring -monitor the system health and alert.

What is the motivation behind this?

1. This will increase the system’s reliability.

9. Evolutionary Design

The move to Microservices should be gradual. It might be tempting to break anything apart and start from scratch. The best approach is start small and upgrade each part separately. This way, we change the system gradually and creating a moderate system and have a lot of opportunities to find out if we broke something.

Conclusion

These are guidelines and not mandatory instructions. We should not follow blindly all of this. We can study and adapt to what we want and what is suitable for us. The Microservices concepts are rapidly changing, so its important to follow new APIs, monitoring, cloud services etc.. and keep you updated.

In my opinion below 5 attributes are more important in general.

1. Componentization
2. Organized around business capabilities.
3. Decentralized governance
4. Decentralized data management (when possible)
5. Infrastructure automation

☕ Like this content? Support me on Buy Me a Coffee!