Skip to content

Overview

What is Karrots?

Short version: a cluster for every story

Karrots is an open source command-line tool that implements the ZeroDiff philosophy using Terraform to quickly create an idiomatic, gitops-automated Kubernetes cluster that is a faithful copy of your production cluster. It has an opinion of how to build secure and manageable clusters. Through community feedback, this opinion improves over time, but you can always eject and hand-maintain the Terraform yourself.

A Karrots cluster contains these optional services:

Ambassador (Lyft Envoy) Load Balancer
Weave Flux/CD gitops
RBAC-Manager
Bitnami Sealed-Secrets
SumoLogic
Automated DNS routing records
Automated TLS certs (Let's Encrypt)

(And many more on the way!)

What Problems Does it Solve?

Short version: system changes are risky resulting in lower velocity

Distributed systems can incur high-risk for even modest changes, so a common strategy is to resist change outside of big-bang releases. This resistance to change reduces the rate we can bring ideas to market. Further, since a company expresses no value until it commits its ideas to production, uncommitted ideas and work are capital locked-up in the business. That leads to lower competitiveness and financial strength.

How Does it Solve Those Problems?

Short version: ZeroDiff

Issue one command, and in the time it takes to brew a coffee, you get a faithful copy of your production cluster where you can work on a story that may contain disruptive change. With zero difference between prototype and production, any new idea can go to production immediately. You test exactly what you intend to release as a collective whole, so releasing it is a low-risk git commit. When each story has its own cluster, you can test disruptive change without risk to other stories or QA!

With lower change-related risk, we can increase the release cadence and make releases less lumpy. This brings the designers, developers and users closer in time which numerous studies have shown leads to better products and user experiences.

What's with the Funny Name?

It's short for "Karrots not orchids." Orchids are a quintessential hot-house flower that require never-ending care and protection, where carrots are predictable, hearty, and bred to grow reliably, so you can harvest and move on. If you're fussing over your clusters, you're holding back the entire organization.

What is Karrots' Approach?

Karrots is a manifestation of the ZeroDiff philosophy: maintain zero differences between prototypes and production. The goal is for designers and developers to use tools where work is always production-ready. When you can ship any work at any time, you become more responsive. New work and new ideas can reach users faster, allowing us to better measure and test concepts. It also makes it possible to fix bugs faster, or recover from sub-optimal approaches.

How Would We Adopt Karrots?

Every Karrots cluster is a git clone that's meant to stand alone — including the first one you ever create. If you're already a Kubernetes shop, then you can follow our guide on how to easily migrate to your first cluster: [coming soon]. If you are new to Kubernetes, but you use containers, then you can follow our seed cluster guide: [coming soon]

Eventually you promote your first Karrots cluster to take over a foundational pipeline cluster like QA or staging. From that point forward, for each new story, you branch a companion cluster for that story.

What does a Karrot Dev Cycle Look Like?

With a single command you can bring up a fully gitops-automated cluster that runs foundational base services along with your applications. If you use Karrots to build the clusters in your software delivery pipeline, then a single command will allow you to branch any part of the pipeline. Need to do disruptive QA work for story JIRA-1234? No problem, just do the following! 

cd ~/git/karrots-cluster/clusters/qa
karrots branch feature/JIRA-1234 qa-feature-1234

About 20 minutes later a QA cluster clone comes up at https://qa-feature-1234.[your-domain.com].

Now the team can begin story work in isolation using a cluster that's equivalent to QA. Change the image tag of an application's deployment.yaml so that it deploys dev work from story JIRA-1234 and two minutes later the cluster is running disruptive JIRA-1234 story changes without any risk to the current, official production QA cluster. If you setup your CI/CD to deploy new images on every feature branch commit, the QA clone will remain synchronized with all story work. There is never any confusion about what's ready for test and where any changes came from!

When the team completes their work and the QA clone is stable, promoting their work to the official QA cluster is a simple git merge.

How is Karrots Doing This?

Karrots uses Terraform to spin-up a Kubernetes cluster that has Gitops automation provided by FluxCD. It configures FluxCD so once the cluster is running it synchronizes with the git repo to bring up core services: What Karrots provides in a New Cluster. It also configures FluxCD to synchronize your services and applications.

Karrots can build clusters in AWS/EKS, Google/GKE or Microsoft/Azure. It doesn't do anything differently than a human would — it just does it using automation and results in sensible, declarative and secure operations.

Karrots Enables ZeroDiff in the Software Delivery Lifecycle:

No Kubernetes cluster should be an orchid — we should spin them up ephemerally, on-demand, consistently and securely so that all run environments operate the same with no magic or surprise. This is the ZeroDiff way: remove all differences between prototype and production, so you can easily and safely ship any working prototype. When the developer-test environment operates exactly as the production environment then we remove impediments to promotion, and that increases how quickly we can safely introduce new ideas to our user base.

Cheap Clusters, Sold by the Kilogram

With Karrots we can easily bring up clusters wherever and whenever we want. AZ failure? No problem, spin-up in a new AZ. Load-Balancing by geo? Sure, spin-up the same cluster in multiple geos. Need to work on an exploratory application concept for an important customer? You got it, spin-up a cluster dedicated to that work. In all these cases the clusters are equivalent, so promotion is entirely by git merges. Incorporating exploratory work has never been easier.

Canaries are Now Easier Than Not Canaries

Because we can spin up a clone any software delivery pipeline cluster (QA, Stage, Int, Prod), we can now do things like branch the Staging cluster. Configure the global load-balancer to send a percentage of traffic to the branch cluster so we can prove the new work is good and safe. We can repeat this when we promote work to production. Working this way, our new or junior devs work with a safety net. This makes it possible for them to work closer to production sooner without getting clobbered. It also allows their ideas to reach production faster, and that leads to more satisfying work.

Self-Documenting and Visible by Definition

Because Karrots clusters are 100% Gitops, any changes you make to your services are self-documenting by definition. You can also git diff any two cluster branches to see clearly their operational differences.

All the Things You Can do

When you use Karrots to manage your software delivery pipeline here are just a few of the things you can do:

  • Quickly create ephemeral clusters that are exactly equivalent to production, but then use them for any purpose such as disruptive feature-refactoring work.
  • Quickly remake foundational clusters for any part of the delivery pipeline: Dev, QA, Stage or Prod
  • Quickly branch, refactor and test the run environment for any part of the delivery pipeline without impacting the current pipeline.
  • Continually update every foundational cluster in your delivery pipeline with the latest Kubernetes practices, including security, versioning, resource management and overall cluster organization. And do this safely by iterating these upgrades on a branch that you can test without disrupting the current production pipeline.
  • Git-diff any two running clusters to see exactly how they differ.
  • Track all changes made to all run environments in the delivery pipeline.
  • Roll-back failed changes or bad ideas.
  • Posses, by definition, a complete, accurate and up-to-date record of exactly what's running in every pipeline cluster.

So Let's Get Started!

Build a few clusters with our getting started guide.