GoldenGolden
Microservice

Microservice

Microservice, or microservices architecture, is a variant of the service-oriented architecture that arranges an application as a collection of loosely coupled services. In this architecture, services are fine-grained and the protocols are lightweight.

Microservice (also known as microservices architecture) is a type of software that allows for applications to be built and maintained using smaller components that work together. It is related to service-oriented architecture (SOA) and enables applications to be scalable. The components are separately maintained, so they can be developed independently. If an issue should arise, it is isolated in that singular component rather than affecting the entire application.

The software is being used by companies such as Netflix, Spotify, ASOS, and Expedia.

Architecture
Visualization of a microservice architecture.

Applications used within microservices architecture have core functions which are known as "services." Services include search engines, product recommendations when using e-commerce, authentications, notifications, and online carts. Each of the services has its own codebase, infrastructure, and database. In order for the services to function together, they communicate through application programming interfaces (APIs) or messaging queues.

It is common for microservices architectures to be adopted for cloud-native applications, serverless computing, and applications using lightweight container deployments. In the deployment, and because of the large numbers of services, decentralized continuous delivery and DevOps with holistic service monitoring are often necessary to develop, maintain, and operate applications.

In microservice applications, independent services prefer to reuse code and accept data duplication in order to improve decoupling. The services do not want dependencies in the application running and accepting the resultant data duplication. This data duplication can increase a service's complexity, but it also results in benefits in agility and performance in a service and in the larger application. Communication and synchronous calls can introduce real-time dependencies which may result in a loss of resilience in microservice applications. These calls can also cause latency.

Key characteristics

Characteristic
Description

Decentralized

Since microservices involve a variety of technologies and platforms, decentralized governance and decentralized data management is favored; each service usually manages its own unique database.

Evolutionary

Microservices enable evolutionary design and an evolutionary system where unforeseen requirements can be addressed overtime without significant redeployment.

Failure resistant

Microservices architecture is designed to cope with failure, in which a single service's failure will impact an application's functioning without stopping the application from working; these failures can be mitigated through monitoring individual services, which is more complicated than in a monolithic systems architecture.

Multiple components

Each service can be tweaked and redeployed without compromising application integrity. This can increase complexity when redistributing responsibilities.

Simple routing

Microservices act like the classical UNIX system: they receive requests, process them, and generate a response. Microservices essentially have endpoints that process information and pipes through which the information flows.

Microservices communication

In a decentralized environment, where each service is independent and serves a single or limited purpose, communication amongst the services becomes crucial to the overall operation of an application. And, with the proliferation of services, the call and response between services add latency. To deal with this, most microservices architectures work to keep calls to a minimum, optimizing code to reduce communications. It is generally considered best for microservice communication if the back-end system uses asynchronous, message-brokered approaches to communication. While front-end can benefit from synchronous communication and a synchronous communication system for the front-end to back-end communication. Although, with increased complexity in the microservice architecture, asynchronous communication is considered to work best.

Communication protocols and methods

Protocol or method
Description

AMQP

For users wanting strictly asynchronous communication, they can use the advanced message queuing protocol (AMQP). This is a lightweight service—similar to SOA but less complex. Unlike HTTP, AMQP provides a message broker which acts as an intermediary between individual microservices and avoids the problems associated with brokerless services. However, the use of a broker introduces extra steps and adds latency.

Asynchronous

The other basic form of microservice communication, asynchronous communication works to solve the dependency problem of synchronous communication through handling each call to other services separately and without waiting on responses from downstream services.

HTTP

HTTP is a common, inter-microservice communication protocol often used for synchronous communication. HTTP's brokerless approach facilitates direct transactions between all microservices and provides simple communications which can cause unwanted dependencies. Often HTTP is only used as a primary protocol between a user interface and the highest level of services.

Multiple-receiver model

The multiple-receiver model is based on a publish-and-subscribe approach. The requesting service transmits a call to any other services that may provide a response. The messages are queued and managed on a first-come, first-serve basis. The approach provides service availability, optimizes response time, and provides more resources as required.

REST

Introducing REST to HTTP can help handle request/response communication asynchronously. REST is usually used to complement the HTTP protocol, and there is a lot of standardization between the two.

Single-receiver model

Part of how services connect and react to calls, a single-receiver model creates a message-based request that connects a single contacting service with a single responding service, and thereby facilitating a direct, one-to-one response. This optimizes response times, but does not protect against cascading failure, with the requesting microservice unaware a failure has occurred.

Synchronous

One of the two basic forms of microservice communication, synchronous communication calls create a chain of dependencies through downstream services, such that a service waiting on an associated service can fail to give a response in the case those services are unavailable.

Enabling technologies and tools
Containers

Containers offer a place for microservices architecture to be housed and are closely associated with microservices. Due to the lack of an operating system and the container being smaller and lighter than a traditional virtual machine, the container can spin up and down more quickly and offer an attractive place for the smaller services in a microservices architecture. It is possible to build microservices without using containers, which tends to increase development and testing.

API gateways

Microservices often communicate through APIs. Though services can communicate directly in some cases, API gateways are often used as an intermediary layer, especially as the application grows. An API can also act as a proxy by routing requests and dispersing requests amongst various services. The API can offer additional security and authentication to the application.

Example of an API gateway in microservice architecture.
Messaging and event streaming

Along with APIs and API calls, which help services establish state and be aware of state, messaging and event streaming can broadcast changes to state and allow other interested services to listen for those changes and adjust accordingly. Combining microservices with event-driven architecture can help build distributed, scalable, fault-tolerant, and extensible systems.

Serverless

Serverless architectures take some of the cloud and microservice patterns to a logical conclusion. In the case of serverless architectures, a unit of execution is not a small service, but a function, and often a few lines of code. The line which separates serverless functions from microservice is blurry, but functions are often understood as smaller than a microservice.

Microservice compared to monolithic
Comparison of monolithic database approach compared to microservices database approach.

This architecture differs from a monolithic software architecture, in which an application is built as a single unit. These applications are often built in three main parts: a client-side user interface, a database, and a server-side application. This server-side application is a monolith, a single logical executable, and any changes to the system involve building and deploying a new version of the server-side of the application. Frustrations from the difficulty in change cycles and scaling for monolithic applications have led to microservices architecture.

Moving from monolithic to microservices

In the case of an organization which chooses to migrate from a monolithic architecture to microservices, there is a process of decomposition and incremental change patterns to move towards a microservices architecture. This is done by recognizing the key components and logical models in the existing monolithic architecture. These domain boundaries, often called bounded contexts, are the units of decomposition. In understanding these individual components, there is also a need to understand how the unique pieces function and their dependencies. From these understandings and bounded contexts, the individual services of the microservices architecture can be built.

Microservice compared to service-oriented

While the microservices architecture is related to service-oriented architecture (SOA), it also differs in a few ways. One difference is communication protocols: for microservices architecture, each service is developed with its own communication protocol; for SOA, each service must share a common communication mechanism called an enterprise service bus (ESB). The ESB can become a point of failure for SOA architectures and sow an entire application. SOAs, through their use of common architecture throughout the services, offer simplified development and troubleshooting. However, these services also tend to operate slower than microservices architectures, which favor duplication over sharing.

Benefits

There are key benefits to the microservices architecture. Each smaller service is independent, which allows an application to continue functioning in the case of a fault in a single service. And again, with the services being separate, the task of fixing any faults or updating any parts of the whole application is done easier and with less interruption to the whole application. Each component service is also capable of being built on individual technology stacks best suited for the required functionality, rather than the standardized approach taken in monolithic applications.

Further, with code updates being easier, components of the whole microservices architecture can be scaled independent of one another, which can reduce the overall cost associated with having to scale entire applications due to a single feature facing too much load. Microservices architecture also allows developers to code for different services in different languages, and offers easier integrations and deployments.

