Microservices is a type of software architecture that has been growing in popularity. This architecture has been adopted by many tech giants, such as Amazon, Netflix, Uber, for their applications and systems. 

So, what are microservices? And why has it been increasingly adopted by companies around the world? Let’s find out in this article!

What are Microservices?

Microservices are an architectural approach where an application is broken into smaller components that are loosely coupled and independently deployable. These independent components are called microservices and typically have the following features: 

• They have their own tech stack, libraries, and dependencies.
• Developers can work on them without involving the rest of the system.
• They communicate with one another via REST APIs, event streaming, and message brokers.

The key reason why microservices are used over other architectures is that they make it easier for developers to build and scale apps. That’s how microservices came to be; they originated from the need for easier development when applications were growing bigger in size. 

History of How Microservices Became Known

To understand how microservices came to be, you need to know what came before them. Monoliths.  

Monoliths, or monolithic architecture, is an architectural approach where an application is built as a single and indivisible unit. The entire system is closely intertwined from the database up to the user interface level. In this architecture, where the services are highly connected, when developers want to make changes to a service, they will have to work on the entire system to those changes. This is what happened to Amazon.com back in the 2000s when its business grew big. 

Circa 2001, the Amazon eCommerce website, built on monoliths, grew to be so vast and complex, due to the company’s exponential growth, that it became incredibly difficult to manage and update. It would take a mountain of operations (such as reconciling the in-process changes from hundreds of developers, resolving all the discrepancies among them, merging them into a single version, etc.) for the release of a new feature or version of the web application.

To get around this problem, Amazon step by step broke up its monolithic website into numerous smaller services that were loosely coupled and could operate independently from one another. For example, there was a single service that rendered the Buy button on the product page, and another service for calculating the correct tax during checkout. This architecture was made possible thanks to APIs being brought into use as the only communication method among services. APIs are what allow services to communicate with one another while being highly decoupled.

Of course, this is a simplified version of the story, and the undertaking wasn’t easy, but Amazon was successful.  Although the company didn’t invent the term microservices, this term didn’t even exist at the time Amazon was transforming its system, this architecture was basically what Amazon set out to build to solve its problem. So it’s safe to say that Amazon more-or-less invented the microservices architecture that we know and use today.

As other tech giants, such as Netflix and Uber, saw how microservices had transformed Amazon’s whole business, they started to make the transition from their monoliths to microservices as well, and inch by inch that was how this revolutionary architecture became known to the world. 

Microservices vs. Monolithic Architecture

Monolithic architecture is a software development approach in which applications are built as a single indivisible unit. In a monolithic application, services are interconnected and interdependent, which means an update on a single service will require adjustment across the entire application. 

In microservices, on the other hand, services are built to be dependent and single-purpose, which means they have their own business logic, and database and perform a single task (e.g, the “Buy” button on the product page). As services in this architecture are loosely coupled, an update on a service doesn’t interrupt the operation of others. 

Due to the way services are built and connected, developers have a much easier time building and updating functions in microservices than in monolithic architecture. You can have different teams working on different services simultaneously while having the rest of the system still in operation with microservices. This highly flexible operation is not possible with a monolithic architecture.

Microservices, however, need APIs to communicate with one another, hence at a slower speed. An API is like a bridge between two separate microservices islands; without it, there’s no communication between the lands. Meanwhile, services in a monolith can communicate with one another more quickly as they are closely connected. 

How Are Microservices & Cloud Computing Related?

Microservices are a software architectural approach; it’s a way to build software in which you can reside anywhere you want. This means microservices applications don’t necessarily have to be built in a cloud environment; you can have microservices in your privately-owned data center placed in your headquarter.

However, microservices and cloud computing are a match made in heaven as microservices allow services to scale up or down based on usage, and cloud computing is built to facilitate this characteristic.

You can place a monolithic application in a cloud environment, but the application won’t be able to make use of the features of the cloud to gain benefits because its architecture doesn’t allow for such a task. Microservices, on the other hand, are what allow applications to sync with the features of cloud computing, which allows the benefits of cloud computing to happen. Applications that are built on microservices, hence, are called cloud-native applications.

Pros And Cons of Microservices

Despite being a revolutionary technology, microservices are not the perfect architectural approach that fits everyone. It does have its own pros and cons, understanding which will allow you to know whether you should go microservices. 

Pros of Microservices

• Agility. Since each microservice can be worked on independently, you can have continuous improvement and faster application updating by having separate teams deploying different features simultaneously.

• Elasticity. Microservices can independently scale up or down based on demand. This means you can add more capacity just to the services with increasing demand instead of the entire application. This is what makes scaling up with microservices highly cost-effective.

• Reduced downtime. In microservices, when a service fails, the failure can be isolated from the rest of the system. This failure isolation ability allows the application to stay up in the event of services failing. 

