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

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Cloud-Native Application Delivery Landscape Update (Deep-Dive) - Alois Reitbauer & 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.

Cloud-Native Application Delivery Landscape Update (Deep-Dive) - Alois Reitbauer, Dynatrace & Lei Zhang, Alibaba

In the session the audience will learn about the state of the cloud-native application delivery landscape. The session will provide examples and guidance how to compose an application delivery stack following the application delivery model defined by the application delivery SIG. The audience will get first hand experience with sample projects and how they can be applied to common use cases.

https://sched.co/Zeuk

A

Hello, this is lee zhang from alibaba, and today me, and my co-speaker royce from datrius- will give you the talk about the cloud native application delivery, landscape update. This is actually a deep dive session for cncf seek app delivery.

A

So today, if I am a application developer and I look at the sensitive landscape around the application, definition and development category, it's actually very interesting.

A

The first section I saw is a bunch of databases which I only heard one or two of them why they are part of application definition and deployment. I'm very curious, should I be some kind of expert on storage engine to write a single application seems not.

A

The second section I saw is a bunch of software with name of streaming and messaging. It's also very real. Indeed.

A

I really don't think how kafka works is a concern for most of the application developers, not to mention the other ones like cloud events which I would probably never need to know what it is and for the rest part of the category, it's essentially a mixed box of every application, packaging and ci cd related projects in the community.

A

Nobody knows why how they are. Nobody knows how they are organized or placed in the sections. It's just the chaos.

A

Honestly speaking, the application category of seeing same landscape needs a significant update since a long time ago. Today, the modern application delivery actually starts from application developers. Writing the code and trigger continues integration process. By pushing the code, then the ci system will generate dark image as the artifacts of your application and for the deployment of these artifacts, we will write kubernetes, yaml files to define workload and the operational configurations for your application.

A

These yaml files normally store in, for example, git, so it can trigger github's workflow for every change in these files.

A

When the change reach capabilities, the controller, like road controller, will response and perform the corresponding application delivery functionality, for example, blue green deployment.

A

This application workflow this application delivery, workflow, which includes githubs and declarative api kubernetes, and the controller pattern at this heart is very different from the traditional ci cd pipelines, and it also creates more emerging technologies and new scopes in this era.

A

It's also another reason that we need to update the sensitive landscape regarding to application delivery, because we definitely want to include these emerging efforts as part of the landscape application delivery. We're talking about so the first emerging technology we want to include in the new landscape is standard application model, so why standard application model is important.

A

We all know that kubernetes is designed for us to build application level platforms, but in real world the requirements from our users are highly diverse. For example, some applications are stateful workloads, so we need to build them. We need to build the users, a stateful application platform with operational capabilities like manual scaling policies and canary road strategies.

A

However, there are also many applications which are stateless. They use deployment at workloads flagger, for example, to do relevant and hp for auto scaling and for some other applications. They just prefer to go to the service style. We have to use kinetic, for example, we need to use kinetic, for example, to save them see, although all these platforms have unique traits, they also share a lot of in common. For example, all of them requires a capability like, let's encrypt, but at platform builders.

A

We have to implement this, let's decrypt functionality in every different form in every different platform. Again and again, since every different platform here speak, different languages speak different apis, so instantially the platform builders are creating more fragmentations today, more silos and more closed systems with a lot of in-house crds. These don't feel good.

A

This is where a standard application model can save the world. Essentially, we now have a unified model layer for all application platforms in the organization they speak api, such as components and application configurations or any kind of standard application level primitive instead of the infrastructure level primitives, which which ensure that we will not leak a lot of too much detail to our users with a unified approach and every platform here will have their own unique workload and trace to serve different scenarios and for the common workloads and chats.

A

We don't need to reinvent the views anymore, because all the platforms now share a common pool of capabilities, so platform builders just pick what they want to assemble them into their own platforms. It's just easy and neat in the community. The existing effort to define standard application model for platform builders is open application model ohm in detail. Ohm defines four application level primitives for kubernetes in standard approach. Firstly, components: it's all about what workloads you want to deploy.

A

In most cases they are kubernetes deployments, but it can also be functions if you want or your own kubernetes operators at workload. The second concept of trade which are used to define how to operate the workloads are scaling. Rollout check management extra are all perfect examples of trades.

A

Some of them are provided out of box by kubernetes, but most of them come from the ecosystem like flagger like istio. This is also where abstractions mostly happen. If you want to make your user's lives either the third. The third concept is application configuration. This is a yaml file to explicitly to buy the chairs to certain components.

A

So you clearly know the topology of your web application instead of tracking them by, for example, labels or use other kind of unstructured approaches.

A

Last but most important the definitions: they are used to register crd or any kubernetes api resource at workload and trades, and we will talk- maybe talk about mode about this in detail very soon.

A

You can also check its website or specification for this detail, of course. Okay. So let's go to the next step. The second scope we want to include in our landscape is multicultural application, delivery and git apps.

A

So why do we want to use multi-cluster? This is a very important question, because today we basically have a lot of kubernetes clusters to manage, not not only in our own, not only our own organization, but also in different organizations. It's very common pattern, so we want to have better isolation. We want to improve the availability, and we also want to have more flexibility to, for example, to do capacity planning, especially for bursting workloads, and of course we want to do location affinity and we want to avoid the vendor.

A

