General | Spacelift Blog

Author title

Title category

Get all the latest content on Infrastructure as Code, DevOps, Spacelift features & news directly to your inbox!

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

applepodcasts

spotify

missionctrl

Welcome to missionCTRL, a show dedicated to exploring the frontiers of modern DevOps. Listen (or watch) as we sit down with the practitioners who are pushing the boundaries of development

Is it Worth it to Become a DevOps Engineer?

General

Phil Vuollet

There’s no doubt about it, working as a DevOps engineer — an engineer that enables DevOps culture — is challenging, cutting-edge, and financially rewarding. DevOps engineering is a relatively new career, with Larry-Page-level opportunities for those with the right technical skills.
It’s also highly relevant in the workplace, and it’s ideal if you’re hungry for both technological and interpersonal challenges. DevOps is an intelligent job transition if you’ve been doing software development, networking, or operations.
DevOps engineers do a lot of automation, monitoring, testing, configuring, networking, and <a href="https://spacelift.io/blog/infrastructure-as-code" target="_blank" rel="noopener">Infrastructure as Code</a> (IaC). That means you’ll need to bring a variety of skills and talent to the table. Let’s face it, it’s a highly technical role that’s usually best left to experienced engineers.
There’s some opportunity in the DevOps field for entry-level engineers, but most of the jobs require experience. So, is it worth it to become a DevOps engineer? And — do you have what it takes? After reading this article, you’ll be better equipped to find out!
Interested in a career in DevOps? See our article on <a href="https://spacelift.io/blog/how-to-become-devops-engineer" target="_blank" rel="noopener">How to Become a DevOps Engineer</a>.

DevOps Engineers use their skills to deliver software quickly, continuously, and reliably. The goal of DevOps is to shorten the software delivery and feedback cycles. DevOps pros typically orchestrate multiple components in a cloud environment. They’re the ones who make sure the system keeps running smoothly, day after day.
DevOps professionals also keep things up to date with the latest changes and security updates. They automate testing, scanning, and deploying. If there’d been DevOps on the Death Star, the rebels never would have blown it up.
<h3>Where did DevOps come from?</h3>
DevOps evolved as a cultural phenomenon. Recently, companies have created specialist DevOps roles to help create and support their culture. There are so many specialized tools and skills in the IT side of every business that supporting DevOps is increasingly a full-time job.
While DevOps has certainly changed how we develop software, it has also fundamentally changed how software is deployed. This is largely thanks to the general availability and lower cost of <a href="https://spacelift.io/blog/cloud-deployment-models" target="_blank" rel="noopener">cloud infrastructure</a>, containerized environments, and the evolution of tools that enable automation.

Working in DevOps isn’t a bad way to spend your time these days. As a field, DevOps is experiencing job growth. Furthermore, the jobs in DevOps pay more than the average tech or computer science job. There’s some level of upward and horizontal mobility too.
Let’s dive a little deeper into each of the three reasons DevOps is a good career.
<h3>1) Massive DevOps job growth</h3>
To say that jobs in the DevOps field are growing would be an understatement. In fact, the Bureau of Labor Statistics (BLS) <a href="https://www.bls.gov/ooh/computer-and-information-technology/software-developers.htm#tab-1" target="_blank" rel="noopener">shows a projected growth rate</a> this decade in the software field at 22%, compared to an 8% median growth rate for all jobs.
While DevOps jobs are only part of that growth, it’s still substantial. Let’s assume, for example, that DevOps jobs growth is only 5%. With 1.8 million jobs in the field now, that 5% growth means 90,000 new DevOps jobs. And given the popularity of DevOps with employers, 5% is almost certainly a lowball estimate.
<h3>2) High salary for DevOps jobs</h3>
DevOps jobs pay very well, like many jobs in IT. If you’re into being paid comfortably and you have the right qualifications, you’re probably already looking at salaries for DevOps jobs.
<a href="https://builtin.com/salaries/dev-engineer/devops-engineer" target="_blank" rel="noopener">Builtin</a> puts the average base salary for a DevOps Engineer in the U.S. at $125 — and upwards in the $300k range. <a href="https://www.glassdoor.com/Salaries/devops-engineer-salary-SRCH_KO0,15.htm" target="_blank" rel="noopener">Glassdoor</a> pegs it closer to $105k. These are just two examples of average pay. The range is fairly wide, but still, the pay is quite nice for a 9-5 job.
Of course, there’s always some variability in the market depending on location, experience, and the company you end up working for.

avarage-devops-salary-in-the-usa-in-different-industries-2

Avarage DevOps salary in the USA in different industries

<h3>3) Upward mobility</h3>
There’s some upward mobility for DevOps Engineers depending on the company. You might find a career path from junior engineer all the way up to DevOps architect. If you have the right stuff, you may even end up managing the department.
It’s also possible to transition to similar roles like site reliability engineer (SRE). Of course, the higher you go the fewer positions are available. (The corporate pyramid leaves less room near the top.)
DevOps offers plenty of horizontal mobility too, since DevOps engineering skills usually translate between industries. Plus, it doesn’t make too much of a difference whether the company makes widgets or life insurance. The work in DevOps is generally the same.

average-devops-salary-2

Average DevOps salary

<ul>
<li><a href="https://spacelift.io/blog/ci-cd-tools" target="_blank" rel="noopener">Top Most Useful CI/CD Tools for DevOps</a></li>
<li><a href="https://spacelift.io/blog/devops-best-practices" target="_blank" rel="noopener">16 DevOps Best Practices to Follow</a></li>
<li><a href="https://spacelift.io/blog/terraform-automation" target="_blank" rel="noopener"><span data-sheets-value="{&quot;1&quot;:2,&quot;2&quot;:&quot;Automating Infrastructure Deployments Using Terraform&quot;}" data-sheets-userformat="{&quot;2&quot;:513,&quot;3&quot;:{&quot;1&quot;:0},&quot;12&quot;:0}">Automating Infrastructure Deployments Using Terraform</a></li>
</ul>

Depending on the company and your specific DevOps role, you may end up working on any number of issues. Your role may relate to automation, infrastructure, tooling, quality, or monitoring (to name a subset). The automation aspect includes code deployment, environment and infrastructure configuration, and even automatic quality checks.
The goal of all this automation is to speed up delivery without sacrificing quality or security. Much of the work is setting up monitoring and alerting for the automation and production systems. Monitoring and altering are important aspects of the feedback loops that power continuous improvement.
Read more about DevOps and security: <a href="https://spacelift.io/blog/what-is-devsecops" target="_blank" rel="noopener">DevSecOps: Making Security Central To Your DevOps Pipeline</a>

There are a few key downsides of a career in DevOps, including a high-pressure atmosphere, lack of recognition, and frustrations from butting heads with other technical teams. You may also feel like a jackrabbit in a field of turtles as you champion cutting-edge advancements while the rest of your organization slogs behind.
Most of the work in DevOps happens behind the scenes. In other words, your achievements won’t be put on display. You may get zero recognition outside your branch in the org chart. In less collaborative environments, DevOps Engineers might face frustrations with other technical teams. See our <a href="https://spacelift.io/blog/are-it-jobs-stressful" target="_blank" rel="noopener">report on stress in IT</a>.
<h3>Out on the bleeding edge</h3>
There may be situations where the goals of DevOps run counter to the goals of other groups that are slow to change or adopt complementary practices. The tools can sometimes be frustrating to work with too. And, in the real world, any number of things can go wrong at any given time.
Part of your job in DevOps is to make sure systems are running well. If something goes wrong, you may have to work outside normal hours to resolve the problem. You may feel intense pressure from extremely high expectations, especially during challenging times.

By now, you should have the answer to the key question: is DevOps a good career? It is.
Still, you might not know if DevOps is right for you. So — if you’re still on the fence, here are a few questions (and answers) to help make up your mind:
<h3>Are you interested in automation?</h3>
If you’re interested in automation, that’s one point for team DevOps. If you prefer coordinated manual deployments, maybe a DevOps environment won’t be the best fit for you. DevOps teams do a lot of automation.
<h3>Do you like the DevOps framework?</h3>
The DevOps framework is a set of behaviors that seeks close collaboration between software development and operations. If using communication, processes, and tools to tighten that loop is appealing, you’d do well in a DevOps environment.
<h3>Do you like being in charge of infrastructure?</h3>
DevOps Engineers play a Linus-Torvalds-size role in establishing and maintaining the infrastructure that runs applications. Most often, the actual infrastructure (the hardware) is provided by a cloud vendor. The work of DevOps Engineers is to configure the rented infrastructure for efficient operations of applications. It’s interesting work if you like fine tuning and solving data flow problems.

Do you have the right skills to be a DevOps engineer? The often-quoted acronym CAMS paints a picture of the spirit of DevOps as: Culture, Automation, Measurement, and Sharing.
That acronym was coined by John Willis and Damon Edwards in 2010. As Willis <a href="https://itrevolution.com/devops-culture-part-1/" target="_blank" rel="noopener">pointed out</a>, Jez Humble later added an ‘L’ for Lean. CALMS pretty much sums up the skills you need for a DevOps career.

top-8-devops-skills-580-x-435-px

top 8 devops skills

<h3>1) Interpersonal</h3>
Patrick DuBois, co-originator of DevOps, still says all problems are people problems. In Jan 2021, he still fights the good fight against organizational silos <a href="https://twitter.com/patrickdebois/status/1350116781982162946" target="_blank" rel="nofollow noopener">as mentioned in this tweet</a>. And since DevOps is a culture of sharing, it helps to have good interpersonal skills.
Part of the job is reaching out with empathy and helping others achieve their goals. And, you know — things will go wrong from time to time. When they do, your interpersonal skills will go a long way toward helping you come out on top.
<h3>2) A programming language</h3>
If you’re thinking about a career in DevOps, you should know how to code, at least at a basic level. Much of the work involves writing shell scripts or using a coding language such as Python to automate tasks. You may need to write Python scripts to call various APIs, or use shell scripts to manipulate files.
Some DevOps roles require knowledge of VB-Script and Windows PowerShell. Either way, you should have a foundation of coding, so you can learn the nuts and bolts of your environment.
<h3>3) Automated build/test</h3>
One of the core principles of DevOps is automation. Automating builds is a human-genome-sized step toward consistency, reliability, and traceability. Once that’s done, it’s time to automate the tests for that build. Sometimes this demands a big shift in thinking and a whole lot of work.
Still, it’s a big win when you can get to automated build and test. DevOps culture centers around this kind of win. You may write tests using Selenium, Postman, the Robot Framework, or other types of automated testing tools. You’ll have to incorporate these tools into the automated release process.
See our list of <a href="https://spacelift.io/blog/devops-tools" rel="">+70 useful DevOps tools</a>.
<h3>4) Containers</h3>
In all likelihood, you’ll use containers in your career as a DevOps Engineer. Many organizations are either using or switching to containers (mainly Docker) for several types of workloads. A container is an isolated runtime environment that includes most of an operating system. It runs on a server or VM. You can launch containers quickly, making them ideal for running tasks fast — a key focus in DevOps work.
<h3>5) Configuration</h3>
Configuration is another task DevOps Engineers spend lots of time on. Actually, most of the work in automating is configuring the systems that perform the work. Even the infamous IaC (infrastructure as code) is really about configuring the infrastructure and environment using a specification language.
DevOps cultures prefer using IaC because IaC tracks changes. That lets DevOps pros measure the effects (remember: CALMS). There’s nothing worse than tracking down a problem without knowing a configuration changed! In DevOps, you want to monitor events like Tony Stark.
<h3>6) Version control</h3>
Along with one of the tools you’ll use frequently as a DevOps engineer — the Linux-based operating system — you’ll most likely use another of Linus Torvald’s inventions — git! Or you might use another version control system like subversion or TFS. They all do the same general thing: keep track of changes to the codebase.
For automated delivery pipelines, you’ll keep the configuration under version control. You’ll store IaC files in VCS as well. And often, a VCS is hosted on a platform that runs a pipeline and can be configured to kick off automation. The VCS is also the heart of a change-management system in a DevOps world.
<h3>7) Package</h3>
Developers from different groups or projects often need the same types of features. They might need logging, authentication, or any kind of functionality plugged into a software development environment. DevOps culture embraces sharing (the “S” in CALMS), so its denizens will often “package” functionality.
DevOps engineers might even dive in and create these packages to share. Or, they may just manage package repositories both public and private. Note that package repositories are another possible destination for delivery.
<h3>8) Networking</h3>
Ahhh, networking! If a problem isn’t a code error, it’s probably something in the network. Networking is another critical skill in a DevOps role. It could be enough to know the IP protocol, but you’ll often need an understanding of certificates and routing, too.
Even in a cloud environment, it’s important to know how networks and subnetworks operate. And even containers have their own type of network configuration to consider.
Take a look at our list of <a href="https://spacelift.io/blog/devops-books" target="_blank" rel="noopener">books for DevOps, Site Reliability, and Cloud Engineers &amp; Architects</a> to advance your career to the next level.

DevOps is a great career in 2023 and beyond. If you’re at all interested in the crossover between development and operations, it could be a Ken-Thompson-level field for you. With six-figure salaries, swift job growth, and plenty of upward mobility, the future for DevOps is blindingly bright. If you’ve felt strongly that DevOps is a good career to get into, then definitely give it a shot.
In the meantime, go ahead and learn how a platform like <a href="https://spacelift.io" target="_blank" rel="noopener">Spacelift</a> can help you and your organization fully manage cloud resources within minutes.
Spacelift is a CI/CD platform for infrastructure-as-code that supports tools like Terraform, Pulumi, Kubernetes, and more. For example, it enables <a href="https://docs.spacelift.io/concepts/policy/" target="_blank" rel="noopener">policy-as-code</a>, which lets you define policies and rules that govern your infrastructure automatically. You can even invite your security and compliance teams to collaborate on and approve certain workflows and policies for parts that require a more manual approach. Get a head start with <a href="https://docs.spacelift.io/" target="_blank" rel="noopener">Spacelift’s documentation</a>.

Spacelift is an alternative to using homegrown solutions on top of a generic CI. It helps overcome common state management issues and adds several must-have capabilities for infrastructure management.

What is Terraform? What is it Used For, How it Works

SRE vs. DevOps: What’s the Difference Between Them?

16 DevOps Best Practices Every Developer Should Know

You still wondering if DevOps is right for you? See our article and find out whether it is worth it to become a DevOps engineer in 2023.

41-why-is-it-worth-to-become-devops-engineer

Who Is DevOps? Is Becoming a DevOps Engineer Worth It?

What Is Infrastructure as Code? Examples, Best Practices & Tools

Jack Roper

Infrastructure-as-code (IaC) is a very important concept to understand in the DevOps world today. It has become almost ubiquitous across the industry and is absolutely key to modern engineering roles.
In this post, I will explain what IaC is, what its benefits are, some of the tooling options available, and point out some best practices along the way. I will then look at some code examples for each tool to compare and contrast.
You will learn:
<ol>
<li><a href="https://spacelift.io/blog/infrastructure-as-code#what-is-infrastructure-as-code-iac" rel="">What Is Infrastructure as Code (IaC)</a></li>
<li><a href="https://spacelift.io/blog/infrastructure-as-code#benefits-of-infrastructure-as-code">Benefits of Infrastructure as Code</a></li>
<li><a href="https://spacelift.io/blog/infrastructure-as-code#challenges-and-limitations-with-iac">Challenges and Limitations with IaC</a></li>
<li><a href="https://spacelift.io/blog/infrastructure-as-code#why-should-i-store-my-infrastructure-as-code-in-a-version-control-system-vcs">Why Should I Store My Infrastructure as Code in a Version Control System (VCS)?</a></li>
<li><a href="https://spacelift.io/blog/infrastructure-as-code#declarative-vs-imperative-approaches">Declarative vs. Imperative Approaches</a></li>
<li><a href="https://spacelift.io/blog/infrastructure-as-code#infrastructure-as-code-tooling">Infrastructure as Code Tooling</a></li>
<li><a href="https://spacelift.io/blog/infrastructure-as-code#infrastructure-as-code-examples">Infrastructure as Code Examples</a></li>
</ol>