Challenges

With the benefits, there are also challenges to microservices architecture. With the distributed deployment, testing can be complicated. This increases with the number of services, which can also lead to information barriers. And, with size, the role of developers increases as they work to mitigate fault tolerance, network latency, and the variety of message formats and load balancing. Integration and management of services can be difficult, especially with a proliferation of programming languages. As well, in use cases where more services without distributed transactions can require increased communication and cooperation amongst service development teams.

In a microservices environment, changing responsibilities between services is more difficult, can include rewriting the functionality in another language, or involve fitting it into a different infrastructure. This can be made more difficult when services are built with different tools and technologies. Some of the resulting complexity of a microservices architecture can be translated into operational complexity, including an increase in network traffic that can result in slower performance. Also, the larger the overall application architecture, the greater the number of interface points to access a respective ecosystem. The architectural complexities can be mitigated with the use of an organizing principle in the microservice.

Companies

Timeline

February 4, 2021
commercetools and Modyo combine microservices and micro frontends to help clients create more flexible omnichannel E-commerce solutions
February 3, 2021
Vermiculus unveils microservice-based clearing system with AI capabilities
January 29, 2021
Microservices create payments products and solutions
January 25, 2021
Survey shows microservices prefer key-value, NoSQL databases
January 19, 2021
OWIT Global announces new version of user experience microservice
November 20, 2020
Spotify scales its infrastructure with thousands of microservices, open source, and a "fail faster" approach
November 9, 2020
Global Microservices Architecture market expected to reach $8.07 billion in revenue by 2026, says Allied Market Research
October 12, 2020
Akamai announced it is adding the ability to deploy microservices on its edge computing platform to enable developers to run latency-sensitive applications.
July 17, 2020
Microservice architecture growing in popularity and adopters report enjoying success
2020
2020 led to a rise in global microservices adoption, reports show.

People

Name
Role
LinkedIn

Further reading

Title
Author
Link
Type
Date

Benefits of Deploying Artificial Intelligence Models as Microservices

Naveen Joshi

Web

September 3, 2020

Follow Microservices on Index.co

Web

How the Edge Improves Microservices - Security Boulevard

Web

December 22, 2020

How to explain microservices in plain English

Kevin Casey

Web

August 16, 2017

It's a Great Time to Transition to Microservices Architecture - DevPro Journal

Jay McCall

Web

April 2, 2020

Microservice Trade-Offs

Martin Fowler

Web

July 1, 2015

Microservices

Web

October 23, 2019

Microservices

Martin Fowler; James Lewis

Web

March 24, 2014

Microservices Architecture Market Outlook 2021: Big Things are Happening | Tata Consultancy Services Limited, IBM Corporation, Microsoft Corporation - KSU | The Sentinel Newspaper

Web

February 12, 2021

Microservices Tutorial: What is, Architecture and Example

Web

January 28, 2021

Microservices: What They Are and How They Work

Lee Atchison

Web

August 22, 2018

Migrating Monoliths to Microservices With Decomposition and Incremental Changes

Sam Newman, Leandro Guimarães

Web

February 9, 2021

The What, Why, and How of a Microservices Architecture

Hashmap

Web

June 7, 2018

What are microservices?

Web

What are Microservices? Code Examples, Tutorials & More

Alexandra Altvater

Web

September 13, 2019

What are microservices? The pros, cons, and how they work

Web

October 9, 2018

Documentaries, videos and podcasts

Title
Date
Link

What are microservices really all about? - Microservices Basics Tutorial

December 31, 2018

What Are Microservices?

August 27, 2018

What are Microservices?

February 26, 2019

What are microservices?

January 24, 2018

Companies

Company
CEO
Location
Products/Services

References

Page 1 of 3
Golden logo
Text is available under the Creative Commons Attribution-ShareAlike 4.0; additional terms apply. By using this site, you agree to our Terms & Conditions.