Microservices from design to deployment (I) Introduction to microservices

Let’s think about it. You’re starting a new ride-hailing app that’s going to compete with Uber and Hailo. After initial communication and requirements gathering, you will generate a new project either manually or using platforms such as Rails, Spring Boot, Play, or Maven.

The new application is a modular hexagonal architecture, as shown in Figure 1-1:

Figure 1-1. A simple taxi-hailing application

At the heart of the application is the business logic implemented by modules that define services, domain objects, and events. Around the core are the adapters that interface with the outside world. Examples of adapters include database access components, message components that produce and consume messages, and Web components that expose apis or implement a UI.

Despite a logically modular architecture, applications are packaged and deployed as a whole. The actual format depends on the language and framework of the application. For example, many Java applications are packaged as WAR files and deployed on application servers such as Tomcat or Jetty. Other Java applications are self-contained executable jars. Similarly, Rails and Node.js applications are packaged as directory hierarchies.

Applications written in this style are common. They are easy to develop because our IDE and other tools focus on building individual applications. These applications are also easy to test. You can easily implement end-to-end testing by simply launching and testing the UI using a test package such as Selenium. Standalone applications are also easy to deploy. You simply copy the packaged application to the server. You can also extend the application by running multiple replicas and combining load balancers. In the early stages of the project, it worked well.

Many organizations, such as Amazon, eBay, and Netflix, have addressed this problem with what is now called the microservices architecture model, rather than building a bloated monolithic application. The idea is to decompose your application into a set of smaller interconnected services.

A service usually implements a different set of features or functions, such as order management, customer management, and so on. Each microservice is a mini-application with its own hexagonal architecture that includes business logic and multiple adapters.

Some microservices expose an API for consumption by other microservices or application clients. Other microservices might implement a Web UI. At run time, each instance is usually a cloud Virtual Machine (VM) or a Docker container.

For example, the system described earlier might decompose as shown in Figure 1-2:

Figure 1-2. A single application decomposed into microservices

Each functional area of the application is now implemented by its own microservices. In addition, Web applications are divided into a set of simpler Web applications. For example, take our rough car as an example, one for passengers and one for drivers. This makes it easier to deploy different scenarios for specific users, drivers, devices, or specialized use cases. Each back-end service exposes a REST API, and most services consume apis provided by other services. For example, driver management uses a notification server to inform an available driver about a potential trip. The UI service calls other services to render the page. Services can also use asynchronous, message-based communication. Communication between services will be described in more detail later in this ebook.

Some REST apis are also exposed to mobile applications for use by drivers and passengers. However, applications cannot directly access back-end services. Instead, communication between them is handled by an intermediary called an API Gateway. The API gateway is responsible for load balancing, caching, access control, API metering, and monitoring, and can be implemented using NGINX. Chapter 2 discusses API gateways in detail.

Figure 1-3. Scale Cube in development and delivery

The microservices architecture pattern corresponds to the Y-axis coordinates of this scaling cube, a 3d scaling model from Architecture is the Future. The other two axes are X-axis scaling and Z-axis coordinates (or data partitions) made up of load balancers running multiple copies of the same application, where the requested properties (for example, the primary key or customer id of a row of records) are used to route requests to specific servers.

Applications often use these three types of coordinate methods together. The Y-axis splits the application into microservices, as shown in Figure 1-2.

At run time, multiple instances of a service run on the X axis, each of which works with a load balancer to meet throughput and availability. Some applications may also use the Z-axis for partitioning services. Figure 1-4 shows how to deploy the Trip Management service on Amazon EC2 using Docker.

Figure 1-4. Deploying the journey management service with Docker

At runtime, the journey management service consists of multiple service instances, each of which is a Docker container. To achieve high availability, containers are run on multiple cloud virtual machines. In front of the service instance is a load balancer such as NGINX that distributes requests across instances. Load balancers can also handle other issues, such as caching, access control, API metrics, and monitoring.

The microservice architecture pattern clearly affects the relationship between applications and databases. Instead of sharing a single database schema with other services, each service has its own database schema. On the one hand, this approach is inconsistent with the idea of an enterprise database data model, and it often leads to some data redundancy. However, if you want to benefit from microservices, each service should have its own database schema. Because it’s loose coupling. Figure 1-5 shows a sample database architecture application.

Each service has its own database. Furthermore, services can use a database that best suits their needs, known as a Polyglot Persistence Architecture. For example, driver management, where drivers who find proximity to potential passengers must use databases that support efficient geographic queries.

Figure 1-5. Database architecture of taxi application

On the surface, the microservices architecture pattern is similar to SOA. Microservices are a set of services. However, there is another way to think about the microservices architecture pattern, which is SOA without commercialization, without the integration of the Web Services Specification (WS-*) and Enterprise Service Bus (ESB). Microservices-based applications support simpler, lightweight protocols, such as REST rather than WS-*. They also try to avoid using an ESB, instead implementing the microservices themselves with ESB-like functionality. Microservices architecture also rejects other parts of SOA, such as the data access specification pattern concept.

