Microservices and Digital Transformation – a Microservices Primer

We will then take a quick look at several globally recognized leaders who have benefited from migration to microservices and the various business problems it helped solve.

What Are Microservices?

Amazon defines a microservice as:

Microservices are an architectural and organizational approach to software development where software is composed of small independent services that communicate over well-defined APIs. These services are owned by small, self-contained teams. Microservices architectures make applications easier to scale and faster to develop, enabling innovation and accelerating time-to-market for new features.

Monolithic vs. Microservices Architecture

Microservices can be written in almost any current popular programming language. Still, some languages are better suited than others for this purpose. In September 2022, Camunda identified the top seven languages used when writing microservice. These are:

• Java
• C#
• Go
• TypeScript
• Python
• Haskell
• Ballerina.

These seven languages were selected based on their popularity according to PYPL criteria, suitability for use, and for being best in a particular class (like Haskell among functional languages).

As each microservice is, by design, a self-contained entity, users can choose the database type that best fits their data persistence needs. A traditional relational database, a NoSQL database, or even a graph database are all valid choices based on the data being used.

This definition and technical parameters give us a great academic answer and also identify many key elements of a microservice. But what is the place of microservices, among other approaches, and what are their unique features?

Does a Microservice Have Any Specific Characteristics?

Sometimes it may be a little tricky to identify a microservice, but in general, all microservices have the following characteristics:

• They are “single task-oriented”: they perform a single task and do it exceptionally well.
• They are totally “self-contained”: each microservice manages its own data, having its own data models, queries, and read/write patterns. Two microservices should not share the same data store. Instead, each one may have its own private data store that cannot be accessed by other microservices. A microservice interacts with consumers through a structured API interface (in most cases HTTP REST).
• They are “owned by the team”: typically, a single team of 2-8 (developers and product owners) manage a microservice through its entire lifecycle. It gives the team complete autonomy to modify and deploy their microservice as they release new features and deploy them as needed without having to rebuild the entire code base or coordinate with any other teams or departments. It allows teams to be more agile and willingly accept ownership of the code base.
• They can have “multiple versions”: it is common to have multiple versions of the same microservice in the same environment as features are being added. It also allows the microservice to evolve over time without “breaking the client.”
• They are “eventually consistent”: data exchange/sharing across multiple microservices is done in a distributed fashion (i.e., a subscribe/publish pattern) where each consumer defines and controls their own inputs and outputs. A single, complete top-down synchronized data flow across all services does not exist. This results in eventual consistency.

6 Differences to Consider When Comparing Microservices and a Service-Oriented Architecture (SOA)

Simply put, Microservices and SOAs differ primarily in their scope. A service-oriented architecture (SOA) has an enterprise scope, while a microservices architecture has an application scope.

SOA vs Microservices

Source

As a quick summary, the key differences are: 

• Communication: In a microservices architecture, each service is developed independently using both a data exchange protocol and data storage mechanism that best fits its needs. In SOA, each component or service must share the same communication mechanism, commonly referred to as an enterprise service bus (ESB).
• Messaging: Microservices are usually built with lightweight communication protocols like HTTP/REST (Representational State Transfers). SOAs utilize more heterogeneous communication protocols like SOAP (Simple Object Access Protocol), AMQP (Advanced Messaging Queuing Protocol), and MSMQ (Microsoft Messaging Queuing).
• Size: Microservices are directly designed to perform one specific feature very well. On the contrary, the services in SOAs can range in size, from small particular features to enterprise-wide services.
• Speed: With sharing common architecture, SOAs streamline development and troubleshooting processes. However, SOAs operate slower compared to microservices architectures.
• Agility: The “stand-alone” nature of microservices allows them to be modified and then deployed quickly. Organizations no longer need to perform long and expensive full-scale system testing when making even small changes.
• Storage: SOA architecture typically implements a single data storage layer that must be shared and accessible to all services within a given application. Due to their independent nature, microservices can implement the data persistence layer that best fits their operational or data format needs (SQL, NoSQL, Graph, etc.) There is no longer any requirement for all microservices within a specific application to “do the same thing in the same way”.

What Differs Microservices from an ESB?

An Enterprise Service Bus (ESB) is seen as a microservice’s ‘anti-pattern’. ESB is an integrated approach that uses a centralized software component (aka Bus) to provide a single integration point between the various applications. It allows each application to share data and communicate via a common endpoint. ESB was seen as an attractive approach since it provided a standardized way for application integration and no longer required organizations to build custom point-to-point integrations for each application. ESBs are the communication backbone that makes SOAs possible.

Both approaches, microservices and ESB, have their own use cases, benefits, and limitations. The microservices architecture cannot completely replace ESB. For instance, an ESB can connect smaller, specialized web services to legacy, enterprise-wide services and apps. It is the best solution for integrating old on-premises systems with SaaS products and other cloud-based solutions. The downside is that applications are more tightly coupled, and the ESB is a single point of failure for all the applications that share the same ESB. Large, more diverse environments choose an ESB solution, while smaller environments, including mobile and web applications, prefer microservices architecture.

How Microservices and APIs Interact?

Microservices typically use an API to interact with the outside world, but microservices can also be “headless“. For example, microservices can be designed to perform some data transfer tasks in the background, system maintenance, or be a step in a workflow. When an API is created as part of microservices, it specifies the contract for interactions with the microservice and presents the functionality for interacting with the microservice.

Microservices can have APIs but not all APIs are microservices.

