Cloud Native Computing Foundation KubeCon + CloudNativeCon Europe 2021, 14 May 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: App Delivery in Cloud Native: Where are We? What's Next? - Lei Zhang, Alibaba & Alois Reitbauer

Description

Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon North America 2021 in Los Angeles, CA from October 12-15. Learn more at https://kubecon.io The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.

App Delivery in Cloud Native: Where are We? What's Next? - Lei Zhang, Alibaba & Alois Reitbauer, Dynatrace

In 2021, there are more and more buzz around the CNCF landscape and it's getting overly complex! So, where are we now? Where are we heading to? In this session we walk through key trends we observed in cloud native application delivery ecosystem and illustrate major challenges we are facing. We will also demo practices tried to solve these issues based on real world case studies collected by SIG App Delivery, with projects available in open source community, for example, the full application delivery workflow from defining your application all the way to running it in production. Whether you are just about to start running applications on Kubernetes or want to improve your skills. This session will help you to identify what to consider when building app platforms, share good practices, compare different approaches and learn about key trends and quick tour through the CNCF ecosystem with a focus on delivering and running applications.

A

Hello and welcome everyone to the kubecon europe session of sick, app delivery. This session will be co-presented by lesang or harry and myself.

A

So, let's get started when people look at the cncf landscape, they easily get overwhelmed by what they see. Some people even made a joke and created a 1 000 piece puzzle. There's a large number of tools in the landscape. Some seem to be doing the same thing and it seems to be kind of hard figuring out what the individual tools are doing and how they are helping, and especially when you want to get started on something like app delivery.

A

You might not know where to start, because, there's just so much or so many tools to start from, on the other hand, there's a great variety of tools. So for your specific purpose, there might be just the right tool there and you can also try different tools and see which one fits their needs best and there's always growing functionalities. So new tools are constantly added to landscape, which might help you for your very specific use case.

A

Still, we understand that it's hard to keep track of this.

A

That's why we started for the last cube console for cubecom north america to build a little project called potato head, which you can find on the url that you see here on the slide. It gives you an idea of what cloud native app delivery looks like in the cncf landscape. So what it does? It provides a very simple small application, but the uniqueness is, you can use app delivery concepts with a variety of tools from the cncf landscape. You can obviously start with manifest. You can use helm, flux2, argo, cd and rollouts.

A

Captain cubevela and recently new tools were added like gimlet litmus chaos and there's also support for very specific deployment approaches like cnap using porter. So you can see that you have this simple project and you can try variety of tools easily, and this project is also constantly growing.

A

If you're interested to learn more about potato head, how it's working. So I highly recommend you either go to the potato head github repository or you watch the talk from kubecon north america, where we walk through those examples.

A

Now for this kubecon we took it a step further and we talked to the individual projects, what trends they're, seeing what developments they're, seeing and put this into this session, to give you an update of how the landscape for app delivery is really involving, and here we also want to thank those projects who shared some trends, some stats on how these projects are evolving, what they are seeing in the market which we condensed into this presentation.

A

This is more or less a very easy step forward approach to get like an insight of all of what's going on in that space. So, let's look at the trends. Now we categorize them into three areas. The first one is application definition. So how do we define applications in kubernetes?

A

What we can clearly see that templating is becoming more and more prominent and more and more front and center, mainly for reuse and simplification, as more people are starting to use, kubernetes and kubernetes related tools, they'll slightly get overwhelmed with all the configuration they need to make, especially when it's about production-ready workloads.

A

That's why teams start to build templates that contain the major parts that you need to do in order to set up a secure and well-functioning workload in kubernetes and you as a developer, only need to bring your development uh specific artifacts, like your containers and so forth.

A

Also kubernetes starts to be used as a management plan for more resources than just the kubernetes resources. There's tools like cross crossplane that allow you to manage workloads that are not kubernetes specific. They also configure cloud resources, so kubernetes becomes more of a management plane beyond just containers.

A

Also, application definitions is moving beyond infrastructure. As we move more towards a developer experience, uh we also need different constructs. We want to model an application, an api service and so forth, and there are numerous projects to do exactly this for you and help you to do this in a better way. On the app delivery side, we see that github's adoption is constantly growing and also the use cases get more mature.

A

So it's no longer about just having a simple git repo synced into your kubernetes cluster, and the proper files being deployed use cases with multi-stage delivery and other scenarios are becoming way more front and center, allowing you to handle way more complex enterprise scale. Delivery scenarios, also progressive delivery is becoming more front and center, so people started from simple deployments on kubernetes, then moving to blue green deployments and now using more and more data to decide whether deployment should stay in production and how traffic should be shifted to this workload.

A

Also operational concerns take more front and center as more people keep running production workloads in kubernetes. What we're, obviously seeing that there are some operational concerns uh that need to be handled that go beyond what kubernetes to us as a platform and also go beyond deployment simply coping with traditional operational things you have to take care of on the tooling side. Kubernetes is really becoming more of a platform than just running kubernetes based workloads. It's really becoming this platform to build platforms. It starts to introduce higher level abstractions by adding additional tools.

A

On top also, chaos, engineering is becoming more front and center and being tighter, integrated into kubernetes application, delivery processes and, last but not least, service catalogs help to really scale the adoption of kubernetes. As we move more into the templating space, you need to store those templates somewhere easily fetch them and apply them to your project.

A

So now I'm passing over to harry who will walk you through, especially what is done from an application definition from a developer-centric experience and how different projects are emerging there and which trends we're seeing, especially in this.

B

Space, thank you guys, hello, everyone. So it's really great for me to um continue to discuss about the change of the application, delivery and management in 2021, of course. So, yes, I will continue from application. Definition. First make sure it's very close to developer and operator experience.

B

So when talking about this, uh I think we already know that kubernetes is a great platform if we want to deliver applications or manage applications at top, but we also know that kubernetes is not that easy to learn. It's actually kind of complicated, especially considering it actually exposed a lot of informational details like networking, security storage to the users. But yes, kubernetes is not an ending guy.

B

That's why a lot of people trying to build upper layer attractions at top speaking of building attractions templating is actually one of one of the most widely used technologies, because it can allow you to define a bunch of best practices as templates and then expose the only needed parameters to your end users, for example, you can define a component which name and web service which exposed the image field. The image tag the replica number, as well as the exposed parts to your end user.

B

So your end user can justify three parameters to define a web service which can be deployed to up to kubernetes and exposed to external world. This is a very simplified experience, but what's more important is the way you use. Template is actually a way how you end the users to customize this abstraction.

B

For example, if one day your end user say okay, I want to be able to define security policy to this web service component. You say yes go ahead, I can give you a new version of template and you can do that. So you can see here. This is a actually a very interesting way to build platforms and type equivalents, because you never ever don't want to introduce restricted attraction to end users. Just like the traditional platform services and many many application engines.

B

They are too opinionated to serve all the user cases of your developers, but with the power of templating. You can do that. This is actually a lot of very interesting project right now, we're doing, for example, kubiwella.

B

It allows you to declare your best practices, as templates by using q language, which is a dsl and, of course, ham chart. So your end users will have a highly, I will say highly extensible way to define application object, attractions based on their own needs. Another interesting project is game late. It actually um have a similar experience based on a hem chart. Allow you to define objections with them them chart and exam and deliver applications use github's manner.

B

So it is more like complementary tool to the existing ddos workflow and in in order for you to define templates, which can be assembled into application deployment, which you in turn give your your end: users, the full extensibility. There are several other projects, for example, open application model. It gives you a specification, or I will say principle for you to follow to categorize your templates. For example, you can say these bunch of templates are for workloads, for example, web service banking worker connective serving workload fast workload or even virtual machine workload.

B

They are all templates that describe how you run a workload and several other category of templates, which named, for example, trades which are all operational behaviors for your work. Work club, for example, how to do blue green deployment, how to split the traffic, how to um declare the ingress rules based on your user cases. So this is what open application model brings to you.

B

So in that case there will be never a attraction log in your system as long as you have the model to declare and categorize your templates and allow any user to use it.

B

Another project I want to mention regarding to the application deployment is of course, called correspond because it allows you to define or declare the color resources or application needs uh in kubernetes survey. Just think about the um the previous. Previously I mentioned the application right. The application actually composed multiple components, including the web service, I've already mentioned, but it can also have a component, which is the cloud database may be provided by ewas.

B

In that case, how can I divide all of the things together in a single source of truth yama file and allow people to do that in kubernetes manifest? So this is a very personal company and, what's more interesting part? Is it gives you the way to implement the core providers? So in that case you don't need to say okay, I have to implement everything. If I want to declare the cloud services from some other cloud provider, don't do that. You just write a very simple cloud provider based on quotes and runtime.

B

That's all your old state and then you you can use open application model or kubiwella to define the application which is composed by your web service workload, as well as the code database provided by crowstep. This is the most convenient experience if you want to bring developer, focusing experience to your end users and make everything work smoothly with high efficiency and speaking of the developer experience, and I think the most valuable approach which the community is trying to presume is, of course application-centric.

B

So kubernetes itself is complex, not because it's wrong just because it cares too much too many things, but for developers it only cares about applications it only they only care about applications. They only want to deploy the application. That's all that's why, for example, um project like open application model and kubernetes try to bring back the application context to kubernetes.

B

So as a platform builder, I can actually build a application-centric platform by leveraging kubervela with kubernetes very easily, and you can think of that. Kubernetes just leverage the templating uh mechanism to allow you to pre-define a bunch of kubernetes, manifest templates in queue and help and use install all of the predefined templates in your system and your end user will assemble them into application and the reason they can assemble them into application deployment is because open application model is there.

B

It provides your end users with a bunch of higher level abstractions, including, for example, components right. What are the components that compose your application? You may say: okay, including the web service, including a bank and worker, and including a cloud database which is provided by crosstalk, of course, and the second concept from coopervela is actually traits which are operational behaviors for you. So in that case, application is composed by components plus this chase aka, the operational behaviors, for example.

B

You can declare your web service will be rollout following a blue green deployment strategy, which is the trade. That is how you allow your end users to define application deployment by fully leveraged developer, focused primitives, which are enforced by templates, designed by you and the last concept in this kind of system in the environment, because your end users will also be able to declare that my application will be deployed to staging cluster or production cluster. That is where the that is what the abstraction of the environment is trying to solve.

B

So in that case, you can see here this project, which is pretty new, but it's it's getting fully adapted by a lot of users. This project is trying to provide your end users with a bunch of abstractions, but these objections are enforced by templates, and in that case your any unit will have a simplified approach to declare their application deployment in a single yaml file, which naming that which naming the application. That's why they say it's totally a application center experience.

B

Okay, so speaking of the trend, I've talked about the application definition, how all of these technologies simplify the experience of your developers and operators.

B

But speaking of that, we also have another approaches which need to cooperate with these application abstractions to make the deployment of your application way easier, which name is githubs, so it allows your developers to declare the deployment of your application by filling the git based process, which is quite similar to them quite familiar to them. So this this is where dops come in, so I will pass these parts over to alloys, so we will continue, explain how detox works, what benefit comes from and how the developers can leverage this workflow to deliver application and skill.

B

So, okay, always here we go.

A

Okay, welcome back and thank you gary for this deep dive. Now, let's look into github's related strengths. Git ups is becoming more and more front and center. When we talk about deploying cloud native workloads. This also led to the establishment of the git ops working group within seek app delivery. The github's working group is working on a common definition: some standardization around concepts, training, material and so forth, and there's lots of people who are already actively working there if you're interested in githubs or are actively using githubs.

A

I highly recommend you engage with the github's working group or look at what they're working on.

A

This is also massively driven by the fact that we see more complex, skid up scenarios emerging, so we see git ups being used in multi-cluster environment scenarios, people usually separate their pre-production and their production scenarios by running them in different clusters and github's tool chains obviously need to support this, and also we need to model stage to stage propagation, which is not just coping the artifacts from one stage to another. So you need to have stage specifics in there and you need two ways to model.