As Fred Brooks wrote in “The Myth of the Man-Month” nearly 30 years ago, there are no silver bullets. Like other technologies, the microservices architecture pattern has its drawbacks. One drawback is the name itself. The focus of the term microservices is too much on the scale of the service. In fact, some developers advocate building very fine-grained 10-100 LOC (lines of code) services. While small services may be better, it’s important to remember that small services are a means, not the main goal. The goal of microservices is to decompose applications sufficiently to facilitate agile application development and deployment.

Another major disadvantage of microservices is that they are complicated by the fact that they are a distributed system. Developers need to choose and implement message-based or RPC-based interprocess communication mechanisms. In addition, because the target request may be slow or unavailable, they must write code to handle some of the failures. None of this is very sophisticated, but modules call each other through language-level method/procedure calls, which is much more complex than a single application.

Another challenge with microservices is the partitioned database architecture. It is quite common to have more business transactions with multiple business entities. The implementation of these transactions in a singleton application is trivial because there is only a single database. In a microservices-based application, you need to update the databases that are useful for different services. Distributed transactions are not usually chosen, and not just because of the CAP theorem. They simply do not support today’s highly extensible NoSQL databases and message brokers. You end up having to use the ultimate conformance based approach, which is more challenging for developers.

Testing microservices applications can also be complex. For example, with a modern framework such as Sprig Boot, you only need to write a test class to launch a single Web application and test its REST API. By contrast, a similar test class for microservices requires starting the service and any services it depends on, or at least configuring stubs for those services. Again, this is not a highbrow matter, but don’t underestimate the complexity of doing so.

Another major challenge of the microservice architecture pattern is the implementation of change across multiple services. For example, let’s say you are implementing A requirement to change services A, B, and C, where A depends on B and B depends on C. In a singleton application, you can simply modify the corresponding modules, integrate the changes, and deploy them all at once. In contrast, in microservices you need to carefully plan and coordinate the changes that occur to each service. For example, you need to update service C, then service B, and finally service A. Fortunately, most changes affect only one service; Relatively few multi-service changes need to be coordinated.

Deploying microservices-based applications is also very complex. A single application can easily be deployed to a set of identical servers based on a traditional load balancer. Each application instance is configured with locations (hosts and ports) for infrastructure services, such as databases and message brokers. Microservice applications, by contrast, typically consist of a large number of services. Hailo, for example, has 160 different services and Netflix has more than 600, according to Adrian Cockcroft.

Each service has multiple runtime instances. There are many more moving parts to configure, deploy, scale, and monitor. In addition, you need to implement a service discovery mechanism that enables the service to discover the location (host and port) of any other service it needs to communicate with. Traditional troublesome ticket-based and manual operation methods cannot be extended to such a level of complexity. Therefore, successful deployment of microservice applications requires a high degree of developer control over deployment and a high degree of automation.

One way to automate this is to use an off-the-shelf platform as a Service (PaaS), such as Cloud Foundry. PaaS provide an easy way for developers to deploy and manage their microservices. IT frees developers from hassles such as purchasing and configuring IT resources. At the same time, systems and network professionals deployed with PaaS can ensure best practices and implement corporate policies.

Another way to automate microservice deployment is to develop your own PaaS. A common starting point is to use clustering solutions, such as Kubernetes, combined with container technologies such as Docker. At the end of the book we’ll see how software-based application delivery approaches such as NGINX handle caching, access control, API metering, and monitoring at the microservice level to help solve this problem.

By Floyd Smith

NGINX is used by more than 50% of the 10,000 web sites, mainly because of its ability to act as a reverse proxy server. You can put NGINX in front of your current application or even a database server for all kinds of functions-higher performance, higher security, scalability, flexibility, and so on. Your existing application only needs to configure the code and make few or no changes. For sites that are under performance pressure, or where high loads are expected in the future, the effect may not seem so magical.

So what does this have to do with microservices? Implement a reverse proxy server and use other NGINX features to give you architectural flexibility. Reverse proxy servers, static and application file caches, SSL/TLS, and HTTP/2 are all excluded from your application. NGINX can also serve as a load balancer, a key player in microservice implementations, by letting applications do what they are supposed to do. Advanced NGINX Plus features complex load balancing algorithms, multiple ways of session persistence, and administrative monitoring are especially useful for microservices (NGINX also recently added service discovery support using DNS SRV records, a top feature). And, as described in this chapter, NGINX can automate the deployment of microservices.

In addition, NGINX provides the necessary functionality to support the three models in the NGINX Microservices reference architecture. The proxy model uses NGINX as the API gateway; The grid routing model uses an additional NGINX as the interprocess communication backbone; The Fabric model uses one NGINX per microservice to control HTTP traffic, implementing SSL/TLS between microservices, which is quite groundbreaking.