Before Spinnaker, GetYourGuide was using its in-house tooling, which leveraged the Kubernetes API for deploying Kubernetes Manifests and ECR images. Outside of the Infrastructure team, there was very little know-how of how deployments worked. It was impossible to extend a pipeline, very difficult to test changes to manifests, and they were using only a small percent of the Kubernetes API. There was no support for CRDs, keeping up with the Python Kubernetes API was a challenge, and they were triggering rolling updates with no other control over deployment strategies.
In addition, hdeploy regularly timed out and had a hard time adopting new deployment targets. Neither hdeploy or Convoy had a deployment locking mechanism, which meant that two engineers could deploy two different versions at the time, resulting in either inconsistent states or nondeterministic behavior. And both tools worked as “trigger, then forget,” tools; after a deployment was triggered, there weren’t machines checking to see if the traffic should be handled or if the deployment should be rolled back.
More broadly, GetYourGuide was seeking to replace in-house tools with the leading industry standard, modernize its workflow to fully-automated multitarget deployments, add canary-based releases for resilience, and fully leverage the power of a microservice-based design.