Hiring and keeping tech staff with in-demand container chops is a challenge for many companies.

Daniel Bryant, an independent tech consultant with 15 years of experience focused on dev-ops, cloud container platforms and microservice implementations, has a few ideas on how to set up a developer experience that will keep the both company and devs happy. He led a recent hour-long webinar packed with tips hosted by the Cloud Native Computing Foundation (CCNF).

“Developer experience is all about minimizing the friction from the idea through to the code in the config to delivering business value,” he says. “how you construct your platform influences the developer experience, high productivity and bottom line fun as an engineer comes from intentionally designing the experience of things like local development, and debugging packaging apps, CI/CD deployment control and observability.”

Infrastructure first

“It’s kind of like Maslow’s hierarchy of needs, you definitely need to get the infrastructure right, build the platform on top and then correspondingly create a workflow,” Bryant says, adding that the workflow can have a bigger impact on velocity and business value but must be built on firm foundations.

Find your workflow

The ideal workflow has definitely shifted over the years. When Bryant started, waterfall was the way to go and while it’s not necessarily a bad method, it assumes you know all the requirements before starting, which might be the case in, say building a bridge, but doesn’t always work in tech.

“With software we have hypotheses, we have ideas but we need to validate them and therefore agile become the de-facto way of doing things, because it’s kind of waterfall but in smaller iterations,” Bryant says. He cites Netflix as an example: with cross-functional teams, each with its own dev, QAs and product managers, “They’ve got everything you need to basically offer a product, they’re moving away from projects to products,” he says, whether that’s streaming play back or analytics. The cycle goes from idea, coded locally, deployed to Kubernetes, then Canary tested, and then measure the impact (with a tool like Prometheus) on users.

DIY platform on Kubernetes

If you’re thinking it would make sense to roll your own platform-as-a-service on Kubernetes, Bryant says there are a few key questions to consider:

Do you want to do everything locally, or do you want to do more more in the cluster?

Do you want to have a Cloud Foundry-like an experience (where Docker/containers aren’t installed on local machines).

How quickly do you need user feedback?

Do you have a strong opinion on code repository structure?

Do you want “guide rails” for dev teams?

Whether you go with remote or local development, “it’s all a trade-off, we’re not saying that one ways better than the other, though if you run everything locally it’s probably not realistic to production,” Bryant says. More on these options and consequences in the chart:

Find the right pattern

There’s definitely a pattern emerging for Kubernetes for for ops, it’s pretty much becoming the de facto container orchestrator-as-a-service,” Bryant says, adding that he has previously worked with Amazon ECS and Mesos. “All the cloud vendors are basically coming up with a hosted Kubernetes offering, it’s kind of becoming the new cloud brokerage platform.” The extensibility of Kubertetes means that there’s plenty of room to impact the developer experience, whether its building custom controllers. “As platform operator has a platform engineer you can really add a lot of value to developers by potentially creating custom resources custom controllers.” For development and deployment, Bryant goes into the advantages of using Draft, GitKube, Skaffold, Helm, KSonnet and Forge. Other key patterns to put in place include those for overall development and deployment, CI/CD and observability.