'Microservices' is a modern software architecture which deliveres the software application as a suite of independent services. This post simply explains "Microservices Architecture" and it's advantages and disadvantages.

Author: Daratha Galkissa


To some people Microservices is still a new buzzword. And to some people it’s a battle tested, proven way of delivering their software for modern day requirements. Actually this is not a very new thing. This is the way the Unix system is built. It is all about building the systems in smaller, independent modules. That modules “Do one thing, and do it right”. In order to understand Microservices architecture, we have to go through the very basics of it. I tried to explain the basics of Microservices as simple as possible throughout this post.

What is a monolith

Before learning about microservices architecture, let’s take a look at the monolithic architecture. It refers the systems that gets too big. When we talk in contrast to the microservices architecture, monolith is the same old way we used to deliver software in one bundle.

 

 

Drawbacks of Monolithic Architecture

  1. Making changes to the system is not easy: because of all the modules are in one bundle, even a little change effects a big area of the application. That increases the release time of new features and bug fixes. Generally application loses it’s agility.
  2. When the application scales, the whole bunch of modules needs to be scaled. Although some of them are not necessary to be scaled.

Let’s take an example, think about a simple shopping cart application. Users search for the products they want. They change their search criteria and search several times until they find a satisfiable product. Some of them proceed to the payment page. But some of them change their minds. In this example the Product Catalog Module gets more requests than the Payments Module. Product catalog needs more resources but payments module doesn’t.

When the application gets more and more hits, it should scale in order to serve these requests. We can scale a monolithic application in two ways.

  1. Scale Up : Increase the resources by using high spec servers.
  2. Scale Out : Clone the application under a load balancer.
With the support of modern day cloud infrastructure, we can automate the process of scaling out according to the amount of requests we get to the application.

Actually the requests are made only to the Product Catalog module, the payments module doesn’t need to be scaled. But as they are in one bundle, we are unable to Scale Up or Scale Out individual modules separately.

 

 

Application Scalability

According to the book - The Art of Scalability, We can scale web application in three dimensions. This is called the AKF Scale Cube.

X axis scalability

Cloning the application into multiple servers under a load balancer.

Y axis scalability

Splitting the different parts of the application. Actually this splitting is based on functionality. Which means if you split your application into microservices, your application scales in Y axis. Even after decomposing your application, you can still apply the X axis scalability by cloning individual services into multiple servers under a load balancer.

Z axis scalability

Splitting into similar things, this is also called horizontal data partitioning. This is the most expensive method of scalability.

 

Microservices Architecture​

Microservices is an architectural style. In simple terms, it is just breaking down the application into set of services.

These services are based on business capabilities.
And deployed independently, runs in it’s own process.
And these services may have different databases. And also may have developed in different languages.
Mostly these services communicate through restful web services or asynchronous messaging.
And it’s highly encouraged to develop and manage each service by a separate team.

In recent years microservices architecture became more popular. Because it solves some of the major problems that current software industry faces.

Building the application as a set of services, give you lot of advantages and also some complexities.

In this diagram we have separated the modules and deployed them independently. These modules are now separate back-end services. They communicate with the front-end by Restful web services. And also they can communicate with each other by Restful web services and asynchronous messaging using message queues.

This diagram gives a basic idea of how the application could break down in to set of services. It doesn’t provide information about practical implementation. There many ways to implement microservices. Hoping to write about them in more detailed manner in later articles of this series.

 

 

 

Principles of Microserevices

Principles are important to do the microservices in the correct way, and to gain most out of that.

Based on Business Capability : Each service must be developed based on business capability.

Infrastructure Automation : Should automate the builds, tests and deployments of the services. Scaling of the servers and other infrastructure management also can be automated to a certain level.

Hiding the Implementation : Each microservice hide it’s database. It should provide the necessary public APIs for other services to access it’s database. No other services should be allowed do any changes in it’s database directly.

Decentralized Governance : Give the authority and the responsibly of the services to the team, rather than govern by a central group. That helps the team to use the right tool for the right job. And they take to full responsibility over the entire operation of the service.

Deploy Independently : Deploy services independently, and let the services communicate over the network.

Consumer First : Always consider about the service consumers when designing and changing the services. Maintain proper documentation and maintain different versions of the services(consumer may not be able to switch to the newer version as soon as the newer version is released.)

Design for Failure : The consumers of the services should aware of the possible failure of the services and should have alternative paths to choose if anything went wrong.

Highly Observable : It’s better to have a good monitoring facility for any kind of system. Because of the nature of microservices, it’s vital to observe each and every service.

 

Why Microservices

So far we have learned what is microservices architecture. let’s have a look at why microservices architecture is so important and what are the advantages.

Scalability

We can identify the areas that actually needs to be scaled and assign more resources to scale them. We can scale up or scale out individual services.

Easier to develop

In microservices we develop, deploy and maintain these services separately. Because the code base is so small it is easier to develop, test and build the services.

Easier to maintain

Because if one service is down it affects the dependent services only, it doesn’t stop the whole application. This is really helpful in maintenance.

Easier to manage the teams

It’s advised to allocate one team for one service, so the team is responsible for the design, development and deployment of the service. Actually it is like the teams are working in separate projects. Less engagement between teams, makes less problems.

Polyglot programming

The communication mostly happens through restful web services and the data is delivered in JSON format. So the underlying technology doesn’t matter. Which means you can write different services in different programming languages. Still they can communicate with the front end and also they can communicate with each other. This enables greater flexibility to choose best technology to get the work done.

Polyglot persistence

Each service has its own database, again no matter which database you choose for your service. So your application gets the benefits of both relational and no-sql worlds.

 

What are the problems in Microservices Architecture

Too much network calls

When one service talk to another service, they always have to talk through the network. That is an overhead in this kind of architecture. A good service design could reduce the amount of network calls.

Maintaining the infrastructure

The goodness of microservices comes with some extra cost. In order to maintain this kind of architecture we need to have some kind of infrastructure which supports this. Things like service discovery, scale up/down of services, automating CI/CD pipelines of services….. etc. It needs skilled and experienced people in order to maintain this infrastructure.

Usage of Linux container technologies like Docker have changed the entire industry. Less resource consumption, Containerized environment to each service and faster spin-up time… makes it one of the most suitable technologies to deal with microservices.
There are many powerful tools available to automate the infrastructure management in a microservices environment. Apache Mesos is used to manage datacenters. And also tools like Kubernetes and Docker Swarm are widely used to maintain the container infrastructure.

Above mentioned tools are not necessary, but it’s better to use them rather doing it yourself.

Transaction management is hard

It’s is hard to manage the transactions in a distributed architecture. And also it’s even harder when we have microservices written in different languages and they store data in various types of databases such as Relational and No-Sql databases. It’s not impossible to manage distributed transactions. But as a best practice it’s always better to carefully design your systems to reduce these transactions between services.

 

Conclusion

Microservices architecture is way of building software applications as a set of services. These services are based on business capabilities. And runs in it’s own process, deployed independently. And these services have different databases. And also may have developed in different languages.

It needs more skilled and experienced staff to maintain the infrastructure for microservices.

As a final thought, I would like to suggest that not to start with microservices. Start with the monolith and later identify the microservices which should be separated from the main application. And also reduce the dependencies between modules as much as possible. That will help to easily extract the microservices from the monolith.

This article was originally published in tecmagz



Tags: Software Architecture Microservices
Views: 1178
Register for more exciting articles

Comments

Please login or register to post a comment.


There are currently no comments.