Mecha: carry mesh to the end


Content abstract: service mesh has been practiced for three years, but the effect has not been ideal. It’s time to reflect. As a service-oriented distributed capability abstraction layer, mecha is the natural evolution version of service mesh mode. It is expected that it will also be the inevitable trend of cloud proto biochemistry and meshing. Let’s carry out mesh to the end.

Introduction to mecha

What is Macha?

The word mecha, I believe that the students who love animation should not be unfamiliar. Yes, it’s the mecha that you’re familiar with:

Mecha: carry mesh to the end

The word mecha appears here mainly becauseBilgin IbryamThis blog post“Multi-Runtime Microservices Architecture”This paper proposes a new idea of microservice architecture: multiple runtime.

Note: this blog post strongly recommends reading. I even suggest reading this article before reading this article, because my content today can be regarded as the in-depth interpretation and thinking of this article. For convenience, a Chinese translation version of multi runtime microservice architecture is provided here.

In this blog, bilgin ibryam first analyzes and summarizes the four major requirements of distributed applications:

Mecha: carry mesh to the end

  • Life cycle
  • Networking
  • State
  • Binding

Due to the problems and limitations of each requirement, traditional solutions such as enterprise service bus (ESB) and its variants (such as message oriented middleware, lightweight integration framework, etc.) are no longer applicable. With the development of microservice architecture, as well as the popularity and wide use of containers and kubernetes, cloud native ideas begin to affect the implementation of these requirements. The future architecture trend is to move all traditional middleware functions to other runtimes, and the final goal is to write only business logic in services.

Note: please refer to the original text for details. In order to save space, only a brief overview is given here, and the original content is not fully quoted.

The following figure shows the comparison between the traditional middleware platform and the cloud native platform. The traditional middleware provides capabilities in various SDK ways, while the cloud native platform uses various peripheral runtimes (such as the familiar servicemesh / istio)

Mecha: carry mesh to the end

Therefore, the author introduces the concept of multiple runtime

Mecha: carry mesh to the end

The authors suggest that it is likely that in the future, we will eventually use multiple runtimes to implement distributed systems.Multiple runtimes, not because there are multiple microservices, but because each microservice will consist of multiple runtimesThe most likely two runtimes are the custom business logic runtime and the distributed primitive runtime.

Description of multi runtime microservice architecture and mecha

Do you remember the movie Avatar and the amplified mobility platform (AMP) “Scooter suit” made by scientists to explore Pandora in the wild? This multi run time architecture, similar to these mecha packages, gives the humanoid driver a super capability. In the movie, you have to put on a suit to gain power and get weapons of destruction. In this software architecture, you will have the business logic (called micrologic / micrologic) that forms the core of your application and the sidecar mecha component that provides a powerful distributed primitive out of the box. Micrologic and mecha function are combined to form multi runtime microservices, which use out of process functions for its distributed system requirements. Best of all, Avatar 2 is coming soon to help promote this architecture. We can eventually replace the old sidecar motorcycle with amazing mecha pictures at all software conferences; -). Next, let’s look at the details of the software architecture.
This is a two component model similar to a client server architecture, where each component is an independent runtime. It differs from the pure client server architecture in that both components are located on the same host and have a reliable network connection to each other. These two components are equally important, they can initiate operations in either direction and act as clients or servers. One of the components is called micrologic, which has very little business logic and separates almost all distributed system problems. Another accompanying component is mecha, which provides all of the distributed system functionality that we’ve been discussing in this article (except for the lifecycle, which is platform functionality).

Here, the author puts forward the idea of mecha

Mecha: carry mesh to the end

The main ideas are as follows:Smart Runtime, Dumb Pipes

My understanding of mecha is: business logic should be “streaked” at the beginning of coding, focusing on the implementation of business logic, and not involving the underlying implementation logic as far as possible; while at runtime, it should be equipped with “mecha”, fully armed and killing all sides. Familiar taste, right? Standard and authentic cloud original idea.

The essence of mecha

