5 Microservices Examples: Amazon, Netflix, Uber, Spotify & Etsy

Many of the large and profitable enterprises in the world started with monolithic applications. However, they owe a large part of their success to transitioning into microservices. A majority of these enterprises dismantled their monolithic behemoths into smaller microservices. This transformation enabled these corporations to scale quickly according to demand, achieve more agility, and make large strides in business development. 

In this article, we attempt to explain what prompted these large business enterprises to move into microservices and how they straddled the change and became wildly successful. 

Maximizing Efficiency: How Large Enterprises Benefit from Adopting Microservices

When enterprises first start their operations, they work with the help of a single large monolithic application or a few interdependent smaller monolithic applications. The code for the application is a cohesive piece that is woven together and having many interdependent parts. 

Download Ebook for FREE "How to choose the best microservices vendor and trim the cost"

Imagine a situation when a single part of the code has to be changed for a specific reason such as a change of operations. This is not going to be easy as it will be very difficult to untangle the interdependent parts. This is likely to disrupt the code for the entire application. 

Any upgrade to a monolith is therefore a time-consuming and expensive affair. Upgrades cause huge disruptions and more upgrades lead to more complications. There always comes a time when upgrades or scaling the application is virtually impossible. 

This is when corporations contemplate shifting to the microservices architecture.

About the Microservices Architecture

An application is organised as a group of compact, loosely linked, and independently deployable services using microservices architecture, a software development methodology. Each service has a defined API (Application Programming Interface) that allows it to interact with other services and carry out a particular business function.

Setting up the microservices architecture starts with splitting the monolith into smaller independent functionalities. The functionalities are loosely coupled and they communicate via APIs. This type of architecture allows for more agility because each of the microservices can be developed, deployed, and maintained independently. This means there is hardly any downtime for the system as the other services are not affected in any manner whatsoever. 

Once the microservices are split into smaller independent functionalities, microservices communication becomes a critical aspect of ensuring the architecture functions seamlessly. Since each microservice operates independently, they need to interact and exchange data to maintain the overall functionality of the application. This communication can be handled through synchronous or asynchronous methods, depending on the use case.

Steps in Building Microservices

The steps below describe in brief how microservices are built. 

Step 1: Study how the monolith functions and break down the application into smaller functions/services as required by the business.

Step 2: The next step is to develop each of the functionalities as an independent microservice that can run on its own. Such programs are run inside a container that is typically located on a cloud server. In an eCommerce application, each of the microservice would be designed for functions such as orders, shipping, accounts, product returns, etc.

Download our ebook: Porting from Monolith to Microservices: is the shift worth it?

Step 3: The next step involves the integration of the services. They are loosely coupled and communicate via API gateways. These loosely coupled services work in tandem to form the functional larger application.

Step 4: Kubernetes is a container orchestration tool that helps to allocate and manage system resources for the individual microservices. 

How organizations overcame processing and scaling challenges with microservices

1: Amazon

Amazon’s website in 2000 was a set of tightly coupled programs deeply entangled within one another. Every single time Amazon’s services had to be upgraded, it meant to disentangle the many dependencies.

Read our blog : MICROSERVICES AT NETFLIX

Though the program that supported Amazon was designed in multiple tiers, the tiers were tightly coupled in a way that they behaved like a monolith. Any startup that is growing faces the problem of a codebase that grows in size with increased business.

A large codebase adds quite a bit of overhead to the process and ultimately, the SDLC slows down. Similarly, at Amazon, a rapidly growing customer base brought with it more challenges. There were delays in development, interdependencies in the services, and coding challenges. At one point in time, Amazon was faced with the absolute need to restructure its system from scratch.

Amazon set to splitting its monolith into multiple smaller service-specific applications. For this, developers separated all the code that served a specific function. They then wrapped up this in a web service interface. 

Download our ebook: Porting from Monolith to Microservices: is the shift worth it? 

Each service was taken on by a different team of developers. All the bottlenecks were resolved by the teams that developed the specific service. The resolution was more efficient as the developers were concerned only with a single service. 

The functions were further designed to communicate only through their web service APIs. This resulted in a highly decoupled services design. Each of the services could iterate all on their own only in adherence to their web interface without any coordination between the services. 

By the side, Amazon developed many other solutions to support microservices architecture in general. AWS and Apollo are two such solutions favored by enterprises across the world. The transition to microservices is believed to have catapulted Amazon to the place that it currently enjoys in the eCommerce world. 

2: Netflix

There cannot be anything said on microservices without Netflix figuring in the discussion. Back in 2008, Netflix thought of changing its codebase when its system faced a major outage because of database corruption. In those days, Netflix was just a DVD rental firm. The net result of the outage was that they could not ship DVDs to their subscribers.

Netflix made a decision to move away from vertically scaled RDBMS and instead settled for distributed data systems in a cloud server. AWS was their choice which allowed for horizontally scalable systems and other services and features. 

Netflix started its migration in 2009 and took 2 to 3 years to complete the final process. They initially started with their non-customer-facing programs and settled for AWS cloud service to function as an independent microservice. As soon as this section was settled, Netflix moved into transforming all their customer-facing programs to independent microservices. The entire system completed its transformation in 2012. 

Netflix quickly overcame all its challenges on the scaling side and service outages disappeared. By the year 2015, the Netflix microservices was able to handle close to 2 billion API requests daily that were well-managed by over 500 cloud-based microservices. Today Netflix has over 139 million customers spread over 190 nations across the world. Today, Netflix’s microservices systems boast of over 700 well-oiled microservices functioning independently. 

Read our blog : What Kind of Challenges Can Microservices Help You Overcome

However, the major positive fallout of shifting to microservices was cost reduction for Netflix. The cloud cost per streaming ended up as only a fraction of what it was costing when streaming was via the data center. It is interesting to note that Netflix today streams over 250 million hours of content to its subscribers in one single day. 

Shifting to Microservices? Call us or drop us a note!

3: Uber

The next case in discussion is Uber. This taxi-hailing cab originated in San Francisco and was meant to serve the people in the city. Soon the service spread to other cities and countries. Problems began showing up when Uber wanted to launch new features or fix bugs or upgrade their services to global levels. Moreover, all the developers needed extensive knowledge of the existing system even to make minor changes. 

Uber’s Monolithic Structure

A REST API connected the Uber drivers and passengers. Three adapters with embedded API served functions such as billing, payments and chats. All features including a MySQL database were contained within the monolithic structure. 

To work through these obstacles, Uber decide to shift to cloud-based services. They soon built microservices for the different functionalities such as management of trips and passengers. The services communicated with the outside world via API gateways. 

Read our blog : Advantages of Microservices Architecture, Disadvantages of Microservices Architecture

Talking about the advantages that microservices brought to Uber’s existing monolithic interdependent system, each development has clear ownership and boundaries of the functionalities to be developed. This improved the speed of development and the quality.  

When the individual teams concentrated on the services that required scaling, all the work related to scaling took place very fast. There was no downtime whatsoever when specific services were up for maintenance. The system fault tolerance was more reliable. 

However, it was well understood that merely getting into the microservices architecture was not the end of troubles for the organization. The need of the hour was a standardization strategy to prevent any loss of control. Here is how they went about the same.

All of the 1300 microservices first adopted local standards for every microservices. This was because Uber’s microservices could not latch with microservices of other organizations because of differing standards. Maintenance became an issue when developers altered a specific microservice. Service outages became common. It was impossible to coordinate the standards for all the microservices after maintenance. 

Read our blog : How to find the best microservices development company

Finally, Uber decided to develop global standards for all of the microservices. For this, they set up quantifiable standards for principals such as documentation, reliability, stability, fault tolerance, etc. These they measured based on business metrics like webpage views, etc. With global standards that were developed, the services were of the highest quality.

4: Spotify

Spotify is a global music company that serves more than 170 million users. Serving these subscribers and looking after the computing, storage, and networking resources is a major task in itself. To be the best music service in the world, the organization started to feel that maintaining data centres did not contribute to this goal in any manner.

Further, they also wanted to free up developers from the jobs of provisioning resources and maintaining them. Moreover, Spotify wanted to derive advantages from Google Cloud’s latest innovations (BigQuery- data warehouse, Pub/Sub - messaging, DataFlow – streaming data).

Read our blog : Should you migrate from monolith to microservices architecture

Spotify formulated the migration plan in 2015 and they split the job into two parts, services and data. 

Services Migration