A

Exactly this and how you propagate this across your git repositories as well, what we see, also emerging more and more and which still doesn't exist that much today is that different tools obviously use proprietary definitions of how they are deploying workloads. So when we talk about cannery and blue green releases, conceptually github's tools are doing this or progressive delivery tools are doing this in a very similar way. Still all of them use their individual definitions and it might be a bit harder to get started there.

A

So we hope that as the space matures more and more, that more and more standards and more will be emerging there and more agreement across different tools.

A

Which leads us directly to the next topic: progressive delivery, progressive delivery, adoption is also growing. We see people using more sophisticated approaches and they're emerging more and more as people are moving more and more workloads to kubernetes and there's also this trend of not just using blue green deployments, but really using progressive delivery for rolling out workloads.

A

One key driver here is that workloads themselves become more and more applicable to be used in a progressive delivery scenario, so two versions can really productively run alongside each other, and the application services are built in a way that they can deal with this rather well. Also, testing and quality gating becomes tighter integrated into this process.

A

So when a new workload gets deployed in a stage, tests are automatically triggered, so this might be load tests, the security tests and then slos are very often also used to validate in the form of a quality gate of whether this workload should stay in the current stage or it should be propagated to the next stage. So here we see the concept of slos of service level objectives not just being used in production, but also being used already during deployments to validate whether all the key criteria of a healthy application are satisfied.

A

So this moves us definitely beyond just checking a health endpoint, but looking at the service way more holistically, there's more complex scenarios. As already mentioned, support for multiple environments, it becomes way easier to configure different environments and move workloads from one environment to another in the progressive delivery pipelines and having this in a more easier to manage approach and also the individual environments are easier to manage and it becomes to be more of a.

A

They agree, agreed upon approach or a better to manage approach on how to model workloads for specific environments and how to do this in a in a way.

B

A

Other people and other tools would understand as well as we start to integrate more tools. It becomes more and more obvious that adding a new tool usually means working with a proprietary api. That's where it is cdf, so the continuous delivery foundation started a sick on events. So what eventsig is doing? They're standardizing across application delivery events across the entire application, labor life cycle, so whether it's testing deployment, validation, new artifacts being available?

A

That are event that will eventually be understood by a wide variety of tools out there, which allows you to easily plug in a tool into an existing pipeline or make it also much easier to exchange tools for different scenarios and, as we obviously move more to a progressive delivery approach, where we use more sophisticated ways of rolling out applications, not just from a traffic switching perspective, but also deciding which user traffic we send to which version. We see a much tighter integration of what a progressive delivery does to how a service mesh is configured.

A

So there will be much closer collaboration between the two and they will also share much more of those definitions going forward.

A

Now. Moving to the next topic about operational concerns, so so far we talked a lot about day, one operations, but obviously, as we run more workflows in production day, two operations becomes way more of a concern as well and, interestingly again, we see slos being also used for validation of remediation actions, so, instead of just executing actions to get applications back to a healthy state, we use slos to really validate whether the action had the desired effect and did not have any additional side effects that we might not be checking for.

A

So this really allows us to build massively improved reconciliation by validating against acid loads. So, as you can see, slos really take a front and center stage here on how we talk about the health of applications.

A

As we talk more about operational concerns, we also have to talk about run books and run books also start to get more automated. We want to automate this entire process for our workloads, so runbooks start to get modeled in code instead of just being verbally described, which means they're shipped along the artifact, and when you have a certain service available, it comes with its run book. That tools can then directly use to mitigate for certain actions. These actions they also move beyond just being a scale-up or a rollback actions.

A

One prominent example: you see automatically using feature flags that developer have added to mitigate certain scenarios, so there is a feature flag within the application, what to do when load gets too high or when certain other situations arise. These are then described in machine, readable, runbooks and integrated into this process.

A

Also, actions are no longer like once the one-step actions. There seems to be more and more the trend that people are modeling, more complex, operational workflows, just the way they used to. So you pick an action you validate whether it actually works. If it did not work, you look up where there's another action to take and automate this process.

