Microservices architecture: from Netflix to APIs

Some years ago making a small change to a web application required a monolithic block containing all the source code of the app in question, often involving various corporate teams in the process, from quality control to sysadmins to marketing.

This approach - now traditionally called 'monolithic' - is still the most widespread in the field of web application development, but everything suggests that its days are numbered.

Starting with companies such as Netflix, one of the first to follow this path, in fact, a revolutionary process involving the entire IT sector has begun, with the deconstruction of the monolithic systems of web services in favour of so-called microservices.

But what are microservices? And why have the world's largest IT companies abandoned their native service structures in favour of microservices architecture?

Microservices: the Netflix case

Most companies used to design their web services according to a single - monolithic - structure that allows for quick set-up and easy deployment of the service. Such a system is still perfectly suited to the needs of small companies or some start-ups, whose core business is closely linked to the activation and deployment of ever new services and products.

As an IT system grows, however, the code increases in complexity, as do the maintenance and management activities of the monolith. Moreover, the more a monolithic system grows, the more its speed, agility and flexibility of services are affected - crucial aspects for any web-intensive business, such as an e-commerce or streaming service.

That's why the world's largest IT companies, starting with Netflix, are leading the momentous shift towards microservice architecture. The case of Netflix is illustrative: the company began the process of migrating all its services to the microservice cloud in 2009, completing the operation only in 2011.

Two years of work led Netflix to the development of more than 1,000 microservices and API Gateways that handle more than two billion requests from users on a daily basis. It is worth remembering here that Netflix is a company with over 200 million users worldwide, who according to the most recent statistics spend over 165 million hours - every day - 'consuming' the platform's content.

The Netflix case, besides being one of the first successful examples of the transition to the new architecture, is emblematic of the important relationship between the new form of services and the migration of content to cloud servers.

The key requirement underlying both processes is the scalability of services: Adrian Cockcroft, the Cloud Architect responsible for the epoch-making transition at Netflix, clearly explained how this became essential as the number of users of the service increased.

It was impossible, Cockcroft explains, to have enough physical space to store all the data of the new users of the service, which was effectively then scaling up to the size it is today.

The move to a cloud-based approach allowed, in parallel, the huge Netflix system to be broken down into the microservices mentioned above. But what are microservices, and why is the move to microservice architecture now essential for IT companies in terms of service scalability and deployment?

Scalability of services: microservices, n-tier model and APIs

In order to understand the horizon within which the increasingly pressing need to deal with software architecture arises, it is necessary to start from a now clear assumption: the spread of smartphones and other devices with web connectivity has revolutionised both user-side usage and the development needs of web applications.

Until a few years ago, a web app had to be able to interact with a single entity at a time, usually the web browser. Nowadays, people tend to access different services from very different devices in terms of usage and characteristics, which is why the speed and responsiveness of a web application is as important as the product itself.

The use of a software architecture based on the multi-tier, or n-tier, model, in which different functionalities correspond to different software layers, is now an established practice for developers. Since the beginning of the 2000s, three-tier services have been built, with the three tiers generally corresponding to the user interface, the processes themselves and data storage.

But the three-tier model was not designed for today's massive use of smartphones and IoT. The move to microservices architecture requires the addition of at least one more layer, which is why we increasingly hear the term four-tier or n-tier architecture.

The division of the application into layers is made possible by APIs (Application Programming Interfaces), small functional bricks that are independent of the programming language and that, exposed between one layer and another, allow real-time two-way communication between two layers, for example the database and the login interface of an app.

What are the four layers of such a system?

• Client: the first level still concerns the user interface, which can be changed even completely without interfering with the other three levels. In this way, it is possible to offer perfectly responsive services centred on a user experience of increasing quality;
• Delivery: the delivery level deals with optimising the "delivery" of contents and services on the basis of the information received from the user, from the power of the web connectivity to the specifications of the device involved in the exchange;
• Aggregation: the 'aggregation' layer is the one that connects, in real time, internal and external services and resources through APIs. For example, Netflix uses AWS (Amazon Web Services) for the cloud storage of its databases, which is why it is necessary for Amazon and Netflix services to be able to communicate efficiently.

Many of the apps on our smartphones today rely on external resources in real time as we use them, just like Netflix, which constantly uses Amazon services to distribute its content to millions of users worldwide.

• Services: the last layer in such an architecture is the one that provides the other layers with the data and functionality required by the application. The service tier acquires its meaning in the context of the application of a microservices architecture: it is a question of applying a sort of main engine, independent of the others, to those services that are essential for the distribution of the software, such as the login service or the card payment management service for any e-commerce.
  In a microservice architecture, in fact, each functionality has its own little engine, and any malfunctioning of a single service (e.g. the management of the user profile image of a site) will not involve the rest of the system.

This is the ultimate meaning of the deconstruction of a monolith like Netflix, and this is the inevitable step for any company that intends to 'scale up' its services beyond a certain threshold, so that the proportion between the number of operations and the effort of the system must necessarily jump to a new ratio.

The Netflix system as it was in 2011 - just before Cockcroft's move - needed about 100 developers to constantly maintain an increasingly large and complex monolith. At the time, it had just under 30 million users.

One wonders whether Netflix's exponential growth would have been physically possible without migrating the entire system to a cloud-based microservices structure.