The best developers are always constantly reading about state-of-the-art technologies, systems and designs that they can use and incorporate into their own projects. But software architecture is never one-size-fits-all.

The Rise of Microservices at Netflix

Companies like Netflix helped generate a boom in microservice development as they contributed open-source libraries, documentation and blog posts about their infrastructure. The advantages of their approach with microservices included the ability to iterate on smaller pieces of code at a time, add domain boundaries to distinct areas of a system, and distribute work between specialised teams in a more controlled way.

Over the last decade, it has been widespread for organisations of all sizes to adopt this microservice-driven approach to development, in part due to the success of companies like Netflix.

However, a critical difference between Netflix and most other organisations is the sheer size - Netflix has a disproportionate throughput of traffic across the entirety of the internet as it streams videos to hundreds of millions of subscribers every month. With this in mind, it makes sense that Netflix would put in an extraordinary effort to engineer state-of-the-art tools and processes to deploy and manage their services across all regions of the globe.

Looking back, though, they had more humble beginnings with a monolithic architecture, as shown in the following diagram from the Netflix Tech Blog:

This image shows a progression through the Netflix API architecture stages from a monolith application to hundreds of microservices fronted by various federated gateways.

In the beginning, they had one extensive system that handled all of their business needs, from subscriptions to streaming to recommendations. However, as they have grown, each area has become significantly more complex, especially with the rise in machine-learning algorithms and personalised content. Therefore, the engineering teams have split up their domain into multiple, smaller domains so that each part can grow more organically with the company.

Nothing comes for free, though, as this increased complexity results in one action from a user generating dozens of internal requests and additional networking load:

Remote calls are never free; they impose extra latency, increase the probability of an error, and consume network bandwidth.
- Netflix Tech Blog

The overhead of managing multiple microservices cannot be ignored in terms of applying distributed transactions, handling networking failures, and reviewing distributed traces, among other requirements.

Instead, I'd like to focus on the very first iteration of the Netflix platform - a platform that worked and was simple. The monolithic approach may have been clunky and not ready for massive growth, but it was arguably necessary to get them to a state where growth was possible.

The Benefits of the Monolith

The monolithic application is typically one extensive application that does everything required for a business without separating business functions into isolated services. For example, this type of application might handle the entire booking system, invoicing system, user management system and reporting system for a small-to-medium-sized organisation.

From an organisational perspective, it's much more likely that a single developer will be able to reliably take on the responsibility of developing a single but large application compared to a plethora of interconnected services. Especially for a new business, time-to-market and initial costs can be the difference between success and liquidation.

This approach eliminates the engineering nightmare of managing distributed systems and all of the incumbent challenges from a technical perspective. The trade-off is to have one relatively larger codebase, though.

Keep it Simple

You will likely see the requirement to understand and develop microservices in many current job advertisements in the tech space. However, the role of an engineering team (and a Software Architect in particular) is to ensure they generate business value through an appropriate system design.

Microservices can be great, just like another technology or pattern, but all of this must be evaluated as part of a larger context. Believing that one way of working is inherently better than another is naive.

Our recommendation for any software architect is to study the organisation - its requirements, size, and vision - before making any recommendations as to the platform's design. Sometimes the best approach is uninteresting to developers, simplistic to management, or simply considered old-fashioned - yet tried and tested.

You can always follow the path of Netflix and grow your systems over ten years as your business becomes successful.