Why Cloud-Native DevEx?

You know there’s something wrong with the developer experience in Kubernetes/containers. Let's discuss why and how we ended up here, so we can move on to the specific solutions with the right mindset.

You’re working on the dev workflow of a team or a project, and you know there’s something wrong with the developer experience in Kubernetes and containers. But maybe you’re not sure how to reason about it, or how to deal with it.

In this series we’ll show you the most common issues people face in this realm, and how to solve them.

But first, in this first video, we’d like to discuss why it is that now in the containers and Kubernetes world, suddenly, developer experience is such an important topic. And with that knowledge, we can go into the rest of the series with the right mindset.

There are four questions that come up really often when people first go down this rabbit hole of cloud-native developer experience. I’d like to invite two colleagues to join us in this video and tell us the answers to those questions and a bit more about those subjects.

Those questions are:

  1. Why is developer experience so important in the cloud-native world?
  2. Is an IDE not enough tooling?
  3. What if I already have a really good CI/CD setup?
  4. What is the end game here?
    What does the goal of developer experience look like?

So without further ado, let’s get to the answers.

Why is developer experience so important?

Helping developers focus on what matters instead of busy work is what’s taken us from writing assembly to writing high level languages.

It’s especially important though in the cloud-native world because when it comes to the inner loop of development — as you’re typing and compiling and getting feedback exploring —  not only has the cloud not helped, it’s actually hurt.

How has the cloud hurt?

Well it changed the vector that we’d been traveling on.

For decades, your app got bigger by your binary getting bigger. You wrote more code. You included more libraries. And tools from Make to Ant to Maven to Bazel are great at making binaries quickly.

But with cloud native architectures now your app gets bigger by having more binaries and having to coordinate them. There’s more plates to spin.

You can see this in an IDE when you’re trying to debug a file.

Well what happens when that file is actually included in 5 of the 17 binaries that make up your app?

How do you interact with that?

You don’t just have one standard out in standard err. You need new paradigms.

So now that’s back to you the developer to manage. It’s like we’re back to writing assembly.

What if I already have a really good CI/CD setup?

You generally do something before you do a git commit and push. You have some way to run your app to test it out. Or you have some way to run unit tests. You run a code linter.

CI/CD  is really important. But you’re almost certainly doing other things too.

There’s a lot more to developer experience than CI/CD because the development process starts much earlier in the workflow.

A lot of time people just aren’t aware of these things because you’ll look at those diagrams and descriptions of the software dev lifecycle (SDL) and it leaves out everything before CI.

But those things are still there!

And that brings us to a separate topic: flow.

Now staying focused in a flow state while working is vital. It’s productive. It feels great.

Anything that distracts developers from that is doing us all a disservice.

Ideally developers should stay in that flow state uninterrupted with no distractions.

No building images. Updating YAML. Restarting processes by hand.

Those are all like paperwork. It’s not what really matters.

CI/CD is like a printing press or like a laserjet printer. On the other hand, you have a text editor.

One is to package things up and make them production ready. While the other
is to experiment, to try, and to figure things out.

Isn’t an IDE enough tooling?

IDEs have always wanted to give developers the workflows they need.

In the past few years they’ve realized they can’t be everything for every language. So they’ve been offloading that. Language Server Protocol (LSP) is an example of how they don’t have to maintain a built-in compiler.

At the same time that they’re looking to offload existing workflows, we’re also
seeing that cloud-native means you need to support new workflows for developer experience.

When those two waves crash together, it means there’s even more of a gap. That’s what we’re looking to address.

What is the goal of developer experience?

"You shouldn’t have to know all [your services] just to get started. You should be able to zoom in on what you’re interested in. But you shouldn’t be required to."

One goal is to get as much as possible out of a developer’s way. Those devs should be able to focus on what really matters to them and not on paperwork and boilerplate.

Kubernetes. Containers. Builds. Certificates. Database migrations.

Who wants to worry about all of that?

Let’s just get them all out of the way.

Something else that’s important is that you want devs on your team to be able to come in and not have to understand the entire architecture of the entire system just to make progress.

Before there were build tools you could just run make or whatever. But the cloud changed things. So that kind of went away.

Now an application has many different parts. Each one’s written in a different
language running in a different environment.

You shouldn’t have to know all of them just to get started. You should be able to zoom in on what you’re interested in. But you shouldn’t be required to.

So we can still have that workflow with the proverbial Make. But nowadays it just looks a little bit different.

What’s Next?

Hopefully this discussion made it a bit clearer why developer experience is such an important part of the cloud-native world.

On the rest of the series we’re gonna be more practical. We’re to go down into the nitty-gritty and talk about practical things.

We’re going to talk about config files and tools like Helm and Kustomize.

We’re going to talk about development clusters both local and remote.

We’re going to talk about tools like Tilt that automate away the boring parts of your development cycle.

Once we’re done with the basics, we’re going to talk about some more unusual and advanced developer workflows to take things even further.

If this sounds like your kind of thing just sign up! We’ll send you an email whenever new content is published. You can also subscribe on youtube or with your favorite RSS reader.

See you next time!