Kubernetes is hard — to paraphrase the words of what one of Kubernetes’ main creators Joe Beda wrote a few years ago in one of his seminal essays on Kubernetes. Flash forward a few years later, and Kubernetes is still painstakingly difficult for most organizations to manage. However, tools and platforms are emerging to make K8s easier for developers to do their development work with little or no knowledge of Kubernetes. These solutions are designed to also facilitate the tasks of operations folks who implement the necessary infrastructure in order to allow developers to do their work with a minimal amount of learning curve to get started creating applications that run on Kubernetes. 

“Organizations moving existing apps to Kubernetes containers, either after or without chopping them up into microservices is the biggest challenge. The business expects these apps to adhere to the same SLAs and offer the same performance, security, and compliance as they did when they ran on bare metal or VMs,” Torsten Volk, an analyst for Enterprise Management Associates (EMA), told The New Stack. “There is no one tool that can take this task off the hands of DevOps, operations and security teams. 

Watching the demo of @acornlabs w/Darren Sheperd, started up by @Rancher_Labs co-founders. For developing production in @kubernetesio, the idea is to "bridge the gap" between development and production with a single artifact. pic.twitter.com/ygwB5nxjgD

— BC Gain (@bcamerongain) August 10, 2022

Recently-created Acorn Labs was launched just for this purpose. Acorn — Acorn Labs’ “first open source project” — introduces a “developer-friendly” approach to deploying applications on Kubernetes, Sheng Liang, CEO at Acorn Labs and co-founder with Acorn Labs President Shannon Williams (both also co-founded Rancher Labs), said. Acorn was also designed to help with a typical pain point: the dreaded YAML configuration. Indeed, developers are generally comfortable with building Docker containers but often find it quite challenging to work with low-level Kubernetes YAML files directly, Liang said. Developers similarly struggle with tools like Helm which simply wrap YAML files. Acorn represents a new class of tools that allow developers to work with higher-level constructs without having any Kubernetes knowledge, he said.

It will be interesting to see how this plays out. This writer, for example, has repeatedly learned to configure YAML files for different versions of Kubernetes, promptly forgets and then has to relearn the process each time. If Acorn Labs can indeed deliver to simplify this process, then that could be a potential boon for developers. However, some observers remain cautiously optimistic. “While the principle behind Acorn of having just one artifact that controls development, testing and production environments, there still is a lot of YAML for developers to write, but at least they do not have to write it separately for every cloud,” Volk told The New Stack.

One of the biggest issues for DevOps teams attempting to work with Kubernetes is that developers, operations and security team members remain siloed — not because they are not attempting to work together, but given the different types of tools each might adopt to do their work. Indeed, inconsistencies between dev, test, and prod environments are still a big problem today, even in times of mostly standardized Kubernetes environments, Volk said. Each of Docker Desktop, AKS, EKS, GKE, OpenShift, Rancher or Tanzu comes with its own secret sauce in the form of developer services, service networking capabilities, ingress controllers, storage integration, disaster recovery, etc., for example. “If Acorn can make these issues go away so that developers can define deployment instructions once and then they work across developer laptops, test and product environments, this would definitely be significant progress,” Volk said.  

Another key technical challenge of such tools is how to deliver a simple user experience without compromising the power of Kubernetes, Acorn Labs’ founders said. Acorn is designed to support many types of applications, including the Kubernetes and microservices stateless and stateful applications, such as storage and databases. To describe complex application constructs, Acorn has its own configuration language, loosely based on CUE, that supports loops, conditionals and functions, while the scope of Acorn will expand over time. For example, the founders said the current version of Acorn does not support custom resources, a feature requested by quite a few early users of Acorn. According to the plan published on GitHub, the development team is working on adding custom resource support to Acorn.

“An additional benefit of Acorn, beyond ease-of-use for developers, is its ability to enforce best practices in using Kubernetes so that the applications are more secure and reliable,” Liang said. “Once developers package their apps as Acorn images, these Acorn images can be deployed with confidence in production environments.”

Fellowship of the K8s

The Acorn Labs project has attracted some interest since its launch a few weeks ago. “The recent Acorn Labs release looks super-interesting, and it appears they are aiming to fill the ‘application packaging’ gap that has emerged with microservices and container technology,” Daniel Bryant, head of developer relations at Ambassador Labs, told The New Stack. “The application primitives provided by platform infrastructure like Kubernetes are too low-level for the ‘99% developer’ who just wants to write code and get it deployed and running.” 

Still, what Acorn Labs is hoping to accomplish is not an easy problem to solve, Bryant said. Others have tried it before. Examples include HashiCorp’s Otto and Docker’s Stacks. The key will be creating the ‘Goldilocks’ developer experience across the necessary stages of coding, shipping, and running within the cloud native SDLC,” Bryant said. 

Different Kubernetes CI/CD platform providers can also be complementary. “The CNCF Emissary-ingress and our Edge Stack API gateway solutions could be readily packaged as part of an Acorn file application definition, as everyone needs to get user traffic to back-end services,” Bryant said.

“Acorn could also be used to package and deploy applications, and Telepresence will enable developers to bridge the local-to-remote development and debugging gap easily,” Bryant said.  “With a simple CLI or web-based UI, developers can use Telepresence to debug a service running locally that is dependent on a remote large-scale Acorn-managed K8s deployment.”

Light at the End of the Tunnel?

Progress is being made, but much work needs to be done. Even for those organizations that have implemented the right tools, training and culture to let their developers create and rapidly deploy great applications on Kubernetes with minimal friction, the containerized environment remains a struggle, except maybe for Google — and even still — for those organizations without the cash burn runway like the Netflixes of the world.

“It’s short-sighted to resign to ‘Kubernetes must get easier for developers.’ Speaking to CIOs years ago, I consistently heard, ‘We feel half pregnant with containers and can’t bring this initiative to term. We’re aggressively looking for ways to back out of this,’” John Steven, CTO at ThreatModeler, an automated threat modeling provider. “So, yes, Kubernetes — like any new technology platform — will have to evolve or it may simply get replaced because it fails engineers in the effort/benefit tradeoff. There were times when Docker or Heroku were considered world-eating, but no more: they failed to evolve beyond their limitations and complexities.”

Indeed, like many technologies, Kubernetes’ Achilles Heel stems from its strength, Steven said. “Kubernetes designed ‘For Google By Google’ to orchestrate humanity-scale application operation,” Steven said. “Looking at the limitations of their data centers, organizations misinterpret their desire for ‘cloud-native infrastructure flexibility’ with that humanity-scale experienced by Gmail, Search or Drive.”