General | Spacelift Blog

Author title

Title category

Level up your IaC knowledge. Stay up to date with educational devops guides & news in infrastructure as code, cloud & more!

Managing Infrastructure at Scale | Spacelift Blog

Warsaw and Redwood City, June 15, 2021: Poland and US-based startup <a href="https://spacelift.io/" target="_blank" rel="noopener">Spacelift</a> has raised $15m in Series B funding led by Insight Partners to scale its management platform for Infrastructure as Code in the US market. Existing investors Blossom Capital, Inovo Venture Partners, and Hoxton Ventures also participated in the round. 
This new investment will allow Spacelift to quadruple its engineering team to accelerate product development and to build out its commercial team in the United States. The company is headquartered in Redwood City, California, USA, and has an office in Warsaw, Poland. 
Over the past few years, managing cloud infrastructure has become significantly more complex. The migration of infrastructures to the cloud has created an explosion in DevOps, but few overarching tools exist to help teams of developers safely manage infrastructure as code at scale. Spacelift has created a plug-and-play platform that allows IaC DevOps teams to: define standardized infrastructures; understand their resources; build policies directly into their workflows and code; synchronize code across multiple projects and/or repositories; automatically detect and remediate resource drift, track lifecycle and cost of every managed resource; and take advantage of advanced workflow delegations and autonomous project teams. 
“With the growth of cloud-native development and DevOps practices, infrastructure as code has become the standard way to provision infrastructure, and Spacelift is addressing an acute need around infrastructure as code management, automation, and security and compliance,” said Josh Zelman, Vice President at Insight Partners. “Spacelift enables developers and DevOps teams to more easily and effectively manage infrastructure across all platforms. In speaking with DevOps teams within the Insight portfolio, we continuously heard about this need and the strength of the Spacelift platform. Insight is thrilled to partner with Spacelift and support its ScaleUp efforts in its next phase of growth.”
Spacelift is the only IaC management solution that extends IaC DevOps to encompass the complete set of IaC frameworks including Terraform, Pulumi and CloudFormation, with Ansible coming soon. Offering a consolidated approach to IaC is beneficial to engineering teams in large corporations that have been acquiring smaller companies that bring different infrastructures and to smaller but diverse organizations aiming to empower application developers. 
Marcin Wyszynski, co-founder and CEO at Spacelift, said: “Since we&#8217;ve founded Spacelift, we&#8217;ve seen a Cambrian explosion of new tools designed for teams to make the most of their cloud &#8211; ranging from cost management to audit to proactive security. Hence our vision of providing the most flexible and extensible platform for infrastructure and policy as-code is now more relevant than ever before. By using Spacelift, our customers get the whole cloud management story in one convenient package.”
Pawel Hytry, co-founder and COO at Spacelift, said: “Over the past few years, IT organizations relied on generic CI/CD tools, open-source components and custom-made solutions to manage their infrastructure. With increasing infrastructure complexity and development of infrastructure as code, this approach proves unscalable and error-prone. Spacelift addresses the issues of scaling and infrastructure complexity by providing a robust, specialized management platform for infrastructure as code. We are eager to partner with Insight Partners and benefit from their experience in the developer tools space.” 
About Spacelift: 
Spacelift is building a platform to help DevOps teams manage their infrastructure-as-code performance for maximum optimization of scaling businesses. Founded in 2020, the management platform allows teams to manage complex cloud infrastructures simultaneously, providing visibility and collaboration.
About Insight Partners:
Insight Partners is a leading global venture capital and private equity firm investing in high-growth technology and software ScaleUp companies that are driving transformative change in their industries. Founded in 1995, Insight Partners has invested in more than 400 companies worldwide and has raised through a series of funds more than $30 billion in capital commitments. Insight’s mission is to find, fund, and work successfully with visionary executives, providing them with practical, hands-on software expertise to foster long-term success. Across its people and its portfolio, Insight encourages a culture around a belief that ScaleUp companies and growth create opportunity for all. For more information on Insight and all its investments, visit <a href="https://www.insightpartners.com/" target="_blank" rel="nofollow noopener">Insight Partners</a> or follow them on Twitter @insightpartners.