Put in the simplest terms, using code, you define the infrastructure that needs to be deployed in a descriptive model. Similar to code for applications, the code for the infrastructure becomes part of the project and is stored inside your version control system (or VCS).
For example, consider that you have developed a web application. That web application needs to be hosted on infrastructure somewhere to be consumed. Using IaC you could define things like where the infrastructure is deployed to, such as a public cloud provider like Microsoft Azure, Amazon AWS, or Google Cloud, and what type of service your web application will run on, such as an Azure web app, or an AWS S3 Storage account. Further to this, you can then define the settings required for the web app, which might include things like how much server compute power is required (in terms of CPU and memory), how the networking is secured, and how the domain name for your app will be exposed, to name a few among many other considerations.

IaC solves many common problems with provisioning Infrastructure.
<ul class="">
<li id="597c" class="mp mq io kf b kg kh kj kk km mr kq ms ku mt ky mu mv mw mx gj" data-selectable-paragraph="">New environments or infrastructure can be provisioned easily from your IaC configuration code. Infrastructure deployments with IaC are repeatable.</li>
<li id="2ed8" class="mp mq io kf b kg my kj mz km na kq nb ku nc ky mu mv mw mx gj" data-selectable-paragraph="">Manually configured environments are difficult to scale. With environments provisioned using IaC, they can be deployed and scaled rapidly.</li>
<li id="1fa7" class="mp mq io kf b kg my kj mz km na kq nb ku nc ky mu mv mw mx gj" data-selectable-paragraph="">If you want to make changes to the existing infrastructure that has been deployed with IaC, this can be done in code, and the changes will be tracked.</li>
<li id="e257" class="mp mq io kf b kg my kj mz km na kq nb ku nc ky mu mv mw mx gj" data-selectable-paragraph="">When IaC is used with a declarative tool (it describes the state you want your environment to look like), you can detect and correct environment drift. If a part of the infrastructure is modified manually outside of the code, it can be brought back in line with the desired state on the next run.</li>
<li id="42dd" class="mp mq io kf b kg my kj mz km na kq nb ku nc ky mu mv mw mx gj" data-selectable-paragraph="">Changes can be applied multiple times without changing the result beyond the initial application. This is known as idempotence.</li>
<li id="e195" class="mp mq io kf b kg my kj mz km na kq nb ku nc ky mu mv mw mx gj" data-selectable-paragraph="">Avoid manual configuration of environments which can typically introduce mistakes due to human error. With IaC, these can be avoided.</li>
<li id="449b" class="mp mq io kf b kg my kj mz km na kq nb ku nc ky mu mv mw mx gj" data-selectable-paragraph="">IaC is a means to achieve consistency across environments and infrastructure. The code can be reused.</li>
<li id="7a68" class="mp mq io kf b kg my kj mz km na kq nb ku nc ky mu mv mw mx gj" data-selectable-paragraph="">Infrastructure costs are lowered as the time to deploy and effort to manage, administer and maintain environments decrease.</li>
<li id="3dd7" class="mp mq io kf b kg my kj mz km na kq nb ku nc ky mu mv mw mx gj" data-selectable-paragraph="">IaC can be used in Continuous Integration / Continuous Deployment (or CI/CD) pipelines. The main benefit of doing this is to automate your Infrastructure deployments.</li>
<li id="b7bc" class="mp mq io kf b kg my kj mz km na kq nb ku nc ky mu mv mw mx gj" data-selectable-paragraph="">DevOps teams can test applications in production-like environments early in the development cycle.</li>
<li id="9dd2" class="mp mq io kf b kg my kj mz km na kq nb ku nc ky mu mv mw mx gj" data-selectable-paragraph="">With your Infrastructure configuration code held in your version control system alongside your application source code, commonly in the same repository. Now everything can be held together.</li>
<li id="7002" class="mp mq io kf b kg my kj mz km na kq nb ku nc ky mu mv mw mx gj" data-selectable-paragraph="">Productivity will increase due to a combination of all the benefits of using IaC.</li>
<li id="f688" class="mp mq io kf b kg my kj mz km na kq nb ku nc ky mu mv mw mx gj" data-selectable-paragraph="">As the code is held in your version control system, it gains all the benefits of the VCS. More on that in the next section.</li>
</ul>

The adoption of IaC is not without its challenges.
Typically, traditional infrastructure or operations teams within organizations may not be familiar with version control systems, use of Git, or be comfortable using tools for code editing such as visual studio code.
Further to this, there is certainly a learning curve when it comes to the adoption of new technology within an organization. Training will be required and time will be needed to develop the appropriate skills.
Skills in IaC and DevOps are currently highly sought after in the industry and so therefore it may be difficult to hire staff with these skills.
The journey to managing your environments using IaC will typically start with a small deployment of new resources to your chosen cloud platform, and from there once adoption within the organization grows, more of your infrastructure can start to be deployed and managed in code. Eventually, when your organization is mature and comfortable with the principles and operation of your chosen IaC systems and tooling, existing resources can be brought under IaC control.

Without diving too deeply into the benefits of using a VCS in this article, we will summarise them here as storing your IaC in a VCS automatically gives you a raft of additional benefits.
In summary, a VCS enables developers and organizations to work more efficiently in improving the quality of their product while recording and evaluating a detailed history of their improvements that will lead to a successful end product. In short, using a VCS enables governance, versioning, and increases collaboration.
1. Efficiency
As configuration files are amended incrementally with changes, testing becomes easier as rollback to previous versions is possible. New features can be built up over time.
2. Tracking &amp; Versioning
Track who made the change, and in which version of the file. Comments can be added to each code change (or commit).
3. Collaboration
Multiple people can work on the configuration files at the same time using branching. Changes can be merged together using pull requests.
4. Governance &amp; Compliance
Tracking changes automatically gives you a powerful audit trail, enabling risk management.
5. Management
A management overview becomes possible through being aware of the author of the configuration, how long it took to make changes, the timeline and its impact.
6. Reduces Duplication
Multiple and out-of-date configuration files are reduced.
7. Backup
Users will typically clone the repository their configuration code is held in and work on it locally. The code then exists locally and in the VCS. The VCS itself is also backed up.

There are 2 approaches to the templates used when writing IaC configuration files. Different tools use different approaches, which are listed in the next section.
Declarative — you define the desired state of the final solution.
The tool or automation platform determines how the goal is reached, the step-by-step executions are handled by the tool and hidden from the user. Declarative tools are the most popular and most dominant in the IaC space. They are most useful when changes or updates need to be made to your solution.
Declarative tools are idempotent because you are defining the required state of the solution. Idempotency refers to a process that can be executed multiple times with the same result.
Imperative — you define the steps to execute in order to reach the desired solution.
An imperative approach allows you to build up multiple layers of commands to reach the end goal. Imperative tools give you more control over how the goal is reached. These tools are most useful when you need to deploy and not update or change the solution in the future.
Imperative approaches may not lead to idempotency, the end goal may be different depending on the starting point, as a series of steps form the process. Consider a process with 10 steps, for example, starting from step 1 would lead to a different result compared to starting with step 6.

<ul>
<li><a href="https://spacelift.io/blog/infrastructure-problems-that-spacelift-solves" target="_blank" rel="noopener"><span data-sheets-value="{&quot;1&quot;:2,&quot;2&quot;:&quot;Common Infrastructure Challenges and How to Solve Them&quot;}" data-sheets-userformat="{&quot;2&quot;:513,&quot;3&quot;:{&quot;1&quot;:0},&quot;12&quot;:0}">Common Infrastructure Challenges and How to Solve Them</a></li>
<li><a href="https://spacelift.io/blog/how-specialized-solution-can-improve-your-iac" target="_blank" rel="noopener"><span data-sheets-value="{&quot;1&quot;:2,&quot;2&quot;:&quot;How to Improve Your Infrastructure as Code using Terraform&quot;}" data-sheets-userformat="{&quot;2&quot;:513,&quot;3&quot;:{&quot;1&quot;:0},&quot;12&quot;:0}">How to Improve Your Infrastructure as Code using Terraform</a></li>
<li><a href="https://spacelift.io/blog/drift-detection" target="_blank" rel="noopener">Fixing Infrastructure Drift with IaC Tools</a></li>
</ul>

