A businessperson standing at a table in an office setting typing on a laptop with one hand while looking at a mobile phone in the other hand

Microservices and Microservices Architecture

Microservices are used to build cloud-based applications that are deployed in a distributed model. They are highly scalable and typically require less time and effort to build and maintain compared to a monolithic architecture.

Microservices Deploy Quickly in the Cloud

  • Microservices architecture is a design methodology for rapid deployment and updating of cloud-based applications.

  • Microservices typically operate independently, often in containers that are loosely coupled by a standard interface.

  • Benefits of microservices include speed of deployment, ease of upgrading, and support for increased scale and complexity.



What Are Microservices?

Microservices are lightweight, loosely coupled modules that can serve as the building blocks of complex cloud-based applications. While individual microservices may operate independently, they are loosely coupled under a unified interface.

Microservices architecture is considered to be a modern, flexible replacement for the more traditional development model of monolithic architecture.

In a monolithic architecture, there is usually one physical or virtualized server allocated to each application, and those servers are always running. Application scaling and availability are completely dependent on the underlying hardware, which is a fixed entity.

Microservices, by contrast, can operate multiple instances on a single server or across multiple servers as the resources scale dynamically to support the demands of the workload. Individual microservices are often containerized to improve portability and scalability.

The Different Characteristics of Microservices

As a development process, the microservices framework has certain characteristics that are common but not universal.

Those characteristics include:

  • Components. Microservices are typically composed of discrete software components that are individually replaceable and upgradable. This architecture has implications for cloud management technology because each of the microservices must be provisioned, monitored, and upgraded separately.
  • Services. The components comprise services that are available to communicate on demand but may not be active continuously between requests or calls.
  • Independent deployment. For the most part, the individual service components operate independently of one another within the microservices framework. If one component is changed or updated, there is little impact on other services and components, especially when compared to a more traditional monolithic architecture.
  • Security. Communication between microservices is often encrypted with mutual transport layer security (mTLS) to protect data from malware and intrusions while in transit.
  • Containerization. Microservices are often deployed in containers for additional portability and scalability.

Microservices architectures make applications easier to scale and faster to develop, enabling innovation and accelerating time to market for new features.

—Amazon Web Services (AWS)

Benefits of Microservices and Cloud Applications

Microservices continue to gain in popularity because of the architecture’s innate flexibility in the cloud. Indeed, a recent study conducted by Intel revealed that 83 percent of all new cloud-native applications and SaaS solutions are using microservices.1

One of the greatest benefits of microservices is the speed and flexibility of deployment. As cloud applications and workloads continue to grow in scale and scope, it is increasingly difficult and time consuming to adapt monolithic architectures to accommodate the new demands. Microservices are disaggregated, so their development, deployment, and maintenance can be managed in a distributed model.

For example, various independent development teams can be given responsibility for one or more of the microservices. The distribution of responsibility facilitates reorganization of the DevOps function according to each unit’s business capabilities. That can lead to modernization of the entire development process and elimination of silos.

Microservices also pose some deployment challenges. Individual modules may run on different systems to fulfill a request, which can cause performance to be inconsistent from one module to the next.

Likewise, latency can become an issue for some microservices, as when there are spikes in demand. These issues can often be resolved by overprovisioning resources to accommodate peak demand levels.

Because the microservices are disaggregated, a service failure that affects one module may cause little or no disruption to the others. That is a benefit, but a service failure can also lead to challenges.

For example, it can be difficult to debug a failed service after it has stopped running. One solution is to coordinate infrastructure and monitor all processes and dataflows in advance. Those monitoring protocols can take advantage of hardware-enabled telemetry collectors and performance monitoring units (PMUs) that are built into Intel® technology-based cloud platforms.

How Microservices Architecture Works

In a microservices architecture, a complex application is disaggregated into discrete capabilities that can be developed and operated independently. The individual microservices communicate with each other, often through APIs, and they are loosely connected, but each microservice can be developed, deployed, and updated separately.

Microservices deployment often follows one of three patterns:

  1. Cloud native. Some established, high-volume applications and services begin as microservices and remain in the cloud. According to International Data Corporation (IDC), about 56 percent of microservices are cloud native, while the remaining 44 percent originated as legacy applications.2
  2. Refactor and shift. These deployments begin on-premises or in a data center at the edge and are refactored to adapt to the cloud-based microservices architecture. Refactoring may include remapping databases and other resources associated with the monolithic architecture, so they are paired with corresponding microservices.
  3. Lift and shift. Some organizations migrate their applications to a microservices architecture, without refactoring, in a simple “lift and shift” transition.

