Introduction¶
Karrots is a devops automation tool that greatly reduces the amount of work and time it takes to bring new ideas safely to users in production. With a single command, karrots create-cluster, you can create a complete gitops-automated cluster that includes base services such as global load-balancing (Envoy, Linkerd), CI/CD (Jenkins), application auto-scaling and observability/metrics. This cluster will also automatically load and deploy your application code entirely via gitops — your team members rarely, if ever, need to access clusters directly.
Because it only takes a few minutes to create a fully-automated cluster that runs your applications entirely from a git repo, it is easy for you to branch and fork these clusters for disruptive work. If you know you have to make a large or breaking change, you can literally branch a deep copy of your QA cluster and test this risky development against the real thing. Once you've proven this new work, you simply merge the branch back to the QA cluster without any surprises at all.
The Two Main Karrots Audiences¶
Data analytics: Teams that struggle to build and maintain secure, reliable and performant production-ready deployments¶
Data analytics teams often work with common tools such as Python, Jupyter, Spark, Airflow, ELK, etc., yet they find themselves doing most of this work from a laptop without an easy way to deploy to production. Even in cases where the team has an easy way to deploy to production, there will often be only one run environment — production itself! This makes experiments and breaking changes hard to manage without significant risk to the production system. Karrots solves this by making easy to branch and create new clusters that optionally deploy base service that a data analytics team needs. With a simple git branch, you get a deep copy of QA so you can work without introducing risk to production.
Devops: Teams that want to accelerate the rate of change in their developer teams while also increasing reliability¶
Most devops teams maintain foundational clusters that run persistently for many years. In a nominal "path to production pipeline," such as dev→qa→stage→prod, each cluster is not only inscrutable, but worse, they drift from each other significantly with no easy way to understand what's different, and no easy way to bring them into alignment. Another problem is that some security and structural changes can only happen when you create a cluster, so if you run a cluster for years and years, you will accumulate unfixable debt, often around your security posture. The result of these shortcomings is that devops teams treat their foundational clusters as hothouse orchids, endlessly fussing over them when really these clusters should be ephemeral — easy to create, branch/copy, spin-down or destroy.
Because you define Karrots clusters entirely within git, you can easily test disruptive infrastructure changes. In the past, major architectural changes represented a huge challenge to setup and test, but now you can quickly branch a story cluster from QA and heavily refactor that story cluster with no risk to the team's other work. Maybe it takes months to complete an architectural overhaul, but during that time you merge changes from the QA to the story cluster so you know if the new architecture maintains test parity with QA. When you complete this work, you simply nominate the story cluster as the new QA cluster.
Where to Start¶
Depending on the type of team you find yourself on, we invite you to start with one of these overview sections: