The Twin Challenges of Scale and Agility
When you have only one server, keeping it up to date is straightforward. But even then, you need the ability to reliably repeat or roll back configurations as things change and new services or hardware comes online.
As you might imagine, this task becomes exponentially harder when you have dozens or hundreds of pieces of hardware, Software Defined Networking, and perhaps thousands of virtual machines. There’s no way that a single person, or even a team, can manage that kind of chaos manually, no matter how well processes are documented. This is especially true in today’s climate of speed, where companies must be agile enough to provide resources virtually immediately to support business goals and innovation.
Where DevOps Fits In
By defining your infrastructure using code such as scripts or templates, you get the advantage of a testable, reliable, repeatable process that can be used to manage any environment, from a single server to a worldwide collection of data centers.
Known as DevOps, this process can take a number of different forms. Some of the most common in OpenStack are Puppet manifests, Salt formulas, Ansible playbooks, or Chef recipes, but there’s no requirement for a specific environment. What’s important is that actions are taken through well documented scripts, rather than individual actions. This way you’re always performing the same task (such as setting up a new server) in the same way.
While DevOps at the application level has been common for some time, containerizing OpenStack and orchestrating it using Kubernetes makes it possible to do the same thing at the infrastructure level, managing not just OpenStack bits, but also related projects such as OpenContrail and Ceph.
Infrastructure as Code
Of course treating Infrastructure as Code is more than just scripting your actions. Typically, these scripts are “declarative”, meaning that rather than saying, “do this, then do that”, they simply say, “this is what I want to end up with” and then the scripting framework takes care of the rest.
The advantage of this means for handling infrastructure is that you can now treat those declarative scripts — a text-based model of your data center — as code. And that means you can validate it and do version control on it, so you can not only track who’s done what, you can roll back to an earlier configuration at a moment’s notice should a problem occur.
And it’s more than that. Because your data center is essentially a physical version of the model, you can keep it up to date using CI/CD just as you would do with any application; when changes come in, they can be tested, then propagated to your production environment.
Over the past 5 years helping hundreds of enterprises successfully deploy OpenStack clouds, we’ve found that the Infrastructure as Code model isn’t just the best way to operate an OpenStack environment at production scale, where agility and reliability are essential; it’s the only way.
To learn more about infrastructure as code, check out these blogs:
