Cloud Native Computing Foundation KubeCon + CloudNativeCon Europe 2020 - Virtual, 4 Sep 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Standardizing Applications For the Cloud at a Global Scale - Jared Watts, Upbound & Lei Zhang

Description

Don’t miss out! Join us at our upcoming events: EnvoyCon Virtual on October 15 and KubeCon + CloudNativeCon North America 2020 Virtual from November 17-20. Learn more at https://kubecon.io. The conferences feature presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.

Standardizing Applications For the Cloud at a Global Scale - Jared Watts, Upbound & Lei Zhang, Alibaba

In our rapidly maturing world of cloud native software, what exactly does it mean to be an “application”, especially as deployments become more complicated and move towards multiple clusters, regions, and even clouds at a global scale? In this talk, we will examine both the need and the benefits of a standard application definition model, as well as dive into the details of recent specific efforts in the ecosystem, such as the Open Application Model (OAM). Once an “application” has a standard definition, it becomes easier to perform powerful higher level orchestration capabilities, such as scheduling the application and all of its infrastructure dependencies across multiple environments. We will learn about how scheduling works in Kubernetes and how the principles of scheduling pods to nodes can be applied to a global scale to schedule complete applications across multiple clouds.

https://sched.co/Zesr

A

Hello welcome to the session of standardized application at global scale. My name is lee john from alibaba and my co-speaker jared comes from alba, so I will start from what problems we are facing and how we substitute phase o and the crosstalk.

A

So the whole story began since 2018 when the team in alibaba started to build one of the largest kubernetes clusters in the world. The goal is to serve the developers and operators throughout the company and support its double lab and sales festival, which is huge.

A

The outcome is pretty good. They even published the awesome blog, which attracted a lot of attentions, and it gave a lot of confidence to the community because they proved that kubernetes works for super large scale, but feedback from our users, however, are unexpected.

A

They even ask us why why we want to force them move to a new infrastructure system which clearly brought no value from their perspective?

A

So what's the problem here, we finally noticed there's a huge gap between what our users expected and what we provided in our kubernetes cluster.

A

First of all, api and primitives, with our users, workers own our code, application and ci cd pipelines, but if you look at one or kubernetes cluster, what it provides are workloads like department, stable, set container level parameters like sidecar ports and infrastructure details like network policy extra.

A

The second issue is the levels of abstraction, for example, for application operators in our company. They are working on policies like how to do all the scaling how to do automatic progress route, but what that would be exposed to them, however, are cooperative service, linguists, permissive and eastern virtual service.

A

Yes, as coordinated experts like us, it's straightforward to assemble them into route strategy or other scheduling products, but these primitives don't make any sense from application operators perspective. The last issue is actually the worst one. It is a user interface as powerful builders. We think kubernetes, we think kubernetes declarative api is very powerful and extensible, but our users.

B

A

Don't agree with them: they want to work with human, readable interfaces like dashboard, command line tool or infrastructure of code writing. Yaml files, however, are like writing assembly language from their perspective, and no one wants to do that.

A

We soon realized that these issues are not only problems in our company. They exist in the community for quite a long time. That's why we begin to build modern application platforms for users.

A

Yes, they are user-facing platforms, they're, user-friendly and what's more important is they're all fully based on kubernetes, extensibility, crds and operators, I mean so, do they solve our problem?

A

Well kind of our users stop complaining about our kubernetes anymore. Since now they have application platforms or even service platforms, which which are all great, but they didn't show happiness at all, since now they have too many platforms.

A

This is because at big company, the requirements from our users are highly diverse. For example, some applications are stable workloads, so we need to build them insteadable application platform which, with value scanning policies, for example, or canary role strategies. However, there are also many applications or stateless.

A

They use deployment and workload flagger to route an hpa for autoscaling and some other apps. They just prefer to go to service stuff. Then we have to use kinetic to serve them see, although all these platforms have unique checks, they also share on their comments.

A

For example, all of them requires less script service, but as apple builders, we have to implement this functionality in different forms. Again and again, since every platform speaks different apis, we are creating more fragmentations, more silos and more closed systems with in-house crds. This doesn't feel good.

A