So you’ve decided to pursue IaC due to the myriad of benefits it enables. Now you need to decide which tool to use! This will depend on a number of factors, including your engineering capability and current use of cloud platforms.
You should also consider the use of a Continuous Integration / Continuous Delivery (CI/CD) platform and the tools that it supports before deciding. The most flexible platforms, such as <a class="au lo" href="https://spacelift.io" target="_blank" rel="noopener">Spacelift</a>, support multiple tools, including Terraform, Ansible, Pulumi, and CloudFormation. For example, with Spacelift, you can set up Terraform Stacks to provision required infrastructure (like an ECS/EKS cluster with all its dependencies) and then connect that to a CloudFormation Stack which then transactionally deploys your services there using <a href="https://docs.spacelift.io/concepts/policy/trigger-policy" target="_blank" rel="noopener">trigger policies</a> and the Spacelift provider <a href="https://registry.terraform.io/providers/spacelift-io/spacelift/latest/docs/resources/run" target="_blank" rel="nofollow noopener">run resources</a> for workflow orchestration and <a href="https://docs.spacelift.io/concepts/configuration/context#remote-state-alternative-terraform-specific" target="_blank" rel="noopener">Contexts</a> to export Terraform outputs as CloudFormation input parameters.
First, we will outline 2 cloud-agnostic options, Terraform and Pulumi, before moving on to the Microsoft Azure cloud-specific ARM templates and Bicep. Lastly, we will briefly discuss other options for AWS, CloudFormation, and CDK, as well as other tools such as Ansible, Chef, Salt, and Puppet.
<h3>Terraform</h3>

iac1

Terraform logo

<a href="https://spacelift.io/blog/what-is-terraform" target="_blank" rel="noopener">Terraform</a> takes the declarative approach. It uses its own language called Hashicorp Configuration Language (HCL), which is considered by most as very easy to pick up and is very human-readable. HCL is based on Go.
Terraform can be used with almost any cloud provider, as well as on-premise infrastructure through its provider mechanism, of which there are thousands available. It is for this reason that many choose Terraform over other options. If you want to use the same language and formatting to configure infrastructure across multiple cloud platforms and infrastructure, it is a natural choice.
In my opinion, even if you only want to use it for one cloud platform (e.g., Microsoft Azure), it is still the best option, due mainly to the maturity of the language and its supporting ecosystem.
Terraform maintains a state file. The state file describes the existing state of the infrastructure and allows Terraform to query, build, maintain, and change the infrastructure as defined in your configuration files. Maintaining the state file introduces challenges around its security, but many solutions exist to the problem.
Dependency mapping between resources is done in the background automatically by Terraform and is largely hidden from the user, but can be controlled if required. Dependency mapping refers to the order resources are created in. Consider the creation of a virtual machine, first, you must have a VNET, subnet, disk, and key vault for disk encryption in place before it can be created successfully. Terraform makes sure resources are created in the correct order. If these need to be manually manipulated, the <code class="ng nh ni nj nk b">depends_on</code> met-argument can be utilized in the configuration to achieve this.
Terraform has a raft of great features, including allowing you to deploy to different environments using workspaces, and the ability to run plans to show what will change without making any alterations to name a couple.
Terraform does have a slight delay in terms of the features it supports. For example, when a new feature or service is released in Azure, this capability must be added to the <code class="ng nh ni nj nk b">azurerm</code> provider by the team that maintains it before the feature will be able to be referenced using Terraform. However, the delay is usually very small and almost all features that are available to a user in the Azure portal and available through Terraform configuration language. If your team lives on the cutting edge and utilizes lots of preview services, this might be an issue. This is not always the case for all providers, as when it comes to the <code class="ng nh ni nj nk b">aws</code> Terraform provider, some new features have been implemented before the AWS native CloudFormation!
Learn more about how you can <a href="https://spacelift.io/blog/terraform-automation" target="_blank" rel="noopener">automate your infrastructure provisioning with Terraform</a>.
<h3>Pulumi</h3>

iac2

Pulumi logo

<a href="https://spacelift.io/blog/what-is-pulumi" target="_blank" rel="noopener">Pulumi</a> is another declarative IaC tool. Instead of having its own language, it allows teams to use an existing programming language, something which can be highly desirable if your team already has strong preferences or skills. Pulumi supports TypeScript, JavaScript, Python, Go, and C#.
Like Terraform, Pulumi also supports multiple clouds, infrastructure, and providers.
Note that any existing Terraform or ARM configuration files you have can be converted into Pulumi files.
Pulumi is harder for coding novices to get to grips with compared to Terraform or Bicep. If no prior coding skills exist within your team, it will take time to learn.
As Pulumi configuration files are coded with the programming language of your choice, this means you can use the same testing tools as you use for your main code, another major advantage.
<h3 id="e9c7" class="pw-post-body-paragraph kd ke io kf b kg kh jp ki kj kk js kl km kn ko kp kq kr ks kt ku kv kw kx ky ih gj">Microsoft Azure ARM Templates</h3>
ARM templates are the native templating option for all resources in Azure. ARM templates are written in JSON format.
Getting started using ARM templates is easy as ARM templates can be downloaded for any existing resource straight from the Azure Portal and can be modified as needed. These templates can allow you to redeploy resources easily. Because ARM templates are the native option in Azure, they are well documented and supported by Microsoft. They can also be used for any resource in Azure from the day of release, an advantage over Terraform.
However, when writing ARM templates from scratch there is a lot of ‘boilerplate’ code that is required, something that tools like Terraform and Bicep extract away from the user, making the code easier to both read and write. JSON language is picky about formatting and can be a chore to learn. Because of the additional code required for ARM templates compared to other options, the configuration files can get very large, complex, and hard to follow, and any syntax errors can become tricky to troubleshoot. There is no concept of ‘state’ when using ARM templates, so any changes that are applied can be breaking. In addition to these disadvantages, there is no plan, or ‘dry-run’ option available when using ARM templates, making it difficult to confirm that what you are deploying will result in the desired outcome.
<h3>Microsoft Azure Bicep</h3>

iac3

Azure Bicep logo

Azure Bicep is a declarative abstraction language used to simplify .json ARM templates that are used to provision infrastructure in Azure. Bicep is a Domain-specific language (DSL), so if you want to use the same language across multiple clouds, this isn’t the option for you.
Bicep aims to take away some of the unnecessary .json boilerplating, leaving simpler, cleaner code, similar to Hashicorps HCL. You can use modules, something not really available with ARM templates, allowing you to simplify complex deployments. Bicep can query the state directly from Azure, so there is no need to manage a state file, which is a great advantage over Terraform.
Bicep is still in its relatively early days, having come to prominence in the last couple of years, and so the community around it is not as large as that of Terraform. However, Bicep is fully supported by Azure Support teams meaning you can raise a ticket through the Azure portal for Bicep-related issues, similar to how you would raise a ticket for any Azure resource problems you might encounter. In theory, anything you can do with ARM templates you can do with Azure Bicep (and more) although some limitations still exist during to the ongoing development of the tool.
Bicep is part of the Azure CLI. Note that you can convert existing ARM templates into bicep files. As an example running the command below in cloud shell will convert your .json ARM template into a .bicep file:

<h3 id="1b64" class="pw-post-body-paragraph kd ke io kf b kg kh jp ki kj kk js kl km kn ko kp kq kr ks kt ku kv kw kx ky ih gj">Amazon Web Services (AWS)</h3>
<a href="https://spacelift.io/blog/terraform-vs-cloudformation" target="_blank" rel="noopener">CloudFormation</a> is the native AWS IaC tool and takes the declarative approach. CloudFormation templates are written in JSON or YAML format. CloudFormation is a managed AWS service and will check the infrastructure it has provisioned to detect if it is maintaining the described state, no state management is required which is a benefit over Terraform. Similar to modules in Terraform, AWS uses a concept called ‘nested stacks’, which enables templates to be called from other templates. Note that interestingly it is possible to provision resources on other clouds or non-AWS resources using CloudFormation, as the custom resources feature enables this. However, this involves additional templating and is certainly not as easy as using Terraform. CloudFormation support is included in AWS support plans.
Similar to Pulumi but not cloud-agnostic, the AWS Cloud Development Kit (AWS CDK) is an open-source software development framework to define your cloud application resources using familiar programming languages. CDK would be generally considered as taking an imperative approach.
<h3 id="b150" class="pw-post-body-paragraph kd ke io kf b kg kh jp ki kj kk js kl km kn ko kp kq kr ks kt ku kv kw kx ky ih gj">Ansible, Salt, Chef, and Puppet</h3>
These are generally considered as configuration management as code tools, but can also be used to provision and manage infrastructure.
Puppet takes the declarative approach. Chef takes the imperative approach. <a href="https://spacelift.io/blog/ansible-vs-terraform" target="_blank" rel="noopener">Ansible</a> and Salt are mostly declarative but offer some support for imperative commands.
See a more detailed <a href="https://spacelift.io/blog/infrastructure-as-code-tools" target="_blank" rel="noopener">list of the most useful IaC deployment tools</a>.

In this section we will compare the code required to create a Storage account in Azure, using Terraform, Pulumi, Bicep and ARM templates. All four examples will create the same result in Azure, a storage account with a container called ‘logs’.
<h3 id="830d" class="pw-post-body-paragraph kd ke io kf b kg kh jp ki kj kk js kl km kn ko kp kq kr ks kt ku kv kw kx ky ih gj">Terraform</h3>
Notice how easy to read the HCL language is, making it arguably the most accessible to the beginner of the four compared options.

See a more detailed guide on <a href="https://spacelift.io/blog/terraform-infrastructure-as-code" target="_blank" rel="noopener">how to manage Infrastructure as Code (IaC) with Terraform</a>.

<h3 id="7418" class="pw-post-body-paragraph kd ke io kf b kg kh jp ki kj kk js kl km kn ko kp kq kr ks kt ku kv kw kx ky ih gj">Pulumi</h3>
The Pulumi example can be coded in many different programming languages, here I have shown the Python equivalent as it will be a commonly used and understood language across infrastructure teams. In Python, it actually comes in slightly shorter than the terraform equivalent but is harder to read for the beginner.

Existing Terraform <a href="https://www.pulumi.com/tf2pulumi/" target="_blank" rel="nofollow noopener">can be converted</a> to Pulumi files using tf2pulumi, a great resource that lets you view the code side-by-side and convert it to Typescript, Python, Go, or C#.
<h3 id="8c19" class="pw-post-body-paragraph kd ke io kf b kg kh jp ki kj kk js kl km kn ko kp kq kr ks kt ku kv kw kx ky ih gj">ARM Templates</h3>
The ARM template example is much more lengthy and verbose, highlighting the issues with ARM templates that Bicep aims to resolve.

[parameters('storageAccountName')]

[format('{0}/default/{1}', parameters('storageAccountName'), parameters('containerName'))]

<h3 id="2d17" class="pw-post-body-paragraph kd ke io kf b kg kh jp ki kj kk js kl km kn ko kp kq kr ks kt ku kv kw kx ky ih gj">Bicep</h3>
The Bicep example is much more concise are easier to read than the ARM equivalent, although not quite as short as the Terraform.

The Bicep playground is a great resource that allows you to <a href="https://docs.microsoft.com/en-us/azure/azure-resource-manager/bicep/compare-template-syntax/?WT.mc_id=modinfra-57552-apedward" target="_blank" rel="nofollow noopener">directly compare</a> ARM templates and Bicep configuration files. Use the ‘Sample Template’ button to select a template to compare side-by-side. You will notice that Bicep files are always shorter, remove the ARM boilerplating, and as a result are easier to use.

<a href="https://spacelift.io/blog/devops-automation-tools" target="_blank" rel="noopener">Automating your Infrastructure</a> using IaC can pay dividends, enabling your team to deliver more and be more agile, saving you time and money.
Selecting the correct IaC tooling for your team can be a daunting task as there are plenty of options available. Comparing the pros and cons of each, along with an evaluation of your requirements and available skill sets in your team, should give you a good starting point.
If you are just starting out with IaC, I would personally recommend looking at Terraform first as it is a highly sought-after skill in the industry today, and is the prevalent IaC tool. There are lots of learning materials available on the web and the community support is great.

<span data-sheets-value="{&quot;1&quot;:2,&quot;2&quot;:&quot;Spacelift allows you to automate, audit, secure, and continuously deliver your infrastructure. It helps overcome common state management issues and adds several must-have features for infrastructure management.&quot;}" data-sheets-userformat="{&quot;2&quot;:769,&quot;3&quot;:{&quot;1&quot;:0},&quot;11&quot;:4,&quot;12&quot;:0}">Spacelift allows you to automate, audit, secure, and continuously deliver your infrastructure. It helps overcome common state management issues and adds several must-have features for infrastructure management.

How Spacelift Can Improve Your Infrastructure as Code

5 Ways to Manage Terraform at Scale - Best Practices

What is Multi-Cloud Infrastructure? Benefits, Best Practices

Infrastructure as Code (IaC) isn’t a new notion, but it still causes confusion. In this article, you’ll learn what IaC is, its benefits, best practices and code examples.

6-infrastructure-as-code

Infrastructure as Code : Best Practices, Benefits & Examples

Want to level up your Terraform knowledge? Explore our tutorials and step-by-step guides written by Terraform experts. Learn Terraform best practices and solutions to the most difficult problems.

Terraform Guides and Tutorials | Spacelift Blog

Terraform

Tianchen Wu

Terraform is a well-known IaC tool from Hashicorp. Terragrunt is a thin wrapper of Terraform that provides extra tools for keeping your configurations DRY, working with multiple Terraform modules, and managing remote states. It is an open source project from Gruntwork, co-founded by Yevgeniy Brikman, author of Terraform up and running.
This article discusses common patterns in <a href="https://spacelift.io/blog/infrastructure-as-code" target="_blank" rel="noopener">Infrastructure as Code (IaC)</a> based on Terraform and Terragrunt examples and summarizes and highlights the design principle underlying good architecture.
We will present these patterns in an abstract way. Although the examples presented in this article use Terraform and Terragrunt, the main concepts apply to other popular IaC tools and platforms like Pulumi, AWS CDK, CloudFormation, Terraform Cloud, <a href="https://spacelift.io/blog/alternative-to-atlantis" target="_blank" rel="noopener">Atlantis</a>, Spacelift, and <a href="https://spacelift.io/terraform-cloud-alternative" target="_blank" rel="noopener">Terraform Cloud alternatives</a>.
To put it simply, “managing collections of infrastructure resources” is an abstract concept. The technologies used to implement this concept include:
<ul>
<li style="font-weight: 400;" aria-level="1"><a href="https://www.terraform.io/docs/cloud/workspaces/index.html" target="_blank" rel="nofollow noopener">Terraform workspace</a></li>
<li style="font-weight: 400;" aria-level="1"><a href="https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/stacks.html" target="_blank" rel="nofollow noopener">Cloudformation (nested) stack</a></li>
</ul>
Git branch (allows you to create two branches, one called workspace_1, the other workspace_2, then relate remote state to each of the branches, which is actually a neat trick.)

In short, to utilize IaC is to describe your infrastructure with code. Coding infrastructure in HCL (<a href="https://github.com/hashicorp/hcl" target="_blank" rel="nofollow noopener">Hashicorp Configuration Language</a>) with Terraform is just like coding with any other programming language, like Python or Java. Programming technologies such as linter, IDE, unittest, documentation, and CICD, are all applicable to IaC. Additionally, a project layout is crucial to defining a structure to organize your code, dependencies, configuration files, etc.
One common pattern of the project layout for IaC is much like the following:

image1-3

common pattern of the project layout for IaC

The basic principle is to:
<ul>
<li style="font-weight: 400;" aria-level="1">Separate the process of IaC into two phases: development and deployment.</li>
<li style="font-weight: 400;" aria-level="1">Separate the deployment environments into prod, qa, and stage, for example.</li>
<li style="font-weight: 400;" aria-level="1">Separate the cloud architecture into components according to projects, types of infrastructure, etc. Each component can be stored in a single “gigantic” repository or multiple “micro” repositories (see Pattern: Mono-repo vs Multi-repo).</li>
</ul>

The process of IaC usually consists of two phases: development and deployment (if you are interested in this topic, the <a href="https://www.weave.works/technologies/gitops/" target="_blank" rel="noopener">GitOps and weaveworks articles</a> are good sources of information).
In the development phase, one writes code to describe and configure the desired infrastructure. In the deployment phase, the written infrastructure code is applied.
The advantages of separation:
<ul>
<li style="font-weight: 400;" aria-level="1">Separation of Concern: developers who write IaC do not need to know the details of the deployment, and can work or test on a new version of the code without influencing the actual deployed infrastructure.</li>
<li style="font-weight: 400;" aria-level="1">Flexibility: a well-designed IaC codebase is modularized and parameterized. The same code snippet can be reused and deployed under different use cases in different environments with customized parameters.</li>
</ul>

<ul>
<li><a href="https://spacelift.io/blog/terraform-in-ci-cd" target="_blank" rel="noopener"><span data-sheets-value="{&quot;1&quot;:2,&quot;2&quot;:&quot;How to Deploy your Infrastructure in CI/CD using Terraform&quot;}" data-sheets-userformat="{&quot;2&quot;:513,&quot;3&quot;:{&quot;1&quot;:0},&quot;12&quot;:0}">How to Deploy your Infrastructure in CI/CD using Terraform</a></li>
<li><a href="https://spacelift.io/blog/5-ways-to-manage-terraform-at-scale" target="_blank" rel="noopener"><span data-sheets-value="{&quot;1&quot;:2,&quot;2&quot;:&quot;Managing Terraform at Scale - Best Practices&quot;}" data-sheets-userformat="{&quot;2&quot;:513,&quot;3&quot;:{&quot;1&quot;:0},&quot;12&quot;:0}">Managing Terraform at Scale – Best Practices</a></li>
<li><a href="https://spacelift.io/blog/how-specialized-solution-can-improve-your-iac" target="_blank" rel="noopener"><span data-sheets-value="{&quot;1&quot;:2,&quot;2&quot;:&quot;How to Improve Your Infrastructure as Code using Terraform&quot;}" data-sheets-userformat="{&quot;2&quot;:513,&quot;3&quot;:{&quot;1&quot;:0},&quot;12&quot;:0}">How to Improve Your Infrastructure as Code using Terraform</a></li>
</ul>

Imagine you have an AWS cloud architecture for web services, including different AWS services like ECS, RDS, S3, IAM, SSM, Secret Manager, Cloudwatch, Cloudfront and so on. One option is to pack all of the components into a single Terraform remote state (main.tf). This is fine for quick and dirty prototyping, but not recommended for production.
Always cut your cloud architecture into meaningful components such as:
<ul>
<li style="font-weight: 400;" aria-level="1">Stateful components like database, filesystem, or S3.</li>
<li style="font-weight: 400;" aria-level="1">Stateless components like lambda, ECS, or API Gateway.</li>
</ul>
You can also cut it based on projects or functional areas (e.g. frontend, backend, data warehouse).
The advantages of separation:
<ol>
<li style="font-weight: 400;" aria-level="1">Avoids scanning the whole architecture if a change needs to be made only locally to one resource. One can enter the component folder which includes that resource, make changes there, and apply them. Scanning a fat cloud account can be time consuming on a large amount of cloud resources, even causing unnecessary API throttling.</li>
<li style="font-weight: 400;" aria-level="1">Avoids unnecessary touches on databases or other crucial infrastructure to prevent accidental destructive operations.</li>
<li style="font-weight: 400;" aria-level="1">Increases readability of the IaC.</li>
</ol>
Translate the above described project layout into folder structure:

image3-3

folder structure

The separation of the development and deployment process is implemented with two git repositories &#8211; env/ and modules/. Notice the .git in the folder. Here, Terragrunt.hcl is simply a configuration file for modules specifically in the language of Terragrunt. The separation of cloud architecture components is implemented with subfolders app/ , mysql/, vpc/. The separation of deployment environments is implemented with subfolders prod/ , qa/ , stage/.

One of the principles of software engineering is DRY (don’t repeat yourself). The same applies to IaC. There are at least two kinds of tricks you can use to DRY IaC:
<ul>
<li style="font-weight: 400;" aria-level="1">Modularization</li>
<li style="font-weight: 400;" aria-level="1">Configuration inheritance</li>
</ul>
<h2>1) Modularization</h2>
A <a href="https://spacelift.io/blog/what-are-terraform-modules-and-how-do-they-work" target="_blank" rel="noopener">Terraform module</a> is a way of creating a template of a cloud pattern, parameterizing, and reusing it. Like any other artifacts, modules can be stored and versioned in the registry. The official Terraform module registry is <a href="https://registry.terraform.io/" target="_blank" rel="nofollow noopener">https://registry.Terraform.io/</a>. You can also build your own private registry.
<h2></h2>

image2-3

AWS security group

<h2>2) Configuration Inheritance</h2>
<a href="https://terragrunt.gruntwork.io/docs/reference/config-blocks-and-attributes/#include" target="_blank" rel="nofollow noopener">Configuration inheritance</a> is a feature supported by Terragrunt. The concept is similar to class inheritance in object oriented programming, except that configuration inheritance serves the purpose of configuration reusability.
In the following example (also see the project layout above), we have a configuration file at the global level (global_vars.yaml) and configuration files at the environment level (environment_specific_vars.yaml). 
In global_vars.yaml, variables like account_id, region_name and repository_url can be defined, and in environment_specific_vars, these global variables will be inherited and present, additionally defining new environment level variables like vpc_id (usually we use separate vpc for different environments), environment_name, etc.

image4-3

Configuration Inheritance

In summary, configuration inheritance increases the reusability of configuration files and reduces the difficulty in maintenance.
Also, by running your <a href="https://spacelift.io/blog/terragrunt-with-spacelift" target="_blank" rel="noopener">Terragrunt commands on Spacelift</a>, you can extend the powers of Terragrunt with other features such as Spacelift <a href="https://docs.spacelift.io/concepts/configuration/context" target="_blank" rel="noopener">Contexts</a> and <a href="https://docs.spacelift.io/concepts/policy/" target="_blank" rel="noopener">Policies</a>.
With Spacelift Contexts, you can define a collection of variables and files and then attach these to Spacelift stack(s). Spacelift Policies allow you to build rules using the <a href="https://spacelift.io/blog/what-is-open-policy-agent-and-how-it-works" target="_blank" rel="noopener">Open Policy Agent (OPA)</a> to govern your infrastructure as code and its automation. For example, you may want to disallow a specific resource type or even a certain way of configuring that resource type – you can easily achieve such a thing using a <a href="https://docs.spacelift.io/concepts/policy/terraform-plan-policy" target="_blank" rel="noopener">Plan Policy</a>. You can also use <a href="https://spacelift.io" target="_blank" rel="noopener">Spacelift</a> to mix and match Terraform, Pulumi, and CloudFormation Stacks and have them talk to one another.

Last but not least, let’s review the concept of mono-repo and multi-repo. It has been pointed out by Hashicorp as a <a href="https://www.hashicorp.com/blog/terraform-mono-repo-vs-multi-repo-the-great-debate" target="_blank" rel="nofollow noopener">major architectural decision for IaC projects</a>, a view I share.
The problem is, there are two ways to organize code. In simple terms, mono-repo stores all code into one git repository (for example with multiple subfolders), whereas multi-repo separates them into multiple repositories.
Analogously, the relationship between mono-repo and multi-repo can be compared to monolith software architecture and microservice architecture. Mono-repo is intended to perceive the architecture as a whole and as evolving together. It is usually more suitable for small projects or big projects in prototyping. Multi-repo, on the other hand, facilitates collaboration but with extra overhead. Naturally, the more repos you have, the higher the maintenance cost, but also the more autonomous and self-service each repository is.

In this article, we reviewed several patterns of IaC architecture in a technology-agnostic way. The examples given are based on <a href="https://spacelift.io/blog/what-is-terraform" target="_blank" rel="noopener">Terraform</a> and Terragrunt, since they are the most popular open source tools on the market at the moment. The idea, however, is to look at different technologies like <a href="https://spacelift.io/blog/what-is-pulumi">Pulumi</a>, AWS CDK, Cloudformation, etc., where the same patterns keep appearing in slight variations.
We rooted the principles of IaC architecture design in software engineering concepts like inheritance, DRY, project layout, parameterization, and so on. Afterall, Infrastructure as Code is coding infrastructure, and recognizing common patterns is the recommended way to learn and apply IaC.

Spacelift is a sophisticated SaaS product for Infrastructure as Code that helps DevOps develop and deploy new infrastructures or changes quickly and with confidence.

Whenever you're embarking on a new journey or seeking to refine your foundational knowledge.

frame-8479

Frame 8479

What Are Terraform Modules and How to Use Them: Tutorial

See common patterns of Infrastructure as Code architecture in Terraform and Terragrunt. Learn the differences between common patterns of IaC.

42-terraform-and-terragrunt

Patterns of infrastructure as code

Patterns of Infrastructure as Code : Terraform & Terragrunt

What does infrastructure as code look like when you are supporting multiple cloud providers?

Kyle Galbraith

In this post, we will dig into the Multi-Cloud infrastructure world. What does it look like when I want to provide my technology in more than one cloud provider? What does it mean when I need to provision and manage production infrastructure in more than one cloud provider?

Multi-Cloud Infrastructure is a term used to describe a data center environment that uses multiple cloud computing services. A multi-cloud setup can increase flexibility and redundancy and improve disaster recovery capabilities.
There is the classic, avoiding vendor lock-in. If you are a retail business running your infrastructure in AWS, you may want a plan for how to replicate that infrastructure to GCP or Azure. So if Amazon decides to eat into your space you can switch to a different cloud provider that isn’t a competitor. 
Or there is the more expensive, less likely, and a bit out there reasoning. AWS goes down. Like, completely offline kind of down. Think the recent Facebook outage kind of a down. In this scenario, you want a “hot-hot” failover to another cloud meaning your entire infrastructure is not only replicated in another provider, but it can be ready to accept traffic at a moment’s notice. A very, very, very hard problem to solve. Not to mention very expensive.
That said, there are reasons and use cases between these two extremes. A simple one is you want to offer your technology to clients that only use one cloud or another. Customers want to use your technology, via your platform as a service (PaaS). But they want to be able to say, “provision your technology in this specific cloud provider”.
This is a very real use case that bleeds into the multi-cloud conversation. When multi-cloud is thrown around, the first two use cases are often thought of. But this third use case is actually much more likely. With the right tools and processes, it&#8217;s also a lot more practical. 
In this post, we will dig into this world. What does it look like when I want to provide my technology in more than one cloud provider? What does it mean when I need to provision and manage production infrastructure in more than one cloud provider?

It depends on the problem you are in the business of solving. If a major cloud provider dipping their toes into your industry is a major threat, maybe it makes sense. Or if complete fault tolerance is necessary for your business, replicating your infrastructure in a “hot-hot” fashion to multiple cloud providers might be of interest to you.
It all comes down to your business, the product you are offering, and the expectations of your users. Those three factors will play into whether multi-cloud is of importance or not.
But, at a high level, what are the real advantages and disadvantages of multi-cloud?

<h3>1. Support different use cases and customer demands.</h3>
Customers like to have choices. Not so many choices that it&#8217;s overwhelming, but enough to feel flexibility. This is very prevalent if you are building any kind of platform or platform as a service offering. Your users will eventually ask if you can run your technology in AWS, GCP, or Azure. 
Why? Maybe they view Amazon as a competitor and want to avoid directly or indirectly giving money to their competition via AWS. Perhaps they have credits in GCP that would make using your technology over there more cost-effective. It’s possible their entire engineering team is only familiar with Azure. So they don’t want to introduce a learning curve by adding another provider.
So, if you provide your technology in more than one cloud provider, you can solve these problems for your customer.
<h3>2. Cloud providers iterate rapidly.</h3>
Cloud providers are in constant competition with one another. They are in a steady state of developing new services and offerings. They are in the business of helping customers (you) in solving your problems more efficiently. Competition is good for you, a multi-cloud thinker.
You can iterate on your own product or offering to leverage the latest cloud development that improves your services. With multi-cloud, you leverage that development in whatever cloud provider introduces it first. Are you going to be able to introduce that new feature or performance boost in all cloud providers? No, but one out of three isn’t bad until the other providers catch up.

<ul>
<li><a href="https://spacelift.io/blog/ci-cd-tools" target="_blank" rel="noopener"><span data-sheets-value="{&quot;1&quot;:2,&quot;2&quot;:&quot;Top Most Useful CI/CD Tools for 2023&quot;}" data-sheets-userformat="{&quot;2&quot;:4737,&quot;3&quot;:{&quot;1&quot;:0},&quot;10&quot;:2,&quot;12&quot;:0,&quot;15&quot;:&quot;Arial&quot;}">Top Most Useful CI/CD Tools for 2023</a></li>
<li><a href="https://spacelift.io/blog/drift-detection" target="_blank" rel="noopener">Fixing Infrastructure Drift with IaC Tools</a></li>
<li><a href="https://spacelift.io/blog/how-specialized-solution-can-improve-your-iac" target="_blank" rel="noopener"><span data-sheets-value="{&quot;1&quot;:2,&quot;2&quot;:&quot;10 Ways to Improve Your Infrastructure as Code&quot;}" data-sheets-userformat="{&quot;2&quot;:513,&quot;3&quot;:{&quot;1&quot;:0},&quot;12&quot;:0}">10 Ways to Improve Your Infrastructure as Code</a></li>
</ul>

We now know some of the pros, cons, and common misconceptions surrounding multi-cloud infrastructure. Now it’s worth chatting about some high-level best practices. These are practices that can be leveraged to make multi-cloud possible, easier to work with, implement, or all of the above.
<h3>1. Choose the right tool and set up processes.</h3>
First, it’s all about choosing good tooling. The tools you choose to manage your infrastructure are going to make or break your multi-cloud adventure. We could even say that multi-cloud is impossible if you’re not using some kind of infrastructure as code.
It’s important to choose an IaC tool that supports multi-cloud. If you are all in on AWS and you represent all your infrastructure in <a href="https://spacelift.io/blog/terraform-vs-cloudformation" target="_blank" rel="noopener">Cloudformation</a>, you are going to have a very difficult transition to multi-cloud. So, choosing the right tools that keep the door open to multi-cloud is critical.
Beyond choosing good tools, you need processes that make them required. This means if you represent all infrastructure as code, do not allow for manual creation or modification. Developers shouldn’t be able to create or change infrastructure in the console. Changes made by hand cause anomalies in your production environment. Anomalies that are not represented in code.
<h3>2. Modularize the core components in IaC.</h3>
Second, modularize the core components of your architecture in your IaC. Say your technology runs in a Kubernetes cluster provided by AWS. You configure `cert-manager` to be deployed to that cluster so you can do SSL/TLS to deployments. With Terraform, you should have a module that represents all the resources for the Kubernetes cluster. Then a second module for `cert-manager` that gets installed into the cluster.  
If you have a clear <a href="https://docs.spacelift.io/vendors/terraform/module-registry#modules-in-practice" target="_blank" rel="noopener">module system in your IaC</a>, multi-cloud becomes a bit easier. Why? Because you know what modules need to be recreated to support another cloud provider. When you want to run this workload in GCP, you need to create an equivalent Kubernetes module. But you should be able to plug in the `cert-manager` module with no need to rework it, as it just needs a Kubernetes cluster.
<h3>3. Make architecture decisions that facilitate multi-cloud.</h3>
Finally, make architecture decisions that facilitate multi-cloud. This is rather obvious when you stop and think about it, but it is often overlooked. If your architecture relies on a specific service in a specific cloud provider that operates in a particular way, it may not be possible to use another cloud provider.
The core cloud providers all have similar services. For example, AWS has Lambda, GCP has Cloud Functions, and Azure has Azure Functions. So if your architecture needs some function as a service offering, you should be alright, at a high level. You may need specific features or performance from a given cloud provider service. These are not always similar and can even be very different.
So, as a best practice you should aim to make your architectures as generic as possible. This makes it easier to port them across providers. Containerization is a great tool to think about that can make this possible.

Here are some good tools and processes for supporting infrastructure in multiple clouds.
<ol>
<li>Terraform, Pulumi, etc for declaring your multi-cloud infrastructure in code. Choosing a cloud provider-specific tool is still better than no IaC tool, but it doesn’t facilitate multi-cloud. Read more: <a href="https://spacelift.io/blog/what-is-terraform" target="_blank" rel="noopener">What is Terraform</a></li>
<li>Continuous integration and deployment for your IaC. <a href="https://spacelift.io/blog/how-specialized-solution-can-improve-your-iac" target="_blank" rel="noopener">Spacelift</a> is a fantastic tool for this. It allows you to automate, audit, secure, and continuously deliver your infrastructure.</li>
<li>Containers provide a cross-cloud packaging and deployment mechanism. You can use <a href="https://www.docker.com/" target="_blank" rel="nofollow noopener">Docker</a> or one of the other many tools out there for building containers like `buildah` or `podman`. Containers unlock the ability to have a single way to package your application and deploy it to any given cloud provider.</li>
<li><a href="https://www.okta.com/" target="_blank" rel="nofollow noopener">Okta</a> or some kind of central identity solution. No one should be able to access cloud provider consoles via logins. Instead, it&#8217;s better if they come in through some kind of SSO provider like Okta. This makes it easier to map your developers to roles or authentication mechanisms in different cloud providers.</li>
</ol>

Multi-cloud is not a small project. It requires careful planning, and a lot of such planning from the beginning of your product or technology. If multi-cloud is something you hope to tack on two years down the road, it likely won’t work.
It requires avoiding architectures, tools, and processes that lock you into a specific cloud provider. So if multi-cloud infrastructure is something you may need in the future, keep it in mind when you make decisions around all these things.
To make the process easier, you can consider using <a href="https://spacelift.io" target="_blank" rel="noopener">Spacelift</a>. It works with cloud-agnostic IaC technologies like Terraform and Pulumi, as well as cloud-specific IaC features like AWS CloudFormation and Azure ARM templates. No matter which IaC technology is used, Spacelift provides a common interface to manage the automated provisioning of multiple stacks in multiple cloud platforms

Spacelift allows you to automate, audit, secure, and continuously deliver your infrastructure.  It helps overcome common state management issues and adds several must-have features for infrastructure management.

Business Benefits of Infrastructure as Code

What is multi-cloud infrastructure? See best practices, advantages, and misconceptions. Learn what tools to use for infrastructure in multiple clouds.

27-multi-cloud-strategies

Peter Christensen

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, <a href="https://spacelift.io/blog/how-specialized-solution-can-improve-your-iac" target="_blank" rel="noopener">specialized management platform for infrastructure as code</a>. 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. Spacelift has raised a total of $22.6M in funding from Insight Partners, Blossom Capital, Hoxton Ventures, Inovo Venture Partners, and the founders of Supercell and Yelp.
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.

<ul>
<li><a href="https://spacelift.io/blog/why-devops-engineers-recommend-spacelift" target="_blank" rel="noopener">Why DevOps Engineers Recommend Spacelift</a></li>
<li><a href="https://spacelift.io/blog/infrastructure-problems-that-spacelift-solves" target="_blank" rel="noopener"><span data-sheets-value="{&quot;1&quot;:2,&quot;2&quot;:&quot;Infrastructure Problems that Spacelift Solves&quot;}" data-sheets-userformat="{&quot;2&quot;:4224,&quot;10&quot;:2,&quot;15&quot;:&quot;Arial&quot;}">Infrastructure Problems that Spacelift Solves</a></li>
<li><a href="https://spacelift.io/blog/alternative-to-atlantis" target="_blank" rel="noopener">Alternative to Atlantis – Spacelift</a></li>
</ul>

Infrastructure Drift Detection and How to Fix It With IaC Tools

$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

Peter is Head of Product Marketing at Spacelift. He brings over 20 experience in product marketing, having launched a
number of products ranging from complex network protocols to developer tools.

Why should business care about infrastructure as code

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 <a href="https://spacelift.io/blog/infrastructure-as-code#infrastructure-as-code-tooling" target="_blank" rel="noopener">IaC tools</a>. 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 <a href="https://spacelift.io/blog/infrastructure-as-code#benefits-of-infrastructure-as-code" target="_blank" rel="noopener">why IaC is important</a>. 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.

<ul>
<li><a href="https://spacelift.io/blog/infrastructure-problems-that-spacelift-solves" target="_blank" rel="noopener"><span data-sheets-value="{&quot;1&quot;:2,&quot;2&quot;:&quot;Common Infrastructure Challenges and How to Solve Them&quot;}" data-sheets-userformat="{&quot;2&quot;:513,&quot;3&quot;:{&quot;1&quot;:0},&quot;12&quot;:0}">Common Infrastructure Challenges and How to Solve Them</a></li>
<li><a href="https://spacelift.io/blog/drift-detection" target="_blank" rel="noopener"><span data-sheets-value="{&quot;1&quot;:2,&quot;2&quot;:&quot;Infrastructure Drift Detection and How to Fix It With IaC Tools&quot;}" data-sheets-userformat="{&quot;2&quot;:513,&quot;3&quot;:{&quot;1&quot;:0},&quot;12&quot;:0}">Infrastructure Drift Detection and How to Fix It With IaC Tools</a></li>
<li><a href="https://spacelift.io/blog/how-specialized-solution-can-improve-your-iac" target="_blank" rel="noopener"><span data-sheets-value="{&quot;1&quot;:2,&quot;2&quot;:&quot;10 Ways to Improve Your Infrastructure as Code&quot;}" data-sheets-userformat="{&quot;2&quot;:513,&quot;3&quot;:{&quot;1&quot;:0},&quot;12&quot;:0}">10 Ways to Improve Your Infrastructure as Code</a></li>
</ul>

<a href="https://spacelift.io/" target="_blank" rel="noopener">Spacelift</a> is a platform to manage infrastructure provisioning workflows which also eases the developer experience to a vast extent. <span data-sheets-value="{&quot;1&quot;:2,&quot;2&quot;:&quot;Spacelift allows you to automate, audit, secure, and continuously deliver your infrastructure. It helps overcome common state management issues and adds several must-have features for infrastructure management.&quot;}" data-sheets-userformat="{&quot;2&quot;:769,&quot;3&quot;:{&quot;1&quot;:0},&quot;11&quot;:4,&quot;12&quot;:0}">It allows you to automate, audit, secure, and continuously deliver your infrastructure. It helps overcome common state management issues and adds several must-have features for infrastructure management.
It is a very powerful platform as it works with cloud-agnostic IaC technologies like Terraform and Pulumi, as well as cloud-specific IaC features like AWS CloudFormation and Azure ARM templates. No matter which IaC technology is used, Spacelift provides a common interface to manage the automated provisioning of multiple stacks in multiple cloud platforms.

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.

Spacelift is a flexible orchestration solution for IaC development. It delivers enhanced collaboration, automation and controls to simplify and accelerate the provisioning of cloud based infrastructures.

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. 

Who Is DevOps? Is Becoming a DevOps Engineer Worth It?

Get the newsletter

Recent posts

Infrastructure as Code : Best Practices, Benefits & Examples

Common Patterns of Infrastructure as Code Architecture: Terraform & Terragrunt

What is Multi-Cloud Infrastructure? Benefits, Best Practices

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

Business Benefits of Infrastructure as Code