Lock these or all the multi-cluster kubernetes can bring us the benefits and values here.

A

But the question is how to deliver applications to these clusters, especially when those clusters blown into different clouds. So the first issue is how we place the applications, the application placement that needs to say how to, for example, deliver the application to a targeted cluster based on always strategy.

A

The first project you need to you can you need you need to take a look at which can solve this problem? Is the federation version 2, but of course it could be fed project, but there is a restriction in this project because you need to define federation types for every kubernetes resource you want to deploy. This is actually very complicated.

A

That's why a lot of people gradually move to git ops, based approach, which means you will basically use githubs with application level placement strategy and, for example, you can use argo cd to do that. It has a feature to name it. Application set for you to define each application goes to this cluster and that application go to go to that cluster. It's very easy and also flux also supports similar pattern, and there are also a lot of commercial products today.

A

For example, google and those which enable you to deliver applications to different target clusters based on your github's configuration, but the second issue is a little bit more complicated, which is the portability of your operational capability. For example, I want to deploy my application to multiple clusters in multiple cloud, but how can I define the a certain operational capability without need to care about the details of the cloud providers or the different clusters right, for example, the cloud resources?

A

How can I define a database which is possible between a google cloud and microsoft editor cloud right? This is very, very complicated issue and today crossplan can help you solve this kind of problem, because it can help you to build a platform agnostic abstraction on top of the cloud resource apis, but there's more operational capabilities, for example, traffic, ingress, rollout monitoring and for traffic management. Today um there is a ongoing effort, which name is smi for you to define traffic management strategies, regardless of what kind of service mesh plugins you have right.

A

This is actually a very good start, but we really need more like this, for example english right. How can we define english specification, regardless of its implementation, and there are community efforts as well like ingress, v2, api and also for rollout for um observability?

A

um For this part, we have open telemetry, which is very promising, but we don't know how to define a portable definition for auto scaling, for example, as well as service fighting. So in one word, the current community is still not there to define generic standards for our interfaces for portable operational capabilities and it's very hard for us to enable real, multi-cluster or multi-cloud application delivery for now. But yes, there are some promising effort and we should keep our eyes on that now.

A

I will let my co-speaker to share more about the rest of the challenges we want to include in the scope of application delivery landscape. So please go.

B

Ahead, thank you harry. That's, a perfect transition into the next challenge that we want to talk about, which is about packaging and shipping cuts or cuts 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 in 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 applied 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 cognitive 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

A

B

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 on the helm shop, especially the images are not in the helm chart and also the target system must have held available. Otherwise we could not use the helm chart.

B

We can use an operator operators also encapsulate this installation logic and obviously a lot more than just installation logic, but images again are still not part of um 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, manage storage, other things you require from our company this cluster to have available.

B

However, right 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.

B

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. 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 even the environment we installed to does not want to have a second service mesh available and requires us to reuse this, so we're getting into a one, more complex situation here on how to handle this.

B

The next chain challenge, we're looking into is, will be handling jane of custody for application delivery, and the next slide should sum this up pretty well queue. Control applies 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 upcoming discussion, 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 a public operator which the nozzle might be an image and.

A

The right part.

B

Our trusted environment, our cluster, our artifacts, our registry, 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 reimport it or we need to use 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 than 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 a container. That's running there from potential solution space. There is two things that are definitely 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 uh 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 what we're actually expecting the network, and this is also something that you should include into your delivery to ensure that only 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 and container level, but really moving it up to the application level and ideally doing this in a reusable format so coming. This 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.

B

Tasks ensure that the application is running properly that go way beyond it 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 ares 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, these metrics, 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 slides and, as slows 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 a monitoring backend and can consume these metrics and alerts.

B

There is also a project called captain that that was a personal.

A

B

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.

A

Thank you, allies for great summary about the new challenges and solutions we are facing in current application: delivery ecosystem, it's very informative. So allow me to do a brief summary for this session, so we're basically seeing that there are new challenges and potential solutions emerging in the application delivery ecosystem, it's huge and it's important.

A

We also notice that some of them are still missing in the current landscape and some others need revisit or it we need to do something to reshape the whole landscape, and we also notice that the current structure of the landscape will need some kind of redesign.

A

So we can deliver the messages to our audiences to let the community know better what a specific project is really about what kind of a challenge it can be used to solve and any potential usage use cases we can discover besides its main description, so all of these things can be delivered very well by restructure and refactor the current uh sensitive landscape.

A

That's why we have the proposal in the sig application delivery of the cncf. Do we want to add a new tab? Which name is application? Delivery for extensive landscape, which uh basically about the clone native application management and development, and focus on this ecosystem.

A

So this is idea- and if you like this idea- and you want to join us together- to reshape the sensitive landscape, the seek app delivery is really the best place for you to get started. So me and alloys advil at brain are co-chairs for this week and you can reach out to us through the slack channel, insensitive workspace.

A

You can raise your discussion in our mailing list and, of course, the best way to join us in you know: discussion around things, fc gap, delivery and the application delivery ecosystem is our sign meeting, which is held every first and the third wednesday of the month.

A

So I think the best way for you to get started to check the agenda notes to see what is currently under discussion, and this update on the landscape is actually one of the most important part for recent work. So welcome to join this gap delivery, and we will be very happy to see you join us and reset the cnc landscape in the future. Thank you very much.