So we stop here and begin to rethink what we've done in the last whole year, especially we're trying to build application label platforms for our users. We want to make sure they are user friendly. So we adopted various ecosystem tools and define our own abstractions and we will it works.

A

We also want to make sure that platforms are extensible. This is an essential value brought by companies right. So we support different kinds of workloads, different forms of operational capabilities and strategies, and that's also why we build different platforms to focus on different scenarios.

A

This also works, but what's messed up here is all of these platforms became stylus.

A

This actually raised a new challenge for us. Can we build them in a standard approach?

A

These rethinkings finally work hard at the standard to build application platforms, which name open application model own and we open source. This work based collaboration on microsoft last year, essentially own defined four application label primitives for kubernetes near standardized approach. Firstly, components: it's all about what workloads you want to define. In most cases they are correct deployment, but it can also be like functions or your own companies operators.

A

The second concept is shapes, which are you to define how to operate the workloads, auto scaling, rollout traffic, etc, are all perfect examples of chips. Some of them are provided out of the box by kubernetes, but most of them come from the ecosystem with crds and operators. This is also where attractions mostly happen. If you want to make your users likes better.

A

The third concept is application configuration. This is a yaml file to explicitly by chase to certain components. So you clearly know the topology of your app instead of tracking them by labels or other unstructured approaches, the last, but most important. The definitions not used to adjust the crd or any kubernetes api resource as workload or change. We will talk about this in detail soon, so all of these concepts are defined by kubernetes. Api resource model, for example. Component is essentially a template object for your workload and is versionized.

A

If the developer modifies this component yama file, for example, it will generate a new revision of the deployment in your class, which is immutable. Note.

B

A

The workload section in the component, the armor file, is fully pluggable, so you're free to define any label of your abstractions in components here, kubernetes department or connective service. It's all depends on you for change and application configurations. There are kubernetes api resources available. The application.

B

A

In this example, it referenced the two components, the front end and the radius, and this by support old scanner and epa gateway are changed for the front end component.

A

So this application configuration could be used as a self-contained application definition file, which includes every dependency and operational capability. Your workloads need to run the last one definition.

A

This is very interesting because for a platform, it's important for you to figure out which complex, api or crd is the capability we want to expose to our users. This means for the other api and crds. They are system level apis and we don't want to leak them to our users.

A

That's why we need to adjust the crd or kubernetes api resource at workloads or trace and expose them to users. They will become the user-facing api for our platform, which over platform speak. You can see here. The point is everything is extensible, because if the users need another workload or trade, for example, what we need to do is simply install the kubernetes crd and the controller and register it as a new capability. The platform support either as a workload or addition.

A

In this example, I demoed how we register each commercial service as the traffic management chain. In our platform, we also define that if conflicts means another service mesh, so the operators cannot make a mistake in the future today, with the help of oh things are getting much better in alibaba, because we now have unified model layer for all application platforms in our company.

A

All of the platforms speak apis, such as component and application configuration with their unique workloads and to serve different scenarios, and, what's more important, is for the common workloads and chase that we don't need to reinvent those wheels anymore.

A

All these platforms now share a common pool of capabilities, so the platform builders just pick what they want and assemble them into their own platforms. It's so easy and neat.

A

Besides as a building block for creating standard platforms, oh also enabled us to dispute software at global scale with collaboration of crosstalk project. This is really important. Now I will let my friend jarrod take from here so he's going ahead. Jared.

B

All right, thank you, harry for showing us a little bit more about the standard application model and uh ohm and how we can use that to describe applications.

B

um So one of the interesting things about real life applications is often they don't just live in a single place right, it's pretty common for applications to be spread out or the components of them to be spread out across different regions and zones, different clusters- and maybe even entire cloud providers as well.

B

There's a number of reasons you might want to do this, um probably the most popular around availability in resiliency, where, if one region goes down or one cloud provider, is down your application running in multiple areas, there makes it more resilient to those outages, uh because there's still parts of your application that are running and accessible right cost is another reason too, where certain services may be cheaper in other cloud providers. So you know choosing the cheapest ones from the cheapest.

B

Clouds can reduce your overall operational costs um and then another one is for new or unique services. Say amazon comes out with a brand new aiml service, or something like that. You want to take advantage of it. You might have your application running across multiple cloud providers in order to use the latest and greatest services that make sense for your business.

