What Organizations Currently Use Microservices?

When discussing the impact of microservices in the tech and business industries, we have to mention organizations such as Netflix, Amazon, Uber, Twitter, and others that paved the way for its development.

“If you go back to 2001, the amazon.com retails website was a large architectural monolith.” - Rob Birgham (Amazon AWS senior manager for product management)

Amazon began as a small bookstore and has since expanded to become the world's largest e-commerce platform.

Like many other commercial giants, Amazon started as a layered monolithic app. However, when it was time to scale, they experienced challenges associated with the monolithic design. Development and deployments took too long, large databases were difficult to maintain, and it was too arduous to add new features to the system, while also dealing with fluctuating website traffic. All of this resulted in Amazon experiencing frequent outages and incurring financial losses.

Eventually, Amazon's architects realized that the company's current structure was limiting its growth and that it was time to switch to a more flexible architecture.

Meaning, every feature of the platform would be provided by a microservice, and those services would communicate with one another using APIs (application programming interfaces). At the time, the word "microservices" didn't even exist. But that was essentially what they set out to do.

They established a unity of direction between individual development teams building different services to be coupled into a single large application, and they developed two rules to guide the development teams:

The “two-pizza team” rule implies that the maximum number of people in a team must not exceed the number that can be fed with two pizzas conveniently. Anything above that is too much. This way, each member of the team can be closely monitored. The two-pizza rule improved the team’s productivity
“You build it, you run it” rule, which means every developer is solely responsible for every service they built.

Those two rules and their impact on Amazon’s teams paved the way for future products like Amazon Web Services (AWS), which supports microservices, and propelled Amazon to become one of the world's most valuable companies.

Netflix is a popular online streaming platform. Like Amazon, Netflix was part of the early adopters of microservices and has contributed immensely to the growth of microservices in the tech industry.

In 2008, a missing semicolon in a code caused corruption in Netflix’s database and had a significant impact on their interconnected system. In response, Netflix decided to change its architecture to what Adrian Cockcroft, Netflix's cloud architect, refers to as “loosely coupled services with bounded contexts”.

Netflix began the gradual process of transition from monolith to microservice in 2009. Within a few years, Netflix had completed the migration to the cloud, breaking their monolith structure into loosely-coupled services.

During the transition, they had to figure out how to:

Manage multiple servers - keeping their cloud and in-house servers working simultaneously
Replicate their massive database on the cloud.

Netflix also developed tools to manage connectivity issues, inadequate performance levels, and incessant breakage.

Evidently, adopting microservices was a good call for Netflix. They recorded increased scalability, achieved effective data management, and reduced sudden downtime. With over 200 million active users, they stream millions of hours daily, and it keeps growing. Following the success of Netflix in migrating to the cloud despite the seeming difficulties and criticism, other top companies like Twitter, Google, and IBM have also migrated to the cloud with microservice as their core architecture.

Uber started their cab-hailing services with a monolithic structure. The whole process of matching drivers to passengers, making payments, and so on was managed and controlled by a single repository.

However, the Uber service gained popularity, and more users signed up. Uber needed to scale, and include additional features. Still, progressive integration got more difficult as the system's components became more interconnected and the entire codebase had to be redeployed with every change.

There was also the possibility that the code change would have a cascading effect on functionality. After deployment, single repo implementations required the extra effort of ensuring that the changes made did not affect other aspects of the system.

The Uber team adopted the microservices model; each service would be responsible for running a specific functionality. Things would become disjointed. Repositories could be taken over by teams. It was simpler to add new features and make code modifications without risking damaging the entire system.

However, just as is the case with every new thing, Uber encountered some challenges during their migration from the monolith to microservice. According to a publication released by Uber Engineering Team in 2015 about their transition, these challenges can be categorized into three main areas:

Obviousness: it is laborious to find an appropriate service with over 500 services running.
Safety: as the number of services calls increased, it became necessary to streamline the processes of service integration. Uber implemented Apache Thrift to handle strict interface definitions to be followed by service calls.
Resilience: the ability to remain functional in the face of failures is another concern they had, but it was tackled with fault-tolerant libraries like the Hystrix library.

“If you are worried about scaling to hundreds of millions of users, you build your system in a way that you scale components independently” - Kelvin Goldsmith (VP Engineering, Spotify).

Spotify is a digital music service that gives users access to millions of songs, with over 75 million active users per month on an average session length of 23 minutes. Spotify was developed by several independent full-stack teams managing different aspects of the product.

It made sense that Spotify adopted the microservices architecture from inception. They developed a system that is flexible, with no extremely hard dependencies between the microservices. Spotify had to find creative ways to solve numerous problems along their microservices journey, including

Creating the Simian Army for ensuring active monitoring to solve monitoring problems that could occur with thousands of instances running autonomously.
“View aggregation” to deal with latency issues that result from services calling other services within the system.

Spotify has around 90 teams, 600 developers, and 5 development offices on 2 continents working on the same product. Some of the benefits they have enjoyed while using microservices are:

Ease of deployment - since the applications are not large, deployment is fast and easier.
It is easy to scale without worrying about obstacles; any bug discovered can be addressed and updated seamlessly.
A large number of services can be down without users noticing until it is fixed.

Karma Go is a product of Karma Mobility Inc. The Karma Go hotspot is an open network that allows customers to share their connections with people around them. At the initial stage, the team planned to split the Karma project into two parts (frontend and backend) to communicate through API, and the backend architecture was monolithic.

The monolith approach didn’t work well for them because of the entanglement in the system, specifically because of three core problems:

Scaling: they had to scale the entire API every time they needed to make an update on any of the three key APIs they were working with.
Versioning: an outdated dependency or package can render the entire application inactive.
Multiple language and frameworks: a need to be able to experiment with different languages wasn’t possible.

While implementing the microservice architecture, they faced some difficulties with testing. In this case, actions and their corresponding results were far apart and made identifying the cause of crucial issues more complicated.

To address this, they worked on making each component functional, implementing queues so that when a service goes down, it can start from where it stopped when it comes back up with no impact on other parts of the system.

A common trend for most of the companies listed above is the need to scale, ensure continuous delivery, avoid downtime and cascading failure. They found Microservices helped solve problems encountered in their monolithic architecture, such as

A change in any component can affect the whole system and disrupt a running program.
Complex and confusing development process.
Difficulty in integration and,
Exploring more than a single language for development.