Table of Contents
Infrastructure updates on big technology companies always make interesting stories. Stakes are high, creativity is a must, and the risk is immense. Companies that migrated from Monolith to Microservices are living proof of this. In this article, we’ll review some of the cases of complex software architecture migration.
eBay, Amazon, and Netflix are noteworthy examples of companies that undertook the daunting challenge of reworking all their infrastructure.
They choose to tackle the technical debt head-on and shared their lessons publicly. In some cases, pioneer companies had to develop new models, processes, and altogether technologies since nothing similar existed in the market.
We’ll talk in-depth about a few examples of Monolith to Microservices adoption below, but there are many more. Google, LinkedIn, Nike, IBM, PayPal, Twitter, Spotify, Target, Nordstrom, Orbitz, and many others.
Too Long Didn’t Read
Big companies share their success stories of migrating their software architecture from Monolith to Microservices. The tales are exciting and full of teachings.
What’s Monolith and Microservices?
Monolith and Microservices refer to two well-known software architectures. In few words, the software architecture dictates how the software is divided into parts and how they communicate with each other.
A Monolith software architecture has a single, indivisible part. It’s the quickest way to organize a system but does not scale well.
For example, a simple eCommerce with user interface, catalog, and payment system in the same codebase. To make big changes in the catalog, it’s necessary to refresh the whole website.
Microservices, on the other hand, divides the system into discrete but connected parts. It’s ideal for scaling.
In our example, if the payment system crashes, it’s possible to debug and reset it without affecting the user interface or catalog.
If we need to change the application in any way, such as upgrading libraries or switching technologies, it’s much faster and quicker to do it with Microservices. Monolith requires rewriting the whole application.
Marcin Kaletka, Team Leader @Kambu
Learn more about what is Monolith, Microservices, Serverless, and other software architectures.
Monolith to Microservices Migration Stories
1. Amazon
Founded in 1994, Amazon presents some interesting cases of technological innovation. They are known for being pioneers in adopting (or creating) new processes to solve problems.
In 2001, Amazon’s website was a multi-tiered Monolith. The engineers knew it was not a scalable architecture, but the practice of updating it was very complex.
They reviewed the code in search of units that served a single purpose and found baffling cases, such as a single service that rendered the “Buy” button on the retailer’s product detail pages. Calculating the correct tax during checkout was also handled by a single-purpose function, explained AWS senior manager for product management Rob Brigham in 2015.
Different teams were responsible for these isolated functions. They had to be merged periodically, which created additional work. Extra builds and redundant tests were common.
To address this, developers were oriented to only create functions that could communicate externally through their own web service APIs. It resulted in a decoupled system, where these functions could be updated independently.
With initiatives such as this, the idea of cloud computing was being born.
2. Netflix
The case of Netflix, founded in 2007, is often talked about when discussing the adoption of a Microservices architecture. Their journey started in 2009, which can be considered as ancient times in the infrastructure ecosystem.
Back then, the company had a monolithic code architecture which was quickly becoming insufficient. The user base was growing exponentially and they predicted the development pipeline was not efficient enough to scale solutions properly.
Netflix hit it right by transitioning in steps while ensuring users would notice as little as possible the changes. The explanation comes from a 2014 presentation by the architect behind Netflix Cloud Infrastructure (video, slides).
The streaming platform started with decoupling backend services such as movie encoding. That was a test to make sure the AWS (Amazon Web Services) integration was working. After that went well, moved to services that impacted the User Interface: sign up, configuration, movie selection, and so on.
All in all, it took two years to break down the Monolith into Microservices, from 2009 to 2011.
The customer-facing transition happened in 2010. Christmas that year was the deadline because of the expected usage surge. If the transition was not complete, the on-premise structure would not have the capacity to handle all requests.
In 2011, it was time to move the data source, backups, and system of records to the cloud.
It’s important to note the integration also involved a different mindset across all stakeholders. As they put it, “DevOps is a Re-Org”.
The benefits were huge: cost and size and risk of change reduced, plus the rate of change increased. In practical terms, the platform was able to minimize downtime even when popular services like Twitter were failing in 2009.
Netflix is one of the platforms that is happy to share its insights. Some highlights:
- Netflix Conductor: A microservices orchestrator
- How Netflix microservices tackle dataset pub-sub
- Seamlessly Swapping the API backend of the Netflix Android app
- The Netflix Cosmos Platform. Orchestrated Functions
We created the whole system for a client based on Netflix’s knowledge. They provide a lot of open source code, which is really valuable and speeds up development.
Marcin Kaletka, Team Leader @Kambu
3. eBay
In 2011, eCommerce stored 9 petabytes of data. The daily load included 75 billion database calls, 4 billion page views, and 250 billion search queries. The information comes from a presentation by the then director of engineering.
The company introduced Microservices that year. It was actually the third big shift.
From 1995 to 1998, it was a Monolith walled garden written in Perl and C++. In 2001, it was layered and rewritten in Java, with some APIs. In 2005, the third change: became organized in services in an internal cloud (still in Java).
The migration from Monolith to Microservices took place in 2011, with an effort to virtualize the infrastructure to create a global resource pool.
Some of the challenges it faced were differing data formats (SOAP, XML, JSON, NV, etc), the latency on big datasets, and low service consumer productivity.
The immense amount of data meant complexity was the major hurdle. To sum it up, 44 million lines of code, hundreds of thousands of classes, and tens of thousands of packages.
The solution came with Microservices, in a modular system with re-utilizable building blocks. Not only this helped to cope with the overall complexity of the code, but also different components had different levels of intricacy. As such, separate teams could adjust themselves to each component.
In 2019, eBay moved to RESTful APIs with semantic versioning in lieu of improperly versioned SOAP-based APIs.
The company also explained the benefits of having an Agile and nimble code base. It allowed the company to quickly and seamlessly deploy a dark mode across web and mobile platforms.
4. Uber
Uber is now global, but back in 2011, it started its operations in one city, with one product: San Francisco, UberBLACK. A single codebase concentrated all core business features: connecting drivers with riders, billing, and payments.
In 2015, the company noted that, as it was growing, the Monolith architecture quickly became a bottleneck for scalability and continuous integration. Every action, from adding features to fixing bugs, depended on a single repository.
More engineers meant more requests and a harder time working around simple changes.
Uber choice to leave the Monolith behind, acknowledging it followed the lead of Amazon, Netflix, SoundCloud, and Twitter.
The journey from Monolith to Microservices involved over 500 services, adoption of the Apache Thrift IDL, libraries built for service resilience, and much more.
The company explained the journey to a Service-Oriented architecture in the Uber blog.
Conclusion – Monolith to Microservices, and Then More
The technological journey of big company is always a fascinating read. Tackling the big numbers requires more than endurance. Often they had to come up with new technologies almost from scratch.
This article focused on the specific path from Monolith to Microservices, but this is one of the steps in big infrastructure updates. Companies big and small are more agile and tuned to refreshing their practices constantly.
Happily for us, many of these organizations are willing to share enticing backstage details. This way we can learn from the success – and failures – of others.
