Application integration of microservice architecture: service grid is not an ESB

The main points of this article

• In enterprise software development, API, service, data and system integration are the most challenging and also the most important requirements;
• in the past, We used to integrate these independent applications in a point-to-point style, and then this approach was replaced by the ESB (Enterprise Service Bus) style. At the same time, there was also Service Oriented Architecture (SOA). );
• With the popularity of microservices and "cloud native" architecture, the concept of "service grid" has emerged. The core idea of ​​the service grid is to take all the business logic code as part of the service, and put the logic related to network communication into the communication infrastructure between services.
• Because the service grid provides some ESB functions, some people misunderstand it as a distributed ESB and make it also responsible for application integration. This is not correct.
• The service grid is just an infrastructure used to communicate between services. Developers should not build any business logic in the service grid. There are some other frameworks and libraries that can be used to implement the integration model of cloud-native enterprise applications.

In enterprise-level software application development, API, service, data and system integration have been the most challenging and basic requirements for a long time.

In the past, we will integrate these independent applications in a point-to-point manner, which was subsequently used by the enterprise service bus (ESB) and service-oriented architecture (Service-oriented architecture, SOA) replaced.

However, in modern microservices and cloud native architectures, we rarely discuss application integration anymore. But this does not mean that this modern architecture has solved all the challenges of enterprise application integration.

The challenges of application integration have hardly changed, but the way we solve them has changed.

From ESB to smart endpoints and dumb pipes

Most enterprises adopting SOA will use ESB as the central bus to connect and integrate all independent APIs, services, data and systems.

If a given business scenario needs to communicate with different entities in the organization, the ESB's responsibility is to detect all entities and create combined functions.

Therefore, generally speaking, ESB solutions are the power source for all built-in integrated functions, such as connectors to different systems and APIs, message routing, conversion, elastic communication, persistence, and transactions.

Figure 1: Use USB for integration

However, microservice architecture tends to build smart endpoints and dumb pipes replaces ESB, which means that our microservices must be responsible for all application integration.

One price of smart ESB decentralization is that the complexity of the microservice code will increase significantly, because in addition to the business logic of the service, they must also deal with these application integrations Function. For example, Figure 2 shows multiple microservices (B, F, and G) as intelligent endpoints, which simultaneously contain the structure of communicating with multiple other services and the logic of the business itself.

Figure 2: Inter-service communication and composition of microservices

Another challenge of the microservice architecture is how to build theThe characteristics of the service business logic, such as flexible communication, transmission-level security, publishing statistical data, publishing tracking data to observability tools, etc. The service itself must implement these characteristics as part of the service logic. It is very complicated to implement all these features in each microservice. If our service is implemented in polyglot, it will greatly increase the related workload, and the service grid can solve this problem.

Figure 3: The actual service grid

The core idea of ​​the service grid is to take all the business logic code as part of the service, and also network communication related The logic is placed in the communication infrastructure between services. When using a service grid, a given microservice does not directly communicate with other microservices. The communication between the service and the service will be carried out through an additional software component, which runs outside the process of the service, called a service grid proxy or a sidecar proxy. The sidecar process and service are located in the same virtual machine (VM) or Pod (Kubernetes). The sidecar proxy layer is also called the data plane. All sidecar proxies will be controlled by the control plane, and configurations related to communication between services will be used here.

Service grid is not used for application integration

Because service grid provides some ESB functions, some people misunderstand it as a distributed ESB and make it also responsible for application integration . This is not correct. The service grid is just an infrastructure used to communicate between services. We should not build any business logic in the service grid. Suppose we have three microservices named X, Y, and Z, which communicate in a request/response manner. In order to achieve business functions, X needs to communicate with Y and Z (see Figure 4). The combination of business logic should be the code of microservice A, and the sidecar of the service grid should not contain anything related to the combination logic.

Figure 4: Service composition logic is similar to service grid

