Introducing Pentagon

Background

In 2015, when I founded Fairwinds (f.k.a ReactiveOps), we started with a simple idea: to bring great infrastructure to companies that couldn’t - or didn’t want to - do this themselves. We wanted to hire great SREs and fill in gaps for big teams solving complex problems. During that time we worked with clients such as Pipeline Deals and Betterment. There was a market for what we were offering and things got off the ground quickly.

When we hired Justin Mound, he came in with the idea that folks’ needs in the world of cloud infrastructure tend to be mostly the same. Everyone wants zero downtime and fully automated deployments, logging, metrics, alerting, etc… the list is long, but it feels like everyone’s list is basically the same. So we set out to see if we could solve these issues in a repeatable way and grow a business that could scale by templating complex infrastructure for that large group of companies who are too big for Heroku but too small to be Netflix.

Initially we solved this on AWS using Terraform to build a VPC, Packer to build AMIs and then we wrote an incredible amount of Ansible to ship everything through different environments and on to production. What we built was really quite impressive. But as we were building this Docker was rising in popularity and with it, container orchestration systems.

When Kubernetes hit version 1.2 a little over a year ago, we threw away (almost) everything we’d written and went all-in on Kubernetes. Kubernetes solves a lot of the same problems we were solving before, but it does it better; and with the community support and demand in the market, we knew it was the right direction to go. But Kubernetes only solves one part of what everyone wants in that long list mentioned above.

Introducing Pentagon

Last week we open sourced Pentagon, our framework for building Kubernetes-based infrastructure. Now before you dive in, we want to mention a few considerations about what we’re doing with Pentagon.

1. Pentagon is not infrastructure by itself, but it is designed to build Kubernetes-based infrastructure. It is not a PaaS, it simply builds vanilla Kubernetes-based infrastructure in an opinionated way in your own AWS account.
2. Pentagon relies heavily on Kops for building clusters on AWS (we have a GCP alternative to Pentagon, but it’s not yet ready to see the light).
3. Pentagon is designed for companies who have more complex needs than a PaaS such as Heroku (or any of the other “one size fits all” black-box platforms) can provide. If Heroku costs you $50/month, don’t leave. If Heroku costs you $10,000/month, and you’re ready to build your own infrastructure, Pentagon may be a good fit for you. We have clients running big data setups, using things such as Consul or Prometheus, and with unusual security needs: Pentagon is built to allow for complex customization.
4. Pentagon is designed for Fairwinds to allow us to build many complex infrastructures quickly, and maintain them securely and affordably, and be consistent from one to the other. It was not built with your specific company’s needs in mind. But it can be tailored to fit your company’s needs.

There is much more to be said, but this should suffice for now. I do want to add that our engineers get a good bit of training on how to use the framework when they come aboard at Fairwinds and I’m sure our documentation will not yet sufficiently make everything obvious. So dive in carefully, if you choose to do so, and be prepared for lots of fiddling. We’ll, of course, be improving it as we go so check back. Pull requests, of course, are welcome; all the code is licensed Apache2.

You can do exactly this with Pentagon.