The author | | AoXiaoJian source alibaba cloud native public number

Dapr is a portable, event-driven distributed runtime that Microsoft opened source in October 2019. It enables developers to easily build resilient and microservitized stateless and stateful applications running on cloud platforms and edges, lowering the barriers to entry for building modern cloud-native applications based on microservices architectures.

V1.0 was released in February of this year. It’s only been a year and a half since the launch, but Dapr is gaining momentum and currently has 1.2 million stars on GitHub. Alibaba is a deep participant and early adopter of Dapr open source project. It was the first to launch production and has more than a dozen applications using Dapr within the group. There are now two Dapr members, the largest code contributor to Dapr other than Microsoft.

At the end of this article, you can learn how to experience Dapr tutorial

Why did Ali choose Dapr?

Java is widely used in Alibaba, not only in business applications, but also in the server side of a large number of middleware and basic capabilities. Over the last decade or so, we’ve built a very complete ecosystem around Java, and we’ve been through all sorts of ordeals.

With the increasingly rich business forms, the demand for multiple languages is increasing, such as NodeJS/Golang/C/C ++ / Rust. Especially after the popularity of microservices, it has become a trend to choose different programming languages to develop microservices according to the actual situation. But emulating Java and creating a fully functional ecosystem for every programming language is not cost-effective. Therefore, a cost-effective solution is needed to solve the multi-language problem, so that the development of micro-services can truly achieve “language freedom”.

With the adoption of cloud, the form of business applications also begins to develop towards cloud native direction, and more and more business applications (especially front-end services) begin to embrace FaaS and Serverless as application hosting and resource scheduling solutions. In FaaS and Serverless scenarios, lighter solutions are needed to meet the need for fast startup and scaling — business applications become bloated in the traditional class library model due to the need to integrate a large number of SDKS. However, in the Function form, it is more incongrent. Take NodeJS as an example: hundreds of lines of NodeJS Function code still need to rely on tens of megabytes of Node modules. At the same time, FaaS and Serverless also provide higher requirements for multi-language support. Therefore, in the new form of FaaS and Serverless, it is necessary to provide lighter, multilingual solutions that are different from the traditional class library approach.

Obviously, the Sidecar pattern advocated by Servicemesh is an excellent solution to these problems. Over the past few years, with the growth and adoption of Servicemesh, the Sidecar model has been well proven: The Sidecar model fits well with the idea of cloud native, especially with its natural advantages in multi-language support and application lightweight.

We appreciate the Multiple Runtime/Mecha Runtime concept proposed by Bilgin Ibryam in “Multi-Runtime Microservices Architecture”. In particular, his analysis of distributed application requirements is in line with our actual situation:

Dapr was the first open source project to implement the Multiple Runtime concept, and we paid close attention to Dapr since its release because Dapr was a good solution to our problems: Sidecar mode naturally provides support for multiple languages, and applications are lightweight after various client SDKS are replaced by Dapr Runtime.

In addition, from the perspective of long-term strategy, we put forward the concept of “Trinity” in 2020, that is, “self-developed technology”, “open source projects” and “commercial products” form a unified technology system to maximize the value of technology. However, the actual situation is that the three have completely different products and technical solutions, which leads to great challenges when we need to migrate a product on different platforms such as Ali internal, public cloud and customer private cloud, or deploy it across multiple platforms. Dapr’s capability-oriented programming philosophy, its standard APIS that emphasize portability and extensibility, and its platform-neutral, vendor-free design appealed to us.

“At Aliyun, we believe that Dapr will lead the development of micro services. By adopting Dapr, our customers can now build portable and robust distributed systems at a much faster rate.”

— Li Xiang, senior technical expert of Aliyun

In mid-2020, we started an internal pilot based on the Dapr program to explore and verify the Dapr concept in the actual landing process. We also actively participated in the construction of Dapr open source project, submitting numerous suggestions and code for improvement.

Here’s how Dapr helped solve this problem, using the actual landing in Ngari.

Dapr’s practice in Ali

Profile 1.

Dapr is currently in an experimental stage within Alibaba.

Our first effort was to develop Dapr components for internal middleware so that business applications could decouple from these middleware and the Java language/Java Client SDK that implemented them. After that, Dapr will be verified in various scenarios through small-scale business applications. After verification, we plan to continue to deploy large-scale business applications.

As of March 2021, Dapr’s implementation scenarios within Alibaba focus on two areas: multilingual support and cloud-to-cloud migration.

