Kubernetes is probably the most talked about option for managing containerized applications at scale in the cloud. Any organization looking to have DevOps capability probably has looked at or will look at Kubernetes. Kubernetes is extremely capable, flexible and powerful, which means it can get complicated.
Container Bliss
Our team develops containerized apps using the Apex Designer low code design tool. For several years, we were happily running the apps on Pivotal Cloud Foundry. It supported docker containers, had an easy to use command line interface and a management portal as well. There were certainly things it could have done better but for most of our low code app developers, it worked just fine.
The Pivotal Fire Drill
Then last September, we received an email with the subject "Pivotal Web Services End of Availability (EOA) Announcement and Timeline". While the advanced notice was pretty short (4 months), we were in a good situation because we were already moving Apex Designer itself onto our shiny new Kubernetes cluster. We completed that migration on December 15th. Then the fun began.
Do we really need to learn all this?
Our developers (myself included) were comfortable and confident using the Cloud Foundry but suddenly needed to learn Kubectl, Helm, Octant and a whole bunch of new concepts and terminology. Kubernetes is powerful and flexible but the complexity can be overwhelming for a development team.
There must be something out there...
I dove down the Kubernetes rabbit hole over the holidays - reading about and trying various tools. I certainly learned a lot (of things I wish I didn't have to) but unfortunately, didn't really find what I was looking for.
Helm charts are ubiquitous and have powerful parametrization capabilities but the templates get complex quickly.
Kustomize's declarative approach using bases and overlays is much more approachable but you still need to know a bunch of Kubernetes objects and it doesn't manage dependency complexity and situational logic.
Knative was interesting because the Knative Service manifest was so much simpler for a developer. The scale to zero capability was also interesting for our dev and test environments (but even for some of our lightly used production apps). When I discussed Knative with my cluster admin, he was concerned about the added overhead for our relatively "normal" Kubernetes workload and that he would have less control over how the workloads are run.
What do we really want?
I discussed the situation with our team and we decided to invest a couple of weeks to see what we could come up with. We chose Nick as our "developer" representative and Rama as our "cluster admin" representative.
Nick shared what he wants as a developer:
- Run and manage my app in Kubernetes without having to learn a bunch of new concepts and commands
- Easily provision and manage my app's dependencies (databases, utilities, etc.)
- Do 1 and 2 first and then learn Kubernetes as time permits (maybe never if I can do everything I need to without learning it)
Rama shared what he wants as a cluster administrator:
- Spend less time hand-holding developers hands and answering silly questions
- Make sure that apps are deployed the way that I want them to be
- Maximize the value my cluster delivers by minimizing wasted resources
What should we call it?
We started putting together concepts to meet these needs and picked a code name for our new project: Harbor Pilot
A harbor pilot is a mariner who maneuvers ships through dangerous or congested waters, such as harbors or river mouths. They are navigational experts possessing knowledge of the particular waterway such as its depth, currents, and hazards, as well as being experts in handling ships of all types and size. Wikipedia
Basically, a harbor pilot is brought onto a ship when things get complicated.
How are things progressing?
The concepts came together nicely and we started refining them through prototype iterations. Our first commit was on January 11. Four weeks later and we had a functional prototype and a complete set of concepts. We are planning to run a closed beta for a limited number of test users to confirm that we have hit the mark for basic capabilities. If you are interested in being included in the beta, please sign up here.
Meanwhile, you can read more about the developer view of the application here, and the cluster admin's view here, and keep an eye on the blog for further updates.