In this paper, the author discusses the characteristics of mecha runtime

  1. Mecha is a generic, highly configurable, reusable component that provides distributed primitives as ready-made capabilities.
  2. Mecha can be deployed with a single micrologic component (sidecar mode) or as multiple shares (Note: I call it node mode).
  3. For example, it doesn’t use the microbubon, RPC, or even the open form of RPC / cloudwith it.
  4. Mecha is configured declaratively in simple text formats (such as yaml, JSON), indicating which features to enable and how to bind them to micrologic endpoints.
  5. Instead of relying on multiple agents for different purposes (such as network proxy, caching agent, binding agent), it is better to use one mecha to provide all of these capabilities.

Here is my personal understanding of the above features:

  1. What mecha offers isabilityIt is not limited to the ability of distributed agent.
  2. The deployment model of mecha is not limited to sidecar mode. Node mode may be a better way in some scenarios (such as edge / IOT, serverless, FAAS). At least, mecha has the opportunity to choose on demand, rather than tied to sidecar mode.
  3. The interaction between mecha and micrologic is open and has API standards. The “Protocol” between mecha and micrologic is embodied in the API rather than the TCP communication protocol. This provides an opportunity to unify the communication between micrologic and mecha.
  4. Mecha can be configured and controlled in a declarative way, which is very consistent with the cloud native concept, and also makes the API pay more attention to the ability itself rather than how the capability is configured.
  5. Applications need so many capabilities (see the figure above: four requirements for distributed applications). If each capability corresponds to a proxy (whether node or sidecar), the number will be very exaggerated, and the operation and maintenance pressure will be terrible. Therefore, as the name mecha implies, the runtime should provide capabilities in a whole set of forms, rather than decentralized.

To sum up in one sentence, I think the essence of mecha should be:

“Application oriented distributed capability abstraction layer”

Just as the essence of service mesh is the abstract layer of inter service communication, the essence of mecha is various distributed capabilities and primitives required by applications, including but not limited to inter service communication.

From this perspective, the scope of mecha coverage is a superset of service mesh: after all, service mesh only covers part of the application requirements (inter service communication is limited to synchronous / one-to-one / request response mode), and there are more distributed capabilities and primitives to be covered.

In other words, mecha’s goals should be:“Go to the end of mesh!”

Mecha’s advantages and future

The author points out that the advantage of mecha is the loose coupling between business logic and more and more distributed system problems.

The following figure shows the coupling of business logic and distributed system problems in different architectures

Mecha: carry mesh to the end

In fact, the idea and service mesh are in the same line, but the coverage of distributed capabilities is more extensive.

There is a question: will mecha become the next form of microservice architecture evolution? My personal answer: with the advancement of cloud nativity, it is the general trend that distributed capabilities (represented by traditional middleware) will sink. The scope of meshization will inevitably continue to expand, and it will be closer to the form of mecha. This is the intention of the title of this article. Mecha will be the next stop for microservices and even cloud native.

Microsoft dapr

After introducing the concept of mecha / multiple runtime, let’s take a look at Microsoft’s new dapr project, which should be the first open source practice project of multiple runtime in the industry.

Project address: 。

Introduction to dapr

Dapr is the abbreviation of distributed application runtime. According to the official introduction, dapr is “a portable, event driven runtime for building distributed applications across cloud and edge”.

Dapr describes in detail:

Dapr is a portable, serverless, event driven runtime that allows developers to easily build resilient, stateless and stateful microservices that run on the cloud and edge and contain multiple languages and development frameworks.
Dapr collates best practices for building microservice applications as open, stand-alone building blocks, enabling you to build portable applications in your chosen language and framework. Each building block is independent, and you can use one or more of them in your application.

The functions and positioning of dapr can be summarized in the following figure:

Mecha: carry mesh to the end

  • The bottom infrastructure is a variety of cloud platforms (supported by mainstream public clouds) or edge environment;
  • On top of this is the distributed capability provided by dapr, which dapr calls “building block”;
  • These building blocks provide services with unified API (supporting HTTP and grpc);
  • Applications can be written in various languages, and then these capabilities can be used through the API provided by dapr. Dapr also provides a client class library to simplify the call to the API, realizing multi language support;

The specific building block provided by dapr is shown in the following figure:

Mecha: carry mesh to the end

For specific capabilities provided by each building block, please refer to dapr’s official document:

Dapr API example

Let’s take a look at an example of an application calling the dart API to experience the way dapr is used.

Take service invocation / service call as an example

Mecha: carry mesh to the end

The deployment and invocation methods are very similar to service mesh / istio, but the difference is that dapr provides the capabilities behind the API in the way that API is provided, rather than protocol proxy.