Which Companies Have Migrated to Microservices?

IMARC Group reports that the global market of microservices architecture reached $2.76 billion in 2021. The expected market growth is $6.84 billion by 2027, at a CAGR of $15.7%. One of the key market drivers is the growing need for digital transformation to meet business requirements. According to the 2022 Service Mesh Adoption Survey, 85% of companies are modernizing their applications to microservices architecture.

Top Enterprise Applications Using Microservices

Source

The need for agility, scalability, and resiliency have become ever more important, and organizations address these challenges by migrating their current monolithic applications to microservices. Here are a few success stories of global giants that have already reaped the benefits from such migration.

1. Amazon

Amazon was initially a big application with monolithic infrastructure with tight dependencies which caused problems when developers needed to scale up and upgrade the system with new functionalities. According to Rob Brigham, a senior product developer at Amazon in 2000s, the situation was critical for further product growth.

Started as a local online bookstore, Amazon developed into the largest global marketplace, selling all types of consumer goods. While being a two-tier monolithic application, the product faced various bottlenecks during that transformation. For example, the team experienced problems with managing growing volumes of data, time-consuming deployments with high risks of downtimes when implementing new functionalities, and many more. Amazon’s architects came to the decision to shift to microservices architecture in order to address the emerging issues.

At first, the app was broken down into small code parts, each one fulfilling specific functionalities like ‘Buy’ option in the tax calculator. Each code chunk was wrapped into a web interface. All app fragments were integrated into a larger system with the help of APIs that allowed interconnections and communication between them. Every feature got a dedicated team of developers for maintenance and improvements.

Such transformation to microservices helped Amazon improve the development processes and consistently grow with the new features, product categories, and tiers. After the initial transformation, Amazon Web Services (AWS) emerged. Hosting microservices architecture in the cloud environment allowed to automate the operational processes and effectively scale up the services according to the growing traffic loads.

The shift to microservices at the beginning of 2000s laid the groundwork for the continuous delivery approach Amazon uses today for faster development and flexible deployment. It also enhanced the scalability of Amazon’s technical infrastructure and led it to becoming one of the most rapidly growing businesses in the world. The latest report from Synergy Research Group also shows that Amazon leads the market of cloud infrastructure services, owning 34% of global market share.

2. Netflix

One of the world’s leading streaming sites was also among the pioneers of adopting the microservice architecture. At the moment it launched the movie streaming service in 2007, Netflix simply became unable to satisfy the growing data loads. High demand for watching movies online even led their legacy DVD-shipping service to 3-days collapse in 2008.

Before this failure, Netflix used one massive database to locate all of its data. Relying on a relational database, a vertically scaled single point of failure, made Netflix far too vulnerable to breakages and data corruption. Netflix engineers decided to migrate to microservice-based systems in the AWS cloud.

Netflix started this transition in 2009. Their first step was migrating all non-customer-facing services and code to the AWS Cloud.

Netflix Deploy on AWS

Source

The entire Netflix app was broken into more than 700 microservices, each one responsible for a specific feature. This transition allowed engineers to make changes where necessary, ensuring no downtime for the entire system, as any issue inside one particular microservice does not affect others.

A microservices architecture allowed them to scale certain services upon their growth needs independently. The speed and agility of development also have been significantly improved. In the fourth quarter of 2022, Netflix had around 231 million paid subscribers globally, that is 8 million subscribers more compared to the previous quarter.

Number of Netflix Paid Subscribers Worldwide

Source

Overall, the microservices architecture provides the required technical capabilities to support the constant growth of loads without affecting the quality of service.

3. Uber

Uber began as a startup that offered only connecting drivers and riders and paying for the rides in San Francisco. It was a monolithic app that completely met all the business requirements of its owners. Riders were connected to Uber’s monolithic system through a REST API. Initially, the system consisted of three adapters for primary functions: text messaging, billing, and payment. All the data was stored in the MySQL database.

Soon Uber began to expand to other cities, introducing new perks, and the application itself started to grow intensively. As a result, its monolithic system could not cover all the requirements anymore. The team could not fix bugs effectively when they appeared, add new features, and extend their market presence in new regions. The app structure became too complex and challenging for maintenance. The tight and overcomplicated dependencies between the application components made every single change extremely time- and resource-consuming.

Moving to microservices architecture helped dedicated development teams focus on specific features. There are over 500 services written in different programming languages, and each one is structured in its own way. Uber engineers implemented Apache Thrift as a binary communication protocol to simplify the services management and unite them into one system. Within the newly adopted architecture, all users access the application through the API gateway. The inner points (microservices) are connected through the REST APIs to exchange data.

Uber Microservice-Based Architecture

Source

This transformation led into the significantly faster implementation of new features, at higher quality and ease of development. It also allowed Uber to develop individual components without affecting the rest of the system, making the network more resilient.

Summary

In this article, I have tried to give you a better understanding of what microservices are and what they are not. We looked at some specific case studies by recognized companies to see how they benefited from microservices architecture and how it changed their businesses. Being cloud-native, microservices allow for the ultimate project scalability and flexibility for future growth. That is why more and more companies migrate their applications to microservices, as numerous surveys confirm.

Infopulse engineers help enterprises with IT architecture modernization or separate software product upgrades using microservices without any business disruptions. We also help build new software solutions utilizing microservices to lay the basis for future growth and scalability.

In our next article, we will take a much closer look at what business leaders need to know about microservices, market position, microservices adoption, benefits, and ROI.

Stay tuned…