• Easier collaboration. Microservices typically have small codebases, which makes it easier for developers to keep track of and understand code, as well as maintain and improve services. 

Cons of Microservices

• Higher Complexity. Although microservices operate independently, they still need to communicate with one another for the application to run as a whole. It’s a challenging task to build proper APIs for this communication to be smooth and secure, and it’s another challenging task to manage those APIs for the system to run stably.

• Difficulty in debugging. A function that the end user enjoys is often a combination of a host of microservices working together. This means a single click on the checkout button may go through various services and create a cascade of other requests along the way before it completes the checkout. If a function fails, it’s much harder to trace which service(s) is the source of the problem. 

• Difficulty in integration testing. Unit testing may be easier with microservices, but integration testing is not. As the components are distributed, developers can have a difficult time testing a feature that requires a given set of components. 

• Difficulty in interface control. While you can update a microservice without affecting the rest of the application, changing an API (the interface) will affect all the microservices that are using it and can cause serious problems if not done correctly. As microservices inevitably result in a large number of APIs, effective management of those APIs is mission-critical for the application to run properly. 

• Higher investment. If you’re running on monolithic architecture, it will require a significant investment to refactor your data into microservices. You’ll also need to invest in skilled development teams who understand and can handle microservices. 

When To Go Microservices & When To Stay monolithic? 

When To Go Microservices

Due to the challenges associated with microservices, you should use this architecture only when the pay-off is worthwhile. Here are some common use cases: 

• When you need agility, scalability, and continuous delivery in your software development.
• When you want to move your monolithic application to the cloud.

When To Stay Monolithic

People are going microservices doesn’t mean you will have to follow suit. There are situations where using monolithic architecture is the most beneficial, such as:

• When you want to test an idea with a minimum viable product. 
• When agility, scalability, and continuous delivery aren’t necessary for the size of your business or market.

Other Examples of Microservices In Use

Netflix

The microservices journey of Netflix started in 2008 when it was suffering from service outages and scaling difficulties after it had started its movie-streaming service in 2007. The tipping point that led Netflix to realize it needed to go microservices was when it experienced a major database corruption and was unable to ship DVDs to its users for 3 days. 

Netflix then came to make the transition to microservices with Amazon Web Services as AWS provided the greatest scale and the broadest set of features and services. In 2009, Netflix began to refactor its monolithic architecture, service by service, into microservices. The first step it took was migrating its non-customer-facing movie-coding services onto AWS as independent microservices, then it spent the next two years turning its customer-facing features into microservices. The transition finished in 2012.

Microservices helped Netflix overcome its scaling and outage problems, and by 2017, the company ran over 700 loosely coupled microservices in its system. Today, Netflix streams about 250 million hours of content on a daily basis to over 139 million users in 190 countries and continues to grow. 

A side benefit that Netflix didn’t expect was cost reduction as its cloud cost per streaming ended up falling to a fraction of that in its privately run data center. 

Uber

As its application exploded in usage, Uber ran into growth hurdles due to its original monolithic architecture. There were a lot of difficulties in developing new features, fixing bugs, and keeping track of its booming global operations, and the monolithic nature of the Uber application required developers of extensive knowledge to make simple updates and changes to the system. 

To overcome these problems, Uber went on to break its system into cloud-based microservices. They built loosely coupled services for different features such as passenger management, trip management, fair calculation, etc. With its system on microservices, Uber was able to assign clear responsibilities for specific services to specific teams, which helped increase the speed and quality of its development.

The transition to microservices at Uber wasn’t smooth though. Uber had about 1,300 services when Uber started working out how it could apply microservices, some were old and some were not in use anymore, and it needed a clear standardization strategy to prevent its system from spiraling out of control during the transformation.

At first, Uber created local standards for each microservices, which worked well and got its microservices off the ground. It later, however, found out that individual microservices couldn’t work effectively with other microservices due to differences in standards. When developers wanted to change one microservice, they often needed to change others associated with it to prevent service outages. This problem hindered the scalability of the platform, so Uber needed to find a new solution. 

Eventually, Uber made an all-out effort to develop global standards for all microservices, which then helped it successfully solve the scalability problem. 

Final Words

Microservices are a revolutionary technology that has allowed many businesses to grow to their full potential. However, this architectural approach does come with a few trade-offs which are the reason it’s not the perfect solution for everyone. Understanding your business and your technological needs will allow you to decide whether you should stick with monolithic architecture or go with microservices.

If your company doesn’t have the expertise to execute your cloud migration project in-house, it’s best to find a good cloud migration service provider to help you. 

CMC Global is among the top three cloud migration service providers in Vietnam. We operate a large certified team of cloud engineers – specializing in Amazon AWS, Microsoft Azure, and Google Cloud – who are able to migrate your legacy assets to the cloud in the most cost-effective way and in the least amount of time. 

For further information, fill out the form below, and our technical team will get in touch shortly to advise!