2. Multi-language support

1) Faas/Serverless scenario

Background: There are a lot of activities and shopping guide needs in Alibaba’s e-commerce system.

These requirements are characterized by “short and fast” : rapid development, rapid iteration, and relatively short life cycles. Therefore, such requirements are well suited for implementation through the adoption of FaaS.

Faas has a strong desire for multilingual support, certainly not limited to Java. However, most of alibaba’s internal applications are Java architecture, which has weak support for multiple languages, especially emerging languages (such as Dart) or niche languages (such as Rust).

In terms of requirements, applications using FaaS also need to communicate with internal running services and various middleware/infrastructure, so the FaaS platform urgently needs to solve the problem of multilingual support.

With Dapr, we solved the multilingual problem of FaaS, allowing customers to achieve a significant increase in development efficiency through FaaS.

2) Access to multi-language applications

Background: Alibaba has acquired a large number of companies.

These acquired companies have a large number of applications, many of which are not Java architectures and have a clear need for multilingual support when accessing Ali’s technology architecture.

In addition, due to business innovation, some applications have a strong appeal to nodejs and golang, while others require Dart and C++.

However, the current ecosystem of these languages is not as complete as Java, especially since some of the middleware and infrastructure has matured into a maintenance state, and it is not possible to redevelop clients for all languages at this time: it is costly and too late.

With Dapr, we can provide multilingual solutions for these applications.

3) Complex Java legacy systems

Background: Complex system based on Java ClassLoader mechanism.

In order to solve the problem of class conflict and isolate different business modules, Ali designed a complex system based on ClassLoader mechanism for Java system. The design of these systems is often very complex and the application is very bloated.

In addition, in order to communicate with existing middleware, some business teams maintain a set of multi-language middleware SDKS, which should be maintained and updated synchronously by the middleware team. This also creates stability pitfalls and risks.

We expect to migrate these legacy systems into Dapr for unified maintenance and updates to the middleware SDK. In particular, there is a requirement that the business development team do as little code-level adjustment as possible to minimize the impact of migration on the business application.

So for Java legacy systems, when we moved to Dapr, we designed an additional Java adaptation layer that ADAPTS the original Java calls to Dapr’s client API.

The above three multi-language practice scenarios are shown in the figure below:

3. Cloud migration

Background: Service applications require cross-platform output.

Some of Ali’s services, such as Dingdingdocument, were originally provided for internal and external users to use directly. At this time, Dingdingdocument only needs to be deployed in the internal business cluster of Ali to directly access the internal ecosystem of Ali.

However, with the development of SaaS services and the strong demand for data security by some information security-sensitive users, it is necessary to deploy nail documents in users’ VPC or public cloud.

To do this, we need to migrate the pegdocument system from Ali internal to the public cloud for deployment, and the underlying technology used by pegDocument needs to migrate from Ali internal technology system to commercial products using open source technology or Ali Cloud.

With Dapr’s standard API and extensible build model, our strategy is to enable users to mask the underlying middleware directly through Dapr Runtime without changing any code: to provide consistent capabilities by activating different components in Dapr when deployed on different platforms.

With messaging power, when an application needs to access a messaging system:

• Inside Ali: Activate Rocketmq components via RocketMq. yaml.
• On the public cloud: Activate the Kafka component through kafka. yaml.

With the portability of Dapr, the upper level of the pinned document application can now be decoupled from the underlying infrastructure, such as the messaging system, allowing smooth migration between different cloud platforms:

Ultimately, it helped our business team achieve their business goal: to make deployment of Dingtalk anywhere possible.

Ali’s plans for the future of Dapr

We will continue to validate Dapr through pilot applications in the future, including:

• Applicable scenario
• performance
• The stability of
• portability

At the same time, we will continue to develop Dapr components to integrate more middleware and infrastructure, including internal products and commercial products supported on Aliyun. Among them, we will contribute the integration code of Aliyun commercial products to Dapr project after verification, so as to provide Aliyun support for Dapr. These projects are expected to include:

• RPC support for Apache Dubbo
• Apache RocketMQ messaging support
• Dynamic configuration support for Nacos
• Ali Cloud RDS MySQL support
• Redis support for Ali Cloud cache service

As a Multiple Runtime architecture pioneer and an early adopter of the Dapr program, we will continue to work with the Dapr community to improve the functionality, performance, stability and other key indicators of Dapr as it is implemented. And the community together to create the cloud of the era of native DistributedAPplicationRuntime!