We’re going to be talking about containers today, which means I am obligated to bring up the traditional ‘pets vs. cattle’ argument again to prove a point. However, I’m going to do it in a novel way that you might not have seen before. For those that don’t know what I’m talking about, containers have introduced the idea of a destructible construct that you can allow to exist, serve a purpose, and then retire without incident. This is in opposition to the traditional virtual machine (VM), which needs care and feeding, and you tend to keep around for a long time, much like a family pet.
So, how is this pet/cattle argument different? Let’s look at one specific aspect of things: Outcomes. What do you want to get out of your investment? When it comes to a pet, there are dozens of things you can do. It can be an emotional support animal that comforts you. It could be a hunting dog or a barn cat that serves a purpose, i.e., getting rid of vermin or helping you hunt vermin down. It could be a bomb-sniffing dog that serves a professional purpose. You could own pets to breed for income. Your pet could even be a part of your family that does nothing but bark at the mailman or cough up hairballs on your carpet. Pets are what you make of them. But that involves time and effort and training to get there. You could spend months, if not years, and significant money training a dog to sit and rollover. If it’s a cat? Don’t even try the training route.
How about cattle? They also have roles they can fill. However, the process is far different. Having grown up in a dairy family, I know a thing or two about cows. They serve roles, but they are clearly defined in this specific case. Female cows give milk. That’s their role. They give birth to calves to start milk production and continue to either produce new cows or milk until they reach the end of their useful lives. Then they can either be sold to be turned into something else or allowed to ‘retire’.
Male cows, or bulls, are designed to either produce new cows or produce meat. When they stop doing the first, they do the second. The outcomes are determined, and the roles ready to be filled.
How do these two things differ? In the pet example, you have a thing, and you want it to do something. You are focused on making the thing you have useful. That’s a classic case for a VM. You’ve spent all this time installing the OS and the patches and the application. It had better start doing something soon.
When it comes to cattle, you have a role you need to be filled: milk producer, livestock producer, or meat producer. You don’t care what fills that role, as long as the role is filled. You are more focused on the outcome as opposed to the animal creating it. If you lose a cow due to disease or inability to serve the role, you move on to the next one until you get the goal accomplished.
Policy Execution
The idea of policy intent vs. machine herding is one that we face in IT all the time. But during RSA this year, I had a chance to sit down with a new company, Styra, this is helping ease the burden of policy creation and distribution in Kubernetes. Containers have a lot of power and a lot of flexibility. That’s also a key warning sign that they can quickly get out of hand without strict management and policy definition.
Whoever coined the term ‘VM sprawl’ must have been flabbergasted when containers hit the mainstream. The ability to spin up dozens or hundreds of short-lived systems to serve a purpose means you can have many resources dedicated in a short amount of time and no idea how they got there. You can lose track of the forest for the trees. Containers need management, which is one of the big reasons why Kubernetes has taken off. But you still need something to drive the management system to ensure your goals are being met.
Taking it back to our example above, let’s say the goal for your herd is Milk Producers. That’s easy enough. But cattle still need to be fed. They need to be gathered into the barn at the right time. They need to be enumerated, so you know when you’ve milked them all. They need to be tracked to ensure they have been immunized against disease and so you don’t lose any of them. It’s a long, arduous process that takes up a lot of time for the dairy farmer, especially when the herds grow larger.
Styra works a lot like a set of farmhands or helpers. The farmer declares the policy, and the hands implement it. Likewise, you defined the policy you want to occur, and Styra executes it. You declare the needs for your platforms, and Styra ensures those needs are created and accomplished. Styra also integrates into the process earlier in the development lifecycle to ensure that the correct policy is being implemented from the start instead of at the end, where it’s harder to correct.
Security Through Policy Enforcement
My focus is on security, so a lot of my discussion with them focused on security. One of the big things that captured my attention was their Open Policy Agent (OPA). This tool was developed as an open source method of providing admission control for microservices and containers. Rather than letting developers create more and more containers to accomplish a goal, or worse yet, have dozens created under their IDs in an attack, Styra OPA allows you to set rules and conditions for admission control.
Let’s say you want your junior developers only to have the ability to create containers with senior sign off for a set period. Styra can help enforce that. Or maybe you want them to have a limit of how many resources they can spin up at once. Again, Styra and OPA can help you there, and because everything runs on the declarative model, your word is the law from the start. There’s no need to go back and change the rules because the outcome is different than what was intended. Since the policy is the only outcome that can occur, your developers are constrained to your intent from the start.
This is the essence of shifting security ‘to the left’ in the development lifecycle. The concerns and needs of security are implemented much earlier because the tools check for compliance and validation long before any code is ever committed to production. In my opinion, this is the essence of making security an integrated part of the process instead of something bolted on at the end that ticks boxes on an audit report. It’s as integrated as the networking stack or the user interface. Since there’s no way around the policy implementation, it’s there no matter what.
Bringing It All Together
Cattle are essential for the purpose they serve, not because they are treasured animals that exist to serve that purpose. It feels cold to say it in those terms, but most dairy farmers I’ve ever met can tell you how many cows they have but don’t have names for all of them. Instead, they look at the goal of milk production. As long as their intent is accomplished, the resources are inconsequential. As IT moves to a more cattle-based approach to systems, the idea of making policy happen through declaration is important. You need tools to help you get that accomplished. And if security is top-of-mind for you, then you should check out what Styra is doing to get that integrated earlier in the process. After all, it’s a lot easier to get milk from a cow than blood out of a turnip.
For more information about Styra and their Kubernetes platform, make sure you check out http://Styra.com.
