Viktor Farcic

Wouldn't it be beneficial if we had a single API and a universal control plane responsible for managing applications, infrastructure, services, and everything else, no matter whether we are in the public cloud and on-prem?

If we had to define the most significant benefit Kubernetes provides, that would not be the ability to run containers, fault-tolerance, or immutability. The main benefit is its API. It is well defined, versatile, and extensible. It might be the main culprit behind the "explosion" of the ecosystem created around Kubernetes.

Can we take Kubernetes API to the next level? Can we use it to manage not only the workloads running inside Kubernetes clusters but for everything else? Wouldn't it be beneficial if we had a single API and a universal control plane responsible for managing applications, infrastructure, services, and everything else, no matter whether we are in the public cloud and on-prem?

In this hands-on session, we'll explore the principles behind the universal control plane implemented through the open-source project Crossplane.

We can enable developers to manage everything yet still be in complete control of the aspects they care about.

We are all moving towards service-based operations and self-sufficient teams. We are all trying to enable developers to be more autonomous. However, it is unrealistic to expect everyone to become an expert on everything, from infrastructure to Kubernetes and everything in between. So, we cannot shift left due to lack of expertise, but we also cannot continue being reactive to the needs of others. The only option left is to simplify services or even remove direct access to infrastructure and Kubernetes.

We might be able to accomplish those goals through Argo CD or Flux (GitOps), Crossplane (universal control plane), and KubeVela (OAM). By combining those, we can enable developers to manage everything yet still be in complete control of the aspects they care about. GitOps allows us to establish Git as the only point of interaction with the system. Crossplane Composites enable us to simplify developer experience when managing infrastructure. Finally, the Open Application Model (OAM) with KubeVela allows us to define applications instead of Kubernetes resources. If we combine those three types of tools and processes, we can enable operations to define the services used by developers to manage infrastructure and applications. We can do all that without anyone even knowing that there is Kubernetes behind all that.

For everyone to use Kubernetes, it needs to disappear.

What are we going to do without Docker inside Kubernetes clusters?

Dockershim has been deprecated in Kubernetes 1.20 and is scheduled to be removed in 1.22. That begs some questions.

What are we going to do without Docker inside Kubernetes clusters? Which container engine should we choose? How are we going to build container images? Is that change for the better, or should we start panicking?

Let's see what are out options among container enginers as well as for building container images. This might just as well be an impetus for making changes that we should have made a while ago.

Three phrases keep popping up when talking about modern workflows and development and deployment techniques; CD, GitOps, and progressive delivery.

Three phrases keep popping up when talking about modern workflows and development and deployment techniques. We have continuous delivery to automate the complete lifecycle of applications from a commit to a Git repository, all the way until a release is deployable to production. Then we have GitOps to define the desired states of our environments and let the machines handle the converge the actual into the desired state. Finally, there is a lot of focus on different deployment strategies grouped under progressive delivery. They are all focused on the iterative release of features to make the process safe, prevent downtime, and reduce the blast radius of potential issues.

While those three practices and the tooling behind those are focusing on specific areas, the "real" benefits are obtained when they are combined. Nevertheless, many did not yet reach that stage. Each of those practices alone can be daunting and, frankly, scary. Yet, we should go a step further and explore how to combine them together and see the benefits such a solution might provide.

Through a hands-on demo, we will combine Argo CD as a tool of choice for applying GitOps, Argo Rollouts for progressive delivery, and Argo Workflows for continuous delivery pipelines that will tie those two together with the rest of the steps needed in the lifecycle of our applications. If we are successful, we might remove humans from all the actions coming after pushing changes to Git repositories.

Deployment strategies affect everyone, no matter whether we are focused only on a single aspect of the application lifecycle or we are in full control. The way we deploy affects the architecture, testing, monitoring, and many other aspects. And not only that, but we can say that architecture, testing, and monitoring affect the way we deploy. All those things are closely related and affect each other.

We'll discuss different deployment strategies and answer a couple of questions. Is your application stateful or stateless? Does its architecture permit scaling? How do you roll back? How do you scale up and down? Do you need your application to run always? Should you use Kubernetes Deployments instead of, let's say, StatefulSets? Answers to those questions will not serve much unless we are familiar with some of the most commonly used deployment strategies. Not only that knowledge will help us choose which one to pick, but they might even influence the architecture of our applications.

For many people, deploying applications is transparent or even irrelevant. If you are a developer, you might be focused on writing code and allowing magic to happen. By magic, I mean letting other people and departments figure out how to deploy your code. Similarly, you might be oblivious to deployments. You might be a tester, or you might have some other role not directly related to system administration, operations, or infrastructure. Now, I doubt that you are one of the oblivious. The chances are that you would not be even reading this if that's the case. If, against all bets, you do belong to the deployment-is-not-my-thing group, the only thing I can say is that you are wrong.

Deployment strategies affect everyone, no matter whether we are focused only on a single aspect of the application lifecycle or we are in full control. The way we deploy affects the architecture, testing, monitoring, and many other aspects. And not only that, but we can say that architecture, testing, and monitoring affect the way we deploy. All those things are closely related and affect each other in ways that might not be obvious on the first look.

We'll discuss different deployment strategies and answer a couple of questions. Is your application stateful or stateless? Does its architecture permit scaling? How do you roll back? How do you scale up and down? Do you need your application to run always? Should you use Kubernetes Deployments instead of, let's say, StatefulSets? Those are only a few of the questions you need to answer to choose the right deployment mechanism. But, answers to those questions will not serve much unless we are familiar with some of the most commonly used deployment strategies. Not only that knowledge will help us choose which one to pick, but they might even influence the architecture of our applications.

We'll explore serverless, recreate, rolling update, and canary deployment strategies and we'll automate them all using Jenkins X.