How to Quickly Improve Your Infrastructure as Code
Tags: devops, iac, cicd, terraform
Published: 2021-11-17 22:40:00

The introduction of [Infrastructure as Code](https://spacelift.io/blog/infrastructure-as-code) or IaC has transformed the way you can provision and deploy high-performance cloud-based IT infrastructures.

IaC tools, such as [Terraform](https://spacelift.io/blog/what-is-terraform), have been integrated into DevOps toolchains, saving DevOps IaC teams from the excessive manual effort.

While these tools undoubtedly help accelerate building IT infrastructures, their limitations can impact DevOps’ ability to optimize and improve control of their IaC processes supporting future business needs.

In this article, you’ll learn about IT infrastructure limitations that IaC DevOps teams deal with on a daily basis and how [Spacelift](https://spacelift.io/) is able to get past them.

#1) Workflow

One of the most frequent challenges while using more generic IaC tools is the **non-intuitive workflow** driven by its reliance on pull requests. Some solutions offer multiple workspaces, but the result can be fragile and nondeterministic. 

Since there’s no concept of mapping projects to branches or tags, anyone commenting on an approved pull request can deploy arbitrary code to production, even if the approval was meant for a short-lived experimental environment.

**Spacelift does not depend on pull requests.** It is mostly driven by push and tag events, so building a sophisticated Git flow is much easier. Spacelift reports the outcome of its jobs as commit status checks, allowing you to block merging the code on a failing Spacelift check.

Triggering a run can be customized using [Git push policies](https://docs.spacelift.io/concepts/policy/git-push-policy). Thanks to that, Spacelift can provide the same level of comfort and security to teams using one project per repository and those using mono repo with hundreds of interdependent projects. You can read more about our approach to VCS integration [here](https://docs.spacelift.io/integrations/source-control/github#tracked-branches).

#2) Access Control

The majority of generic tools don’t offer access control models but rely on comments on pull requests to drive infrastructure deployments. While it is usually fine when a single repository drives a single Terraform project, it becomes a huge liability for more complex scenarios.

Spacelift ships with a sophisticated mechanism **allowing administrators to declare** [who can log in](https://docs.spacelift.io/concepts/policy/login-policy) (and under what circumstances) and what their [level of access](https://docs.spacelift.io/concepts/policy/stack-access-policy) to each of the managed projects should be. Even our [Slack integration](https://docs.spacelift.io/integrations/slack) can be subject to policy controls, allowing an admin to grant access to a project [based on Slack-specific data](https://docs.spacelift.io/integrations/slack#managing-access-to-stacks-with-policies) (think team, channel, user, etc.).

#3) Policy Framework

One thing that’s not in scope for most IaC solutions is the way to ensure that your infrastructure is compliant with industry best practices and your company policies.

Spacelift puts **policy-as-code** in the center of its value proposition and builds a consistent, [robust policy framework](https://docs.spacelift.io/concepts/policy) on top of [Open Policy Agent](https://www.openpolicyagent.org/). Apart from providing a comprehensive automated change review and ensuring compliance of your [Terraform changes](https://docs.spacelift.io/concepts/policy/terraform-plan-policy), Spacelift uses the same approach to allow you to declare rules around the [account](https://docs.spacelift.io/concepts/policy/login-policy) and [project access](https://docs.spacelift.io/concepts/policy/stack-access-policy), [handling push notifications](https://docs.spacelift.io/concepts/policy/git-push-policy), [starting runs](https://docs.spacelift.io/concepts/policy/run-initialization-policy) and [triggering tasks](https://docs.spacelift.io/concepts/policy/task-run-policy), and creating [relationships between projects](https://docs.spacelift.io/concepts/policy/trigger-policy).

#4) Complex Workflows

Handling interdependencies between projects has always been Terraform’s Achilles’ heel. The usual approach to this problem is adding another layer of abstraction in the form of a Terraform wrapper like [Terragrunt](https://terragrunt.gruntwork.io/). But it’s only a partial solution as it breaks the problem into smaller chunks.

[Spacelift’s trigger policies](https://docs.spacelift.io/concepts/policy/trigger-policy) on the other hand provide a smart, **declarative automation layer** on top of vanilla Terraform. They allow you to plug into state changes of individual projects and declare dependencies that should be resolved, following the changes that have just been applied. Read more [here](https://docs.spacelift.io/concepts/policy/trigger-policy) to discover other exciting possibilities.

#5) Private Module Registry

Another problem to solve externally when using some of the generic tools is authoring and maintaining reusable [Terraform modules](https://spacelift.io/blog/what-are-terraform-modules-and-how-do-they-work) for your organization. Terraform is flexible in allowing modules to come from [various sources](https://www.terraform.io/docs/language/modules/sources.html), but ensuring confidential access, as well as testing and versioning, are left to you, the user.

Until now, the golden standard in that regard has been the [private module registry from HashiCorp](https://www.terraform.io/docs/cloud/registry/index.html). But Spacelift offers much more. Far from being just a glorified package manager, Spacelift adds a [full CI solution for Terraform modules](https://docs.spacelift.io/vendors/terraform/module-registry), out of the box and free of charge. You can thus ensure that your private modules are healthy before you distribute them to the rest of your organization.

#6) Effortless Setup and Customization

If you manage a single or a handful of rarely changing projects, it’s likely that you just set your IaC up once and forget about it. But in a more dynamic environment, where microservices come and go, new environments proliferate and new product teams require their own Terraform workspaces. The need to configure it each and every time become a major nuisance, putting a lot of pressure on your DevOps team.

Enter Spacelift. In Spacelift, much of the **configuration can be handled by the project owners** themselves—you can add Terraform and/or [environment variables](https://docs.spacelift.io/concepts/configuration/environment) and mount files (even inject Terraform code!) programmatically or through the GUI without the need for administrative privileges or changing the central server configuration. For administrators, adding new projects requires minimal hassle since there’s no need to set up webhooks or change any YAML. And it can all be done programmatically using Terraform.

#7) Programmatic Configuration

What comes as a pleasant surprise to users of generic CI tools, Spacelift entities such as stacks, contexts, modules or policies can be managed in a declarative way using your favorite infra-as-code tool (this rule applies also to their configuration). Yes, that’s right—[Spacelift offers a Terraform provider](https://docs.spacelift.io/vendors/terraform/terraform-provider) that allows you to **programmatically manage the lifecycle of its own resources**.

Administrative stacks get credential-less access to the subset of our [GraphQL API](https://docs.spacelift.io/integrations/api) that does not involve managing the actual infrastructure. For more sophisticated use cases, Spacelift allows you to generate API keys that are subject to the same access controls as normal users are, allowing you to create single-purpose tokens for restricted use by your internal scripts.

#8) Drift Detection

Generic IaC platforms do not provide any mechanisms to detect if your infrastructure is undergoing drift. Drift is a condition that represents the difference between the desired and the actual state of the infrastructure managed by your tool of choice – [Terraform](https://www.terraform.io/), [Pulumi](https://www.pulumi.com/), [CloudFormation](https://aws.amazon.com/cloudformation/) or another. Drift can be caused by either or a combination of changes directly introduced by external actors – either humans or machines (scripts) or via the dependency of your resources on external data sources. In any case, drift is not good.

Spacelift has got you covered here. You can configure periodic [drift detection](https://docs.spacelift.io/concepts/stack/drift-detection) to **notify you whenever drift happens**, and take immediate action. You can even go a step further with optional automatic [reconciliation](https://docs.spacelift.io/concepts/stack/drift-detection#to-reconcile-or-not-to-reconcile), ensuring your infrastructure always resembles your Terraform configuration.

#9) Resource Visualization

General-purpose CI/CD platforms provide little to no insight into resource utilization from either a real-time or historical perspective. Which resources are over-or underutilized? 

Developers need to be able to intimately understand the material they’re working with. With regards to infra-as-code, the most important part of this story is understanding the managed resources in-depth. Both from the current perspective and through being able to put each resource in its historical context.

The resources view in Spacelift gives you **greater visibility into each and every resource**. With this deep insight into resources, DevOps are able to gain an understanding of the lifecycle of each resource managed by Spacelift and document it, regardless of the technology used — [Terraform](https://www.terraform.io/), [Terragrunt](https://github.com/gruntwork-io/terragrunt), [Pulumi](pulumi.com), or [CloudFormation](https://aws.amazon.com/cloudformation/).

#Creature Comforts

Last but not least, Spacelift puts an emphasis on great user experience, offering a myriad of creature comforts. [Contexts](https://docs.spacelift.io/concepts/configuration/context) for example allow you to attach entire collections of configuration to individual stacks and modules. [Tasks](https://docs.spacelift.io/concepts/run/task) provide a powerful audited way of running one-off administrative commands on an initialized Terraform environment – subject to [their own policy constraints](https://docs.spacelift.io/concepts/run/task). [Stack locking](https://docs.spacelift.io/concepts/stack#stack-locking) allows a single individual to take exclusive control over a stack to ensure that nobody is able to modify its state while crucial changes are being made. 

#Why Spacelift

Spacelift is an innovative and sophisticated SaaS product for Infrastructure as Code which helps IaC DevOps develop and deploy new infrastructures or changes quickly and with confidence.

Spacelift offers a unique set of IaC management capabilities:

1. a more intuitive, [versatile](https://docs.spacelift.io/concepts/policy/git-push-policy) and [robust](https://docs.spacelift.io/concepts/run#run-state-machine) workflow
2. extremely granular access controls on [account](https://docs.spacelift.io/concepts/policy/login-policy) and [project level](https://docs.spacelift.io/concepts/policy/stack-access-policy) that work well with [an identity provider of your choice](https://docs.spacelift.io/integrations/single-sign-on) (SSO);
3. an [automated code review](https://docs.spacelift.io/concepts/policy/terraform-plan-policy) and [threat detection](https://docs.spacelift.io/concepts/policy/task-run-policy)
4. the ability to [declare complex workflows](https://docs.spacelift.io/concepts/policy/trigger-policy) between projects across multiple repositories
5. a [built-in private module registry](https://docs.spacelift.io/concepts/modules) with a full CI system for modules
6. effortless setup and customization with [per-project environment management](https://docs.spacelift.io/concepts/configuration/environment) and [Docker integration](https://docs.spacelift.io/integrations/docker)
7. [programmatic configuration](https://docs.spacelift.io/integrations/terraform-provider) using Terraform;
8. [drift detection](https://docs.spacelift.io/concepts/stack/drift-detection)
9. [resource visualization](https://docs.spacelift.io/concepts/resources)

… and a myriad of creature comforts like [contexts](https://docs.spacelift.io/concepts/configuration/context), [tasks](https://docs.spacelift.io/concepts/run/task) or [stack locking](https://docs.spacelift.io/concepts/stack#stack-locking).

# Key Points

There are many ways of working with Terraform. Each way is different in terms of complexity and offers a different set of features. It is important to keep in mind that choosing one way or another should be based on business and technical requirements. Most often, there is no point in implementing an in-house solution as the cost and effort of building and maintaining it may exceed its potential benefits. It is much easier and more efficient to leverage platforms such as [Spacelift](https://spacelift.io/product) to provide these features for you instead. You can [try Spacelift for free](https://spacelift.io/free-trial) or [book a demo](https://spacelift.io/schedule-demo) with one of our engineers.