Cloud Native Computing Foundation Cloud Native + Open Source Virtual Summit China 2020, 11 Sep 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Keynote: Five Biggest Challenges In App Delivery and How We Solve Them - Lei Zhang & Alois Reitbauer

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.

Keynote: Five Biggest Challenges In App Delivery and How We Solve Them - Lei Zhang, Alibaba & Alois Reitbauer, Dynatrace

In this session, we will deep dive five biggest issues in the app delivery space: - Application definition - no unified/simple way to this. - Packaging for COTS usage: If you want to simple ship a COTS “run on Kubernetes” app it is hard - Installing new apps into multiple clusters, SMI etc. are a good starting point but there are many corner cases - Chain of custody for delivery. Hard to understand what gets installed based on Operators etc. - Ability for operations automation at an application level in a reusable form - Dependency management for both multiple applications and components within one application Plus, we will explore the community within scope of sig-app-delivery and share the existing efforts and trends in the community.

https://sched.co/cpGG

A

Hello, my name is lee. Jung from alibaba, and today me and alois from daitress will give you a session about five biggest challenges at delivery and how it solves them. So the whole story begins from the background that the application delivery today is quite different from it was before so today, after developer finished code trigger ci pipeline generated the docker image for the application.

A

The rest of things we need to do is just to define a bunch of yammer files, which are you know, declarative configuration for application, but just some coordinates api resource to define workloads and your operational configurations.

A

These yaml files are stored in date, for example, and use bit operations to trigger this deployment to the kubernetes and kubernetes, however, will use controllers to help you to finish the continuous delivery process, for example, a rod controller to leverage the uh plugins like steel and permissions to do automatic progress, progressive deployment for your application. So this is how the whole thing worked today, but we can also hear, but we can also see here there are some new challenges emerged.

A

I will start from the first one, which is the unified application definition or unified application model. The reason we're talking about this is you know today. All of us are actually application platform builders, because it's how kubernetes is designed right, but the more platforms we build. We are actually build the building more silos because every platform here, although they have similar functionalities, but they are all different from each other, because the reason behind this is because there's no unified model for us to build.

A

It's tap, build this platform, especially there's no unified or standard application definition. So all of these platforms, they speak different apis. You cannot define applications in platform, one and then migrate application to platform. Two, it's impossible, even though those two platforms are very similar to the functionalities.

A

That's why we say a standard application model can help us to solve this problem, because in that case, both platforms, they will speak the same because they will speak the similar api following the same pattern and what's more important all of these platforms, they can share capabilities and that will make us build this platform more easier. We just assemble the capabilities from the shared resource pool and, to you know, assemble them into a platform we want in the community.

A

There is existing effort to solve this problem, for example, open application model um it actually essentially trying to model the micro service by three application level primitives. The first is the component to describe what to run. The second is change to describe how to operate, and then the application configuration for you to configure trades to components. So essentially it's open source framework for you to build a standard application platform.

A

Okay. The second challenge is application delivery into multiple clusters. The reason we want to do this is because multi-cluster kubernetes brings us with a lot of benefits, for example, beta isolation, improved availability, better capacity planning for busting services and, of course, for better location affinity and was more important to avoid the vendor locking.

A

But the question is how I think the first issue is how you place your application to your target or destination cluster. How you do that in the community there is federation in kubernetes, for example, could be fade for you to do that.

A

To find your destination cluster, but in that case you need to define federation types, other thing which I don't think is reasonable.

A

So the second pattern is to use git apps, which is a modern way for you to deliver application to kubernetes, for example, argo cd, you can define application set to say, okay, which cluster my application want to go. There are also commercial products like google cloud and those for you to help for you to do that. So essentially, the community is quite a mature on this, but the second issue, however, is more complicated because we don't have a standard way to define operational capabilities in different clusters only for the cloud.

A

So, for example, how can I deploy my application to a cluster? And I don't want? I just don't want to care a specific operational capability is implemented. I don't care about that. This is very hard, for example, cloud services and today in the community you can use crossplan to define abstraction on top of cloud resources on big cloud, which is very important in this case, but there's more operational capabilities, for example, traffic, ingress, rollout monitoring and so on. There are also ongoing effort here, for example, smi.

A

It will essentially help you to defy traffic rules in a unified approach, so you don't need to care about. What's implementation under this interface, for example, whether it's aws service mesh or it's still, you don't need to care about that. This is a good start, but you know again, there are still more operational capabilities.

A

For example, rollout today you don't have the unified or standard way to define the world the role strategy for your application, and that that makes it very hard for you to deploy application into multiple clusters, especially on multiple providers, and I can see here there are some approaches in community like flagger, and it has a very good api, but we are not sure whether it will become a defective standard in future.

A

A similar pattern or similar issue also happens in several other capabilities like uh scaling self-spiding, but they are, but we can also find they are working progress in the community. So, let's see what will happen next well, uh this is the first issues I want to cover in the session, and I will just let aloys to take over from here to talk about the rest of the training choice we are facing.

B

A

B

Thank you harry. That's a perfect transition into the next challenge that we want to talk about, which is about packaging and shipping cts or cards applications.

B

So what is a cts application? Cts means commercial off the shelf application. Basically applications. You run within your company that you simply didn't install and use, but not develop yourself.

B

A lot of companies and a lot of applications in the modern company are these kind of applications and the more we move to kubernetes the more we can expect more of these applications being also deployed to the meters.

B