How a Specialized Management Platform Can Improve Your IaC

5 Ways to Manage Terraform at Scale

Why should business care about Infrastructure as Code

$15M in a new funding round led by Insight Partners will enable  Spacelift to quadruple engineering headcount in Europe and build a sales and marketing organization in the United States.

series_b_blog-og

Spacelift raises $15m in Series B funding from Insight Partners

Infrastructure as code (IaC) is being used in companies small and large, technical and non-technical. The days of configuring your infrastructure by hand are moving behind us. More and more infrastructure is being represented as code. Whether it is HCL with Terraform, TypeScript with AWS CDK, or Python with Pulumi. 
This transition to infrastructure as code is fast-paced and changing at a rapid clip. So it begs the question, why is infrastructure as code becoming so important? But also, why should a business or a product manager invest their developer’s time in establishing it?

Investing in solid infrastructure as code practices is no small investment. It has its own learning curve and the steepness of the curve varies across different IaC tools. So if a team is going to invest this time, what are the benefits?
The benefits of cloud computing are well known at this point. The ability to scale out and in your compute resources automatically. Cost savings from no longer needing to pay for the overprovisioned hardware running in your closet. Pushing massive security processes to the underlying cloud provider. All these things are benefits of cloud computing
But what are the tradeoffs? There are many. The one that is most relevant to infrastructure as code is complexity. Running production-level workloads in the cloud is complex. It’s not a problem if you are running a single web application on an EC2 instance behind a load balancer. But it’s quite a bit different when you are running a web application, a database, a Kubernetes cluster, and some serverless functions to support all the services of your application.
That problem is only exacerbated when you need to run many environments. Think about your development, staging, and production environments. You have to provision and maintain all that infrastructure. Doing that manually is a massive burden and time commitment.
This complexity is why infrastructure as code is critical. Depending on your chosen tool you can represent all that infrastructure as a single module in code. Then when you want another environment you add another instance of that module with your new environment name. All that work to create the module never has to be repeated again, like DRY for your infrastructure.
But infrastructure as code is important for another reason. Visibility.
With infrastructure as code, everyone has visibility into what the current configuration is. Why? Because it’s represented in code and committed to a source code repository. Anyone who has access to the code can see what the current configuration is. Changes to the infrastructure configuration go through a pull request review. With pull requests, everyone can see what is changing and why.
There is a large list of reasons why IaC is important. But the two most important that make huge differences from day one are better complexity management and increased visibility into infrastructure configuration.

All those reasons infrastructure as code is important ring true for engineering teams. But a Product Manager might not see those as benefits to what they are trying to deliver, solutions for their users. It’s a bit of the classic engineering and product tug of war that is natural. But with infrastructure as code, the benefits of investing that time and resources can seem opaque to someone who is always thinking about the end-users of the product, not the underlying infrastructure.
So we must take a look at what the benefits of infrastructure as code would be for someone in a product role. More generally, these are benefits the entire organization can realize.
<h3>1. Decreased risk</h3>
Provisioning all your infrastructure by hand is risky. It requires manual work that is error-prone. It may require a single person to do. That person could leave the company, taking all that knowledge with them. Infrastructure as code minimizes both of these risks. By representing infrastructure as reproducible blocks of code we are far less error-prone. Infrastructure as code lives in a source code repository. Its history and changes are visible to everyone on the team. 
<h3>2. Stable &amp; consistent environments for faster iterations</h3>
When environments have to be manually configured or modified it slows down product development. This is especially true if the product wants to change its architecture to better serve its users. With infrastructure as code environments are stable, consistent, and easily modifiable. They live in code alongside the product, so when we want to change one we can change the other at the same time. This harmony means that new features can be developed for the product faster. There is less overhead to managing a given environment.
<h3>3. Cost optimization</h3>
When all resources are represented in code you can see what is running and what shouldn&#8217;t be. Optimizing cost maintains product profit margins. Those optimizations become much easier with infrastructure as code.
<h3>4. Self-documenting</h3>
There is a philosophy in software development that says good code is easy to read. It often doesn’t need extensive comments because it’s clear what it’s doing. The idea is that a new developer should be able to come in, read the code, and understand the logic that is happening. With infrastructure as code, it is self-documenting like any other code. This can benefit the product by making it easier to add more people to the team. With self-documenting code, you can reduce the time it takes for a new developer to onboard into the team.

