This is the story of three different companies. One a giant, started off by selling books online. The other started off by distributing DVDs. The third, makes reading books quicker for people short of time.
You have probably guessed the first two – Amazon and Netflix. You might have heard of the third one, Blinkist. It is a small startup that distills books, mostly non-fiction, to it’s core ideas so that you can read them in minutes.
The products that these companies produce are as different as can be. Their stories have different beginnings, turbulent middles. Despite the differences they have all converged to the same enlightened ending. Story time anyone ?
The Story of Amazon
In the early 2000’s the Amazon website ran as a large monolith, architecturally speaking. The frontend consisted of an Apache webserver that talked a backend database. This was called the Obidos and combined all of the the display logic, the business logic and all other functionality that Amazon supported.
Werner Vogels, the CTO of Amazon in one of his talks explained how they tried to scale this monolith as the load on Amazon grew. Initially they scaled the backend DB as much as they could. They then scaled the front-end until they reached a point where it couldn’t be scaled anymore.
In addition the monolith software lifecycle looked like this:
Rob Brigham, from Amazon, talks about how the speed of this cycle essentially determined the agility of the company and controlled the responsiveness of Amazon to it’s customer needs. As the codebase grew, the complexity grew and so too the time of the lifecycle. Everything from development to final release had to happen in lockstep coordination between a large number of developers and several other teams. These teams supported them in various activites – from regression testing, building, to releasing the software. This lengthened the lifecycle considerably and the same process was followed irrespective of the size of the code change. Developers time was not being put to productive use after the development phase was done. They had to wait for the latter parts of the lifecycle to complete.
So in 2001, Amazon decided to make a change to their architecute to fix all the problems they were having. They converged on using SOA as a way to re-architect and fix the issues. Thus began their effort to break down the monolith into independent services. This eventually evolved into the Microservices architecture that Amazon uses in all of it’s products today. They haven’t looked back.
The Story of Netflix
About a decade ago Netflix was operating a monolithic architecture that looked like this:
They had major problems scaling to demand especially around the holiday season. As the number of subscribers grew it could not scale it’s data centers fast enough. The types of devices that it needed to support also increased adding to the complexity. Another story has it that a single missing semicolon brought down the entire Netflix site for several hours. These were the main factors that pushed Netflix to move to the cloud completely and split the monolith into independent services and adopt the microservices architecture. They haven’t looked back either. As of 2017, Netflix served media to about 109 million people worldwide successfully.
The Story of Blinkist
Blinkist starting from the year 2012 to 2015 had a simple monolithic architecture that looked like this:
It served the initial purpose it was intended for. To validate the idea and the product in the market. As it inevitably happens with any growing company, new features and new growth came in (which is indeed a very good thing for a startup). Much to their dismay, the monolithic architecture slowed down the development cycle and could not easily scale. Given that their services had high coupling and the use of a shared database, it was not a patchable issue. They took the prudent route of solving these issues with a microservices architecture. Blinkist is growing it’s customer base successfully and scaling well to handle the growth with the new architecture.
A common theme emerges from these stories. They all started as monoliths and eventually were faced with issues that could no longer be fixed easily. They had to solve problems of delivering software with speed and scale with safety. As they were looking into solving these issues, only then did they organically arrive at the microservices architecture as a potential solution. They gradually evolved into it in phases. Almost all of them continued to use their monolith while extracting services that adhered to the ‘Single Responsibilty Principle’. Amazon and Netflix are probably all microservices at this point. There are also companies that use a hybrid approach successfully – some parts are monolith and some microservices.
From these experiences it almost looks like going first from a monolith to a microservices architecture is a rite of passage for success even for companies starting with a clean slate. However if you follow the Bounded Context pattern and the Domain Driven Design paradigm (More on this in another post), then it is possible to start with a microservices architecture and keep refining it as your product evolves.
I could continue to write about the companies that have adopted microservices until the cows come home. As Phil Calcado of SoundCloud said in 2015 that MicroServices are a thing, they still very much seem to be. So I’ll just mention a few major ones and you can read up their stories if interested – Gilt, Walmart, AirBnb, Nike, Spotify and SoundCloud.
As a final thought, these stories affirm what I was referring to in my first post and second post when I said that this architectural style is backed with empirical data and hence behooves every enterprise architect to evaluate it’s applicability and fit for their domain.