In Figure 1, ServiceA initiates a request to call a remote service. The HTTP request is as follows:

POST/GET/PUT/DELETE http://localhost:<daprPort>/v1.0/invoke/<appId>/method/<method-name>

Among them:

  • The parameter daprport is the listening port started by dapr runtime to accept outbound requests from applications;
  • The parameter appid is the association ID of remote applications in DARP. Each app registered with dapr has a unique appid;
  • The parameter method name is the method name or URL of the remote application to be called;

The payload can be stored in the HTTP body and sent with the request, such as JSON.

Note that although they all provide the same functions, the difference between dapr (or mecha behind it) and service mesh is reflected in the following aspects: exposing API or proxy communication protocol.

Let’s take a more obvious example. The “publish / subscriptions” capability provided by dapr allows applications to easily publish messages or subscribe to topics and receive messages. The following figure shows the application publishing message, and the request can be sent directly to dapr:

Mecha: carry mesh to the end

In the example, the parameter topic specifies the topic to which the message is to be sent (in the example, deathstarstatus). Subsequent dapr will complete the message into the queue, and then push it to the application that has subscribed to the topic. The way to receive messages is similar, but this time it is initiated by dart

Mecha: carry mesh to the end

  1. Dapr will first request the application and consult which topics the application needs to subscribe to, such as the topica / topicb returned by the application in the example;
  2. Dapr implements topic subscription. After receiving the message, it sends the message to the application. Different topics are distinguished by different URL parameters;

Note that during this call, whether sending or receiving messages, the application does not care about the underlying pub / sub implementation mechanism (such as Kafka, rocketmq, or other message mechanisms provided by the public cloud), and does not need to introduce the client SDK of the implementation mechanism at all, but simply uses the API defined by DARP That is to say, it can decouple from the underlying layer and “the manufacturer is not bound”.

In order to further simplify the call process (after all, sending the simplest HTTP get request also requires the implementation of HTTP protocol call / connection pool management, etc.), dapr provides SDKs for various languages, such as Java / go / Python / dotnet / JavaScript / CPP / rust. In addition, it also provides HTTP client and grpc client.

Taking Java as an example, the client API interface of Java is defined as follows:

public interface DaprClient {  
   Mono<Void> publishEvent(String topic, Object event);
   Mono<Void> invokeService(Verb verb, String appId, String method, Object request);

The details are as follows:

Analysis and summary

This paper introduces the architecture of multiple Runtime / mecha and Microsoft dapr project, which is one of the reference implementations.

As the idea of multiple Runtime / mecha is very new, it has just been put forward, and Microsoft dapr project is also a new project. Both the theory and practice are in a very early state, and there is no perfect methodology.

Special statementThe following content is more of my current understanding and perception, only represents personal opinions, there must be a lot of immature and even fallacies, welcome correction and discussion.

Inspiration from mecha and dapr

  1. The mesh model should be pushed to a larger area.

With the development of cloud primitiveness, the distributed capabilities required by applications should sink in an all-round way, not limited to the inter service communication capabilities provided by servicemesh; the application form will go further towards the goal of pure business logic, and the application will be more cloud original.

This is the general trend and the driving force for the emergence and development of mecha architecture.

  1. Mecha emphasizes “capability” rather than communication agent.

There is a big difference between the usage of mecha and service mesh: mecha emphasizes the provision of distributed capabilities for applications, which are finally presented in the form of well encapsulated APIs. API reflects the application’s “demand” and “willingness” for capabilities, and does not involve how to achieve it. Implementation is the responsibility of mecha, and what kind of implementation is adopted is also controlled by mecha.

Under service mesh, there is no such requirement: service mesh provides inter service communication capability, which is provided by sidecar. There is no other lower level implementation, and there is no possibility of isolation and replacement. Due to the limitation of service communication protocol and message schema, service mesh can only “forward” the request, and its ability focuses on “how to forward”. It has no other ability to isolate and replace.

When mecha extends its capabilities beyond service mesh, many capabilities are provided by external systems: for example, pub sub capabilities can be implemented by different message queues; state management capabilities can be implemented by connecting different key values. At this time, the isolation and substitutability of capabilities become the key requirements: decouple application and capability implementation, and allow mecha to replace the underlying implementation (thus realizing the supplier not locking, etc.).

