Microservices in the Cloud-Native Era

Must-know facts before you make the move to microservices

Microservices architecture is one of the most discussed topics in the software industry today. The software development processes have come a long way, and Microservices has been regarded as an advanced architecture pattern for decades and is proven to be a favored choice for enterprises to develop software.

Melting down a giant asynchronous software ball into several and more convenient pieces has enormous benefits, as seen by the industry today. For improved software development, monitoring, functionality, and speed – it is a must to adopt a microservices architecture. 

In this article, we will explore many important aspects related to Microservices. 

A brief history

The term microservices was coined by Dr. Peter Rodgers in the year 2005 and was acknowledged initially as “micro web services.”

Later it was also referred to as microservices architecture. The main idea behind “microservices” was to break up single large “monolithic” architecture into multiple independent elements/services, making the codebase more granular and manageable – single-function modules with clearly-defined interfaces and operations. 

Companies have been employing microservices architecture for years. According to ‘Architecture and Design InfoQ Trends Report – January 2019‘,  microservices come under the ‘late majority’ section, which means – It is pretty standard in the industry. 

Why microservices? 

With developer tools and platforms like Docker, Kubernetes, AWS, GitHub, etc., software development has become very approachable and easy. You have a monolithic architecture and three million lines of code.

Making changes to the code base whenever required and releasing new features was not an easy task before. It created a lot of dilemmas between the developer teams. Finding the mistake that was causing the code to break was a monumental task.

That’s where microservices architecture shines.

Many companies have recently moved from their humongous monolithic architecture to microservices architecture for a bright future. There are many advantages of shifting to microservices architecture.

While a monolithic application puts all of its functionality into a single code base and scales by replicating on multiple servers, a microservices architecture breaks an application down into several smaller services. It then segments them by logical domains (i.e., authentication, user directory, reporting, checkout, etc.). Together, microservices communicate with one another over APIs to form what appears as a single application to end-users. 

The problem with a monolithic application, when something goes wrong, the operations team blames development, and development blames QA. Since the mistakes are invisible, there begins a blame game. It is hard to find which code broke the production and who or which team is responsible for the error caused.

Image source: Microsoft

Microservices architecture is where different pieces are loosely coupled and made to communicate with each other without breaking anything. 

Microservices architecture will have specific boundaries and simple to develop, test, deploy, and scale.

A couple of advantages of microservices architecture.

• Allows you to embrace DevOps tools and automation.
• Clear boundaries and hence work efficiency among the teams. 
• Reduces the complexity of writing large lines of code.
• Improves the communication between development, QA, and testing teams.
• It makes it easy to find bugs and address them quickly.
• Faster startup time thanks to lightweight servers.
• Each service can scale independently.

Why does everyone care about Microservices?

Architects -> Easy to design. Instead of developing the entire Facebook as one app, If they see various components as microservices ( newsfeed, chat, etc.), then it is easy for architects to decide what it should look like, plan & design, and how they should interact. Also, it will be easy to define the failure cases ( in case chat microservices face any errors and goes down, the news feed will still be available for customers)

Developers -> If you tell a developer to develop a feature, let’s say notification for newsfeed and messages in Facebook with a clear distinction, he will be able to make code changes. In this case, he will just add some lines in the newsfeed microservice and most probably similar code in chat microservice also. This will ease the work and increases productivity.

DevOps Engineer -> Let’s say chat microservice has some code updates; it would be unnecessary to update the other microservices in production.

(in a monolith, you will replace the entire code instead of just updating the code that has been added). It is far easier and simpler to update small parts of apps. This is where Docker comes into the picture and revolutionizing the whole software development industry. So, DevOps engineers will use docker/Vmware or some other technologies to update apps in parts.

Microservices case studies

Spotify

Spotify has more than 75 million active users a month, and it is super fun to see how Spotify employs microservices to handle the system efficiently. The aim is to make the customer experience seamless.

Here’s how Spotify manages it:

• The Spotify system is split into self-contained and single-purpose microservices with independent teams to work on such services. Each microservices team is known as squads. 
• Every microservice at Spotify has a specific goal attached to it. For example, a search engine, user behavioral analytics, songs recommendation engine, etc. 
• These services are significantly less operationally dependent on each other. Hence, customer service is fast, consistent, and the company can resolve issues fast without putting any services down. This way, Spotify employs microservices to mitigate the risk of getting its services down and increase the overall efficiency. 
• At Spotify, developers deploy microservices by themselves, and at the same time, they are accountable for their own operations. They are provided with tools that make it simple to provisions and deploy.

WIX

