Learn About the Microservices Architecture

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 following diagram shows the architecture of an application that consists of multiple microservices.

Description of the illustration microservice_architecture.png

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 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 data store 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.

Typically, each microservice runs in a container that provides a lightweight runtime environment.

Differences Between Microservices and Monolithic Architectures

Before you begin designing applications using the microservices architecture, you must understand how this architecture differs from the traditional monolithic architecture.

Application design focuses on solving business requirements and implementing business logic. In a monolithic architecture, the entire application is built as a single unit that contains all the business logic. In the microservices architecture, the business logic is organized as multiple loosely coupled services.

The following illustration shows the monolithic and microservices architectures.

Description of the illustration monolithic_vs_microservice.png

The following table summarizes the differences between the microservices and monolithic architectures.

Characteristic	Microservices Architecture	Monolithic Architecture
Unit design	The application consists of loosely coupled services. Each service supports a single business task.	The entire application is designed, developed, and deployed as a single unit.
Functionality reuse	Microservices define APIs that expose their functionality to any client. The clients could even be other applications.	The opportunity for reusing functionality across applications is limited.
Communication within the application	To communicate with each other, the microservices of an application use the request-response communication model. The typical implementation uses REST API calls based on the HTTP protocol.	Internal procedures (function calls) facilitate communication between the components of the application. There is no need to limit the number of internal procedure calls.
Technological flexibility	Each microservice can be developed using a programming language and framework that best suits the problem that the microservice is designed to solve.	Usually, the entire application is written in a single programming language.
Data management	Decentralized: Each microservice may use its own database.	Centralized: The entire application uses one or more databases.
Deployment	Each microservice is deployed independently, without affecting the other microservices in the application.	Any change, however small, requires redeploying and restarting the entire application.
Maintainability	Microservices are simple, focused, and independent. So the application is easier to maintain.	As the application scope increases, maintaining the code becomes more complex.
Resiliency	The application functionality is distributed across multiple services. If a microservice fails, the functionality offered by the other microservices continues to be available.	A failure in any component could affect the availability of the entire application.
Scalability	Each microservice can be scaled independently of the other services.	The entire application must be scaled, even when the business requirement is for scaling only certain parts of the application.

For more details about these characteristics, see Microservices: a definition of this new architectural term (Martin Fowler and James Lewis, 2014).

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.

Be prepared for the operational complexity that the microservices architecture involves. According to Martin Fowler, the following prerequisites must be fulfilled before you move a monolithic application to the microservice architecture:

• Rapid provisioning: Ability to provision servers quickly
• Basic monitoring: Ability to detect service problems and business issues. The service problems include service availability, functional errors, and performance issues
• Rapid application deployment: Ability to deploy any service swiftly to the test and production environments

Make sure that the benefits of the microservices architecture outweigh the cost.

For more information, see Microservice Prerequisites (Martin Fowler, 2014).

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.

About Required Services and Roles

This solution requires the following services:

• Oracle Cloud Infrastructure Database
• Oracle Cloud Infrastructure Container Engine for Kubernetes

Define policies that, at a minimum, permit your user's group to manage the instance-family, volume-family, virtual-network-family, cluster-family, object-family, and database-family resource-types in your compartment. In addition, grant access to the repos resource-type in the tenancy.

See Learn how to get Oracle Cloud services for Oracle Solutions to get the cloud services you need.