By forming a team of engineers and Google experts, Spotify first created a live visualization of the migration process so that the engineers could easily track progress on their own. The visualization was a set of red (data center) and green (Google Cloud) bubbles and the size represented the number of machines that were involved.  

The team then mapped dependencies as every microservice would rely on a minimum of 10 to 15 other microservices for just servicing a customer request. Therefore, all-at-once migration was ruled out because customers expect constant uptime from Spotify. 

The engineers were therefore tasked with moving the systems in just a 2-week window, and in this period, they temporarily put on hold all the product development activity. They pushed everything unnecessary out of their way. They used the Virtual Private Cloud option to their advantage. 

Read our blog : The 5 Best Microservices Technologies List

Another problem the team faced was VPN latency. Shifting 1200 microservices to the loud took up a lot of VPN bandwidth. The team then collaborated with Google to get over this problem. Then they started moving the user traffic to the cloud. Soon after this, they could decouple the service migration from user traffic.

The central migration team induced failures which were kind of dry runs to see how the teams reacted to and managed the new microservices architecture. By 2017, the traffic was routed through Google Cloud and they soon closed their on-premise data centers. 

Data Migration

This task involved moving Europe’s biggest on-premise Hadoop clusters to the cloud. Following the dependency map, the task was to move close to 20 000 data jobs to Google Cloud without any downstream disruptions.

Read our blog : Microservices Architecture – 5 things it is not

They wanted to copy all the data to the cloud and restart the required operations. Even if the speed was 160 Gb/s, the job would have taken two months to complete. To handle operations without disruptions they also decided to copy the moved data to the on-premise cluster till the job got done completely. The entire job lasted for almost a year. 

Spotify now runs its data on BigQuery while running close to 10 million queries per month. 

5: Etsy

Poor server processing time was what prompted the eCommerce platform to think of microservices. Performance issues started cropping up regularly and soon the development team began to set goals to reduce processing time to 1000-ms time-to-glass. This is the amount of time required for the screen to update values on the user’s device. 

The development team also realized that concurrent transactions are the only way that would improve processing time. They had a PHP-based system and this ruled out concurrent API calls. 

DO you want to know how microservices can help your business move forward? Call us today!

Etsy’s earlier system was based on sequential transaction execution and this made it very sluggish. The development team also wanted to extend the Etsy mobile app capabilities. The API team decided to move ahead with a new approach where the development teams could be familiar with and access the APIs.

Etsy’s approach

With inspiration from Netflix’s migration to microservices architecture, Etsy first decided to establish a two-tier API with meta endpoints with each of them aggregating additional endpoints. With this arrangement, low-level general-purpose resources on the server-side were transformed into device-specific resources. 

This action created a multilevel tree and the customer end of the website and Etsy’s mobile app were composed into a custom view using one layer of concurrent meta endpoints (atomic component endpoints). The non-meta-endpoints (those at the lowest level) are the ones that will communicate with the database. 

Download our ebook: Porting from Monolith to Microservices: is the shift worth it?

Even at this stage, a lack of concurrency was limiting the processing speed of the eCommerce application. Though all these actions generated a bespoke version of the mobile app and website, the sequential processing of the many meta end-points was an obstacle to reaching the performance goals.

This problem was ultimately solved by the development team when they used cURL for parallel HTTP calls that helped them achieve API concurrency. They had to make a few more associated changes before Etsy’s new structure went live in 2016. Etsy went on to create general-purpose tools that favored the developers and helped them speed up the adoption of the 2-layer API.

Now their microservices structure supports faster upgrades, concurrent processing, easy scaling, and innovation as and when required.

In addition, Etsy implemented circuit breakers in their microservices architecture, which provided a safeguard against system failures by isolating failing services and preventing cascading issues. This approach ensures that even when individual services encounter problems, the system can maintain overall stability and continue to function efficiently. By combining circuit breakers with their improved API concurrency, Etsy now benefits from increased resilience, allowing for faster upgrades, concurrent processing, and seamless scaling. This strategy has empowered the company to innovate rapidly without compromising performance.

 Wrapping up …

Microservices and the advantages that they can bring are very evident from the success stories of these large corporations. Are microservices the right choice for your business? You must be aware that the shift requires time and brings along its challenges. However, at the end of it all, the advantages of microservices can help your business scale to newer heights.