 Hi, everyone. Welcome to KubeCon. In this talk, I'm going to talk about how we use KubeVela and Dapper to develop and build microservice applications. Before we start, let me introduce myself. My name is pronounced as Hong Chao Dan. I'm currently working as a staff engineer at Alibaba and focusing on cloud-native application delivery. I love open source and have been contributing quite a while. I am a committer of KubeVela, OAM and Cosplay projects. In the following, I will first introduce KubeVela's background and overview. Then I will dive into its architecture and provide more detailed analysis. I will conclude KubeVela's section with some of its key features for application management. And then I will give a brief introduction about Dapper. And finally, I will talk about how Alibaba uses KubeVela and Dapper in production and do a case study on application monitoring. First, let's talk about KubeVela. Let me start with talking about the background first. Like delivering applications on Kubernetes needs composing a couple of Kubernetes resources. For example, deployment, state-of-the-art, ingress, services, etc. Usually we not only need to bundle all those resources into a package, but we also need a composition model to parameterize and connect those resources together. A few approaches have been trying to solve these problems. One is called application CRD from the Kubernetes SIG. Why it's the earliest from upstream effort? It doesn't resolve any developer or operator concerns so far, other than providing basic metadata. It doesn't work for application rollout for this reason. And there isn't any active development on it as far as I can see. Another project that a lot of people use in production to manage applications is Ham. More specifically, users just write some templates of Kubernetes resources and put them in a bundle called chart. Why HamChart? A lot of people use it. They are two black boxes to use this. The HamChart is built as parameter values, which is hard to understand and infer operation resources underneath. Additionally, the parameter values doesn't have API schema defined for them. Finally, chart doesn't have any composition model that you can use those modules of templates to just plug and play and we use across different projects. Very often, platform teams decide to build their in-house application CRDs to solve the problems I just discussed. For example, Pinterest has built its own Pinterest service and Robinhood has its own application of CRD. But developing such thing requires strong Kubernetes development skills, which means very high learning curve and very few people can do it and deserve the time to do it. And these APIs are usually very in-house and not generic for reuse or extension. So what Pinterest built for itself where we couldn't use it in Robinhood or other companies, right? And they only offer limited composition model for their own resources. So like this is very in-house and not like generic uniform experience in the open source side. So the solutions that we talked about earlier had their own limitations and couldn't satisfy many of the use cases we have seen. The application model we need are at the end of the day bogged down to two requirements. It should let platform teams expose high-level APIs of only users' concerns and hide those infrastructure complexity. And secondly, it should be an extensible model that provides uniform experience to manage all CRDs and compose all resources on Kubernetes, not just like in-house or limited by resource set. So we would like to basically, we would like to have the simplicity of the ham values file and the structural experience of like those application CRDs that we see from many, for Pinterest or Robinhood and also an extensible open core model that like people can just bring their own operations resources and they can just compose them together. To satisfy this needs, we do a project called KubeVela. It's an application engine to assemble different resources and expose high-level APIs. It's based on open application, OAM open standard, which is initiated by Alibaba and Microsoft. It uses Kubernetes as the control plane. And so you can reuse like Kube CTL to, and all those tools you're familiar with Kubernetes to do to like play with it. And after it's released in KubeCon North America last year, like KubeVela have become trending on GitHub right that day and have been growing ever since. So it's an active growing project. So here's an architecture diagram of how to deliver like applications on KubeVela. Let's take a look. So first the platform teams need to set up deployment environments and capability templates. Basically the capabilities are defined as workload or trade definitions, which include the templates to expose the high-level APIs. These definitions are all registered in Kubernetes as CRDs. When developer users want to deploy their apps, they choose the target environments and pick the high-level templated APIs and compose application objects, and finally roll out applications objects to life clusters. That's basically the general workflow. And here's more details about like the KubeVela application object. An application consists of multiple components. Each component is a separate service that contain the basic parameters to run a service workflow. And a component could be attached with multiple trades. And each trade is an operations enhancement to the app. For example, you might add auto scaling trade to a component and the component will have the auto scaling operations like automatically done. And here the component and trade definitions are also like fully extensible. You can add more like component type and trade types to it and so that like your user can use it. Also we will look at that later for example. Let's take a deeper look into the component definition object. Basically it encapsulates a workload type that takes the major role to run the service. It provides a couple of templating methods and for platform teams to choose, you can use ham, queue, or terraform like HCL languages. It also writes back useful information in status. For example, there's just a schema of the exposed parameters and there's other things like you can write health chat back to the status as well. So now let's take a deeper look into the trade definition object in reference to a CRD that provides the operations capability. It tells the workload types that it can apply to and it also provides a couple of templating methods for platform teams to choose like you can use ham, queue, or terraform to write the modules. It also writes back useful information in status which is just a schema of the parameters. Now let's walk through an example of how Coup-Bella works in real-world organizations. First, the platform team creates an operator called matrix. They use the matrix as a shader so they need to write the trade definition as a matrix YAML file and the platform admin, usually this is the platform team itself as well, could execute a command to apply these definitions files along with the operator resources onto the cluster. In this way, the capability will be registered on Coup-Bella automatically. Then the developer users can just use the matrix as a cheat in their application objects and finally roll out it to dive. Note that there's no need to restart or upgrade the platform itself. That's how Coup-Bella will take the registration and handle this automatically. You can see how Coup-Bella solves some critical team collaboration problems. There are many other features that we don't have enough time to cover the details. Notably, we have the application rule out object which is doing the progressive rule upgrade, also app deployment object that can do multi-cluster, multi-vision application rule out. There's some health policy to do health checking and custom status that you can write some status reports using Q and there are some catalog environments and control playing features as well. If you're interested, please check out the website below. Secondly, let's talk about Dapper. Dapper is a polyglot distributed application one time. This means it can work for multi-languages. It provides basic building blocks such as state management, PubSub, RPC routing, and active programming models, etc. It's danceable and pluggable design as a community-driven open-source project and also providing consistent portable and open APIs. It's a platform elastic which means it could run on cloud or edge across different clouds. Finally, let's take a look at how Qt Vela and Dapper are adopted and used in Alibaba. Alibaba contributes a lot to both projects. We basically have five committers on Qt Vela and three committers on Dapper projects. They are widely adopted in Alibaba. We have more than 10 platforms, thousands of apps, and that's running them in production. There are solutions across five industrial scenarios. Let me give a case study of how we use Qt Vela and Dapper to achieve application monitoring. We first developed a matrix sheet that basically translates the app-consent values, which is the port and also the export type, into Kubernetes resources that actually made the Dapper sidecar and Dapper resources that will trigger the sidecar to connect matrix from the application port. The Dapper sidecar will then push the matrix to open telemetry collector, which is basically an intermediate storage. The collector will finally export the matrix data to S2 systems to consume and display, and that depends on the environment. For open source users, they can use Prometheus and Grafana to export the data and show it on Grafana dashboard. For cloud, there are other more smooth integrations, like we can use Alibaba ARM services or CloudWatch or Datadoc, those kind of services to get the matrix and show it on dashboard. That's basically all I have to talk about with Kubevela and Dapper today. If you are interested, definitely follow us on Kubevela project and let us know if you have any questions. Thank you.