Blog

Microservices are often on the table in software development discussions. There are multiple theories around this how, when and why we should use a monolithic or microservice based architectural approach. Somehow, it’s natural that if we talk about microservices, we must mention the big ones, like Netflix, Google, Amazon, Linkedin, Über, Spotify, Twitter or eBay, which all managed to have a successful transition to microservices setup.

Building monolithic software is a trend which went down significantly in the last few years. No wonder that monolithic systems are losing their popularity when nowadays software are involving client-side user interface, server-side applications and databases.

*Source of photo: MartinFowler.com

Start with Netflix

Netflix is a famous example when it comes to switching from a monolithic system to microservices, they made the whole process public, showing the transition to a setup where multiple microservices are holding together the architecture.

It was a pretty big story back in 2009 when Netflix migrated everything from monolith to Amazon Web Services (AWS) cloud-based microservices, continuing this strategy in the following year and right up until the end of 2010. They also had their entire web-based user interface moved to AWS. At the end of 2011 they managed to migrate everything to cloud, breaking up their monolith system into more than 100 microservices. The best part of the story is that they made their solutions public and open-source, so everybody may benefit from it. They also made public their biggest downtime on the Xmas Eve of 2012. Today Netflix became a technological leader in cloud computing and microservices, so it’s worth it to check out their story on this topic before making any decision on this matter. Learn from the big ones if possible 🙂

*Source of photo: Revenue-hub.com

Build up a good team

One of the main necessities when thinking about microservices is to have the proper experts and skills in your team. This is not really an initiative where you can rely only on experiment. You need experienced people in your development team when it comes to cloud based microservices. Your team has to have the required architectural skills and experience, you need to adapt a DevOps mentality, and have containers experts and domain modelling expertise.

*Source of photo: MartinFowler.com

Do not underestimate dockerization either. Docker is a must have tool which will help you save enormous time with on-boarding new team members. If you are not a Docker fan, choose an orchestration tool, maybe Kubernetes, Docker Swarm or Mesosphere Marathon, or any other tool which will help you maintain the infrastructure.

Whatever you do, you need to assure that developers from your team monitor and maintain the CI/CD configuration for each microservice. Here you have some tips if you are lost regarding this subject.

List your problems

When you reach a level with your monolith system where you encounter #limitation issues and the #complexity gets so high that performing changes fast and correctly is no longer possible, then you know that it’s time to switch to microservices.

When a bug can impact the availability of the whole system and risks the stability of the business, then you know that it’s time for scalability and reliability strategies. #Internal dependencies can cause a lot of headache when you have deployment/release windows.

When you constantly have #risks and limitations on the technology chosen and development language and additional changes and upgrades seem unrealistic, you need to kill the beast and start thinking in microservices, where you can apply multiple technologies independently.

Although developers see through their own chaos, the architecture might need a replacement

Get some advice before building microservices

When you realize that the monolithic system is no longer the way to go, before you kill it, you should #keep the old system and build the microservices around it.

Spend as much time as possible on #research and architecture, the key is to plan properly for the future setup instead of jumping into the development without any bulletproof strategy. This is an investment you won’t regret in the long run.

Regarding deployment, your life will get much easier as each microservice can be #deployed separately and if something goes wrong only a part of your system will go down. Of course, it’s also easier to roll back a single microservice instead of the entire system. The integrity of your business is no longer a problem. There will be less mistakes during deployment, you can set up hard-to-cross limitations between the existing microservices.

#Releasing new features will go much faster, you will spend less time on QA, build time and execution time will get shorter. The microservices can be isolated, you will have less Git conflicts during the release. This will also mean better strategy of breaking down the work into tasks.

Monolithic systems are hard to scale but once microservices are in place you can use your resources and people in a much smarter way. From now on you can scale only parts which require more resources, #performance will no longer be an issue. Horizontal and vertical scaling is a key aspect of breaking into smaller microservices a giant monolithic system. You can save costs by having auto-scaling as you will pay only what has been used.

Of course, there are many more aspects to be considered before making such an important decision to build or to transit to microservices. You need to decide how much you would want to invest in this, what are the biggest pros and cons on breaking up a monolith system. Is it really worth it? Is the transition really justified? If you do a google search, you will find thousands of articles on this topic, the more you dig in, the more you may get a bit confused. Opinions are very different, things which are considered to be advantages in one analysis, in another article the same things are identified as disadvantages. Everything depends on your current and future needs, every situation is different so there isn’t one single technical solution which is universally considered the best one.

Our article is just a teasing summary of the challenging world of APIs and microservices, this is just the tip of the iceberg. If you would like to read some more in-depth analysis, we recommend this, this and this article.