  1. No “zero invasion” is required.

In service mesh, “zero intrusion” is a very important feature, so we do not hesitate to introduce iptables and other traffic hijacking schemes. “Zero intrusion” will play a huge advantage in some special scenarios, such as accessing service mesh without modifying old applications. The advantages are self-evident, but zero intrusion also has its own limitations: the client must be able to send network communication requests that meet the requirements of the server, and the process cannot be interfered by the outside.

For inter service communication, this is not a big problem. However, for other capabilities, due to the need to decouple from the implementation, it is not appropriate to initiate native protocol requests through the client. Therefore, mecha tends to adopt a lightweight SDK scheme with low intrusion. It can also realize cross language and cross platform, but it needs to pay the cost of implementing various language SDKs. Because the SDK is light enough, the cost is not high.

These small amount of work and a small amount of intrusion can be exchanged for the convenience and cooperation provided by the lightweight SDK (simple understanding: opening the back door), which can realize the abstraction of capabilities and the encapsulation of API. Weighing the pros and cons, mecha prefers lightweight SDK solutions.

  1. Sidecar deployment is not limited.

Sidecar deployment mode has the disadvantages of resource occupation and maintenance cost increase, which may not be suitable in some cases

  • Edge network and IOT scenario: the resources are very limited and it is not suitable to start too many sidecars;
  • FAAS scenario: the application itself is light enough, even lighter than sidecar;
  • Server less scenario: when scale to zero, there are strict requirements on the cold start speed, and the startup and initialization of sidecar may drag down the application startup speed;

In mecha, the deployment mode is not limited to sidecar, node mode is allowed to be selected when appropriate, and even node mode and sidecar mode are mixed.

  1. API and configuration are key.

API is the abstraction of distributed capability, which needs to be customer-friendly, easy to use and stable. These APIs also need to be standardized and widely accepted and adopted by the community in order to realize the non lock-in and free migration of manufacturers and improve customer value.

In addition, the API also needs to be used with configuration. When abstracting capabilities as APIs, they do not provide detailed control of capabilities. These controls will be implemented by mecha at run time according to the configuration, which can be understood as “API + configuration = complete capability”.

The formulation and standardization of API and configuration are expected to be the key to mecha’s success or failure.

The essence of mecha

Program to an interface, not an implementation.
Design Patterns: Elements of Reusable Object-Oriented Software (GOF, 1994)

The essence of mecha begins with the following famous saying:

  1. In mecha, in order to implementdecoupling andReplaceable, Runtime quarantineThe underlying implementation is changed into “program to an”Runtime, not an implementation.”
  2. Considering that the runtime, whether deployed in sidecar mode or node mode, is localhost, so it has the following characteristics: “program to an”Localhost, not an implementation.”
  3. In order to simplify development, mecha will still provide lightweight SDK and API as a capabilityabstract:“Program to an API, not an implementation.”
  4. Considering that API is usually provided in the form of interface, mecha finally returns to the origin: “program to an”interface, not an implementation.”

Personally, the essence of mecha lies in these key points: isolation / abstraction / decoupling / replaceability. As shown in the figure below:

Mecha: carry mesh to the end

  • In mecha, micrologic (i.e. the code implementation of business logic) does not allow direct use of the distributed capabilities provided by the underlying implementation;
  • Mecha runtime will provide distributed capabilities for micro logic while isolating applications and underlying implementations;
  • In order to be convenient to use, lightweight SDK is provided, in which the API layer realizes the abstraction of distributed capability, and the application only needs to be oriented to API programming;
  • The combination of lightweight SDK and mecah runtime can decouple and replace the underlying implementation;

The implementation principle of mecha

On the implementation of mecha, I understand the following principles:

  1. Runtime is the main force to be thick;
  2. The lightweight SDK is mainly used to coordinate with the runtime;

Mecha: carry mesh to the end

Specific division of responsibilities:

  • Lightweight SDK: multi language access, low intrusion (but no zero intrusion pursuit);
  • API interface: unified and target community + standardization are provided in lightweight SDK to provide developers with consistent programming experience and portability;
  • Application: the lightweight SDK / runtime provides various distributed capabilities, and the application is insensitive. It only needs to simply use the API and does not couple the underlying implementation;

In mecha architecture, runtime is naturally the core of the whole architecture, playing a role similar to the data plane in service mesh

  • All the processes of using distributed capabilities (including accessing internal ecosystem and accessing external system) are taken over and masked by runtime;
  • Realize declarative configuration and management (similar to service mesh) through CRD / control plane;
  • In terms of deployment mode, runtime can be deployed as either sidecar mode or node mode, depending on specific requirements and not mandatory;

Note: mecha has a lot of capabilities and implementation details. Here’s an overview of high level. Details will be covered by a series of articles one by one, welcome more exchanges and discussions.

Mecha summary

Probably in early March, when I first read the article “multi runtime microservices architecture”, I had a feeling of sudden enlightenment. In particular, there were many problems that had been repeatedly considered and weighed but could not reach a conclusion. In this article, I got a clear answer. It has benefited a lot.

During the three years of exploration and practice of service mesh, many problems have been encountered, and many problems that have not been thought of before have emerged. For example, I always thought that the biggest trouble caused by the introduction of sidecar in service mesh would be performance, but in fact, from the current practice, the maintenance cost brought by the introduction of sidecar is a more troublesome thing. In contrast, the performance loss brought about by the introduction of sidecar seems harmless.

To summarize my core understanding of mecha architecture, there are two main points:

  1. Mecha is the inevitable trend of cloud proto biochemistry and mesh: cloud Nativity continues to develop, the distributed capabilities required by applications need to continue to sink, and more and more capabilities will appear in the form of sidecar, which is the general trend. However, it is impossible for an application to deploy more than a dozen sidecars, which will be the operation and maintenance hell. Therefore, it is necessary to appear new forms to solve the problem of too many sidecars, and it will become inevitable to merge into one or more sidecars.
  2. Mecha is the natural evolution version of service mesh mode: service mesh has been implemented for three years, but the effect has not been ideal. It is time to reflect on it. Moreover, the scope of mecha is far more than the communication between services, and there should be new thinking and breakthrough under the new demand. The existing fixed mode of service mesh can be broken under mecha to explore new ways: don’t stick to sidecar, try node mode; don’t stick to communication protocol forwarding, try to decouple the underlying implementation of runtime capability; do not be constrained by zero intrusion, try to keep a lightweight SDK that is light enough in the application.

As has been said, “micro service is the good part in SOA practice”. I hope that in the exploration and practice of mecha, we can learn from the practice of service mesh successful experience and failure lessons, and hope that mecha can also become a good part of service mesh. It is hoped that in the evolution route of cloud native, mecha can become the next station of cloud native landing practice after microservices and service mesh.

Back to reality, at present, mecha and multi runtime are still a very new idea. The dapr project has just started. Mecha has a long way to explore, and everything still needs to grope for progress.

Appendix: References

At the end of the article, I would like to thank the author of “multi runtime microservices architecture”“Bilgin Ibryam”I very much agree with the ideas and ideas in this article. The analysis and summary are in place, and the ability to refine and sublimate is admirable.

The author introduces:
Mecha: carry mesh to the end
Chief architect of red hat, committer and member of Apache Software Foundation. Open source evangelist, blogger, occasional speaker, author of books kubernetes patterns and camel design patterns.

This paper refers to the following contents produced by bilgin ibryam:

  • The idea of bilgin ibryam, mecha, author of multi runtime microservices architecture, comes from this article and is highly recommended. You can also look directly at the version I translated for the multi runtime microservice architecture. As mentioned earlier, it is recommended to read this blog before reading this article.
  • The evolution of distributed systems on kubernetes: the author, bilgin ibryam, gave a speech at qcon London in March 2020, which is still highly recommended. The content is very wonderful. It summarizes and prospects the evolution of distributed system on kubernetes. Of course, it still preaches the concept of multi runtime microservice architecture. Many of the images in this article are quoted from this ppt.

Recommended Today

Layout of angular material (2): layout container

Layout container Layout and container Using thelayoutDirective to specify the layout direction for its child elements: arrange horizontally(layout=”row”)Or vertically(layout=”column”)。 Note that if thelayoutInstruction has no value, thenrowIs the default layout direction. row: items arranged horizontally.max-height = 100%andmax-widthIs the width of the item in the container. column: items arranged vertically.max-width = 100%andmax-heightIs the height of the […]