The benefits of Microservices are many and varied. Many of these benefits can be laid at the door of any distributed system. Microservices, however, tend to achieve these benefits to a greater degree primarily due to how far they take the concept behind distributed systems and service-oriented architecture.

Lets take a look at the key benefits one by one:
  1. Technology Heterogeneity: With a system composed of multiple, collaborating microservices we can decide to use different technologies, whichever we think would be appropriate for our use case, inside each microservice instead of having a more standardized, one-size-fits-all approach. We may use Java as the programming language for developing one microservice, while use Go for another and Scala or Ruby for a different one depending on which programming language would be suitable for having improved performance of that respective service.

    We may also decide that how we store our data needs to change for different parts of our system which gets the data from different microservices. For example, for a social network, one microservice may deal with users’ interactions and we might store users’ interactions in a graph-oriented database, whereas another microservice may deal with users’ posts and could use document-oriented data store to store the users’ posts.

    With microservices we are also able to adopt new technologies more quickly. One of the biggest barriers to trying out and adopting new technology is the risks associated with it. With a monolithic system if we want to try a new technology, database, or a framework, then any change will impact a large amount of the system. Trying a new technology in a microservice has a lot less risk. If I really can rewrite my microservice in two weeks, you may well mitigate the risks of embracing new technology.

  2. Resilience: A key concept in resilience engineering is the bulkhead. If one component of a system fails, but that failure does not cascade, then the problem can be isolated and the rest of the problem can carry on working. Service boundaries become the obvious bulkheads. Due to this reason often each microservice uses its own dedicated connection pool to provide bulkhead so that if one connection pool gets exhausted it impacts only one service and not others.

    In a monolithic system, if a service fails, everything stops working. The chance of failure can be reduced by running the system in multiple machines. But, with microservices, we can build systems that can handle total failure of services and degrade functionality accordingly. If one microservice has some issue we may temporarily disable the feature provided by the service thereby degrading the functionality appropriately.

    While we are talking about making our microservices more and more resilient, we also need to understand the new sources of failure that distributed systems have to deal with. Networks can and will fail, as will machines. We need to know how to handle these and what impact it may have on the end users of our software.

  3. Scaling Independently: With a large, monolithic service/system, we have to scale everything together. It may so happen that only one small part of the overall system is constrained in performance, but if that behaviour is locked up in a giant monolithic application, we have to scale everything in that system even though only one small component needs the scaling. For a system using microservices, we just scale those microservices that need scaling, allowing to run other services and parts of the system to run on smaller, less powerful hardware.

  4. Ease of Deployment: An one-line change to a million-line-long monolithic application requires the whole application to be deployed in order to release the change. This could be a high-risk, large-impact deployment. The more the addition and modification of code is done, the higher the risk of the deployment.

    This is totally different in microservices architecture. With microservices, we can make changes to a single service and deploy it independently of the rest of the system. This allows us to deploy our code faster. If a problem occurs it can be isolated easily, making fast rollback easy to achieve. It also means we can get our new functionalities out to customers faster. Thus microservices remove as many impediments as possible to getting software out the door.

  5. Organizational Alignment: Many developers have often experienced the problems associated with large teams and large codebases. The problem exacerbates even more when the team is distributed. Smaller teams working on smaller codebases are often very productive. Microservices allow us to better align the architecture with the organization, helping us to keep the number of people working on any one codebase minimum to hit the sweet spot of team size and productivity. Conway’s Law is worth giving a look in this context.

  6. Composability: One of the key promises of distributed systems and service-oriented architectures (SOA) is that they open up opportunities for reuse of functionality. Microservices allow for the functionality to be consumed in different ways for different purposes. Gone are those days when developers only had to think about desktop and mobile devices. Now we need to think about the myriad of ways that a functionality can be used in the Web, native applications, mobile web, tablet app and wearable devices. As organizations move away from thinking in terms of narrow channels to more holistic concepts of customer engagement, microservices architecture would be of more and more help.
  7. Replaceability: Often we see that some legacy code, which has been written two decades ago, sit in the corner of codebase for years and no one wants to replace this old code. Why? Because this legacy code is too big and too risky a job.
With microservices, the cost for replacing them with a better implementation or even delete them altogether is much easier to manage. Teams using microservices are often comfortable with completely rewriting services when required, and just killing when it is no longer needed. When codebase is just few hundred lines line, it is difficult for people to become emotionally attached to it and the cost of replacing it is pretty small.

The above content is written by:

Abhishek Dey

Abhishek Dey

A Visionary Software Engineer With A Mission To Empower Every Person & Every Organization On The Planet To Achieve More

Microsoft | University of Florida

View LinkedIn profile

If you have any feedback, please use this form:

Subscribe to Our Youtube Channel

Follow Us On LinkedIn