B

Of course, that does come with some challenges, though, um and as with anything, you really have to know. uh What are you building an act of intention there, because if you just want to start putting an application in you know, different regions of different places use a bunch of different services without actually knowing what you're trying to solve you're, not going to end up in a good place with that so understand what you're building but also understand the infrastructure needs of your application understand.

B

You know where you need to reduce latency or what services need to be accessible to what components in your application, and you have to factor all that in when you have the components running in various places around the globe right um when you start using a lot of different cloud providers or different platforms, you're going to run into some complexity there, with every cloud writer having their own dashboard, their own console, their own cli tools, etc, um and then different skill sets as well.

B

So you kind of have to think about how much complexity do you want to take on um in order to um you know, get the benefits out of being able to find multiple places. Sometimes you might not even need to hire uh for new skill sets to be able to match what your application needs and where it needs to needs to run. Then, of course, all the operational stuff that comes along with the application. That gets a little more complicated too. When you're running in multiple places, you want to be able to.

A

B

It manage it make sure the policy is applied. All that operational stuff running across a lot of different areas becomes more complicated.

B

So one solution here that we believe to be pretty efficient is a control plane solution. um You know we've seen control planes before for kubernetes itself. Right kubernetes is a control plane um that is able to run a bunch of components like pods, let's say across a series or set of nodes, um so you can think of the same thing for a control plane that is running and managing a global application.

B

So, outside of the scope of just one cluster, you can have a centralized control plane that puts all of our decision making and our orchestration and scheduling, etc, into a single centralized place with a single api to access it as well.

B

So you put that logic and the complexity into the control plane to manage this global application and deployment and infrastructure for us, and it can greatly simplify the burdens that we put on ourselves as humans right.

B

So one particular control plane that meets this description here is a open source project. It's called cross, and so it is a cncf sandbox project now uh just recently as in the last month. But it is a open source control plane. It is really focused on being able to provision infrastructure and get it ready for the applications and be able to connect everything together so that applications have everything they need to be running and successful, and so there's three main parts to the design and feature set here for cross plane.

B

The first one is to be able to provision infrastructure itself. uh You can use that do that declaratively using the kubernetes api, like with cube control, you can bring up. You know amazon, rds database or google cloud sql or whatever you want directly using the greatest api, but more power here actually comes in uh ability to be able to create your own uh infrastructure api without writing any code.

B

So you can build your own um brand new declarative api, that kind of captures what it means to be an application or a set of infrastructure in your organization.

B

We'll get into more details on that, but essentially you know capturing the configuration policy best practices and putting that all behind a api that your applications can self-service on demand use to get the infrastructure that they need, and then the third feature area here is around running and deploying applications to use that infrastructure that we're bringing up so crossplane is the um open application model implementation for kubernetes.

B

So we see a big tie in here with crossband as a control, plane and ohm for having a standard uh normalized way of declaring our applications.

B

So, as we've been talking about the standardized applications, they'll need infrastructure at some point with you know, databases or buckets some networking primitives all that sort of stuff and this control plane. Api that we've been talking about um is a perfect place, a a centralized place to do the provisioning and getting the infrastructure set up for our standardized apps to consume, and so a little bit more details about this api. This infrastructure api that we've been talking about.

B

So when you have the ability to define your own api, your own infrastructure api, you can put all of the important details of what it means to be- let's say a postgres database in your organization. What policy? What configuration you want? All this complexity uh around the standard or best practices, ways to do infrastructure for your organization.

B

You can capture that and encode that in this api here, so that when uh applications want to consume infrastructure, they have this easy to use api and it's a safe, uh secure way of getting infrastructure on demand for the applications that need it, but making sure that it's aligned with the policy and configuration and best practices that is important to your organization.

B

In the last slide. Here we have a diagram of what this looks like for a centralized control plane, providing an infrastructure api to global applications. So we see in the blue box here the cross, building control plane and this infrastructure api that you have designed and declared there. So the control plane is, you know, spanning we could think of it as spanning across multiple cloud providers.

B

So it has connections to them and can bring up when needed or provision infrastructure in any of the cloud providers that you have it pointing at, and then this infrastructure api that you have declared will be published to all the various clusters where you want to be running your applications. So this is a bit of a new design here for the cross screen project, where we have this uh application operator running inside each one of the clusters that you want to be running your applications and where those applications will need some infrastructure.

B

So basically, you can think about it as the application uh needs something like a database and it will look at the api, the infrastructure api that you have published and declaratively state hey. I need a database from this infrastructure api and it will that request will be sent off to the centralized control plane where your infrastructure api lives, and it will turn that simple request of okay. I need a database and it will turn that into well.

B

What does a database mean for my organization and all the policy, all the configuration best practices, all that stuff will be enforced when the actual database gets provisioned in one of the cloud providers there. So that's a bit of a picture of it and let's actually see it all in action now, with a demo in this demo, we're going to walk through how to build a global control, plane, api uh and use that api to provision infrastructure and deploy standardized applications uh all in a global context.

B

So let's go ahead and get started on that back at the command line here, so just want to get you up to speed on what I already have set up. Basically, all I have set up is the global control plane itself, so I've got crossplane installed, uh crossband's little package manager, uh some support for ohm and for alibaba, and that's basically it I haven't defined my infrastructure api. Yet I don't have any applications running so let's go ahead and start defining the infrastructure api as the very first step.

B

So I'm going to need to do three things here to basically define and publish my api. So, let's start with the infrastructure definition that I'm going to create. Basically I am saying uh or start as the first step of starting to define my infrastructure api, I'm going to say: um okay, one type that you can create from my infrastructure. Api is going to be postgres and I'm going to provide a schema of things that you're allowed to set things that you can configure when you're asking for postgres when an application is requesting postgres.

B

Basically, all we're putting in here is the uh amount of storage the size of the database, so an application can say I need 100 gigabyte postgres and that's really all that they get to say. um The next phase is publishing this api, so just an infrastructure publication object that will ensure that this api is published to the application clusters, where the actual containers and pods etc that have the application.

B

Logic will be running the ones that need this infrastructure and then the final part of the infrastructure api that I'm creating is that we've defined postgres as part of the api. But we haven't really said what it means underneath so in this particular infrastructure api that I'm building as the infrastructure owner I'm going to say that when an application requests postgres, um what they're actually going to get is an alibaba cloud, rds instance for postgres and then remember how we said that a application developer.

B

They just get to say how big the storage amount of storage for it. But me, as the infrastructure owner, gets to say a lot more than that. I'm gonna specify all the configuration the policy, the best practices. All that sort of stuff is what I have control over and it's underneath the api line right. It's not exposed to the user and they don't get to control that sort of stuff.

B

So I have some more details, uh configuration and policy etc about this postgres instance that an application can request, and that basically, is what makes up my infrastructure api. My custom infrastructure api that I am publishing and providing for applications in my organization. So when they request postgres, they can just say how big it is. But then all of my important policy will be applied to it. Underneath.

B

Okay, so those are the three things that we need to create, so I'm going to go ahead and just use my cheat sheet here to copy and paste them into the command prompt and so we're creating our infrastructure definition. We're publishing it and we're giving the specific alibaba composition, composition uh for that postgres api that we're defining all right. So the infrastructure api is now published and defined and ready.

B

So, let's move on to a totally different role. So so far I've been the infrastructure owner. I've been defining and creating and publishing this infrastructure api for my applications, my application teams, but I haven't actually um done anything with the application yet so now I'm going to switch roles to be an application developer. I have you know: I'm spending my time writing code, I'm creating container images that contain my code and so for me uh in this application that I'm writing, I'm just going to define a set of components for it right.

B

It's you know what makes up my application is a postgres database right, so I need postgres. I have a requirement uh in my application for postgres and then I have a number of containers uh that I want to run to to access the postgres database um to show some uh flights that are currently running uh some earthquake information from the database.

B

um You know just a couple other components like showing weather as well uh and a ui for it all, so that is uh all the components that make up my application. You know I'm the application developer here, and this is what I produce. So, let's go ahead and create those too.

B

So I'm going to go ahead and apply my application components and those are all now all created and then, let's go on to the final phase here of we've, seen two roles so far, we've seen the infrastructure owner who defines the infrastructure api we've seen the application developer, who defines the components that make up their application, and now this third persona or this role it is the application operator who's in charge of actually putting the application components together in a uh you know, a way at run time.

