Microservices Architecture

Table of contents

Reading Time: 4 minutes

Introduction

If you want to design an application that is multilanguage, easily scalable, easy to maintain and deploy, highly available, and that minimizes failures, then use the microservices architecture to design and deploy a cloud application.

In a microservices architecture, each microservice owns a simple task, and communicates with the clients or with other microservices by using lightweight communication mechanisms such as REST API requests.

The above diagram shows the architecture of an application that consists of multiple microservices.

Microservices enable you to design your application as a collection of loosely coupled services. Microservices follow the share-nothing model, and run as stateless processes. This approach makes it easier to scale and maintain the application.

The API Gateway layer is the entry point for all the client requests to a microservice. The API layer also enables the microservices to communicate with each other over HTTP, gRPC, and TCP/UDP.
The logic layer focuses on a single business task, minimizing the dependencies on the other microservices. This layer can be written in a different language for each microservice.
The database layer provides a persistence mechanism, such as a database storage engine, log files, and so on. Consider using a separate persistent data store for each microservice. Oracle offers database containers with multiple pluggable databases that make it easy for microservices to isolate data for security, HA, and scaling. In addition, SaaS applications can take advantage of multi-tenancy in a secure manner. Also, a converged database brings the variety of data under one roof for richer insights from the data.

Differences Between Monolithic and Microservices Architectures

Monolithic applications

If all the functionalities of a project exists in a single codebase, then that application is known as monolithic application. We all must have designed a monolithic application in our lives in which we were given a problem statement and were asked to design a system with various functionalities. We design our application in various layers like presentation, service and persistence and then deploy that codebase as single jar/war file. This is nothing but a monolithic application where “mono” represents the single codebase containing all the required functionalities.

Microservices applications

It is an architectural development style in which the application is made up of smaller services communicating with each other directly using lightweight protocols like HTTP. According to Sam Newman, “Microservices are the small services that work together.”

The Microservice architecture has a significant impact on the relationship between the application and the database. Instead of sharing a single database with other microservices, each microservice has its own database. It often results in duplication of some data but having a database per microservice is essential if you want to benefit from this architecture as it ensures loose coupling. Another advantage of having a separate database per microservice is that each microservice can use the type of database best suited for its needs.

Considerations for Adopting the Microservices Architecture

When you design a new application, consider the microservices architecture for applications that require high levels of scalability, flexibility, and reliability. You can use a different programming language and framework to develop each component.

Consider migrating a monolithic application to microservices if you can divide the application’s functionality into focused services, each with a limited scope. For complex monolithic applications that can’t be migrated to the microservices architecture, consider developing only the new functionality as microservices.

Interdependencies among services can affect how much of the application is unavailable during a service redeployment. Resolve any such dependency issues during the application design.

Refactoring a monolithic application is difficult. If you intend to use the microservices architecture, then plan for it from the start of the project.

Consider the complexities of distributed systems when you develop microservices, and remember that remote calls are slow and can fail. Depending on the use case, you must balance between consistency, availability, and partition-tolerance.

About the Communication Mechanism in a Microservices Architecture

In a microservices architecture, the services run on multiple servers. The communication between these services occurs through protocols such as HTTP, AMQP, and TCP. HTTP/REST and asynchronous messaging are the most widely used protocols.

A REST API for web services commonly uses the HTTP protocol. With HTTP methods (such as GET, POST, PUT, and DELETE) clients can access and manipulate the application resources by using a uniform resource locator (URL).

Clients send a request to a service through a REST API that represents an entry point to the application functionality. Clients can communicate with microservices either directly or through an API gateway.

An API gateway pattern defines a single entry point for all requests to the services. When a client request arrives, the API gateway routes the request to the appropriate service.

A variant of the API gateway pattern is the backend for frontend pattern, which defines a separate API gateway for each kind of client (for example, one gateway for mobile clients and another for web applications).

Minimizing communication between the services is a recommended practice. When communication is essential, asynchronous communication is preferable. The service that sends the request can continue operating without waiting for a response.

Messaging queues and streaming systems are ideal methods of providing asynchronous communication, and when integrated in the database they provide transactional semantics for a data operation and sending a message. This makes microservices simpler and more scalable to deploy. Using REST APIs exclusively makes the communication between microservices synchronous, and usually limits scaling.