Developers and Operators — A Complicated Relationship

In the cloud there are two types of people making the magic happen: Developers and Operators.

Developers — Putting the Software in SaaS

Developers are concerned with application speed, stability and new app features.

Developers are exactly what they sound like. Devs build, test and push out code as fast as possible. Developers are always thinking about the speed and stability of their applications. Getting new features and enhancements into the hands of users, as fast as possible, is job number one.

Operators — The Team Behind the Curtain

Operators worry about the underlying infrastructure, security and compliance.

Operators generally build and manage the resources that developers use for their applications. This includes databases, servers, and cloud resources. While this is not their entire responsibility, operators tend to worry about things like security patches and scaling up the infrastructure as their main focus.

While their roles have evolved over time, operators are often responsible for regulatory and compliance requirements. This includes things like data encryption, redundancy and data backups. These are critical to the business but generally don't concern the developer.

Though operators do more than spin up infrastructure for developers, this post is focused upon the relationship between the two.

Where Operators and Developers meet

The operator creates a new server. The developer deploys their app to run on the server. The developer knows if the app is a banking app processing customer payments or a game app saving high-scores. These applications have very different security and infrastructure needs.

Developers deploy applications on infrastructure managed by Operators.

Developers continue working to fix or improve their applications after deployment. When devs create new features or bug fixes they want to deploy the new version of their app right away.

The challenge is that operators don't want developers to access the infrastructure. Operators worry that developers may change security policies or violate regulatory requirements. Operators force developers to work with them to deploy new versions of their apps.

Developers can't self-service app upgrades without Operator involvement.

Kubernetes to the Rescue

Kubernetes solves these problems. Kubernetes allows developers to deploy their applications without waiting on operators. Kubernetes allows developers to deploy software independent of operator policies. Operators to manage the infrastructure like servers and databases. They rely on Kubernetes policies to determine which servers host which applications. Operators can ensure the bank app is only deployed on a secure server. This creates a developer "self-service" environment. Developers deploy their apps without needing Operator involvement.

Kubernetes allows developers to deploy their applications without Operator involvement.

Developer self-service is great but Kubernetes is more than an app deployment tool. Kubernetes is a full control plane providing APIs and automatic state enforcement.

The Power of Control Planes

APIs are well understood in the cloud ecosystem. APIs provide a standard way for programs to speak to each other. APIs define acceptable questions ("requests") and templates for answers ("responses").

Less well known is the concept of "state enforcement". "State" is the current status, or state, of something. For example, is a server on or off? Is the database encrypted or not?

"State enforcement" is defining what the state should be and ensuring that it's true. If the state changes, an external program sets the state back to the desired setting.

A machine enforcing the state of a switch. Source: Make:

Kubernetes provides state enforcement for applications and policies. Kubernetes ensures everything is doing what it's supposed to. It constantly monitors the apps and infrastructure to ensure what developers and operators asked for is true. For example, if the developer wants four copies of their app Kubernetes enforces this. If an app crashes or a server goes offline, Kubernetes deploys a new copy.

The Limit of Kubernetes

Although Kubernetes solves many problems related to application deployment there are still gaps. Kubernetes works great when the only thing an application requires is a server to run on. Many applications still need things outside the scope of the Kubernetes cluster. Things like cloud managed databases or object storage.

Application deployments requiring these external resources still need operator involvement to deploy. The developer asks the operator for a cloud resource and waits to deploy their app. This creates the same slow down and friction that Kubernetes tried to solve in the first place.

Developers requiring cloud resources still need to ask Operators for help.

Crossplane goes beyond the capabilities of Kubernetes to control infrastructure outside of the traditional scope of Kubernetes. Crossplane uses Kubernetes Custom Resources to connect Kubernetes to any external cloud resource. This enables the same Kubernetes-centric deployment process regardless of the resources involved. Crossplane is available as both open-source or as fully-supported Upbound Universal Crossplane.