It's like a multi-cluster scenario that we were talking about before, but more to an extreme, because every cluster is different and we can make no assumptions what the class is going to look like, which gets us to that point, that we need a kind of basic contract of what to expect from the environment that we truly deployed to.

B

Currently, we can only rely on the basic platform components of our kubernetes cluster and not on additional requirements which the application, however, might have, and ideally we also have a standardized self-contained packaging format that we could use to deploy this application.

B

So let's look at packaging solutions, so obviously we can use help help as a package manager allows us to package all the individual components we need for our application and put them into a helm chart, but not all components, and they help chop, especially the images are not in the helm chart and also the target system must have helm available. Otherwise we could not use the helm chart. We can use an operator operators also encapsulate this installation logic and obviously a lot.

A

B

Than just installation logic, but images again are still not part of that operator, so it doesn't solve our dependency on the register side either.

B

We have always something like synapse or cloud native application, bundles that allow us to package components together, also sign them and do a number of other things as well, and if you use a concept, that's called a thick bundle. It comes with the images included. However, we again get a requirement on additional tooling in our cluster.

B

So with these requirements we have exactly a situation as we've seen in the seat here on the top. All of our platform assumptions are met, so everything we actually require is also available for us ingress service managed storage. I don't think you require from our company this class that we have available.

B

However, when now one of those components is missing, we can't run the application like in this case the service mesh is missing, so we can't run the application. What we could do, though, we could decide that we install the service mesh as a dependency of the application and just ship the application all together with the service mesh.

B

That works fine in certain situations. However, in other situations where there is already a service mesh available, we might run into problems there or uh even the environment we installed to does not want to have a second service match available and requires us to reuse this. So we're getting into one more complex situation here on how to handle this.

B

A

B

Challenge we're looking into is really handling jane of custody for application delivery, and the next slide should sum this up. Pretty well cubecontrol apply some file from the internet and, let's see what happens, this is definitely how not how we want to deploy our applications to production. This is not how we want to deploy ideally anything to our company disgusted because we don't know, what's really going to happen right.

B

So if we look at our environment, it's actually split into two parts. The left part is the untrusted zone, a public image, a public health chart and public operator which the nozzle might be an image and the.

A

B

Our trusted environment, our cluster, our artifact, store our registry.

B

So somehow what we need to do, we need to move things from the untrusted zone into the trusted zone and ensure that we're only also moving things over that we expect to move over and not something else.

B

So what we need to do is we need to establish trust and ensure authenticity of the artifacts. Are we really getting what we think we're getting?

B

We need to get them into our safe zone, which can be somewhat tedious, because we need to export everything re-import it or we need to lose some kind of federation for registries, but it's still kind of inconvenient to get there there's more convenience for some of these moving things into your environment and for installing applications using operators.

B

On the other hand, um I've also seen people always rather relying on more declarative approaches and operators, because they want to see exactly what is happening to the cluster before they execute it, and operators might just be a binary inside the container. That's running there from uh potential solution, space there's two things that I definitely was looking into: dct docker content, trust, which is by itself only a partial solution that was into the problem, but it helps you to verify um that certain images are coming from a certain provider.

B

Obviously, if you trust that registry, that's a requirement here and for help, we have uh approaches for health improvements and integrity that allows us to do similar things for healthcare to ensure we're getting whatever we actually expecting that never again- and this is also something that you should include into your delivery- to ensure that only uh items can be executed against your cluster- that you should be allowed to execute against that cluster.

B

The last challenge we want to talk about here is really operations- automation, but not so much in the infrastructure container level, but really moving it up to the application level and ideally doing this in re-user performance.

B

So kubernetes is great in handling generic application operations, restart scaling, health monitoring based on health, endpoints and awareness endpoints, but applications are managed not just on these health endpoints. Usually you have slis and slos that you use for your operations, tasks ensure that the application is running properly. Let's go way beyond it's just there or it's working, and there are also domain specific operations that you're running that require custom logic like if your load gets too high. You want to switch to static content, delivery versus calculating things at one time.

B

So what are your options here? So exposing the metrics rs is really easy. You can use prometheus. You can use open telemetry, which makes it real easy to expose those metrics. You still need to have a backend that consumes this metric this matrix, obviously, but you can assume that the cluster has them available for operations. Automation, kubernetes operators, as the name always suggests, are a great.

A

B

As they can handle and work with these metrics and these environments, however, it's not really that well defined or, let's say standardized on how the operator would get information about slis and seos that they should act on like how would their operator know or even be able to access this information, which is stored most likely in monitoring backends and can consume these metrics and alerts.

B

There is also a project called captain that was a personal involved in that tries to solve, amongst other things, some of those problems and how you can use slides as the lows and put some automated operations logic on top of it, and also ensures that, like all three things get tied together automatically.

B

So if these are problems that you're dealing with as well, that you have solutions for they have opinions on or that you just think you want to discuss with your peers.

B

um I want to draw your attention to seek app delivery within the cncs ecosystem, where we are working on several of these challenges and things on top there's also dedicated working groups. So there's the operator working group dealing with everything operator related and the air-gapped working group that estimated just deals with air-gapped environments, but a lot of the trust topics and the deployment topics we discussed before will eventually also be part of the work done there.

B

Also, if you have some best practices that you want to share some experiences, you want to share with the wider community you're more than welcome to join one of our upcoming meetings and present your content and your findings.

A

B

Thanks for your time and your attention.