Why Kubernetes should be like a vending machine

A vending machine is the ultimate self-service device for selling stuff. They have a self-explanatory user experience, which makes it easy for users to get exactly what they want, when they want it, securely; all without having to talk to anyone about anything.

As the owner of a vending machine, you’ve got two jobs: make sure it’s stocked and make sure it works. That’s it. The concept of a vending machine is simple and there’s a lot we should learn from them as we think about how best to deploy containers and Kubernetes.

Why?

As an IT team, our mission is to create a reliable and resilient ‘self-service’ operating environment that allows our customers (typically developers, but sometimes an ‘apps’ team) to deploy software and resolve problems quickly and easily without talking to us. We did this quite well in the past with IaaS based environments; deploying automation tools that offered service catalogs, letting users self-serve and deploy pre-configured VMs on-demand. So…surely, we can just do the exact same thing with Kubernetes, right?

Out of the box, Kubernetes is about as far from a vending machine as you can get. Kube’s claim to fame is it can be made to do anything, in any way, and it does this by being near infinitely configurable. However, it’s this vast flexibility that makes it so difficult for IT teams to offer a predictable, self-service, catalog-based service offering for their customers.

If you want the transformative power of Kubernetes to be adopted widely across your organization, you need to remove a lot of this configurability and get back to offering a standardized set of services that are easy to understand and easy to consume. By overlaying a third-party Service Delivery Platform, Kubernetes can start to look a lot like the vending machine we’re looking for.

A Service Delivery Platform turns your Kubernetes implementation into a Containers-as-a-Service (CaaS) environment. It gives users secure self-service access to the functionality they need through a simple GUI that negates the need for them to learn the intricacies of Kubernetes. It also gives Platform Managers the ability to set up and configure the rules by which developers play, which puts them firmly in control of how the ball game is played.

A well configured service delivery platform enables users to:

• Instantly deploy vanilla “turnkey” fully functional landscapes (picked from a catalogue), equipped with all the supporting services their application needs to run
• Easily deploy their application into that landscape
• Keep their application up to date as they develop new features (CD)
• Facilitate the easy promotion of their application across environments through a simple “click to promote” process
• Provide a simple means to triage their application should it not function as expected
• Scale their application to support increasing production loads
• Easily configure the reverse proxies and load balancers needed to run their application successfully in production
• Easily consume storage when they need to make applications persistent
• Provide a “secure by default” behavior, removing the burden from the user to ensure this is done right.

All without having to write a single line of YAML or know any CLI.

The concept of a Service Delivery Platform isn’t new – there are a number of fairly well-known examples around already (not necessary called SDPs) and no doubt plenty of start-ups in the wings chomping at the bit to enter the space. However, not all platforms are equal and there are at least 2 important things to think about before selecting a vendor.

• Some SDPs come tied to a full stack of Kubernetes capability underneath them (K8s distro, Managed Service etc) which starts to look a lot like vendor lock-in. If you get hooked on a particular SDP, and it’s tied to a particular K8s distro, then there’s no easy way out of that distro. That might be OK in a mature market, but the Kubernetes market is moving fast and today’s ‘distro-of-the-day’ might not be tomorrows (it won’t be) and right now you need to not lose your ability to be agile.
• The SDP’s interface can be as hard to learn as Kubernetes itself. We’ve played with a lot of SDPs and whilst they might be easier to use than Kubectl, they are definitely not simple, straightforward and intuitive. Interestingly, many of today’s SDPs have been designed to surface every last piece of Kube functionality, which is good in theory, but as we’ve established already, large parts of Kubernetes simply aren’t relevant or necessary for ‘mainstream’ implementations and can create more problems than the solve.

Portainer differs from other SDPs on the market in 3 important ways

• It works with any / all distros and can be used to provide a single consolidated view of clusters running in different environments. This is unique and as organizations spread their clusters across different environments a critical piece of capability
• Assuming your team is familiar with containers and have come from a Docker background (most have) then there’s a good chance they will already be familiar with Portainer’s interface as Portainer cut its teeth in the Docker world
• Portainer is moving forwards at a pace and by hitching your wagon to Portainer you won’t need to change or retrain your team as the market moves and changes (think serverless) as we’re already working on what’s coming next….

So, if you’re heading into Production with your Kubernetes implementation and you can see the value in a vending machine then give Portainer Business a try with 3 free nodes.