Microservices and DevOps

The disaggregated nature of microservices architecture often leads DevOps teams to adopt a cross-functional approach to application development.

Instead of developing software applications in a stack, with one team assigned to work on firmware, another to middleware, and a third to user interfaces, for example, the microservices development effort is more likely to organize around business capabilities.

In a way, the development processes and the organization of DevOps teams can mimic the microservices structure itself, with its quasi-independent, self-contained units that interact loosely, transcending barriers and silos.

It is very important for all stakeholders to understand that modernizing a monolithic application into a microservices architecture is an epic journey and might take many iterations. It is necessary for architects and developers to closely evaluate various aspects of the monolith and come up with a migration approach for each of them.

Securing Microservices

Because microservices are often designed to interact with each other, it’s important to protect data while it is in use at each end of the interaction or in transit between those two points.

Encryption with mutual transport layer security (mTLS) is a common solution that helps reduce the risk of intrusion and malware for data at each endpoint and in transit. The goal of mTLS is to encrypt every request made by each microservice. Such a holistic approach to security forms the basis of a zero trust environment, where each microservice, user, and connection must be verified and authorized independently.

It's not always necessary to include the authentication and encryption in each individual microservice, however. To avoid redundancies, many developers deploy a service mesh instead. The mesh acts as an infrastructure layer or proxy instance within the microservices architecture to help secure, control, and monitor communications.

Security protocols may require significant computing power, which can tie up resources and slow the delivery of microservices. To accelerate encryption algorithms and help reduce latency, microservices developers can deploy Intel® Data Protection Technology (Intel® DPT).

Intel® DPT includes the Intel® Advanced Encryption Standard – New Instructions (Intel® AES-NI) and Intel® Secure Key Instructions, as well as the Intel® Digital Random Number Generator (Intel® DRNG) for rapid creation of encryption keys.

These advanced, algorithmic protections are optimized for the built-in security features of the Intel® Xeon® Scalable processors. For example, Intel® Advanced Vector Extensions 512 (Intel® AVX-512) and algorithmic innovations such as symmetric encryption, secure hashing, and function stitching offer significant performance improvements for cryptography.

These and other hardware-enabled security features are available from major cloud service providers in instances powered by the Intel® Xeon® Scalable processors.

Microservices Architecture Examples and Its Evolving Framework

As cloud applications continue to grow in scale and scope, developers rely increasingly on microservices to construct complex, multifunctional applications and scale them rapidly to accommodate changing usage models.

For every microservices-based deployment, there are typically multiple, loosely connected component services running separately. These modular components work together to create an integrated user experience or application.

In some microservices-based applications, where user experiences may be differentiated according to group characteristics, a benefit of using microservices is that code may be shared and reused. This approach eliminates the need to build and maintain multiple instances of the same service. If one of the differentiated experiences requires a customization, additional microservices can be incorporated.

For example, popular ridesharing applications are based on microservices, but drivers and passengers have differentiated user experiences. Driver management, location tracking, passenger profiles, and payment processing are among the disparate microservices that together support the user and driver interfaces on their respective mobile devices. All the interfaces share the same brand, but some of the functionality may be different for each group.

A microservices architecture is also a common environment for e-commerce stores. The product recommendation and checkout processes might be developed and deployed as individual microservices, but the shopper would experience both processes within the online store’s branded environment and interface.

When to Use Microservices

A microservices approach can help to migrate and scale applications by breaking the most complex solutions into their component parts. Each microservice is developed and deployed independently, and the various microservices operate together as a loosely integrated entity.

Organizations are most likely to use microservices when developing a new cloud-native solution. They may also deploy microservices when an existing monolithic architecture becomes too unwieldy to serve their changing needs.

The transition to a microservices architecture can lead to changes in the organization and structure of the DevOps teams themselves. Over time, teams may align with their new, cross-functional focus on business capabilities instead of silos that mimic the functional layers in the technology stack.


Frequently Asked Questions

Microservices are lightweight modules that can serve as the building blocks of complex cloud-based applications. While individual microservices may operate independently, they are loosely coupled under a unified interface.

Microservices can be deployed quickly and easily, relative to monolithic architectures. The microservices framework also scales readily to accommodate increasingly complex workloads and expanded usage models.