Improving Infrastructure-as-Code in today’s hybrid and edge cloud environments

Today, IaC is regularly used by DevOps teams. However, I would argue that with the increasing complexities of data center configuration and management, IaC is rapidly becoming a last-decade technique and new emerging technologies can help solve and streamline many of the issues IaC presents.

For the purposes of our discussion, I am defining IaC as a well-known methodology for cloud infrastructure provisioning that uses application development principles (i.e. writing code). Typically, scripts are guided by templates, other scripts, and policies. When programming for infrastructure, a developer would use IaC to create their product.

IaC Benefits

Before IaC, operators created templates of well-known configurations that are repeated for application set-up. While that worked well when the application topology had minimal variance or volatility, the reality is that isn’t the way the world works.

IaC offered companies a new, compelling way to build their infrastructure. When it comes to IaC DevOps workflow, most teams build out their infrastructure in the following order:

1. Build base infrastructure
2. Build out the platform/application services
3. Application provisioning or CI/CD
4. Application monitoring

IaC is particularly good for steps 1 and 2 — base infrastructure and base services. The best thing about IaC is that it allows teams to treat infrastructure like product code. Changes are easy to track, repeatable, iterative, and recoverable.

IaC also standardizes the setup of infrastructure — reducing the potential for errors — while increasing the likelihood of applications running seamlessly.

IaC Pitfalls

In order to balance the need for speed, scale, and functionality with security and compliance, many companies deploying cloud-native applications have turned to DevOps and compliance engineers to create Infrastructure-as-Code. But this comes with its own set of challenges, including finding employees with programming, operations, and information security/compliance experience (these employees are unicorns), and slower implementation due to the manual nature of stitching together the many tools needed to create a secure cloud infrastructure, with constantly changing compliance guidelines.

This manual process of writing code to build infrastructure, using multiple tools, and making additional changes before redeploying the code, is time-consuming and expensive, making it difficult for startups and small businesses to go to market quickly while staying on budget.

An unexpected pitfall is that maintaining IaC is often harder than writing the original code. Cloud resources are exposed as-is to the DevOps engineers and DevOps must explicitly specify every resource in fine-grained detail. Infrastructure is a continuous operation and small changes can ripple through thousands of lines of code, making it difficult to scale. Additionally, IaC is missing application-centric abstractions (think C++ vs. assembly language).

Lastly, multi-user self-service is practically impossible. Terraform requires client-side scripting language with no server-side component, meaning that only one person can change code at a time within a project’s scope. For example, let’s say an operator is trying to update a firewall rule while another needs to update a database parameter — both for project X. Each user would be required to wait on the other, resolve any updates and understand the scope of unrelated changes. This often results in a lot of wasted time.

How can we make IaC better?

One of the biggest things we can do to make IaC better is to make sure that IaC operates at a higher level of abstraction. This includes application-centric automation, adding a rules-based engine, and providing developers self-service capabilities with guardrails.

If we dig deeper, it is not possible to get to an app-centric interface or a rules-based engine unless there is a very active stateful component that is running behind the scenes in a centralized way. This means that today, IaC is purely a compiler and a coding language that runs on people’s laptops. If there are five people there is no way those five people can simultaneously coordinate because there is no central system.

In addition to the above, the stateful component needs to add intelligence, allowing developers to run their IaC through it to check for errors. In other words, we need a rules-based engine that can take app-centric information and automatically run the rules to make sure that the software is compliant with the relevant security standards (SOC 2, PCI, HIPAA, etc.)

The best way to build and manage a secure infrastructure with agility is to add a layer of orchestration on top and use that to provision and change infrastructure resources. This layer needs to understand the high-level intent and required policies.

Lastly, we need to give developers a self-service option while providing guardrails. Developers want to focus on applications — not infrastructure. With code automation, developers can ask for secured resources (think VMs, load balancers, etc.) without having to know tons of lower-level details in order to meet operations or accidentally violating the needed compliance and security requirements.

About the author

Venkat Thiruvengadam is founder and CEO of DuploCloud, a provider of a no-code/low-code platform that automates the provisioning and compliance process for cloud-native applications.

DISCLAIMER: Guest posts are submitted content. The views expressed in this post are that of the author, and don’t necessarily reflect the views of Edge Industry Review (EdgeIR.com).

Article Topics

application development  |  DevOps  |  DuploCloud  |  IaC  |  Terraform