Moving from Heroku to Google Kubernetes Engine
We&#x27;ve been running in production on GKE for a little over two years and it&#x27;s been a solid platform since day one. It&#x27;s nice to read articles like this and see others coming to the same conclusions we&#x27;ve come to. If your practices and workflow are oriented to containers and you outgrow your PAAS then k8s is the logical place to land.<p>With respect to the choice of helm: we started out rolling our own pipeline with sed and awk and the usual suspects. When that became too complex helm was just taking off and we moved to that. We still use it to install various charts from stable that implement infrastructure things. For our own applications we found that there was just too much cognitive dissonance between the helm charts and the resulting resources.<p>Essentially the charts and the values we plugged into them became a second API to kubernetes, obfuscating the actual API below. The conventions around the &quot;package manager&quot; role that the tool has taken for itself also contribute to lessen readability due to scads of boilerplate and name mangling. We recently started deploying things in a new pipeline based on kustomize. We keep base yaml resources in the application repo and apply patches from a config repo to finalize them for a given environment. So far it&#x27;s working out quite well and the applications engineers like it much better. Now with kubectl 1.14 kustomize&#x27;s features have been pulled in to that tool, something I have mixed feelings about, but at least the more declarative approach does seem to be the way the wind is blowing.