• Skip to main content
  • Skip to primary sidebar
  • Home
  • About
  • Subscribe BMA
  • Contact Us!

Be My Aficionado

Inspire Affection

You are here: Home / Programming / Principles of Microservices – Deploy Independently

Principles of Microservices – Deploy Independently10 min read

October 19, 2020 by Varun Shrivastava Leave a Comment

This is one of the most important principles in the world of Microservices.

This has a direct impact on the ability of an organization to roll-out new changes in less time and with more accuracy.

The idea here is to be able to deploy a new version of any part of the functionality in isolation such that the consumers of that service won’t even know that something has changed.

In the image below, S3 has changed without the notice of S1 or S2. Other services won’t even know that something has changed.

  • 3 Microservices
  • Independently change the service
    S3 changes without any notice to S1 or S2

Topics Covered

      • What is the benefit of Independent Deployment?
      • How can we tackle these problems then?
  • One Service Per OS
    • Scale Independently
      • Here’s my Personal Experience On This
  • Consumer-Driven Contracts
  • Multiple Service Versions
  • Conclusion

What is the benefit of Independent Deployment?

Well, the benefit is quite evident. But to make it more clear let’s try to prove it via negation.

Let’s say you have 5 microservices in your network (this number is very humble, usually there are more than 30 or 40 microservices in a mid-size organization easily) and they all share a tight coupling between each other.

So, what will happen if we try to make a change in any one of the services?

Microservices talking to each other
Microservices talking to each other

There are many things that can be happening here.

  • If all services are deployed on the same box then they all will experience downtime even when you have to deploy let’s say S3.
  • If the deployed changes in S3 breaks the S1 (or any other service) then there could be cascading effect which will eventually compromise the entire system. Since each application is dependent on one or the other application.

How can we tackle these problems then?

Let’s look at the solutions one-by-one…

One Service Per OS

When organization were starting out with microservices, it sure felt like a nice thing, to put multiple services on a single OS/Box/Container. This sure had benefits in terms of maintainability; like they don’t have to maintain each service individually and cost reduction in the infrastructure.

But once the virtualization was made easy; with the tools like Docker and Kubernetes; deploying one application per container became the obvious choice.

Once you have isolated your services at the host level then you get the freedom to do a lot of things.

One immediate benefit is that the technology is not a barrier anymore. You can have a completely different environment for different microservices.

You could choose Java for one service and Python for another. There is no restriction.

Another benefit is in terms of maintenance. Since different teams maintain different services the maintenance is also no longer an issue.

Plus you get the ability to deploy each service independently without touching any other service in the ecosystem.

This is an obvious benefit and that’s why more and more organization are adopting cloud platforms because the cloud makes provisioning easy.

Scale Independently

Once each service has its own home, scaling becomes easy.

Usually, there is one favourite service which gets the most calls. This happens almost all the time.

That service requires more resources than any other service in the network. And if that service is deployed in its own container, then resources of that container can be increased in isolation to the other services.

This not only helps to scale better but also reduces the cost of the infrastructure.

You are only feeding the service that requires it. Every other application will keep on working as usual.

Here’s my Personal Experience On This

Recently I got a chance to work on a legacy project. This project was huge. We had to migrate more than 34 components to the cloud. And it was not very straightforward because these components were a part of a huge monolith.

The reason they wanted to migrate to the microservices architecture was because of the ease of development and maintenance.

Also, these codebases grew so big that it was difficult to roll-out a new feature on the platform quickly therefore time to market for any new feature was bad.

Okay, so let me give you a very high-level overview of the kind of structure that they followed:

Monolith architecture where multiple services are deployed on the same server.
Multiple applications deployed on the same server

Scaling was the obvious problem with this architecture.

There was one service that consumed 80% of the resources on the server.

And if there is a sudden surge on the website traffic, the service starts to consume even more and as a result, the other services on the same host has to suffer. They don’t get the sufficient resources and as result, the overall latency of the system increases.

Now, if these 3 applications were microservices deployed on their own host with dedicated resources. Then we could have easily increased the resources of that one server without changing anything for the rest of the services.

This way everyone would have been happy; also the load need not be shared among the services. They all get dedicated resources.

After converting the monolith into microservices we were able to accomplish that.

The overall structure looked something like this:

One service per host
One Service Per OS

This structure is so elegant and solves most of the problems automatically.

Definitely, if you would have asked me to build a similar structure in the 90s then I would have never recommended this. But with the cloud computing and virtualization, spinning up a new server is completely automated. And it only makes sense to adapt to this new world as early as we can to reap the maximum benefits.

Consumer-Driven Contracts

There are benefits of microservices but as uncle ben says –

So even though we have found the power to replace any component individually without affecting the other components in the network, there is a need to be extra careful of the breaking changes.

For example – Let’s say you’ve broken down your monolith components into their own microservices.

But what if you have to make a breaking change in the inventory service. Now, since these two services are no longer maintained by the same team and don’t even share the same code base, there needs to be a certain contract between them.

A contract that will make Shipping believe that the Inventory service will behave in a certain order.

