CloudDevelopersDevOpsFeaturedLet's Talk

Six Core Components Of Infrastructure as Code | Rob Hirschfeld, RackN

0

CEO and Co-Founder of RackN shares some important tips on how to approach IaC properly.

Out of the gate, Rob Hirschfeld makes it clear that Infrastructure as Code (IaC) is much more than just putting everything into source code. The CEO and Co-Founder of RackN believes there are specific components to IaC that must be examined.

But what is Infrastructure as Code? Hirschfeld defines this as a CIO pounding on the table and saying, “I wish my DevOps team was more like the developers!” The first thing you can point to for that is using source code control and then jumping to control of artifacts, a degree of sign-off, as well as stability. Hirschfeld continues to say, “So when we talk about just stuffing things in infrastructure code, in the source code repository and then pulling them out and running them, and you don’t have a second person checking it, or some form of validation, or some way to branch and fork and do patches…this isn’t just, oh, I have a safe place to store my automation.”

Instead, Hirschfeld says you want to be using source code control processes as part of building your automation, which is the most foundational thing you can do for any such process to ensure repeatability.

The next component is immutability, which, according to Hirschfeld, is “something that you can’t change. So when you’ve committed something into source code, that’s a degree of immutability, it’s locked in source code. You can add to it, but you can’t change it.”

The next component is state management. Hirschfeld says this is one area that trips people up, in part “because we have so many tools that manage their own state.” The issue with state management is that it “means being able to reach past the silos in each one of these tools, tools which have to have their own state.” Hirschfeld cites an example of Ansible: “If you’re using Ansible, you have a big inventory file, something changes outside of that inventory file, and all of a sudden, Ansible is confused.”

Hirschfeld calls the next state “target driven”–By this, he means “What we’re saying here is that when you’re building IaC, you want to be very driven by the final state of what you’re building. So you don’t want to have to drive functionally everything through your system. You don’t want to say, ‘Oh, I need to build a Kubernetes cluster so I need to get servers and then share credentials, and then share keys and then install Kubernetes and then join the cluster.'”

Finally, Hirschfeld focuses on collaboration and reuse. To that end, he states, “One of the things about IaC to me is it’s really about collaboration. And this is where collaboration and reuse go beyond just using Git.” Although Git will help you coordinate with your team and offer a degree of control over when things change, it doesn’t help you reuse automation. To that end, Hirschfeld says, “When you look at IaC, you should be thinking, How do I create and reuse automation within my system?

Summary for this interview/discussion was written by Jack Wallen

Don't miss out great stories, subscribe to our newsletter.

Login/Sign up