 Do you prefer to use Kubernetes raw through YAML or do you prefer to have a platform on top of it? If you choose Leder, I'll be very happy to introduce to you my product, Kubeela. If you choose a former, I'll still try to convince you against it. Hi, I'm Andy Shi from Alibaba Cloud. This talk is about standardizing cloud native application delivery across different clouds. A little bit background of who are we? We are platform builders and our customers are developers, application developers especially. We have a large team. We have people working on Kubernetes directly. We have teams working on pass and we also have infrastructure operators. And our customers are internal customers, which is the e-commerce sites of Alibaba. So we maintain some of the world's largest Kubernetes cluster, more than 10,000 nodes. Also, we are the team that's on the Alibaba Cloud, which serves the public as public cloud offerings. And what do we build? We build platforms, basically, extending Kubernetes. And we serve both the external customers or public cloud customers and private cloud customers and internal business units as well. So our infrastructure is a hybrid infrastructure. We have cloud infrastructure. We have on-prem and we have hybrid cloud solutions as well. But mostly our paths are a wide range of platforms, basically ranging from the full-scale paths to lightweight serverless and middleware platform. And we also have things like Eda's, which is an enterprise distributed application service. So all these different flavors, but they all share a lot of features that are common and maintaining so many different versions of the same feature really is painful. And that's why we are looking at some better approaches to solve this problem. But before we get to the solutions, I think one other question people always ask is why do we build platforms? Well, like I said in the beginning, if you prefer to use YAML, that is just a small percentage of users. The majority of developers prefer to not directly dealing with Kubernetes, not just because of YAML, but because of the exposure of Kubernetes capabilities right now is very primitive. Imagine this, right? Instead of using Linux share commands, you have to use syscalls to implement the same features. And you need to train the different syscalls together just to implement one function. That's what Kubernetes is right now. So majority of our users, which are application developers, they prefer the application-centric way, meaning that they don't really care about the cluster. And a lot of tools or platforms, they will provide this cluster-centric or infrastructure-centric view of how many deployments you have, how many other things that's in your cluster. But for application developers, what they care about is my application, right? What they want to have is to just ship their code, build it, package it, and deploy it. They really don't care about the cluster or infrastructure, etc. So a lot of our efforts also are concentrated on making the application-centric API or making the application-centric abstractions and application-centric user interfaces, right? Basically, I do a lot of modeling. So I guess what I just described, the problems and the goals are common amongst many, many different tools or platforms. Everyone is trying to manipulate the Kubernetes API some way so that it's more acceptable to the developers and everyone is struggling with trying not to reinvent the wheels, as we often say. So let me give you a little taste of what Kuvila does before we move on to explain how we are doing it. And this demo is, I would say, the first demo of Kuvila. So if you see it and feel like it's not very impressive, I totally understand. But I would like to tell you that inside of Alibaba, so many different platforms, we are building this together. So in the short term, we should see a huge difference. Let's get through the demo. So with the workloads, we show you the workload types that's available. So these are the basic types. The back end is the workload that doesn't open a service or doesn't open a port. The web service on the other side, we just open a port. So what web service will do is going to create a deployment and a service with a port. Back end would only have a deployment on the Kubernetes. But we do not expose these APIs to the users. Task is a job for Kubernetes. But again, we don't expose those APIs to the user. So these workloads are abstracted to or from Kubernetes workloads, but they're not really correlated. It can be customized and we're going to see it. And another tool, another command we're going to see is VilaTrades. And it's going to show you all the available traits that you can add attached to the components. And here on the right side, you can see what kind of, what type of workloads this can apply to. And it is a convenient way to show you. But we think it would be better if we can have an in conflict with it. So some traits are in conflict with another. So we need to know, like in description, what is available if we have added one trait, if the next one will have a conflict or not. But anyway, so that's some useful commands that we can use with Vila. But we can check how many commands are available. So if we just type Vila, we can see there are a lot of them. But they're pretty concise. So we have the minimum information that's going to show I'll be printed because we don't want to overwhelm users. And it has created an app and a component. So look at this. This is how we design this command line. We say comp. And we specify the type of the workloads and the image and the port we want to expose. And of course, it's web service. So you will see a deployment and a service. And as last we say, it's the app name is my app. So why don't we do it the other way, right? So if we create an app first and then add comp, add components to it, this command line would be more cuba. So because it's going to be Vila create app my app, and then Vila app my app, add comp or deploy comp is it. But nevertheless, it really is the app-centric view or app-centric way of doing things. So let's take a look at this app, right? Vila app status. It's going to show you this application. So yeah, so as you can see, it shows you this application, how many components it has. And also it has the house check. But this house check though is not always reliable because some parts of some workloads might not have this house check. So here you're going to see some area information. So that's something we need to work on. Okay, so we've done with the demo and I hope you like it or enjoy it. I would like to tell you more about this platform. So who is it for? It's mainly for developers, right? Developers are our users or customers. But it's also for platform builders. Let me explain a little. So for developers, what we provide is the traditional people are familiar with those pipelines where you can ship your code and build it and deploy it and release it and operate on top of it, right? In terms of operation, we're talking about Kubernetes capability, like traffic shifting, adding a domain, adding TLS, doing canary deployment, etc. All these things, we can do it. But so do all the other platforms. But for platform builders, there are always two questions to answer. One is how do you make that opinionated approach of your presentation layer? And the second one is how do you absorb the new features, new capabilities that emerge every day from the community? So Kuvila addresses these two problems by adopting what we call the OEM open application model. What it does is it allows new capabilities to become building blocks so that platform builders don't have to reinvent the wheels. They can focus on how to present them. Even though the features look similar or actually the same, the presentation can be hugely different. Like we've just seen in our use cases, we have pass and pass or serverless at the same level. So they're using the same features. How do you present them to the user? That's another problem. So Kuvila is aiming to help platform builders to alleviate the pain to adopt new features and presenting them easily to the customers. I would like to tell you about the three design principles of Kuvila. Number one is its application-centric. So it's built for the developers. So we definitely put developers in just at the top priority. Application should be the main API that exposes to users. So we don't have things like deployment, replica set, all those APIs from different packages. No, it's all about your applications. And the second principle is we believe that it should be capability oriented. So each feature, each new feature can be added or old features can be deprecated. Without breaking the build without breaking what we have here. And also you should be able to swap out certain capabilities of those building blocks without even changing the look and feel of your product. And that's something we really are trying to make a difference. And the third principle is it should be highly extensible, especially for its user interface. So what we are talking about is we want to decouple the user interface from the underlying APIs. That's one. And also it should be highly extensible. So we just talked about how painful it is to build an opinionated approach pipeline. So you always lose some customers in that process. What we want to do is to have a very flexible structure that you can satisfy most of them, if not all of them, by extending your GUI by keeping different revisions of the look and feel of your APIs and serving them to your customers. So that's the three design principles of Qvilla. So next let's look at a simple diagram of Qvilla. In this diagram we are seeing that the user will interact with Qvilla through GUI. There's a GUI that we built and also through a CI that give people the flexibility if they have something simple to change or simple to deploy. And also we would have what's called the app file to deal with complicated, more complicated user configurations. Now what we have for the users is they're dealing with applications. So they're dealing with workflows and traits. What are workflows? Workloads are things that's runnable. It can be a pod, it can be a task, it can be a job, and it can also be a remote cloud service. What are traits? Traits are operations that you want to attach to the workloads, things like scaling, rollout, routes, etc. These traits don't exist by themselves. They have to be tied to a workload to take effect. So these are called traits. The term comes from Rust. On the right side we see all the capabilities, what they are, they are the things that's coming out of the community. We have Flagger, we have Keda, we have Nginx, etc. Very rich, but you can also define your own controller or CRD and we can shape them into the building blocks of traits and supply them to the customers. So that's really what could be in a nutshell look like. And we briefly talked about the app file. What is the app file? If you take a look at this on the app file, you're going to say, oh, well, it looks a lot like Docker file. Well, actually Docker Compose file. Yes, that's really the target. We want to bring in this Docker Compose user experience, but if you look closely, you're going to see that we have a lot more than what Docker Compose can do. We actually put traits or operational tasks inside this app file. So users can define what their whole application looks like. And it doesn't have to be just one container. It can be several, right? In the microservices architecture, you can have several components or several workloads, and each one would have one or more traits that's attached to them. That's what this app file should be. So on the right side, you're going to see a couple of templates. So these are the templates we talked about earlier. How do you manipulate the user interface? So we use the same card queue template to generate these templates and to evaluate them. The good part of this is that when you change the template, let's say you create a new template, it will not need any additional steps to directly appear on the API and also on the GUI. And you can use them directly in your app file. This app file will be evaluated strictly using the templates. And the good thing about the template is it decouples from the API itself. So in the definition part, on top of the template, you're going to see typical Kubernetes APIs. There's a kind, there's a group, there's a name, right? But when you are translating them into templates, you don't have to follow that, right? You can define your own, you can even negotiate with your developers what they like to call those terms and then put them into the app file. So in the end, as a result, what we have from the app file is that the app file looks nothing, nothing like a Kubernetes YAML file, right? And that's the beauty of what we are doing. Next, let's take a look at the architecture diagram of KubeVilla. Well, if you look at this, you're going to say, well, it looks like that previous natural diagram inverted 90 degrees. But here it gives you another perspective. So here we are talking about two levels of abstractions. Let's go from the bottom up, right? At the bottom, we see several different projects we listed. And all these projects will provide CRDs or operators, right? And those CRDs and also with some building CRD controllers from Kubernetes itself will be shaped into the building blocks, which would be the workloads and the traits. To the user, there's another layer of abstraction, which is what we just talked about, the Q-template. So by using that as decoupling again from the APIs, and it provides a user, a very user-friendly application-centric view, and also to the platform builders, they don't have to be bound by the API terminologies. So the users can choose to use from a file or CLI or using the GUI if they like to interact with the system, the platform. One thing I would like to point out is here we listed project crossplane here. So what crossplane does for Qvilla are two things. One is it provides the infrastructure resources or cloud resources, the managed cloud resources, that's the right term, to Qvilla. And B is it also hosts the OAM runtime, the open application model runtime. It's very important. And also I would like to point out that there's a CRD registry, something we want to have, actually we call that the capability registry. So we can keep track of or manage the capabilities that we have inside of Qvilla. So this is basically what the architecture of Qvilla looks like. If we reflect them back to the three principles, we can see that it provides an app-centric view and it gives us the extensibility that we are looking for both on the UI side and also on the capability side. Also we have the capability oriented architecture where the building blocks can be added or removed from our Qvilla system without breaking the others. In summary, Qvilla is a project for developers, provides an app-centric platform and it's very easy to ship application, especially cloud native application, and to manage them on Kubernetes clusters. For platform builders, it's highly extensible and it's simpler to maintain, especially when you're talking about adding new features on day two. Current project status, we are still in a pre-release stage. So if you try it, probably something will break, but hopefully not. We have a roadmap, we would like to have a 1.0 release on December. Current features that's available would be ffile and cri, and dashboard is still working progress, and we have a couple of workflows defined already. So I would like to stress here that for each and every project, there are three different perspectives. The envisioned features of the builders of those projects, the current status quo, what's implemented, what has been done in what way that's presented of this project, and also the perceived features of this project by the users. There are three stages or three different perspectives. What we want to have is of course to consolidate them and into our own envisioned version of this project, but right now I think it's too early. So what I would encourage or I would hope for you guys is to not jump to conclusions too fast. If you feel interested in this project, come and join us. We have a community call every two weeks if you check the website, the links here, there's a stack, there's a Gitter, and we welcome everyone to join us. I would like to stress that Kubila, even though I'm from Alibaba Cloud, but this project is truly open source. And from day zero, day zero, there are bootstrapping engineers from eight different organizations. So it's truly by the community, a lot of people feel the same pain, they want to do the same thing, and we are doing this together. So we hope more will be joining us and we hope this project will provide enough benefits to the users of Kubernetes. Thank you.