For that to happen there needs to be a written contract; certain expectations that Shipping Service has from Inventory Service. These expectations/contract should not be broken at any time by the inventory service.

Before rolling out any new changes the inventory service should respect the shipping service expectations.

Inventory must run all the test cases (expectations) once to see if everything works as expected. And if something breaks they would know where they made a mistake.

Now, what should inventory service do if it has to make a breaking change?

Well, inventory service will have to inform the Shipping Service that they are planning to roll-out these new changes which will break their existing expectations. So, they would ask Shipping to be kind enough to set new expectations so that they can continue with their business uninterrupted.

Here, we actually trust the consumer to do a good job in writing the test cases. And also they trust us to run their test cases before rolling-out a new change. It’s a mutual contract.

Multiple Service Versions

There could be a scenario where you do not have control over your consumer. And that you have to roll out a new breaking change.

This kind of situation arises when you don’t know who your consumers are. A very good example would be Google or Facebook apis that we use in our applications to leverage their functionality such as login, firebase etc.

In these scenarios, contractual changes won’t work. Because the API is open to all.

This is where Co-existing service versions come in handy.

Let’s take a real-life scenario where you are consuming 3rd party analytics service.

Consumer consuming V1 service
Consumer consuming V1 service

The analytics service releases new changes to the market with more advance features but it contains the breaking changes for V1 consumers.

So, instead of changing the V1 service, it would roll out all its changes under a new endpoint (V2). Once it gets new users on V2 and it knows that V2 is stable, it would announce the end date for V1.

Google Roll-outs V2 service with breaking changes
Google announces V2 service with breaking changes

This is the time when it would ask all its consumers to move to V2 from V1 at their own pace. This would give ample time to the consumers of the analytics service to adapt to their new APIs.

Consumers adopt the newer version at their pace
Consumers adopt the newer version at their pace

This is how a third service releases a new service because it can no longer make the changes in the existing service without breaking the user’s contract.

Conclusion

In this article, we covered various aspects of deploying the microservices independently. One Service Per OS model works great when in achieving independence in terms of scalability and independence.

Then we talked about the Consumer-Driven contract between microservices which enables the smooth functioning of the overall system.

And at last, we talked about the Multiple-service endpoints in case the service wants to roll out the breaking changes.

I hope you enjoyed the article and if you have anything to share or talk about, then do comment below. I’m waiting to start a conversation 🙂

Share this:

  • Click to share on Facebook (Opens in new window)
  • Click to share on LinkedIn (Opens in new window)
  • Click to share on Twitter (Opens in new window)
  • Click to share on Pinterest (Opens in new window)
  • Click to share on Reddit (Opens in new window)
  • More
  • Click to print (Opens in new window)
  • Click to share on Tumblr (Opens in new window)
  • Click to share on Pocket (Opens in new window)
  • Click to share on Telegram (Opens in new window)
  • Click to share on WhatsApp (Opens in new window)
  • Click to share on Skype (Opens in new window)
  • Click to email this to a friend (Opens in new window)

Filed Under: Programming Tagged With: consumer-driven-contracts, deploy-independently, microservices, one-service-per-os, principles of microservices

Reader Interactions

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Primary Sidebar

Featured Posts

The New Boy In Town (Pune)

July 8, 2016 By Varun Shrivastava 2 Comments

What is Google Cloud Pub/Sub and How Does it Work?

March 18, 2019 By Varun Shrivastava Leave a Comment

Top 5 Best Gaming Headphones in the World Right Now!

March 10, 2017 By Vaibhav Leave a Comment

Almost Sorted Hacker Rank Problem (Medium Difficulty)

November 27, 2020 By Varun Shrivastava Leave a Comment

Create Page Layouts with React and Typescript

July 28, 2020 By Varun Shrivastava Leave a Comment

Latest Posts

  • 3 Best Laptops (Mid-Range) For Every Use Case In India
  • Distributed System Architectural Patterns
  • The Power of being in the Present
  • Basic Calculator Leetcode Problem Using Object-Oriented Programming In Java
  • Study Abroad Destinations : Research and Review

Categories

  • Blogging (103)
  • Cooking (11)
  • Fashion (7)
  • Finance & Money (12)
  • Programming (51)
  • Reviews (4)
  • Technology (22)
  • Travelling (4)
  • Tutorials (12)
  • Web Hosting (8)
  • Wordpress N SEO (19)

Follow us on facebook

Follow us on facebook

Grab the Deal Now!

Hostgator Starting @$3.95/mo

DigitalOcean Free Credits

Trending

Affordable Hosting amazon aoc-2020 bad luck believe in yourself best database earn money blogging education experience fashion finance Financial Freedom food friends goals google india indian cuisine indian education system java javascript life life changing love make money microservices motivation oops poor education system principles of microservices problem-solving programmer programming reality search engines seo SSD Hosting success technology tips top 5 web web developer wordpress

Copyright © 2021 · BeMyAficionado by Varun Shrivastava · WordPress

loading Cancel
Post was not sent - check your email addresses!
Email check failed, please try again
Sorry, your blog cannot share posts by email.