Want repeatable scale? Adopt infrastructure as code on GCP

Imagine you provision a virtual machine for your dev environment, work through the kinks, and then decide you needed to create one just like it for your test environment. Are you confident that you can recreate the same configuration? What about all of the tweaks you made to get things running in dev—did you track them? Can you validate that the two environments are configured identically once provisioned? What happens when you need to scale that same configuration to thousands of machines to support production?

If you answered ‘no’ to any of these questions, then you should really be thinking about infrastructure as code (IaC), which lets you make changes to your environment in a way that can be tested, automatically applied and be audited, according to your change management processes. The good news is that if you run on Google Cloud Platform (GCP), it’s already tightly integrated with popular IaC tools. Better yet, adopting IaC principles sets the stage for being able to handle massive growth in demand for your applications.

Understanding infrastructure as code

At a high level, infrastructure as code is a process that allows you to treat your infrastructure provisioning and configuration in the same manner you handle application code. Your provisioning and configuration logic is stored in source control and can take advantage of continuous integration and continuous deployment (CI/CD) pipelines, so that it’s visible and discoverable across your organization.

You may be wondering whether you can use IaC processes with different kinds of infrastructures, such as:

• Virtual machines (or bare metal systems) set up with a configuration automation product like Puppet, Chef, Salt or Ansible? Check!
• Containers deployed in a Kubernetes cluster? Why not!
• A pleasant mix of the above? Done!

What changes are the actual artifacts that you version in your source control system. Those artifacts can be YAML descriptors, Dockerfiles, shell scripts and their dependencies, among others. It does not matter what tools your are using to provision and configure your infrastructure—the important thing is to capture the process in a way can be repeated and automated!

By implementing IaC process in your projects you increase the level of control you have on the design and implementation of the infrastructure that supports your applications. This is due to continuous versioning and review of the descriptors that define your infrastructure. Want the development team to review the changes? Check! The Ops technical manager demands periodical audits? Check!

Then, by extending your CI/CD pipeline beyond your application, you can have changes applied to your test and production infrastructures within minutes of committing the changes to the code repository. You can get even fancier, too, by applying a test-driven development model to your infrastructure. Why not—your infrastructure deserves tests too! Open source tools like InSpec let you develop a platform-agnostic compliance test suite that checks the correctness of all the moving parts of the infrastructure.

Infrastructure as code gotchas

Be on the lookout for pitfalls, though! Just like implementing DevOps for your application stack, infrastructure as code automation requires process and governance changes. For one, system administrators who may have traditionally made configuration changes manually need to adopt a developer mindset, complete with checking in their configuration changes to source control and implementing a managed test and promotion process. If so, manual changes (that should not be allowed by your change management process!) made outside of the IaC pipeline will be lost in subsequent releases. Implementing IaC could bring unnecessary overhead if the change management process you adopt is too heavy. Rule of thumb: if you feel that it’s taking too much time to apply a change, it probably is! Finally, you may also need to train your Ops colleagues who don’t have experience with IaC tools and concepts.

How GCP simplifies IaC

GCP supports IaC processes by letting you build environments with repeatable and automated processes. These environments include not only the runtime environments, but also networking and related services, Cloud Identity and Access Management (Cloud IAM), as well as DevOps-inspired build/deploy pipelines.

Because GCP is built on open standards and open-source projects, you can just re-use your existing expertise to build your next-gen infrastructure in the cloud. Tools like Terraform help your team fully exploit all the resources that GCP has to offer. Don’t worry about starting from scratch as we have ready-made templates that follow Google’s best practices! Read more about the available tools.

GCP’s approach to IaC doesn’t have a steep learning curve or complex interface to master: deploy your whole environment with one command and keep it updated automatically! It also gives you the flexibility of an incremental migration approach where you can lift-and-shift your workloads to GCP and gradually optimize them for the cloud by managing changes via IaC processes.

IaC also gives you the chance of achieving linear Ops-team growth in the event of exponential workload growth. With IaC, it doesn’t matter if you are managing an environment with ten containers or one million (apart from the obvious scalability issues to tackle). Want to know more? Read Chapter 18th of the Site Reliability Engineering book.

Putting IaC Best Practices to Work

In this blog post we presented a high level description of what IaC is and why you may want to use it to manage the infrastructure supporting your GCP projects—namely, to have more control of your resources, and to be sure your infrastructure will stand up to increased demand. Click here to learn more about Infrastructure as Code on GCP.