Wix had an original architecture of a vast Java monolith (along with Hibernate, Ehcache, Tomcat, and MySQL) that managed everything, starting from the user registration to login to editing Wix sites and serving content; it did this all. 

Over the years, Wix abandoned Hibernate and Ehcache. It took 4.5 years to break down the monolith; it involved a complex process because they kept Wix running and improved with new features while gradually moving components from the monolith to new microservices. Today Wix has more than 100 microservices. 

Wix embraced microservices to nullify a substantial technical debt that had accumulated and created critical stability issues inside Wix. As applications at Wix were interconnected, bugs in one portion of the system could bring down the whole system. In early 2010, the Wix company started to break the monolith into more independent services to handle scalability and quality assurance better.

• Read more about Wix’s microservices architecture from this article: Scaling Wix to 60M Users – From Monolith to Microservices.’

Best Buy

The initial state was involved with infrequent and inconsistent code releases, with deployments outlined months in advance. But the releases were usually regularly delayed to finish the old and unfinished work, and the real deployment process involved more than 60 people, with all-night sessions of more than 8 hours.

There were many related problems like single points of failure in their application: spikes in traffic easily bringing the site down. The answer for all these problems was the monolithic application that Bestbuy was built on, which was killing productivity and overall efficiency of the system. 

In 2010, Best Buy launched an initiative to remodel its e-commerce platform. The purpose of this initiative was to break their monolithic, tightly coupled complex application into microservices to deploy any new features easily and quickly respond to market changes happening in the retail scene. Learn more about this transition here. 

Netflix

You can’t ignore Netflix when talking about microservices.

Netflix began its microservices journey in 2008, even before the word microservices had come into the DevOps world. In 2008, Netflix started experiencing service outages and scaling difficulties. It had severe database corruption, which delayed its operation for three days and badly affected its revenue.

This was the point when Netflix realized it has to move away from vertically scaled single points of failure toward horizontally scalable, distributed systems in the cloud. Then this made them chose Amazon Web Services (AWS) as their cloud provider.

In 2009, Netflix started its gradual process of refactoring its monolithic architecture into microservices step by step. They first took the challenge of migrating their non-customer-facing, movie-coding platform to run on AWS cloud servers as an autonomous and independent microservice. Then Netflix spent the following two to three years transforming its customer-facing systems to microservices. 

Things to consider before moving to a microservices architecture:

There are a few considerations before you start moving to a microservices architecture:

• The degree of independence

The first decision is – how independent do you require your services to be? You can pick one of the following options:

• Each service is entirely separate and independent. 
• You can choose to share some components, usually databases. 

• Organization of code

You can organize code base with mono repo or multi-repo. Creating a repository for individual service or creating a single ‘mono repo’ for all services. 

• Technology stack

We need to decide on the technology stack for each microservice.

• Operational complexity

We need to consider infrastructure requirements, load balancing, scaling aspects, monitoring, and service discovery. 

• Organization of team

Team structure changes when you move from a monolithic to microservices architecture. Like a two-pizza team (usually employed while working with microservices), the overall team structure gets affected, needs to be taken care of, and decides how to organize your development teams. 

• Strategy to transform a monolithic application to a microservices architecture

You need to decide on the strategy or strategies you will employ to smooth transitioning of a monolithic application to microservices. The processes to be implemented, dockerizing the applications, using GitHub like platform to collaborate between developers, etc.

Deploying microservices

Deploying a microservices application is quite challenging. The organization will have many services written in a mixture of languages and frameworks. Each one can be considered as a mini‑application in itself that will have its own distinct deployment, scaling, and monitoring necessities.

Any organization on the path of DevOps and has adopted the Microservice architecture wants to:

• Release the features quickly, which will help them stay ahead of their competitors.
• Have no Downtime, which increases reputation.

To achieve this, the organization must have a robust system or a framework to store all the artifacts generated with the respective version number, meta tags, description, etc.

This is because, in case of any production issues that occur with the current release, we will have two safe choices – we can either patch the fix and deploy to the production, or if it is too complicated, we can simply revert back to the old state (with the help of an artifact repository manager) without affecting the end-user. 

We can also use tools such as Docker to deploy Microservices effortlessly and efficiently. Each of the Microservice is further split into processes that can be easily run in separate Docker containers. Everything here can be defined through Dockerfiles and Docker Compose configuration files.

In large-scale deployments, we can make use of popular provisioning tools like Kubernetes to operate and run a cluster of Docker containers over multiple hosts along with co-location, replication control, and service discovery features, making the deployment sturdy and efficient.