B

That makes sense so uh there's a couple of traits that we're going to apply to the components that our application developer created, so we're going to apply a scalar trait so that you know the various some of the components of the application are gonna run with the higher replica count, so we're gonna scale those up for them and uh we're also going to specify some information about um where the data can be picked up from so you know the application developer said they need postgres that came from the infrastructure api that we created and we're going to tie it all together here.

B

So let's go ahead and create this application configuration as well.

B

Okay and once this runs here, this basically kicks everything off. So this starts the process of uh you know: we've modeled all this stuff with the open application model and then crossplane is going to take those uh general ways of describing the application uh like components and workloads and traits, and things like that that we've talked about and that's going to start turning those into real primitives uh that can actually run and deploy and use.

B

um Sorry to you know, run the application itself and uh you know provision the infrastructure from the infrastructure, api and kind of get everything up and running all together. So we should start seeing this come together. Let's uh take a quick look of you know: what's actually running right now um this is a small command. I don't think I needed to copy paste that one, but I did from my cheat sheet.

B

So basically, we can see that we have. A number of our containers are now up and running, and the data api one is not ready yet. So this is the one that wants to talk to postgres and uh most likely postgres isn't quite ready yet because it does take a while to spin up in alibaba cloud, and you know, on demand, bring a brand new database in the cloud like manage database in alibaba cloud up and running.

B

So let's get a little more details about um that alibaba rds instance: um it's in the creating state, so we're going to need to wait for it to finish creating and then the rest of our application we'll be able to pick it up and start talking to it and the rest of the application will just start working. So let's go ahead and wait for that. Just a second okay, let's check in on the database instance- and it looks like it's now ready and in the running state.

B

So if the alibaba cloud database instance is up and running, then we should check on our application pods that are running in gke and they are all now running and the data api is able to connect that alibaba uh postgres and so everything looks like it's up and running, and so now let's try to get into the uh the ui for this application. Let's look at the load balancer uh for my gke cluster and let's go ahead and go to that and find uh the dashboard here.

B

Basically, so the application that I brought up is up and running it's talking to the database. It's got uh data from postgres, and so we can start looking at. You know in this application, some of the data that was uh captured for us and held in our alibaba postgres database. So we can see various flights that are up and running right now uh we can see the latest earthquake information. You know this is all real time. That's uh picked up for various services and stored in our postgres.

B

um Oh that's a big earthquake up near alaska or sorry, british columbia. That's um hopefully, that's nothing to be concerned about, and you know various weather and stuff too. So, basically, um everything looks to be up and running, which is great. uh So let's try to wrap all this up here. So basically, we did three different things where we defined an infrastructure api uh for my applications to consume. We gave them some knobs to configure such as the size of it, but we published it for them.

B

uh You know as part of that infrastructure api I specified. What does it mean to be postgresql? It means in my environment that I'm going to pick up that database from alibaba it's going to have this particular configuration and policy, and then my application developers to find all the components for their application. uh The fact that they need postgres.

B

um You know how big they want that postgres um and then the application operator took the components of the application and specified some traits for them to make them more scaled, put everything together in gke, so that we ended up with a live service, that's up and running and running in gke, but we've got infrastructure provisioned from our custom, declarative infrastructure, api and our global control plane that resulted in infrastructure like the database, the postgres instance being provisioned in alibaba. So all these things got put together with a standard way to define our applications.

B

A global control plane with an api to safely on demand, self-service, consume infrastructure in a way that has been uh you know, blessed and codified all the best practices and policy and configuration that our infrastructure owners feel is important and brought all this together in a very standardized way uh at a global scale.

B

So, let's head back to our slides, real quick to finish this all off.

B

So basically, you know: ohm uh is an open source. Spec a you know, cross planes an open source project as well, um so we have communities around those and we love everyone to get involved. Happy to jump in and help you get started, here's some uh helpful links on where to find the quick start, documentation, we're active on twitter and slack and everything. So uh you know if you want to learn more contribute, uh open issues, anything like that. We are a happy community and we're growing and we'd love to have you.

B

So I think that pretty much wraps everything up and uh harry- and I will be here to answer a couple of questions um at the end of this recording, but otherwise thank you very much for attending and we're uh happy to share this information with you today.