We admit, this headline is a little clickbait; Amazon is still heavily dependent on micro-services, both for its own architecture and as a beneficiary of their adoption in industry. However, a recent case study by the Amazon Video Team – touting a 90% reduction in costs as a result of moving to a monolith architecture – has caused tremors in the developer community, as a blow to what some consider to be the overhype of micro-services.
In this article we’ll discuss the recent transition by the Amazon video team, and the potential ramifications of this change. First, let’s set the scene a little.
A monolith is an application developed, deployed and scaled as a single component. Amazon in its early days had a very tightly coupled architecture, so much so, it could be considered to be pseudo-monolith.
Amazon experienced significant growth during the dot-com boom of the early 2000s, which brought with it a host of challenges associated with scalability, including the task of reconciling a vast number of changes from hundreds of developers. Working in large development teams on monolithic applications can be quite painful – the code base soon becomes bloated, and if changes have to be merged, this necessitates the rebuilding and retesting of the entire code base, which causes a lot of overhead to delivery pipelines.
As a result, an approach was developed on the basis of decoupling functional units, splitting them into different components which looked after different things. Each component or ‘micro-service’ has its own version control, released and updated independently from one another, as well as their own database and infrastructure, communicable via APIs.
Discretising an application into a series of sub-applications is akin to building a process map; you can identify the ripple effect of changes in your development pipeline, and Amazon found there to be some severe inefficiencies. However, it also incurs potential expense in and of itself, due to latency between API calls.
One of the main challenges of micro-services is their complex interdependencies, which creates difficulty in running them locally for development purposes. This necessitates either the development of mock implementations of dependent micro-services, which allows for the simulation of interactions between services, or the use of multi-containerisation of micro-services and their dependencies, via tools like Docker, which enables the replication of the production environment.
This shift toward micro-services, and the subsequent challenges faced led to the creation of many of Amazon’s solutions which support micro-service architecture. For example, mocking up endpoints is a functionality of AWS Lambda, and indeed, this was a tool utilised (and therefore called into question) within the micro-service distribution for Amazon Video.
Hence why the act of admitting to their infallibility is particularly brave.
This shift toward micro-services, and the subsequent challenges faced led to the creation of many of Amazon’s solutions which support micro-service architecture. For example, mocking up endpoints is a functionality of AWS Lambda, and indeed, this was a tool utilised (and therefore called into question) within the micro-service distribution for Amazon Video. Hence why the act of admitting to their infallibility is particularly brave.
Now, what was behind video team’s decision to move away from micro-services?
Essentially, a tool was developed by the Amazon Video team for the purposes of video quality analysis, whereby customer streams were monitored to identify issues and trigger processes for their resolution. Initially, this was run via a series of distributed micro-services, however this was found to be expensive to run at scale, and a number of bottlenecks occurred.
A decision was therefore made to consolidate the distributed services into a monolith application, leading to greatly improved cost efficiency and scalability for Prime Video’s live stream monitoring service.
Marcin Kolny, the author of the study – perhaps unsurprisingly – was quick to highlight that this is a special use case, but it’s difficult to not see the obvious bias inherent in that declaration, prompting speculation among the developer community as to how narrowly this applies to the specific use case, or whether or not it can be inferred as a chink in the armour of micro-services and their purported benefits.
The reason there’s such lively debate is because the answer is nuanced; every decision relating to software architecture is complex and highly dependent on the use case.
However, historically there has perhaps been a bias toward the automatic adoption of micro-service architecture.
Micro-services are often assumed to be the default choice. Adopting micro-services prevents cascading failures, allows the developers to use a wide range of tools and increases the resilience of infrastructures. There are endless articles that belittle monoliths and promote the use of micro-services. The latter are touted as the holy grail of software architecture, but there are many examples where this is not the case.
It makes sense for small-scale or simple applications to exist as singular centralised entities in the form of monoliths so as not to introduce undue complexity. Plus, distributed components incur a sharp increase in expense which makes no sense to a nascent company to incur. They also introduce complexity; complex communication between sub-services can quickly cause severe latency and expense, and data-consistency across services and the databases they rely upon is a significant challenge.
Amazon is an industry giant openly admitting that monoliths are in some cases preferred. Whilst this may be considered by some to be an admittance of failure, in any case, this admittance may pave the way for the emergence of more and more use cases wherein monoliths are found to be preferential. Perhaps now more nuance will be integrated into the debate, and more attention paid to the different ways to track and analyse service performance of software architectures.
—
Looking for your next hire in data/software? Let’s discuss how we could help you.