Hiram Software adopted Kubernetes for hosting production workloads, jenkins, and internal corporate resources.

Read on for the longer story.

Hiram Software’s AWS account dates back to 2010, back when “the cloud” meant running virtual machines on someone else’s servers.

A lot has changed since then. Heroku, Beanstalk, Chef/Puppet, ECS – all have come along, but none has really stuck. They all were “bolted” on to the 1.0 wave of cloud computing.

Kubernetes feels different. It feels like a major step towards a 2.0 wave of “the cloud” (whatever that is). We waited to jump on the Docker train, and once we did we were happy to use ECS. Over time, however, we found a little bit of friction in having to manage “task definitions” and ingress with ECS. ECS gave us density (more applications per EC2 instance), but it didn’t really give us elastic application hosting. The new ECS Fargate may do it, but it still depends too much on clunky ECS concepts.

With Kubernetes, we just apply a new yml file and “stuff happens.” It’s been wonderful with Jenkins, which historically suffers from the peak load problem and dirty workspaces. Kubernetes solves both by making builds start faster, run faster because images already have dependencies (we use our own build images), and builds no longer share workspaces.

Plus, we self-host a few applications (Wekan and Gogs to name a few). It’s nice to be able to “install” applications and set ingress all by making a yml file. It also means upgrading applications is as easy as bumping the version on the docker image.

We look forward to AWS adopting more and more Kubernetes features. I think AWS’s security (IAM) + Kubernetes ease of use will be an unstoppable combination.