A colleague asked me the other day “what is serverless actually good for” and it did take me a minute to come up with a good answer. There seemed to be a lot of hype over lambdas and cloud functions a few years ago, it felt like we were at a tipping point in the cloud journey where server boilerplates were going to be abastracted away from us just as the phhysical servers were abstracted before.

I found myself needing to write an integration test for a complex workflow invovling dynamic payloads being delivered to kubectl. The idea is that a user can call a rest endpoint, which will kick off a whole Rube Goldberg machine, the end result is that a kubernetes manifest is generated and applied. There are many moving parts and a solid testing stratergy is needed. In particular it’s essential that we have full end to end testing that shows a user can reliably submit their payload and a real job is spawned on a cluster as a result.

Kustomize is a tool for composing kubernetes manifests. It helps you to not repeat yourself when configuring many resources which are similar and staging those resources accross environments whciih are similar. It is not a templating language. In general this is a good thing. There are other tools whcih can help you with templating, kustomize just helps with boilerplate reduction. I ran into a situation recently where I found it desirable to have both a CronJob and a Job resource which were mighty similar.

In this post I’m going to talk about running kubernetes locally on a dev machine. Specifically I’m going to cover Why you might want to do this What the options are Making the dev experience not suck Why? Kubernetes is a sledgehammer, your dev environment is a nut. These two things do not work well together. If you can avoid running kubernetes locally on a day to day basis you absolutely should.

Node moves fast. Like most people I manage the frequent updates with NVM. A feature I wish existed in NVM is a one liner to updgrade to the latest available node and set this as the system default. Fortunately this is not too hard to script, here’s my attempt: #! /usr/bin/env bash source $NVM_DIR/nvm.sh CURRENT=nvm current LATEST=nvm ls-remote | tail -n 1 | grep -o "v[0-9\.]*" echo "current ($CURRENT), latest ($LATEST)" nvm install $LATEST –reinstall-packages-from=$CURRENT nvm alias default $LATEST Reasonably self explanatory but a couple of points are worth noting: