Advantages and disadvantages of microservice Architecture

Advantages and disadvantages of microservice Architecture
Abstract: This article is from the official Nginx blog and is the first article in The microservice series. It mainly discusses the shortcomings of traditional monolithic applications and the advantages and challenges of the microservice architecture. As the author said, microservice architecture is more suitable for building complex applications, although it also has its own shortcomings.

This article is written by Chris Richard, who was the founder of the early Java-based Amazonite EC2 PaaS platform CloudFoundry.com. Now he provides enterprises with consulting services on how to develop and deploy applications. He also often published articles about microservices in http://microservices.io.

Microservice is gaining more and more attention in blogs, social media discussion groups, and conference speeches. It ranks very top in Gartner's 2014 Hype Cycle. At the same time, the software community also has many skeptical that microservices are not anything new. Naysayers believes that this is the re-packaging of the SOA architecture. However, despite the different arguments, the microservice architecture model is providing great help for agile deployment and complex enterprise application implementation.

This blog is the first article in the seven series about how to design, develop, and deploy microservices.Readers will learn the method from it and compare it with the Monolithic architecture model (Translator's note: This article will translate Monolithic into Monolithic. These articles describe different elements in the microservice architecture. You will understand the advantages and disadvantages of the microservice architecture model, so as to decide whether to better apply the microservice architecture to your own projects and how to apply this model.

First, let's see why we should consider using microservices.

Develop standalone applications

Suppose you are developing a taxi dispatch software competing with Uber and Hailo. After preliminary meeting and demand analysis, you may start this new project manually or using a generator based on Rails, Spring Boot, Play, or Maven. Its hexagonal architecture is modular and the architecture diagram is as follows:

The core of an application is the business logic, which is completed by the module that defines services, domain objects, and events. The core is the external adapter. The adapter includes database access components, Message Components that produce and process messages, and web modules that provide API or UI access support.

Although it is also a modular logic, it will eventually be packaged and deployed as a monolithic application. The specific format depends on the application language and framework. For example, many Java applications are packaged as WAR and deployed on Tomcat or Jetty, while other Java applications are packaged into self-contained JAR formats. Similarly, Rails and Node. js will be packaged into a hierarchical directory.

This application development style is very common, because IDE and other tools are good at developing a simple application, and such applications are easy to debug. You only need to simply run this application, you can use Selenium to link the UI to complete end-to-end testing. A single application is also easy to deploy. You only need to copy the packaged application to the server. By running multiple copies at the backend of the Server Load balancer, you can easily scale the application. In the early days, such applications run well.

Disadvantages of monolithic applications

Unfortunately, this simple method has many limitations. A simple application will grow over time. In each sprint, the development team will face the new "story" and then develop a lot of new code. A few years later, this small and simple application will become a huge monster. Here is an example. I recently discussed with a developer that he is writing a tool to analyze the dependencies between JAR files in an application with millions of lines of code. I am confident that this code is a monster developed by many developers over the years.

Once your application becomes a big and complex monster, the development team must be suffering. Agile development and deployment are difficult. The main problem is that the application is too complex to be understood by any single developer. Therefore, it is very difficult and time-consuming to fix bugs and correctly add new features. In addition, team morale will also go downhill. If the code is difficult to understand, it cannot be modified correctly. In the end, it will go into a huge and incomprehensible quagmire.

Monolithic applications also reduce development speed. The larger the application, the longer the startup time. For example, a recent survey shows that sometimes the application startup time exceeds 12 minutes. I also heard that it takes 40 minutes to start some applications. If developers need to restart their applications frequently, they will spend most of their time waiting, and their production efficiency will be greatly affected.

In addition, complex and huge monolithic applications are not conducive to continuous development. Today, SaaS applications change many times every day, which is very difficult for the single application model. In addition, the impact of such changes is not well understood, so we have to do a lot of manual testing. Then, continuous deployment will be difficult.

In case of resource conflicts between different modules, it is very difficult to expand a single application. For example, if one module completes a CPU-sensitive logic, it should be deployed in AWS EC2 Compute Optimized instances, while the other Memory database module is more suitable for EC2 Memory-optimized instances. However, because these modules are deployed together, we have to make a compromise on the hardware choice.

Reliability is another problem in standalone applications. Because all modules are running in one process, a bug in any module, such as memory leakage, may cause the whole process to crash. In addition, because all application instances are unique, this bug will affect the reliability of the entire application.

Finally, monolithic applications make it very difficult to adopt new architectures and languages. For example, assume that you have 2 million lines of code written using the XYZ framework. If you want to change to the ABC framework, both time and cost are very expensive, even if the ABC framework is better. Therefore, this is an insurmountable gap. You have to bow your head in front of your initial choice.

Summary: At first, you had a very successful key business application, and then it became a huge, incomprehensible monster. The adoption of outdated and low-efficiency technologies makes it difficult to hire potential developers. Applications cannot be expanded, and reliability is low. In the end, agile development and deployment cannot be completed.

So how should we deal with it?

Micro-processing architecture -- processing complex things

Many companies, such as Amazon, eBay, and NetFlix, solve these problems by adopting a micro-processing structure model. The idea is not to develop a huge monolithic application, but to break down the application into small, interconnected microservices.

A microservice generally performs certain functions, such as order management and customer management. Every microservice is a micro-hexagonal application with its own business logic and adapter. Some microservices also release APIs for other microservices and application clients. Other microservices complete a Web UI. during runtime, each instance may be a cloud VM or Docker container.

For example, the possible decomposition of a previously described system is as follows:

Each application functional area is completed using microservices. In addition, Web applications are split into a series of simple Web applications (such as a pair of passengers and a pair of taxi drivers ). Such splitting is easier to deploy for different users, devices, and special application scenarios.

Each background service opens a rest api, and many services use APIs provided by other services. For example, Driver Management uses a notification service that notifies drivers of a potential demand. The UI Service activates other services to update Web pages. All services adopt asynchronous message-based communication. The internal mechanism of microservices will be discussed in the subsequent series.

Some REST APIs are also open to mobile apps used by passengers and drivers. These applications do not directly access backend services, but use API Gateway to transmit intermediate messages. API Gateway is responsible for load balancing, caching, access control, API billing monitoring, and other tasks. It can be easily implemented through NGINX. This article will introduce API Gateway in the future.

· The microservice architecture model corresponds to The Y axis that represents The Scalable Scale Cube. This is a 3D scaling model described in The Art of Scalability. The X axis of the other two extensible axes is composed of multiple application copies running at the backend of the Server Load balancer. The Z axis routes requests to related services.

An application can be expressed in three dimensions. The Y axis indicates that the application is divided into microservices. During running, the X axis indicates running multiple instances hidden behind the Server Load balancer to provide throughput. Some applications may still use the Z axis to partition services. The following figure shows how the itinerary Management Service is deployed on a Docker running on AWS EC2.

During running, the itinerary Management Service is composed of multiple service instances. Each service instance is a Docker container. To ensure high availability, these containers generally run on multiple cloud VMS. The front of a service instance is a Load balancer such as NGINX, which distributes requests among instances. The server Load balancer also processes other requests, such as cache, permission control, API statistics, and monitoring.

This microservice architecture model profoundly affects the relationship between applications and databases,Unlike traditional services that share a database, each service in the microservice architecture has its own database.. In addition, this approach also affects the enterprise-level data model. At the same time, this mode means multiple copies of data. However, if you want to obtain the benefits of microservices, each service must have a unique database, because this architecture requires such loose coupling. The following figure shows the architecture of the application database.

Each service has its own database. In addition, each service can use a database type that is more suitable for itself, also known as a multi-language consistency architecture. For example, Driver Management (finding a driver closer to a passenger) must use a database that supports geographic information query.

On the surface, the microservice architecture is a bit like SOA, which is composed of multiple services. However, from another perspective, the microservice architecture model is an SOA that does not contain Web Services (WS-) and ESB services. Microservice applications are willing to adopt simple and lightweight protocols, such as REST, rather than WS-. Avoid using ESB and similar ESB functions within microservices. The microservice architecture model also rejects the use of SOA concepts such as canonical schema.

Benefits of microservice Architecture

The microservice architecture model has many advantages. First, the complexity problem is solved by decomposing huge monolithic applications into multiple service methods. Without changing functions, an application is divided into multiple manageable branches or services. Each service has a clear boundary defined using RPC-or message-driven APIs. The microservice architecture provides a modular solution for features that are hard to implement using a single-type encoding method. Therefore, a single service is easy to develop, understand, and maintain.

Second, this architecture allows each service to be developed by a dedicated development team. Developers are free to choose development technologies to provide API services. Of course, many companies try to avoid confusion and only offer some technical options. Then, this freedom means that developers do not need to be forced to use the outdated technology used at the beginning of a project. They can choose the current technology. Even because services are relatively simple, it is not very difficult to use the current technology to rewrite the previous code.

Third, the microservice architecture model is independent deployment of each microservice. Developers no longer need to coordinate the impact of deployment of other services on the service. This change can speed up deployment. The UI team can use AB testing to quickly deploy changes. The microservice architecture makes continuous deployment possible.

Finally, the microservice architecture makes each service expand independently. You can deploy the desired scale based on the scale of each service. You can even use hardware that is more suitable for service resources. For example, you can deploy CPU-sensitive services on EC2 Compute Optimized instances and deploy memory databases on EC2 memory-optimized instances.

Insufficient microservice Architecture

Fred Brooks wrote 30 years ago that "there are no silver bullets", and like any other technology, microservice architecture is also inadequate. Similar to his name, "microservices" emphasizes the size of services. In fact, some developers advocate creating a slightly larger 10-100 LOC Service Group. Although small services are more likely to be used, do not forget that this is only the choice of terminal rather than the ultimate goal. Microservices are designed to effectively split applications for agile development and deployment.

Another major disadvantage is that microservice applications are distributed systems, resulting in inherent complexity. Developers need to select and complete the inter-process communication mechanism between RPC or message transmission. What's more, they must write code to handle partial failure problems such as slow message transmission speed or unavailability. Of course, this is not difficult, but this technology is more complex than a single application that uses language-level methods or process calls.

Another challenge about microservices comes from the partitioned database architecture. It is common for commercial transactions to update messages to multiple business subjects at the same time. This kind of transaction is easy for monolithic applications, because there is only one database. In microservice architecture applications, you need to update different databases used by different services. Using distributed transactions is not necessarily a good choice, not only because of CAP theory, but also because today's highly scalable NoSQL database and messaging middleware do not support this demand. In the end, you have to use a final consistency method, which puts forward higher requirements and challenges for developers.

Testing an application based on the microservice architecture is also a complex task. For example, it is easy to test its rest api for a single web application using the popular Spring Boot architecture. In turn, the same service test needs to start all services related to it (at least stubs of these services ). Once again, we should not underestimate the complexity brought about by the adoption of the microservice architecture.

Another challenge is that the application changes in the microservice architecture model will affect multiple services. For example, if you are completing A case, you need to modify Services A, B, and C, while A depends on B and B on C. In a monolithic application, you only need to change the relevant modules, integrate the changes, and deploy them. In contrast, the microservice architecture model needs to consider the impact of changes on different services. For example, you need to update service C, then B, and finally A. Fortunately, many changes generally only affect one service, but few changes need to coordinate multiple services.

Deploying a microservice application is also complex. You only need to deploy the servers behind the complex balancer for a distributed application. Each application instance needs to configure basic services such as databases and message-oriented middleware. A microservice application generally consists of a large number of services. For example, according to Adrian Cockcroft, Hailo has 160 different services, and NetFlix has about 600 Services. Each service has multiple instances. This results in many parts that require configuration, deployment, expansion, and monitoring. In addition, you also need to complete a service discovery mechanism (published in subsequent articles ), to discover the address (including the server address and port) of the communication service with it ). Traditional solutions cannot solve such complicated problems. To successfully deploy a microservice application, developers must have sufficient control over the deployment method and be highly automated.

One automated method is to use the PaaS service, such as Cloud Foundry. PaaS provides developers with a simple method to deploy and manage microservices. It packs and solves all these problems. In addition, PaaS system and network experts can use best practices and policies to simplify these problems. Another way to automatically deploy microservice applications is to develop the most basic PaaS System for you. A typical start point is to use a cluster solution, such as using Mesos or Kubernetes with Docker. In the subsequent series, we will look at how to provide caching, permission control, API statistics and monitoring at the microservice level based on software deployment methods such as NGINX.

Summary

Building Complex applications is really very difficult. The monolithic architecture is more suitable for lightweight and simple applications. If you use it to develop complex applications, it will be really bad. The microservice architecture model can be used to build complex applications. Of course, this architecture model also has its own shortcomings and challenges.

In my subsequent blog, I will go deep into the microservice architecture model and discuss strategies such as service discovery, service deployment selection, and how to break down a distributed application into multiple services.