"Go" application architecture a mess? How to transform monomer application into micro service

Overview

Transforming monomer applications into microservices is actually a process of application modernization, something developers have been doing for the past decade, so there are already some reusable experiences.

All overrides are absolutely useless unless you focus on building a microservices-based application from scratch. Although it may sound appealing, it is risky and likely to fail. As Martinfowler said: "The only thing a big Bang rewrite guarantees is a big bang!"

You should re-construct your monomer application in a gradual manner. You can gradually build a partial microservices application and then integrate it with your monolithic application. The functionality of the implementation of the monomer application will gradually become less and eventually disappear or become a new micro-service component.

The strategy of application modernization is Strangler application. The name comes from a plant strangler Vine found in a tropical rainforest that, in order to reach sufficient sunlight, grows around the tree and upward. When the trees die, they leave only a tree-shaped vine. The modernization of the application is a similar pattern, and we will build a new application with microservices in the old application, slowly replacing the old one. Here's a look at these strategies:

Strategy 1: Stop Loss

Law of holes tells us that if you are in a hole, don't keep digging. When your monomer application has become impossible to manage, do not continue to expand its scale. For example, if you want to add new features, do not add code to the standalone app, but place the new code in a separate microservices. Shows the architecture of the system after using this method:

In addition to the new service and the old monomer application, there are two additional components. One is request routing (requests router), which is used to process (such as HTTP) requests, similar to API gateways. This route sends the request corresponding to the new function to the new service and routes the old service-related requests to the singleton application.

The other component is the glue code (glue codes), which integrates the service with the monomer application. A service is rarely isolated and requires access to data from a single application. The glue code is responsible for these data integration. A microservices component can read and write data from a single application.

A service can access data in a single application in three ways:

• By invoking the remote API provided by the standalone app

• Direct access to a single database

• Keep a copy of the data in sync with the singleton database

The glue code is sometimes called the anti-corruption layer , which prevents services that own the original domain model from being affected by the concept of the monomer domain model.

The Glue code can act as a translator between two different models, and the term "anti-corrosion layer" first appeared in the book "Domain Drivendesign" written by Eric Evans. Developing an anti-corrosion layer is not a small project, but it is important if you want to get out of a single hell.

There are many benefits to implementing a new feature with lightweight services. First, it can prevent the monomer application from becoming more difficult to manage; second, the application can be independently developed, deployed and extended.

However, this method does not solve the problem encountered in the old monomer part, you also need to destroy the original monomer part.

Strategy 2: Separation of front and back

One strategy for reducing the monomer application is to separate the presentation layer from the business logic and the data access layer, and a typical enterprise application consists of at least three components:

• Presentation layer: This layer of components is used to handle HTTP requests, implementation (REST) APIs, or HTML-based Web UIs. In an application with a complex user interface, the presentation layer usually has a lot of code;

• Business Logic Layer: The core code of the application used to implement the business rules;

• Data access layer: A component that accesses a database or information mediation.

There is usually a clear distinction between performance logic and business and data access logic. The business layer has a coarse-grained API that consists of one or more facades, and the façade encapsulates the business logic components. This API is a natural "stitch", so you can split the monomer into smaller applications, one application contains the presentation layer, and the other application contains the business and data access layers. After separation, the performance logic layer application can invoke the business logic layer application remotely, showing the architecture before and after the transformation:

This separation of monomer applications has two main benefits. First, you can independently develop, deploy and scale two applications, such as for the presentation layer developers, they can implement a quick iteration of the user interface, A/B testing is easy to implement, and second, this will open a micro-service can also invoke the remote API.

But this strategy is only part of the solution, and is likely to become a two chaotic monolithic application. Need to use the following third strategy to reduce the proportion of the monomer portion.

Strategy 3: Extracting services

The purpose of the third strategy is to transform the modules in the monomer into separate microservices. Each time a module is extracted, it is transformed into a micro-service, and the monomer portion is reduced. Once you have converted enough modules, it is not a problem whether the monomer part is completely gone or becomes smaller as another microservices.

Which module to change first?

A large and complex monomer application, usually consisting of dozens of or even hundreds of modules, can be extracted and selected first to extract which is a problem. You can accumulate the experience of microservices from the beginning of easy extraction, and then extract the modules that will bring you the most benefit.

It is often useful to extract modules that change frequently, and once you have extracted the module, you can develop and deploy it independently, accelerating development.

The other is to extract the resource requirements and other parts that have very different modules. For example, to transform a module with a memory database into a service, it can be deployed on a large memory host, and similarly, extracting the modules that implement the complex algorithm can be deployed on a CPU-heavy host. In summary, this will help you expand your app.

When you decide which module to extract, you need to look at the existing coarse-grained boundaries to help you transform the module into a service. For example, a module that interacts only with asynchronous information and other applications can easily be transformed into a microservices service.

How do I extract a module?

The first step is to define a coarse-grained interface between the module and the monomer. Since the data of the monomer and the microservices are all in demand, it is much like a two-way API. But there are chaotic dependencies and fine-grained interaction patterns between this module and the rest of the application, so implementing this API is challenging. The business logic implemented by the domain model is particularly difficult to transform, because the relationships between the various domain models are complex. Often a lot of code changes are needed to break these dependencies.

Once you have implemented a fine-grained interface, you can transform the module into a separate service. To write code to implement the communication between Monomers and microservices through the use of an IPC-mechanism API. Shows how an architecture is transformed and transformed before it is transformed:

In this example, Module Z is the module to be extracted. Module x uses the z component, and z uses module Y.

1. The first step of the transformation is to define a pair of coarse-grained APIs, the first interface is the inbound interface of module x calling Module Z, and the second is the outbound interface of Module z calling module y;

2. The second step is to transform the module into a standalone service. Both the inbound interface and the outbound interface are implemented through the Code of the IPC mechanism. You might need to build this service by combining the module Z to the MicroServices chassis framework, which is used to handle crosscutting concerns, such as service discovery.

Once you have extracted this module, you can develop, deploy, and expand it independently. You can even rewrite the service from scratch, and the API code that combines the service and the monomer becomes an anti-corrosion layer, equivalent to a translator between two domain models. Each time the extraction of a service, is a step towards microservices, the proportion of the monomer will be gradually reduced.

Summarize

The process of transforming a monolithic architecture into a micro-service is a form of application modernization and should not be rewritten from scratch. Instead, you should gradually transform your application into a series of microservices. There are three strategies that can be applied: using microservices to implement new functions, separating presentation layer components from business and data access components, and transforming modules in monomers into microservices. As time goes on, your microservices will grow in proportion and your development team will have more flexibility and speed.

"Go" application architecture a mess? How to transform monomer application into micro service