A

I was eventually escalating it to a human operator if none of the automation really helps, but also there's other operational concerns um that we have to take uh care of which also ties into their progressive delivery and github scenarios.

A

We have to manage how to run an application separately from the core application definition and the q valor project. Take when using oem um takes this approach of modeling them into using traits.

A

So trade smallers define how an application a hard workload a service should be run in a certain environment and how it should be properly configured so having this model explicitly and not being part of the core manifests on the one that increases flexibility, but it also creates a separation of concerns between defining how a workload should be run basically and how a certain environment wants this workload to be run from an operational perspective.

A

Chaos engineering is also one of those increasing trends, as already mentioned just to have some numbers. Here we talked to the litmus chaos project, which is also cncf project, and they are seeing a four times increase in the number of experiments that are run.

A

There's also a trend of moving left into pre-production, so instead of running chaos, experiments solely in production, they are tightly integrated into continuous delivery pipelines and github scenarios where chaos experiments are run against workloads when they get deployed in a progressive delivery fashion to see how those workloads behave in those scenarios where they still are able to cope with certain scenarios.

A

Most experiments today are still run at a pot level. That might be a bit surprising because you would assume that kubernetes is already taking care of most of the part level. Chaos like killing a pod, and things like this still.

A

It is very widely used, mostly to identify configuration issues where workloads are not properly configured or there's no high availability configuration available available, so these can then easily be surfaced early on and these chaos experiments help to validate exactly these scenarios, hypothesis checking front and center to a chaos experiment, so you always have a hypothesis you want to check against, and here also slo modeling becomes central. So we really start to see, as slows being established as the central language spoken across the application delivery life cycles.

A

You have these observability metrics really become a key component to to chaos. Engineering beyond the part level experiments there is an increase in network and serviceability experiments. Again, we are talking about distributed, applications here and testing, whether distributed for a distributed application, whether all services are working properly or not, is obviously key. So integrating this into chaos, testing makes sense and last but definitely not least, there's also.

A

This emerging trend of security, chaos or chaos, experiments that focus specifically on security related issues and, as we start to talk about devsecops and integrating security close into the life cycles, it obviously also makes sense to run security related experiments as we are releasing our workloads.

A

So as we start to have more high-level components and more pre-packaged components available from pure infrastructure definition to higher level service definition, we need to store those definitions somewhere. We need to make them available to people to easily consume them, and that's why service catalogs are becoming more front and center. So obviously, in a corporate scenario, you don't want anybody to run a cube. Control, apply minus f on some file. They found on the internet how to run a cassandra or something like that and.

B

Also, most services, even.

A

If they have an operator available, they don't come in a way that they're ready to be run in production. They still require operational configuration and cause a configuration specific to your environment, so how you want to run and operate those workloads, and these needs to be applied, and not everybody immediately knows how to do this, or it might not be their core job on how to do this, so there are usually configurations added on top, even on this pre-picked components that are provided by operators, for example.

A

By the way, this makes the life of actually both easier for developers because they get a service that actually works the way they want it to work and also for operations, because they still have the control and they can define the environment the way they want to define it.

A

This helps us also change the mindset moving from a infrastructure, related mindset to a service related minds that you also start to really consume higher level services. As a service like as a developer, I want to get a sql style database. I don't necessarily know how to configure it for all environments that it's going to be deployed to. Nor do I need to know all of these details, I'm just going to a service catalog, I'm getting the database that I want as a service that I can then use in my application.

A

So that's it from the sick, app delivery trends. What we're starting to see in uh project! I hope there is something there for all of you. Some interesting trends or some validation of things you're already doing or you're already planning to do also feel free to engage with, seek app delivery directly. If you have questions, if you have real world examples that you like to be sharing, um you can obviously find us on our github in our github page, or you find us on the cncf slack.

A

There are also meetings every two weeks, so every first and third wednesday at 8 am pacific time so feel free to reach out to us. Ask any questions or engage with the wider app delivery community within the cncf.

A

That's it for today, and thanks for your time.