Most of this article comes from a Digital Dessert (how we use to call some tech discussion/presentation in my current company) that I’ve prepared with my former dev team. The most inspiring starting point was a 2014 article from Martin Fowler.
“If you go back to 2001, the Amazon.com retail website was a large architectural monolith”. This quote is from Rob Brigham, Amazon AWS senior manager for product management.
What’s the point? In general, Enterprise Applications are built in three parts:
- a database (consisting of many tables usually in a relational database management system),
- a client-side user interface (consisting of HTML pages and/or JavaScript running in a browser), and
- a server-side application. This server-side application will
- handle HTTP requests,
- execute some domain-specific logic,
- retrieve and update data from the database,
- and populate the HTML views to be sent to the browser.
It is a monolith – a single logical executable. To make any alterations to the system, a developer must build and deploy an updated version of the server-side application.
It was probably what Amazon needed in 2001.
Now, have a look at the current Amazon Death Star-like architecture
Let’s take another famous example: Netflix is one of the earliest adopters of microservices, and one of the most discussed.
The story of Netflix turning towards microservices starts in 2009, when this approach wasn’t known at all.
They set up their microservice architecture on AWS.
Their transition process progressed in steps:
- first they moved movie encoding and other non-customer facing applications.
- Then they decoupled customer facing elements, like account sign ups, movie selection, device selection and configuration.
Netflix needed 2 years to split their monolith into microservices, and in 2011 announced end of redesigning their structure and organizing it using microservice architecture. Today, the Netflix application leverages 500+ microservices and API Gateways that handles over 2 billion API edge requests daily.
Which kind of team capability is required to achieve this kind of architecture? Of course, not a bunch of siloed functional team, that would lead to a siloed architecture per definition.
The microservice approach to division is different, splitting up into services organized around business capability.
Such services take a broad-stack implementation of software for that business area, including
- user-interface,
- persistant storage,
- and any external collaborations.
Consequently the teams are cross-functional, including the full range of skills required for the development:
- user-experience,
- database, and
- project management.
Now the question is: do we need a microservice architecture to avoid:
- Many many dependencies (no developer understands the entirety of the application)
- Lack of independent scalability
- Limitations on technology, discouraging “the right tool for the job”
?
Not necessarily, sometimes a trade off becomes a mandatory step along the way to a better structured architecture.
It is very common, for example, for a big retail company that requires largely scalable features to be initially supported by a monolithical platform (usually some all-in-one e-commerce).
Starting with a monolith usually means:
- Get the show on the road…
- Avoid the upfront cost of many services…
- Identify modularity and what are the parts that really change more quickly than others…
- Understand where the cost of change is high…
But then things evolve and, let’s say after years, it becomes necessary to modernize the entire digital infrastructure, adopting a pattern such as the strangler architectural one: the architecture is progressively being split into middle-sized services interconnected to form a single application or platform. Essentially a monolith and microservice hybrid which follows business needs along the way.
N