Infrastructure as code is a game-changer for companies large and small. The benefits of it are often expressed as engineering benefits. But the benefits of it are felt across the entire business from product to finance. 
It’s not a silver bullet. It requires investment. But when that investment is made the benefits are almost immediate. Faster product iterations, decreased risk, optimized costs, and simpler onboarding are all benefits that can be felt in the engineering team, but also within the product team. An investment into a healthier infrastructure process using infrastructure as code can pay dividends for the entire life of the product or company. 
&nbsp;

Alternative to Atlantis - Spacelift

Infrastructure as code is a game-changer for companies large and small. In this article, we describe the benefits of Infrastructure as code from the engineering perspective and across the entire business from product to finance. 

23-1

Why should business care about infrastructure as code

Why should business care about Infrastructure as Code?

The introduction of 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, 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 is able to get past them.

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 <a href="https://docs.spacelift.io/concepts/policy/git-push-policy" target="_blank" rel="noopener">Git push policies</a>. 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 <a href="https://docs.spacelift.io/integrations/github#tracked-branches" target="_blank" rel="noopener">here</a>.

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 <a href="https://docs.spacelift.io/concepts/policy/login-policy" target="_blank" rel="noopener">who can log in</a> (and under what circumstances) and what their <a href="https://docs.spacelift.io/concepts/policy/stack-access-policy" target="_blank" rel="noopener">level of access</a> to each of the managed projects should be. Even our <a href="https://docs.spacelift.io/integrations/slack" target="_blank" rel="noopener">Slack integration</a> can be subject to policy controls, allowing an admin to grant access to a project <a href="https://docs.spacelift.io/integrations/slack#managing-access-to-stacks-with-policies" target="_blank" rel="noopener">based on Slack-specific data</a> (think team, channel, user, etc.).

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, <a href="https://docs.spacelift.io/concepts/policy" target="_blank" rel="noopener">robust policy framework</a> on top of <a href="https://www.openpolicyagent.org/" target="_blank" rel="nofollow noopener">Open Policy Agent</a>. Apart from providing a comprehensive automated change review and ensuring compliance of your <a href="https://docs.spacelift.io/concepts/policy/terraform-plan-policy" target="_blank" rel="noopener">Terraform changes</a>, Spacelift uses the same approach to allow you to declare rules around the <a href="https://docs.spacelift.io/concepts/policy/login-policy" target="_blank" rel="noopener">account</a> and <a href="https://docs.spacelift.io/concepts/policy/stack-access-policy" target="_blank" rel="noopener">project access</a>, <a href="https://docs.spacelift.io/concepts/policy/git-push-policy" target="_blank" rel="noopener">handling push notifications</a>, <a href="https://docs.spacelift.io/concepts/policy/run-initialization-policy" target="_blank" rel="noopener">starting runs</a> and <a href="https://docs.spacelift.io/concepts/policy/task-run-policy" target="_blank" rel="noopener">triggering tasks</a>, and creating <a href="https://docs.spacelift.io/concepts/policy/trigger-policy" target="_blank" rel="noopener">relationships between projects</a>.

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 <a href="https://terragrunt.gruntwork.io/" target="_blank" rel="nofollow noopener">Terragrunt</a>. But it’s only a partial solution as it breaks the problem into smaller chunks.
<a href="https://docs.spacelift.io/concepts/policy/trigger-policy" target="_blank" rel="noopener">Spacelift’s trigger policies</a> 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 <a href="https://docs.spacelift.io/concepts/policy/trigger-policy" target="_blank" rel="noopener">here</a> to discover other exciting possibilities.

