<Insert Keyword Here>-as-Code

It occurred to me this weekend that <X>-as-Code has gotten a little overloaded, and it might be a good time to explore it in more depth. Investigating further revealed that others have thought the same thing. The articles I read were all focused on a technical audience, which is fine for me, but probably not fine for many readers.

So I thought to myself: “Self, you should write up an overview of the different <X>-as-Code metaphors using an easy to understand literary device”. Interesting idea. We’ll explore this through a series of analogies.

First off, a definition:

Infrastructure — Noun — the underlying foundation or basic framework of something

The Pizza Delivery Store

The first car in our analogy train is the Pizza Shop. You want to feed your family. You call the pizza shop, or use a website, or a phone app. You describe the pizza that you want. The people inside the shop take those instructions, create the pizza and deliver it to your house. For your purposes, that pizza is the infrastructure of your family’s meal.

Most of you have seen the order slips that get attached to your pizza box. You’ll see that the piece of paper described the pizza you wanted. It didn’t describe how the pizza was made. It didn’t specify how many cups/grams of flour were needed. It didn’t specify that the cheese should be grated. It just says:

Large Pizza,

+Cheese,

+Pepperoni,

+Thin Crust

And it should follow that if you sent an email to the pizza shop, and the email contained only the words: “Large Pizza, +Cheese, +Pepperoni, +Thin Crust”, they would know exactly what to do. They wouldn’t need you to specify how many tablespoons/milliliters of water to put into the dough, or how many seconds to cook the pizza. They already know how to do all of that.

You send them a “structured document” describing what you want, and you can trust that they will produce the outcome you desire.

Note: a ‘structured document’ means a document that follows formal rules about the way the document is formatted and the specific words/letters/contents that the document can contain).

Note 2: this is a basic example of the concept of ‘Infrastructure-as-Code’. I’m hopeful that it works for most people. If you still feel like you’re missing something about the concept of IaC, please contact me (johnbr@paclabs.io) so I can work on making this example better.

In the most common “real world” application, Infrastructure-as-Code means that you submit structured documents (typically via APIs) to systems (such as AWS or Google Cloud, or Kubernetes). The system examines the document, and creates servers/load balancers/disks/routers/etc for your use.

Dietary Restrictions

The second car on this analogy train is dietary restrictions about your orders from the pizza shop. If your house observes religious restrictions, or is vegetarian or vegan, or gluten-free, you might choose to limit what type of pizza is brought into your home.

“But that’s easy, I’ll just order the right pizza”. True. But what if your kids figure out how to send the ‘structured document’ to the pizza shop? They might not follow the rules of your household.

So what if you could have some system in place that could look at the ‘structured document’ before it was processed at the pizza shop? What if you could create a set of ‘rules’ that prevented the delivery of inappropriate pizzas? This would be nice, wouldn’t it? Your kids would have the flexibility to order pizzas that they wanted, but the rules would prevent them from ordering pizzas that didn’t follow your household’s policies.

You guessed it. This is an example of Policy-as-Code. The rules/guidelines/restrictions that you place upon the people under your authority are your policies.

Policy — noun — (a) prudence or wisdom in the management of affairs.

(b) management or procedure based primarily on material interest

Policies are more general than just dietary restrictions. In your house, you might have rules about shouting, or running, what words should not be used (or what words must be used in certain situations). You might have rules about what types of devices, or what apps are allowed on the devices. The list of rules available to you is vast, and is best left to your imagination.

In the organizational world, there are also lots of policies. Many (most?) organizations don’t let you create arbitrary infrastructure (such as virtual machines that have an insecure operating system). But policies go well beyond just the creation of infrastructure. If your company provides APIs or microservices, there will (typically) be policies about how many times per hour a user can access the API. There will be policies about which people are allowed to access the microservice. There will be policies about the size of API requests. There will be policies about the contents of the requests. About the security of the request. And an almost unlimited mix of other restrictions.

For the longest time, these policies were typically ‘baked in’ to the systems — the software developers who were writing the APIs/Microservices were also including the organization’s rules directly in the code. So the concept of policy being captured as code is nothing new. What is new is the way that current systems, like the Open Policy Agent (OPA), allow many of these rules to be kept separate from the API code. Systems that allow you to separate the organization’s policies from the functionality are the systems that drive the concept of Policy-as-Code.

Governance

One day, the doorbell rings, and you discover that your kids have ordered 20 pizzas. Every pizza follows your dietary policies, but there are 20 of them, and you don’t have that many kids.

So you probably establish a rule — no more than $50 worth of pizza.

The next day, the doorbell rings, and now there are $50 worth of pizza and another $50 worth of, say, strombolis.

You establish another rule — no more than $50 worth of food in one order.

The next day, the doorbell rings, and there’s $50 worth of pizza. Okay, no problem. But then an hour later, another delivery of another $50 worth of pizza. And then another hour, more pizza.

Egad, yet another rule (disciplining your children is beyond the scope of this article). No more than $50 worth of pizza per day.

The next day, you get $50 worth of pizza, and $75 worth of soda and ice cream from the grocery store. Apparently your kids have figured out how to order stuff from multiple sources.

Alright, so now a new rule: a limit of $50 per day across any number of services.

A week later, you’re hosting a birthday party, and you need $200 worth of pizza and soda and ice-cream. You send in your orders, but they’re blocked…

Sigh. You add a rule — when an adult orders pizza or soda or ice-cream, there’s no limit on the amount.

What we’ve just gone through is a series of examples of the evolution from Policy-as-Code into Governance-as-Code.

Governance — noun — the act or process of overseeing the control and direction of something

“These seem to be just more sophisticated policies” I hear you say.

Yes, you are absolutely right. In general, governance rules are just more sophisticated policies. One way to think about the difference between Policy-as-Code and Governance-as-Code is that PaC is generally focused on one specific system at a time, while GaC is focused on the ‘big picture’ — rules that apply across multiple systems in parallel.

Another example of how they are different is in their “memory”. Policy-as-Code rules typically focus on one request at a time, they don’t care about what happened in another request a few minutes ago, or a few minutes hence. So in the household pizza example above, there can be a policy about ordering no more than $50 worth of stuff in one order, but a limit on the cumulative amount one can order across multiple orders in a day would typically be governance.

As of this writing, there are no good automated solutions for governance. OPA isn’t a great fit to track requests across multiple systems in parallel, and adding ‘memory’ to OPA is complicated and difficult to scale.

Conclusions

We’ve reached the end of the train (for now). I hope this was helpful. I would love to hear about your thoughts. Does this make sense? Did I miss the mark? Do you have additional questions for me? Please contact me at: johnbr@paclabs.io