What are the benefits & challenges of Infrastructure as Code?
8th December 2021
As mentioned in a previous blog “What is Infrastructure as Code” we learned that IaC is a method of technology creation, definition, and management where manual steps are eliminated from the creation of an IT Infrastructure hosting application workloads.
In this instalment, we explore the benefits and the challenges of adopting Infrastructure as Code.
What are the benefits of Infrastructure as Code?
- Accelerated Deployments
The goal of IaC is to make deployments faster by eliminating manual processes thereby reducing the effect of key resource bottlenecks within the deployment process and the people involved in that process.
Adopting a code-based approach to deployments makes it easier to get more done in less time. No need to wait on someone with IT admin skills and credentials to manually complete the task at hand before they can get to the next item in the queue.
This also means that as a business you can iterate quickly and more often which is the basis of Constant Integration and Constant Deployment (CI/CD) agile methodologies.
- Greater Consistency and Reduced Errors
In my opinion, this is one of the biggest benefits of IaC. You do not need to worry about tasks not being completed or being done incorrectly because your Infrastructure Admin is focused on something else.
Also, you can update infrastructure and implement changes globally while keeping the same version of the software (or improving your code) as new security advice, services, or functionality is released within your chosen cloud fabric provider’s capabilities.
- Improved Efficiency
IaC moves the responsibility for full-stack deployment directly into the developers’ and automation engineers’ hands. Infrastructure provisioning becomes more reliable, consistent, and ultimately more secure through continual improvement of the code.
This continual improvement and deployment of an identical environment in each deployment cycle means developers can start focusing more on application development and functionality without having to worry if the last code drop was installed correctly by the operations team.
With IaC deployment methodologies, operators can script once, test, and use that code multiple times, thereby saving time and reducing effort whilst maintaining complete control over their full-stack deployment.
- Reduced Management Overhead
In a traditional data centre world, there was a need to have admins to govern and manage storage, networking, compute alongside the other layers of hardware and middleware configuration.
IaC eliminates a need for these multiple roles at each deployment iteration. Admins can now focus on identifying the next exciting technology they want to implement and how they can add value and business benefits to the organisation.
What are the challenges with Infrastructure as Code?
Whilst Infrastructure as Code deployments add a lot of value to the IT environment, there are, as with most things, some challenges that you should be aware of. Some challenges will no doubt be specific to your own organisation, but here are some of the general issues we see on a regular basis with clients implementing IaC.
- Do you have experts at coding who know how to Script?
As mentioned earlier, the power shifts from the infrastructure to the developer in an IaC deployment methodology. Therefore since IaC is more code-dependent than a manual deployment you need to be an expert at coding. The learning curve for this change can be steep especially if you don’t develop anything within your environment today and just consume Commercial Off The Shelf (COTS) software packages.
Select tooling carefully. If you intend to use just one public or private cloud infrastructure, invest in learning the language that your chosen technology provider uses natively from the list provided in my previous blog such as Powershell for Microsoft, JSON or YAML for AWS.
If your business has multi-cloud or hybrid cloud aspirations, then look at multi-cloud ready toolsets where the coding language remains constant and the vendor does the conversion into the cloud-specific language required.
A good example of a code-once-and-use-in-any-cloud toolset is Terraform, which uses the HashiCorp Configuration Languages (HCL) to build the configuration required and then individual “Providers” convert the HCL into the language specific to the Cloud Fabric at the time of deployment.
But be aware, these infrastructure coding skills are in short supply in the IT marketplace and when you do find someone who has them, that person will probably be expensive which can hamper your IaC usage potential.
Finally, what if your overall strategy is to move away from VM’s or containers and make things serverless in the future? Think of the strategic direction in which you are heading before you jump in… as maybe IaC is a pit stop that you can avoid taking if your end goal won’t require it.
- Can your management, security tooling, and governance processes support IaC?
IaC will be more dynamic than your existing provisioning and management processes. As a result, your legacy management and security tools might not capable of being configured programmatically which makes it difficult for them to support the new world of IaC.
Until this is resolved you might have to manually check if the provisioned resources are operational, secure, and being used by the right applications. Although manual checking is a confidence-building step, it might take a lot of iterations or even new tooling to get your management processes and tool stack tuned to fully support IaC.
When you embark on the introduction of IaC, we recommend reviewing your existing processes and governance procedures. IaC is a major culture change that can be used optimally to bring benefits or it can be abused even faster. Therefore, you might need to take extra steps to ensure you’re establishing policies, procedures, and guardrails for complete governance in this new world.
- How do you track what is happening, when and by who in your organisation?
In continuation of the previous point around governance and process, you might need additional tools to track who is provisioning what, where, how often, and what the cost of that is.
You might also find it challenging to track the usage/capacity by your old methods and tools especially if those are static and you still assign elements like IP addresses from worksheets or rely on other manual steps within your deployments.
Infrastructure as Code delivers the highest levels of benefits only when the entire deployment process is automated from end to end.
If you are a highly distributed or global company you might need to think of better ways of doing this and invest in some new monitoring and management tooling.
Taking our own advice and running with it…
Here at CSI, as a managed service provider and partner within several cloud ecosystems the decision to move to an Infrastructure as Code deployment model was a no-brainer.
It’s hard to achieve consistency and continual improvement through conventional deployment methodologies especially within the highly regulated industries in which our clients operate.
CSI not only deploys all of our client environments via IaC now, but we also secure them using Governance and Policy as Code which we maintain and improve with each iteration or as new guidance becomes available from vendors and independent security bodies, like CIS.
In fact, we are so good at it now that we not only enforce CIS best practice policies into each of our new builds at the point of deployment, we also help CIS write their policies through the input of our technical architects into the process. (Check out page 12 of the CIS Microsoft Azure Foundations Benchmark v1.4.0 and you will see Mark Weaver (CSI Senior Technical Architect) gets a mention as a specialist contributor!)
You can download the latest CIS info from https://www.cisecurity.org/benchmark/azure/
For help with your journey to the public cloud, get in touch to find out how CSI can support you with Infrastructure as Code services and building a secure foundation in the cloud.