Another problem to solve externally when using some of the generic tools is authoring and maintaining reusable <a href="https://spacelift.io/blog/what-are-terraform-modules-and-how-do-they-work" target="_blank" rel="noopener">Terraform modules</a> for your organization. Terraform is flexible in allowing modules to come from <a href="https://www.terraform.io/docs/modules/sources.html" target="_blank" rel="nofollow noopener">various sources</a>, 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 <a href="https://www.terraform.io/docs/cloud/registry/index.html" target="_blank" rel="nofollow noopener">private module registry from HashiCorp</a>. But Spacelift offers much more. Far from being just a glorified package manager, Spacelift adds a <a href="https://docs.spacelift.io/concepts/modules" target="_blank" rel="noopener">full CI solution for Terraform modules</a>, 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.

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 <a href="https://docs.spacelift.io/concepts/environment" target="_blank" rel="noopener">environment variables</a> 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.

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—<a href="https://docs.spacelift.io/integrations/terraform-provider" target="_blank" rel="noopener">Spacelift offers a Terraform provider</a> that allows you to programmatically manage the lifecycle of its own resources.
Administrative stacks get credential-less access to the subset of our <a href="https://docs.spacelift.io/integrations/api" target="_blank" rel="noopener">GraphQL API</a> 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.

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 &#8211; <a href="https://www.terraform.io/" target="_blank" rel="nofollow noopener">Terraform</a>, <a href="https://www.pulumi.com/" target="_blank" rel="nofollow noopener">Pulumi</a>, <a href="https://aws.amazon.com/cloudformation/" target="_blank" rel="nofollow noopener">CloudFormation</a> or another. Drift can be caused by either or a combination of changes directly introduced by external actors &#8211; 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 <a href="https://docs.spacelift.io/concepts/stack/drift-detection" target="_blank" rel="noopener">drift detection </a>to notify you whenever drift happens, and take immediate action. You can even go a step further with optional automatic <a href="https://docs.spacelift.io/concepts/stack/drift-detection#to-reconcile-or-not-to-reconcile" target="_blank" rel="noopener">reconciliation</a>, ensuring your infrastructure always resembles your Terraform configuration.

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 — <a href="https://www.terraform.io/" target="_blank" rel="nofollow noopener">Terraform</a>, <a href="https://github.com/gruntwork-io/terragrunt" target="_blank" rel="nofollow noopener">Terragrunt</a>, <a href="https://www.pulumi.com/" target="_blank" rel="nofollow noopener">Pulumi</a>, or <a href="https://aws.amazon.com/cloudformation/" target="_blank" rel="nofollow noopener">CloudFormation</a>.

Last but not least, Spacelift puts an emphasis on great user experience, offering a myriad of creature comforts. <a href="https://docs.spacelift.io/concepts/context" target="_blank" rel="noopener">Contexts</a> for example allow you to attach entire collections of configuration to individual stacks and modules. <a href="https://docs.spacelift.io/concepts/task" target="_blank" rel="noopener">Tasks</a> provide a powerful audited way of running one-off administrative commands on an initialized Terraform environment &#8211; subject to <a href="https://docs.spacelift.io/concepts/task" target="_blank" rel="noopener">their own policy constraints</a>. <a href="https://docs.spacelift.io/concepts/stack#stack-locking" target="_blank" rel="noopener">Stack locking</a> 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.

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:
<ol>
<li style="font-weight: 400;" aria-level="1">an intuitive, <a href="https://docs.spacelift.io/concepts/policy/git-push-policy" target="_blank" rel="noopener">versatile</a> and <a href="https://docs.spacelift.io/concepts/run#run-state-machine" target="_blank" rel="noopener">robust</a> workflow</li>
<li style="font-weight: 400;" aria-level="1">granular access controls on <a href="https://docs.spacelift.io/concepts/policy/login-policy" target="_blank" rel="noopener">account</a> and <a href="https://docs.spacelift.io/concepts/policy/stack-access-policy" target="_blank" rel="noopener">project</a> level that work well with an <a href="https://docs.spacelift.io/integrations/single-sign-on" target="_blank" rel="noopener">identity provider of your choice</a> (SSO)</li>
<li style="font-weight: 400;" aria-level="1">an <a href="https://docs.spacelift.io/concepts/policy/terraform-plan-policy" target="_blank" rel="noopener">automated code review</a> and <a href="https://docs.spacelift.io/concepts/policy/task-run-policy" target="_blank" rel="noopener">threat detection</a> </li>
<li style="font-weight: 400;" aria-level="1">the ability to <a href="https://docs.spacelift.io/concepts/policy/trigger-policy" target="_blank" rel="noopener">declare complex workflows</a> between projects across multiple repositories</li>
<li style="font-weight: 400;" aria-level="1">a <a href="https://docs.spacelift.io/concepts/modules" target="_blank" rel="noopener">built-in private module registry</a> with a full CI system for modules</li>
<li style="font-weight: 400;" aria-level="1">effortless setup and customization with <a href="https://docs.spacelift.io/concepts/environment" target="_blank" rel="noopener">per-project environment management</a> and <a href="https://docs.spacelift.io/integrations/docker" target="_blank" rel="noopener">Docker integration</a></li>
<li style="font-weight: 400;" aria-level="1"><a href="https://docs.spacelift.io/integrations/terraform-provider" target="_blank" rel="noopener">programmatic configuration</a> using Terraform</li>
<li style="font-weight: 400;" aria-level="1"><a href="https://docs.spacelift.io/concepts/stack/drift-detection" target="_blank" rel="noopener">drift detection </a></li>
<li style="font-weight: 400;" aria-level="1"><a href="https://docs.spacelift.io/concepts/resources" target="_blank" rel="noopener">resource visualization</a></li>
</ol>
… and a multitude of additional perks like <a href="https://docs.spacelift.io/concepts/context" target="_blank" rel="noopener">contexts</a>, <a href="https://docs.spacelift.io/concepts/task" target="_blank" rel="noopener">tasks</a> or <a href="https://docs.spacelift.io/concepts/stack#stack-locking" target="_blank" rel="noopener">stack locking</a>.

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 to provide these features for you instead.