, for services that use event-driven communication, the service code should handle all business logic Details (it's worth mentioning that the service grid does not yet fully support event-driven architecture). Therefore, even if we run microservices or cloud-native applications based on the service grid, the integration of these services and applications is still necessary. In the era of modern microservices and cloud native architecture, application integration is one of the most critical requirements, but to a large extent it is still an invisible requirement.

Integration of microservices and cloud-native applications

In micro-services and cloud-native applications, application integration or building smart terminals all involve integrated micro-services. Services, APIs, data and systems. These integration requirements range from the integration between several microservices to the integration with a single subsystem, to the creation of an anti-corruption layer. In-depth study of the application integration requirements in microservices and cloud-native applications, we will find that the following key functions are required in the application integration framework:

• The integration runtime must be cloud-native and able to run smoothly. Docker/Kubernetes, and provide seamless integration with the cloud native ecosystem.
• It needs to support service orchestration/activity combination, so that a given service contains the logic to call multiple other services, so that business functions can be combined.
• It needs to support choreography/reactive combination, so that inter-service communication can be achieved through synchronous event-driven communication, avoiding centralized services that include service interaction logic.
• It must haveBuilt-in abstractions for information protocols (HTTP, gRPC, GraphQL, Kafka, NATS, AMQP, FTP, SFTP, WebSockets, TCP).
• It must support forking, joining, splitting, looping and aggregation of messages and service calls.
• It needs to support storage and forwarding, persistent delivery and idempotent message technologies.
• It must have the function of message type mapping and conversion.
• It must be able to integrate with SaaS (such as Salesforce), proprietary solutions (such as SAP) and legacy systems.
• should have message routing oriented to business logic.
• It must support the realization of distributed transactions in a compensation manner.
• It must have a long-running workflow. The
• anti-corruption layer must be able to connect microservices and single subsystems.

In any microservices and cloud native applications, these features are very common, but building from scratch can be a daunting task. This is why it is so important to carefully analyze these functions and choose the appropriate technology and framework based on integration requirements when building microservices and cloud-native applications. For example, if the service we are building requires complex orchestration logic, then the framework or technology we choose should make this type of composition easier to write. If the service we want to build is to be long-running and has compensation functions, then we must choose a framework with built-in workflow and compensation functions (see InfoQ's article " Events, processes and long-running services: Workflow automation The modern solution ", Martin Schimak and Bernd Rücker deeply analyzed the current workflow technology for cloud-native architecture).

Although application integration is ignored by most microservice experts, authors of articles like Christian Posta (former Red Hat chief architect, Field CTO of Solo.io) have emphasized the importance of application integration, such as Posta's blog post Cannot put the security and correctness of the application on Istio or other service grid . In the InfoQ article Microservices in the Post-Kubernetes Era , Bilgin Ibryam emphasized the decentralization of application integration in the cloud-native architecture and how to build application integration based on the service grid.

Development and integration from the perspective of CNCF

The Cloud Native Computing Foundation (CNCF) is at the forefront of building microservices and cloud-native applications. Its goal is Build a sustainable ecosystem, build a community around a set of high-quality projects, and use container orchestration as part of the microservice architecture. CNCF hosts projects composed of open source technologies and frameworks that can implement different aspects of microservices or cloud native architectures. We can look at where these application integration technologies are located in the technology stack.

CNCF recommended cloud native path There is an App Definition and Development section, but there is no special application development or integration classification. Considering the importance of application integration, we can see that it will be included in CNCF in the future. Figure 5 shows the application integration technology under application definition and development.

Figure 5: Application integration in CNCF in the future

Application integration-related technologies

Although there are many monolithic application integration technologies available, most of them are not suitable for cloud native or microservice architecture. Among the existing integration providers, only a few have implemented cloud-native variants for their products and tools.

has some specialized integration frameworks, which can implement general integration modes in the application integration field. Generally, most of these technologies are inherited from traditional ESB-based integration methods, but they have been modified and can be directly integrated into the cloud native architecture:

• Apache Camel/Camel-K is one of the most popular open source integration frameworks. The Camel-K project provides seamless support for the Kubernetes ecosystem based on the Camel runtime.
• WSO2 Micro Integrator is a cloud-native variant of the open source WSO2 enterprise-level integration platform. Micro Integrator provides a lightweight integrated runtime, which can run directly in the Kubernetes ecosystem.
• Although Spring Integration does not have a runtime version specifically on Kubernetes, it can be used well in the application integration function of the cloud native architecture.

Some application development frameworks can also meet the needs of application integration:

• Spring Boot itself is not an integrated framework, but it has many important requirements for application integration Features.
• Vert.x is a toolkit for building reactive cloud native applications. It can also be used for application integration.
• Micronaut is a modern, JVM-based full-stack framework that can be used to build modular and easy-to-test microservices and serverless applications. The framework has many integrated abstractions built-in, and avoids the complexity of traditional frameworks (such as Spring). Programming languages ​​such as
• Go, JavaScript/Node.js have some built-in or library-based application integration features. Some emerging languages, such as Ballerina, the language itself provides an abstraction for integration.
• Quarkus is a new Kubernetes native Java stack, which is customized for GraalVM and OpenJDK and assembled by the best Java libraries and standards. It combines multiple application development libraries, such as RESTeasy, Camel, Netty, etc.

Conclusion

In the process of splitting monolithic applications into microservices and cloud-native applications, the need to connect these applications has become more and more challenging. Services and applications are scattered in the network and connected through different communication structures. The realization of any business scenario requires microservice integration, which needs to be completed as part of the service realization logic. Therefore, in the era of microservices and cloud native architecture, cloud native application integration is one of the most critical requirements, but it is largely an invisible requirement.

The service grid pattern overcomes some challenges in microservice integrationHowever, it only provides the general characteristics of communication between services, which is independent of the business logic of the service, so the application integration logic related to the business scenario still needs to be implemented at the service level. Therefore, the most important thing is to choose the appropriate development technology to build integrated services and minimize the development time required to combine services. There are some frameworks and technologies emerging to meet the needs of application integration in cloud native environments, and we need to evaluate these technologies according to each specific use case.