Terraform Functions, Expressions, Loops

Terraform vs. Ansible: Key Differences

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 ready-to-go platform to provide these features instead.

How a Specialized Management Solution Can Improve Your IaC

Learning Terraform can be easy. The HCL configuration language is simple enough to start with basic resource creation straight away. 
But—
Once the code that defines your infrastructure grows in complexity, maintainability, and dependency, an uphill battle can ensue. And that is why working out an efficient deployment workflow is crucial for further development.
In this article you will see five approaches to managing Terraform at scale, what their benefits and downsides are, and what problems they address.

A quick and easy way to start deploying resources using the Infrastructure as Code pattern is to use Terraform locally from the same machine you’re developing the code on. The only requirement is to have access to the target provider and an installed Terraform binary.
This approach makes it much easier to leverage commands related to day-to-day operations (such as state import, move, remove) or to get outputs than if doing it within the implementations where you have no direct access to the underlying provider.
You can also use all of the features of Terraform, such as remote state and state locking, to work with your teammates all-at-once. If you collaborate using a version control system and do not have continuous integration in place, but want to keep your code at a decent level of quality, there are tools to help you.
One of these is <a href="https://github.com/antonbabenko/pre-commit-terraform" target="_blank" rel="nofollow noopener">pre-commit-terraform</a> that will run a set of selected tools to lint the code you’re creating before you even commit it. Even if you have continuous integration available, it’s a handy way to avoid wasting time waiting for results from pull request status checks.
What are the drawbacks of this approach? Each action is manual and must be performed directly by the developer, which leads to several issues. 
In a situation where multiple people are working on the same codebase, you could often encounter a scenario such as this one:
Person A applies their changes to the environment and follows up with a pull request. At the same time, Person B would like to deploy their changes but is blocked as the codebase is not up-to-date with Person A’s changes. Applying the changes in this state would cause damage to the resources created in the previous deployment. When working in larger teams, this will often result in a lot of wasted time just waiting and rebasing on a codebase to apply the changes.
If you happen to write unit tests for <a href="https://spacelift.io/blog/what-are-terraform-modules-and-how-do-they-work" target="_blank" rel="noopener">Terraform modules</a> (and you should be), you’re sure to know they need to be executed manually from your computer. Running them every time you change something in your configuration can be tedious and time-consuming. If you do not yet write tests for your modules, you’d be well advised to start looking at <a href="https://docs.spacelift.io/vendors/terraform/module-registry#tests" target="_blank" rel="nofollow noopener">Spacelift modules tests</a> or <a href="https://terratest.gruntwork.io/docs/getting-started/quick-start/" target="_blank" rel="nofollow noopener">Terratest</a>.
Privileged access to an underlying vendor is required, which can easily result in a compromised environment. It’s much harder to keep restricted access within this model, as Terraform must be allowed to create, change, and destroy resources. The same rule applies to a scenario where access to private (internal) resources is required, e.g., every developer has to set up a VPN connection to interact with them.
Moreover, every person working with the codebase needs access to the Terraform state, which creates a security concern due to how Terraform state works. Even if you’re pulling sensitive data from an external system such as Vault, it will be stored within the state file in plaintext once used in a resource. A threat actor could simply run `terraform state pull` to access all the secrets!
Keeping all these issues in mind, let’s take a look at a more automated approach.

Implementing homegrown automation means incorporating Terraform workflow into your continuous integration / continuous deployment process. A specific example would need to directly tie to a CI/CD tool you are using, so let’s try to keep the example as generic as possible.
As the applying actor is the CI/CD system, the hard requirement of privileged access for developers is gone. You can grant this type of access to the execution layer while developers keep read-only permissions. This is true for private (internal) resources, and if your code is being executed on an agent that resides within the target infrastructure with the proper permissions having been set. In a model where everything has to go through the CI/CD pipeline, visibility of changes is improved as the system logs produced during the operation execution are available in real-time. 
Linting, compliance checks, and automated unit tests can be moved to pull request status checks, and it’s up to you to configure these steps of the pipeline.
But—
If your CI/CD is executing jobs concurrently, you will end up with race conditions causing pull requests to fail non-deterministically. 
It is not difficult to imagine a situation where two operators open a pull request within several seconds of one another. The pipeline gets triggered immediately for both, and one pull request will be marked as successful, while the other will be marked as failed. This situation will definitely happen if you are using state locking (it is a best practice and you really should be using it).
The explanation is simple: the first pull request has locked the state and therefore the second one could not, so it failed. This issue can be resolved by configuring queued runs, where only one pipeline can run at a time. However, this is not so simple with some CI/CD products.
The biggest issue and concern with this approach is the effort you have to put in to build a complete pipeline. If you consider requirements such as:
<ul>
<li style="font-weight: 400;" aria-level="1">planning on pull requests</li>
<li style="font-weight: 400;" aria-level="1">linting</li>
<li style="font-weight: 400;" aria-level="1">unit tests</li>
<li style="font-weight: 400;" aria-level="1">compliance checks</li>
<li style="font-weight: 400;" aria-level="1">applying once merged</li>
<li style="font-weight: 400;" aria-level="1">periodical drift detection</li>
<li style="font-weight: 400;" aria-level="1">registry for all your versioned modules</li>
<li style="font-weight: 400;" aria-level="1">modules sharing across different parts of the organization</li>
<li style="font-weight: 400;" aria-level="1">shared variable contexts/reusable values</li>
</ul>
It might be tempting to implement solutions for those requirements by yourself. However, taking into account the time and effort required for doing it, you might want to take a look at alternatives, such as open-source tools.

One of the most popular open-source tools to use with Terraform is Atlantis, which describes itself as “Terraform pull request automation”. You can read more about it here: <a href="https://spacelift.io/blog/post/alternative-to-atlantis" target="_blank" rel="noopener">Alternative to Atlantis</a>.

Terraform Cloud is an application provided by the company behind Terraform itself—HashiCorp. It is available for free for up to 5 users. Two plans are available for more users: “Team &amp; Governance” and “Business”. As the product is created by Terraform authors themselves, any new feature that makes it to Terraform will be quickly available within Terraform Cloud as well. Neat!
<h3>Advantages of Terraform Cloud</h3>
Advanced security compliance mechanisms available through Sentinel allow you to enforce organization standards even before the code actually ships and creates resources with the chosen provider context.
Another important feature is a module registry that acts as an artifact repository for all your modules. It can be compared to JFrog Artifactory, Sonatype Nexus, or other similar software. Having every module in a separate repository and versioning allows you to control code promotion in a granular fashion or quickly roll back to if it allows you to go back to the most recent version only, then we should use “the”, but if it lets you go back to some other earlier version then we should use “a” previous version. 
Having a centralized place to store all the pieces also enables you to quickly browse through available modules, their documentation, inputs, outputs, and used resources. It is a great single pane of glass in terms of module management. However, it can only be used within the same Terraform Cloud organization and cannot be shared. This might be troublesome for operations teams that base their separation on the organization level.
There’s also the remote execution backend, which is an exclusive feature for Terraform Cloud. It allows you to work with Terraform on your local computer as you would usually do, upload your local codebase, and run a plan against it. It is a very efficient way of quickly verifying if what you are working on is actually working.
<h3>Disadvantages of Terraform Cloud</h3>
Along with so many benefits, there are some drawbacks as well. Any linting or module unit tests need to be implemented inside your own continuous integration system. This requires an additional effort the development team has to make to sustain their code quality.
Another disadvantage is that you are not able to share common values across your workspaces. Imagine a situation where you share a common set of variables like cloud region or environment name. The only way to achieve something similar to shared context is to have a dedicated workspace that will output this information as an input for all remaining workspaces, although this would be more of a workaround than an actual solution.
Compliance as code is available via Sentinel, a framework created by HashiCorp. Having a built-in solution to develop policies is nice, but operators often already use Open Policy Agent (OPA) to define these within different areas of the infrastructure. This frequently ends up in a doubled effort as you need to create a similar policy in both frameworks.
The biggest shortcoming of Terraform Cloud is in my opinion the lack of periodical drift detection runs. Once something is applied and the codebase does not get updates, you will never be notified if anything has changed in comparison to the state within the repository. Scheduling a daily “plan” to verify if everything is up-to-date would be highly beneficial to keep the infrastructure as described programmatically.

And here we are. You can compare Spacelift directly to Terraform Cloud. They share a lot of functionality with each other in terms of the actual deployment execution, but also in the area of compliance.
While Terraform Cloud uses Sentinel (the HashiCorp approach to implementation for compliance as code), Spacelift leverages Open Policy Agent. It is beneficial to have a similar way of working with policies for companies that already incorporate OPA in their workflow (e.g., for Kubernetes). As there is no need to learn another syntax, operators can focus their efforts on providing compliance, instead of learning yet another tool.
Spacelift also allows you to automate your workflow even further. By having a built-in continuous integration for modules, you can shift your linters or unit tests really quickly into one place dedicated to Terraform. It helps you reduce the effort required to implement integration workflow by letting you utilize a solution that you are already using.
Sometimes you need to work with a Terraform state directly to import something, for example. In scenarios where you are leveraging Terraform Cloud, it is often impossible to do this without accessing the provider yourself. In contrast, Spacelift gives you the ability to run literally any command within the context of a particular codebase via tasks. This way, you do not need to grant any additional permissions to import, move, or remove resources directly.
By utilizing contexts, you can simply share anything you like across multiple stacks—whether it is a set of environment variables or a file. This is something that becomes much more valuable once your codebase complexity increases.
As mentioned in the previous paragraph, drift detection is something that becomes much more important once your infrastructure grows. With Spacelift, it is possible to schedule a periodic drift detection on any stack. Going even further, you can enable automated remediation if any changes are found compared to what you have in your codebase.

There are many ways of working with Terraform. Each way is different in terms of complexity, and has 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 times, there is no point in implementing an in-house solution as the cost and effort of building and maintaining it may often exceed its potential benefits. It is much easier and quicker to leverage platforms such as Spacelift to provide these features for you instead.

How to provision an AWS EKS Kubernetes cluster with Terraform - step by step

Getting started with Terraform on Google Cloud Platform (GCP)

This article goes through five approaches to managing Terraform at scale: using Terraform locally, automating it in-house, using open source solution, using Terraform Cloud, and using Spacelift.

Spacelift Blog

Categories

Spacelift raises $15m in Series B funding from Insight Partners

Why should business care about Infrastructure as Code

How a Specialized Management Platform Can Improve Your IaC

Read also

How a Specialized Management Platform Can Improve Your IaC

5 Ways to Manage Terraform at Scale