Ernesto Garbarino is Enterprise Architect, Cloud Evangelist and Account CTO at Mphasis, a Blackstone company. Mr. Garbarino holds an MSc in Software Engineering from University of Oxford with Distinction as well as two diplomas in Computing from the same institution. He is also the author of “Beginning Kubernetes on the Google Cloud Platform”, published by Apress.

Ernesto Garbarino

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

Infrastructure as Code (IaC) isn’t a new notion, but it still causes confusion today. While most large enterprises are in the process of adopting IaC, as they move their workloads to the cloud, only a few have managed to implement it effectively.
IaC has evolved significantly from its early beginnings, when the infrastructure surface was only the operating system, and &#8220;Puppet vs Chef&#8221; was a common debate. Today, operating systems often constitute a legacy abstraction, superseded by containers, Function as a Service (FaaS)-based applications, and sophisticated managed services.
In this article, you’ll learn about the state of the art in IaC and DevOps today, and the factors you must take into account for a successful implementation.

Infrastructure as Code (IaC) is the ability to define all aspects of a virtualized infrastructure using code instead of a configuration management tool for operating systems. Virtualized infrastructure handles foundational primitives like compute, storage, and network resources. But it also increasingly offers advanced services like API gateways and managed databases.

IaC started initially as a means to reduce the time system administrators spend on servers. But in a world where servers have moved to the cloud, the role of IaC goes beyond increased productivity via automation. IaC is used more and more to ensure the integrity of an infrastructure, its security, and the traceability of its changes.
Moreover, IaC solves the very real problem of environment drift within the release pipeline. Teams that don’t use IaC have to devote labor hours regularly to maintaining multiple deployment environments.

Infrastructure as code is a time-saving tool for DevOps pros because it lets them skip the IT admin bottleneck and automate their infrastructure. This creates a fast, consistent infrastructure for every project. This makes life easier for DevOps by streamlining the software development life cycle (<a href="https://www.vtc1.org/cms/lib/PA03000913/Centricity/Domain/17/SDLC%202.pdf" target="_blank" rel="noopener">SLDC</a>).
In DevOps, there’s no separation of church and state between writing code and deploying it. Ops tasks are meant to be expressed as code, rather than carried out manually. An example would be the automatic deployment of code that’s been checked into a source code management system such as Git.
DevOps teams can use IaC to create and test applications in production-like infrastructures early on in the SLDC. They can provision as many reliable environments as needed, effectively preventing common deployment issues. With manual configuration out of the picture, efficiency becomes the norm, and configuration drift a thing of the past.

One basic IaC use case involves the financial system. Imagine that you work for an international bank that operates across multiple world jurisdictions, with varying data sovereignty rules. 
IaC can help you create a single infrastructure definition common for the entire bank holding. Yet this definition is instantiated in different regions — say, Canada and Germany. It ensures compliance without a duplication of technical efforts.

IaC provides a uniform, repeatable specification for an infrastructure. Why repeatable? Because with IaC, you can be sure of obtaining the same infrastructure every time. Evolving and maintaining an infrastructure that’s defined as code is more effective than maintaining it manually.
With IaC, you can track changes, compare versions, ensure security, and enforce policies.
Here are the main benefits of IaC:
<ul>
<li style="font-weight: 400;" aria-level="1">Speed: Companies that use IaC spend less time on manual processes, getting more done in less time. Iteration is faster without the bottleneck of waiting for an IT admin to complete manual tasks.</li>
<li style="font-weight: 400;" aria-level="1">Consistency: With IaC, every step of the process is managed and completed automatically, eliminating human error, sick days, weekends, or PTO. Changes are implemented globally and swiftly, freeing up development teams to add value.</li>
<li style="font-weight: 400;" aria-level="1">A more efficient software development lifecycle: IaC makes it easier for developers to do real work. With a more consistent path to provisioning infrastructure, they can save time and focus on non-repetitive, higher-order tasks.</li>
<li style="font-weight: 400;" aria-level="1">Less overhead: Without the need to manage networking, storage, and other systems, admins can focus on streamlining the process and supporting the development team.</li>
</ul>
Infrastructure as Code is beneficial not only for developers but also for Product Managers and business people. You can learn more about it in our blog post on <a href="https://spacelift.io/blog/business-benefits-of-iac" target="_blank" rel="noopener">Business Benefits of Infrastructure as Code.</a>

While IaC has the potential to solve all the demands listed above, it comes at the expense of complexity. That doesn’t necessarily mean the nature (or amount) of code in the infrastructure itself. Instead, it means writing, maintaining, submitting, validating, applying and controlling the effects of IaC definitions.
The main disadvantages of infrastructure as code are:
<ul>
<li style="font-weight: 400;" aria-level="1">Dependency on coding: With IaC, IT admins are no longer front-and&#8211;center during infrastructure management. This puts developers in the limelight. A shortage of coding language skills in your company can put a crimp in IaC implementation.</li>
<li style="font-weight: 400;" aria-level="1">Monitoring issues: Though IaC makes monitoring easier, the monitoring itself can require the use of additional tools. Old monitoring tools won’t always carry forward into an IaC environment.</li>
<li style="font-weight: 400;" aria-level="1">Legacy security may need updating: Existing security processes and tools might not translate to an IaC environment. Before transitioning to IaC, it’s vital to assess and update legacy security tools and systems.</li>
</ul>
A flexible IaC management platform like Spacelift addresses all those challenges automatically, allowing workflow customization, automation, security, and monitoring, all from one convenient platform.

The below code snippet, written using Terraform&#8217;s HCL language, lets you set up a DynamoDB table in AWS:

That (very simple) IaC example doesn’t just provision the DynamoDB &#8220;resource.” It also creates a table, using user_id as the hash key. Though it’s basic, it illustrates how overarching IaC is in scope today, and the extent a modern virtualized (in most cases cloud) infrastructure can be codified.
On a grander scale, other IaC examples include:
<ul>
<li style="font-weight: 400;" aria-level="1">Automating the configuration and deployment of applications and resources in the cloud</li>
<li style="font-weight: 400;" aria-level="1">Creating cloud-agnostic templates for cloud resources</li>
<li style="font-weight: 400;" aria-level="1">Deploying security policies for virtual networks</li>
<li style="font-weight: 400;" aria-level="1">Automatically updating applications</li>
</ul>

Broadly speaking, the minimum IaC framework you’ll need to manage infrastructure as code consists of a source code management system (SCM) tool, at least one infrastructure definition tool, a number of security and quality tools, and a CI/CD pipeline to string the first three together.

Trying to implement an infrastructure as code system from scratch is problematic, not to mention costly and time consuming. Most organizations today leverage useful infrastructure as code tools to ensure a smooth, efficient process. The most common tools for each of the four aforementioned categories are as follows:
<ul>
<li style="font-weight: 400;" aria-level="1">SCM: GitHub, GitLab, and Atlassian Bitbucket (All &#8220;Git&#8221; implementations)</li>
<li style="font-weight: 400;" aria-level="1">Infrastructure Definition: Terraform and Pulumi are the most popular general-purpose multi-cloud tools in this space. Ansible is also often used in tandem, for operating system-centric edge cases. </li>
<li style="font-weight: 400;" aria-level="1">Security and Quality Tools: There’s a vast ecosystem of IaC security and quality tools on offer. Qualys and Checkmarx, are examples of tools that can detect the inclusion of vulnerable operating system packages.</li>
<li style="font-weight: 400;" aria-level="1">CI/CD Tools: Traditional general-purpose CI/CD tools are often subdivided into pure continuous integration tools like Jenkins, deployment-oriented tools like Spinnaker, and &#8220;one stop shop&#8221; CI/CD tools like GitLab.</li>
</ul>
While you can use general-purpose CI/CD tools for IaC, they have limitations. (Managing the commonly-used tools of IaC itself eats up massive resources of both budget regular developer time.) Specialized IaC management tools like <a href="https://spacelift.io/blog/how-specialized-solution-can-improve-your-iac" target="_blank" rel="noopener">Spacelift</a> overcome those limitations automatically.
To manage IaC smoothly, follow the best practices below.

A sound IaC strategy involves using the following best practices:
<ul>
<li style="font-weight: 400;" aria-level="1">Use a source code management system: Establish a code workflow strategy including review, verification, and approval procedures.</li>
<li style="font-weight: 400;" aria-level="1">Write code rather than documentation: Define your infrastructure definitions and tasks (backups, disaster recovery, etc.) using code rather than by writing documentation, lists of steps, or runbooks.</li>
<li style="font-weight: 400;" aria-level="1">Optimize your DevOps process for IaC: Include checks to prevent insecure, or non-compliant infrastructure definitions from being deployed. </li>
<li style="font-weight: 400;" aria-level="1">Make integrity your first goal: Make your infrastructure immutable and set up an automatic mechanism to detect state drift.</li>
<li style="font-weight: 400;" aria-level="1">Modularize and scale your infrastructure: Arrange your code base so it can be delegated and managed by different team members using a privilege-based access control system.</li>
</ul>
Increasingly, IaC tools like Spacelift automate the IaC best practices above, baking them into the platform from day one.

Terraform provides a single language (HCL) that can describe infrastructure for every major public and private cloud platform. But its key differentiating feature is that it uses a declarative approach, rather than an imperative one. 
In Terraform, you define the desired &#8220;end&#8221; state for a given infrastructure, as opposed to the steps required to achieve that state.
<h3>Declarative Definitions</h3>
Effective IaC isn’t just about replacing manual steps with code. All virtualized platforms have a command line interface (for example, the ‘aws’ command in AWS or the ‘az’ command in Azure) that can be used in a script for automation purposes.
The advantage of Terraform&#8217;s declarative approach is that it abstracts away from the specific number and order of steps needed to achieve an infrastructure. 
This doesn’t just create more clarity from a specification point of view. It also helps you reason about deltas between past, present, future, and tentative versions of an infrastructure architecture. This approach lets you identify unintended changes produced by parallel changes or external actors. In short, it prevents “state drift.”

IaaS (Infrastructure as a Service) was initially synonymous with cloud services. Over time, the term became more specific, as other &#8220;as a service&#8221; acronyms emerged. For example, &#8220;Platform as a Service&#8221; (<a href="https://www.comptia.org/content/articles/what-is-paas" target="_blank" rel="noopener">PaaS</a>). 
Presently, IaaS refers to the provision of managed foundational resources (compute, storage, and networks), different from other &#8220;as a service&#8221; offerings. Modern IaC can automate all &#8220;as a service&#8221; capabilities, not just foundational resources. It’s a ruling automation that replaces IaaS and PaaS.

Take the example of the DynamoDB table definition you saw earlier in this article. Imagine you want to include an additional attribute called email, together with a global secondary index, so you can look up users by their email address. To achieve this, you would add a few extra directives as follows:

If after adding the above directives, you ask Terraform to suggest an action plan (by typing &#8220;terraform plan&#8221;), you’ll notice that Terraform will propose modifying the table in place. It simply adds the email global secondary index, as opposed to destroying and recreating the table.

Conventional CI/CD tools provide an effective framework to work around the stages (e.g., build, test, and deploy) that pertain to a software application pipeline. Yet these tools are agnostic to the specific semantics of the applications languages at hand. 
Jenkins, for example, does not directly differentiate between building a C++ application using Makefiles from, say, building a Scala application using sbt.
<h3>Integration isn’t automatic</h3>
While the general-purpose nature of conventional CI/CD tools lets you integrate IaC stages (e.g., running the &#8220;terraform apply&#8221; command), the tools treat Terraform as a blackbox, and vice versa. 
As a result, we can only achieve the definition of specific validations, conditions, and triggers that apply at the infrastructure &#8220;code&#8221; level by piping command line utilities. We’re missing a “single pane of glass&#8221; experience (where all parts of our infrastructure are integrated in a single  management console).
<h3>Obfuscated resources</h3>
Last but not least, a notable limitation in general-purpose CI/CD tooling is the lack of insight into the resources that an infrastructure code definition will create. 
For example, Jenkins can successfully show that a &#8220;Jar&#8221; artifact was created as a result of running a successful Maven build. Yet it can’t show that a &#8220;Lambda&#8221; or “s3 bucket&#8221; was created as a result of successfully running a Terraform definition.

<a href="https://docs.spacelift.io/" target="_blank" rel="noopener">Spacelift</a> is rapidly becoming the de facto tool for automating, managing, and securing IaC code bases — especially those defined using Terraform and Pulumi.
<a href="https://spacelift.io/blog/how-specialized-solution-can-improve-your-iac" target="_blank" rel="noopener">Why Spacelift vs another IaC tool?</a> Isn’t it easier to settle for &#8220;one CI/CD tool to rule them all?&#8221; It all comes down to complexity and the level of sophistication required to manage mature IaC code bases effectively. 
For a small infrastructure platform, supported by one or two engineers, any tool that offers a minimum level of automation is sufficient.
The difficulties appear when the number of projects goes beyond the remit of a single small team, and the infrastructure needs to be broken up and managed in a modular fashion, with a multi-tenant model in mind. 
Spacelift was designed from the ground up to manage IaC code bases (e.g., written in Terraform). It’s far more versatile than general-purpose command line tools such as those used to build regular application code.
The typical limitations and frustrations that apply to conventional CI/CD tooling are addressed elegantly and effectively with Spacelift:
<ul>
<li style="font-weight: 400;" aria-level="1"><a href="https://docs.spacelift.io/concepts/policy/trigger-policy" target="_blank" rel="noopener">Workflows</a> can be adapted to reflect bespoke or specific paradigms such as Gitflow, trunk-based development, and &#8220;mono repos.”</li>
<li style="font-weight: 400;" aria-level="1"><a href="https://docs.spacelift.io/concepts/policy" target="_blank" rel="noopener">Policies</a> can be defined using the Open Policy Agent (OPA) mechanism, and applied directly to the specific semantics of infrastructure code definitions.</li>
<li style="font-weight: 400;" aria-level="1"><a href="https://docs.spacelift.io/concepts/policy/login-policy" target="_blank" rel="noopener">Access control</a> can be tightly defined at various granular levels, and identity can be resolved using the enterprise&#8217;s central identity provider.</li>
<li style="font-weight: 400;" aria-level="1">All resources resulting from the application of code definitions <a href="https://docs.spacelift.io/concepts/resources" target="_blank" rel="noopener">can be visualized and verified</a> directly within the tool, without requiring access to the cloud provider&#8217;s web console.</li>
<li style="font-weight: 400;" aria-level="1">State <a href="https://docs.spacelift.io/concepts/stack/drift-detection" target="_blank" rel="noopener">drift detection</a> can be configured to run not only on-demand, preceding the application of &#8220;apply&#8221; stages, but also recurrently, to alert of changes created by external actors.</li>
<li style="font-weight: 400;" aria-level="1">As with conventional CI/CD tools, all IaC stages can be configured to run &#8220;pre&#8221; and &#8220;post&#8221; commands or scripts. </li>
</ul>
Future versions of Spacelift also plan first-class integration of <a href="https://spacelift.io/blog/ansible-vs-terraform" target="_blank" rel="noopener">Ansible</a>. While Ansible is an imperative, rather than declarative IaC tool, it will allow Spacelift to work more effectively with legacy, mutable (and thus, operating system-centric) infrastructures as well.
You can check all of the above features today, for free, by going <a href="https://spacelift.io/free-trial" target="_blank" rel="noopener">here</a> and creating a trial account.

How a Specialized Management Platform Can Improve Your IaC

5 Ways to Manage Terraform at Scale

Multi-Cloud Infrastructure: Misconceptions, Benefits, Best Practices

Infrastructure as Code (IaC) isn’t a new notion, but it still causes confusion. In this article, you’ll learn about the state of the art in IaC and DevOps today.

what-is-infrastructure-as-code

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

The term DevOps is used as a massive catchall for several different tech-job scenarios and skills. But essentially it boils down to building useful tools for your internal customers.
DevOps as a career can be rewarding in many ways. First, there’s the <a href="https://www.glassdoor.com/Salaries/devops-engineer-salary-SRCH_KO0,15.htm" target="_blank" rel="noopener">average salary of $105,000</a> to <a href="https://www.ziprecruiter.com/Salaries/What-Is-the-Average-Devops-Engineer-Salary-by-State" target="_blank" rel="noopener">$114,000</a>, spiking to over $160,000 at the top end. Then there’s the swift job growth, estimated at over 20% per decade, with over <a href="https://www.linkedin.com/jobs/devops-jobs" target="_blank" rel="nofollow noopener">118,000 openings listed on LinkedIn</a> right now.
Plus, DevOps beats the daily grind of “same old, same old,” thanks to its fast-paced, system-support setup. In this article, we share how to become a DevOps engineer — the systems administrator who just happens to be a coder that develops internal tools as well. You’ll learn about the mindset, tools, and skills you’ll need to master, and also how to get a DevOps job.
Before you start though, is DevOps the right choice for you? See our guide: <a href="https://spacelift.io/blog/who-is-devops-engineer" target="_blank" rel="noopener">Is it Worth it to Become a DevOps Engineer?</a>

DevOps is a mix of development (Dev) and operations (Ops). Beyond that, it’s all the connected tools and disciplines of both of those business areas that let an organization deliver services and software applications at high speed, so they can better serve their customers.
The Microsoft-approved definition of DevOps is “the union of people, processes and technology to continually provide value to customers.” Both definitions are open to interpretation, but DevOps centers around writing code that pulls together customers (internal and external), and business processes.
Sometimes, DevOps engineering means just “being that go-to employee” who can quickly and efficiently write code to address an engineering issue. In other words, in some organizations, DevOps is the indispensable IT employee who knows how to write effective code.

The question of how to become a DevOps engineer has a relatively straightforward answer. With that said, you’ll need to bring a few things to the table. First and most important to the DevOps career path is a passion for learning, knowledge, and logic.

DevOps engineers need to be able to read between the lines in their customers’ requirements. They also have to produce software and services that meet those requirements in a usable, testable form. Since development doesn’t happen in a vacuum, you’ll also need leadership and management skills, along with a cool head under pressure.

When most DevOps hiring managers look for a new employee, they’re more concerned with mindset than with tools. If you’ve got a tech background, you’re willing to learn, and you’re an engineer at heart, you’ve already got the basics of a DevOps career.
DevOps engineers are curious, constantly improving their skillsets, and focused on lifelong learning. So while you can build the core skillset in a few months, your main driver should be on learning, with a goal of providing massive value to your next employer.
Learn to understand systems and processes, and you have the right mindset. That mindset will help you learn how to start a career in DevOps, and more important, how to be a good DevOps engineer.

It takes about six months to become a DevOps engineer, assuming you have some basic Linux admin and networking skills, and that you apply the DevOps engineer learning path outlined below. With that said, that career won’t just happen overnight. The length of time required depends on several factors, including your mindset, your current skill level, and your career position.
With that caveat, there’s no shortage of free tools and resources you can use to help you on your journey. Some professional DevOps engineering sites even offer free or vastly reduced exams to help you grow and prove your worth.  Let’s dig into how to become a DevOps engineer, starting with the tools and skills.

To become a DevOps engineer, at the bare minimum you’ll need basic Linux admin and networking skills, plus some scripting fundamentals, along with the following DevOps skills:
<h3>1. Intermediate to advanced Linux skills</h3>
In DevOps, you’re not installing a server once and then logging in every now and then to perform a few admin tasks. You need to understand how to create highly customized Linux images from the ground up, both for VM and container use cases — unless you plan to become a Windows Server DevOps engineer.
<h3>2. Intermediate networking skills</h3>
In DevOps there’s no “network team.” All network resources are software-defined. In other words, networks are part of infrastructure as code. At a bare minimum, you’ll need a solid grasp on the OSI model, IPV4, subnetting, static and stateful firewalling, and DNS. These skills are usually included in advanced cloud certifications.
<h3>3. A commitment to at least one cloud</h3>
Clouds aren’t merely managed data centers. In order for you to automate workloads in a given cloud (AWS, Azure, GCP, etc.), you need a firm grasp of their specific semantics. You’ll need to know what resources are available, how they’re organized, and what properties they have. 
<h3>4. Infrastructure automation</h3>
Once you understand the resources (and their properties) applicable to a cloud, you’re ready to automate their creation using tools such as Terraform and Ansible.
<h3>5. SDLC, CI/CD pipelines, and scripting</h3>
In DevOps, we deliver infrastructure in a similar way to applications. So — you’ll need to be acquainted with the fundamentals of the software development life cycle (SDLC). This includes versioning strategies using source control code management systems like Git, and CI/CD pipelines such as Jenkins, and CircleCI. Advanced automation tasks may prove difficult through shell scripts alone. You’ll often require more powerful scripting using the likes of Python, Perl, or Ruby. 
<h3>6. Container technology</h3>
For legacy workloads you may automate the creation of a VM image. But for new applications you’ll be working with containers. As such, you need to know how to build your own Docker images (Linux skills required!) and deploy them using Kubernetes. FaaS technology like AWS Lambda also uses container technology behind the scenes.
<h3>7. Observability technology</h3>
While all clouds have monitoring dashboards and standard “telemetry” hooks, most large employers use third party (both commercial and open source) monitoring tools such as Prometheus, DynaTrace, Datadog, or the ELK stack.
Beyond that skills list, tool-building in DevOps requires a fundamental understanding of logic, its application, and how to apply it in a computer-recognizable form. While that may sound a tad scary for the uninitiated, there are several good books that cover programming fundamentals without using any specific language. Here are a couple of my favorites:
<ul>
<li style="font-weight: 400;" aria-level="1"><a href="https://www.amazon.com/_/dp/1449355730?tag=oreilly20-20" target="_blank" rel="nofollow noopener">Learning Python</a> (O’Reilly)</li>
<li style="font-weight: 400;" aria-level="1"><a href="https://www.amazon.com/Learn-Windows-PowerShell-Month-Lunches/dp/1617291080" target="_blank" rel="nofollow noopener">Learn Windows PowerShell in a month of lunches</a> (Jones, Hicks — A personal favourite as I love PowerShell)</li>
</ul>
Now let’s dig into the nuts and bolts of how to become a DevOps engineer — starting with education.

One of the great things about DevOps is that it’s about what you can do, not what qualifications you have. Some of the best DevOps engineers in the field are self-taught, with little in the way of formal higher education. The biggest requirement is motivation and an interest in DevOps engineering.
With that said, you’ll have a much easier time both learning DevOps skills and getting a company to hire you if you have a bachelor’s degree in software development, IT, or a related field.

Start your DevOps engineer roadmap by looking through the skills list above. If you already have some of those skills — great. If not, be honest about the time you’ll need to spend to learn them. But don’t stress about getting everything perfect before you start. If you wait for mastery, you’ll never get a DevOps job.
Start by learning a few of the easy-to-learn skills. If you’re already employed in a non-DevOps job, start working on some DevOps projects now, to build mastery and proof you have the skills. Then make the switch to a full-time DevOps career.
You may even find that your own company has DevOps openings you could move into. Keep a keen eye on internal and external vacancies alike.

Let’s take a deeper look now at how to become a DevOps engineer — the DevOps career path and how to build the skills. We’ll share the reasons each of these tools is important, and how long it’ll take to learn each one. We’ll also point you to some good online classes and certifications.
You can learn most of these skills on the job — but a word of caution. In the sink-or-swim world of DevOps career growth, different companies have different requirements. There’s no one-size-fits-all approach.
<h3>Foundation knowledge: 4 months</h3>
We’ve put a plus-sign after each of the time frames below, because while you can learn the basics quickly, mastery can take much longer.
<h4>1. Intermediate to Advanced Linux and Networking: 1 month+</h4>
Linux is the OS and server platform of choice for DevOps engineers in companies of any size. Linux’s open-source nature, small operational footprint, and support from the Likes of Redhat and Ubuntu make it the go-to not only for DevOps, but for tool building in general.  One of the best things about Linux is that you can download it and start using it today.
If you feel that your Linux skills are rusty, you can get started with the free course offered by <a href="https://www.udemy.com/course/learn-linux-in-5-days/" target="_blank" rel="noopener">Udemy</a>. In fact, if you want to learn how to become a DevOps engineer exclusively from Udemy, they have an entire <a href="https://www.udemy.com/topic/devops/" target="_blank" rel="noopener">curriculum of core DevOps classes</a>.
In terms of networking, you’ll get the necessary skills if you do an intermediate cloud certification, such as <a href="https://aws.amazon.com/certification/certified-solutions-architect-associate/" target="_blank" rel="noopener">AWS Certified Solution Architect</a>, but it helps if you take a specialized course such as <a href="https://www.coursera.org/learn/computer-networking?specialization=google-it-support" target="_blank" rel="noopener">The Bits and Bytes of Computer Networking</a> on Coursera.
<h4>2. Advanced Scripting: 2 months+</h4>
First of all, you’ll always need shell (e.g., bash) scripting skills, because this is the default for Linux and most tools. 
For “advanced” scripting use cases, there are quite a few languages out there, but Python is a good start if you don’t know what scripting language to pick.
You can <a href="https://www.coursera.org/articles/how-long-does-it-take-to-learn-python-tips-for-learning#:~:text=In%20general%2C%20it%20takes%20around,can%20take%20months%20or%20years." target="_blank" rel="noopener">master Python in as little as two months</a> with online tutorials from <a href="https://www.learnpython.org/" target="_blank" rel="noopener">LearnPython.org</a>. However, you’ll find that many employers also use other languages such as Perl and Ruby as well, so be ready to learn those, if need be.
<h4>3. Cloud Training and Certification: 1 month+</h4>
AWS is the 600lb gorilla in terms of agile cloud providers, and AWS and Linux go together like Strawberries and cream. You’ll need to be fluent in AWS before you can call yourself part of the DevOps community.
The beauty of AWS and cloud development in general is that you only pay for what you use. That model makes cloud computing ideal for DevOps testing. You can set up an environment quickly, use it for what you need, then pull it down again.
It’s easy to start using AWS, since there’s a 12-month free version available to anyone who signs up. You can learn professional-grade skill in AWS in <a href="https://openupthecloud.com/how-long-to-learn-aws/" target="_blank" rel="noopener">as little as one month</a>, though mastery can take years of continual on-the-job use. Get your <a href="https://aws.amazon.com/certification/" target="_blank" rel="noopener">AWS certification here</a>.
<h4>4. Google Cloud: 1 month+</h4>
Azure offers similar employment opportunities to AWS, but what about GCP?
The Google Cloud Platform (GCP) is smaller than AWS and Azure but it excels particularly in data mining and artificial intelligence (and other deep learning technologies). Google’s DevOps-related offerings are becoming increasingly popular with large companies.
In the banking industry for example, the Google AI/ML tools are creating new ways of doing business, plus adding fraud detection and usage-pattern tracking. This saves huge amounts of time trying to develop similar tools in-house.
Similarly, other large companies are using Google’s ML tools to bring massive data sets down to size, drawing business-driving insights from previously unmanageable seas of data.
Want to know more about how to become a DevOps engineer with Google Cloud? You can get your <a href="https://cloud.google.com/blog/topics/training-certifications/get-google-cloud-certified-in-3-months#:~:text=Get%20Google%20Cloud%20Certified%20in%203%20months,-Rochana%20Golani" target="_blank" rel="noopener">Google Cloud certification here in three months</a>, though you can <a href="https://www.coursera.org/specializations/developing-apps-gcp" target="_blank" rel="noopener">learn to develop applications with Google Cloud in as little as one month</a>.
<h3>Skills: 1 month</h3>
It doesn’t take long to learn the DevOps skills you’ll need to succeed in your new career. All these tools are free to use and experiment with. They just require a little time and effort on your part. Let’s look at how long it takes to learn the basic DevOps tools like Terraform, Git, Docker, Jenkins, ECS, and ELK Stack.
<h4>1. Configure: Terraform (and Ansible) — 1 week+</h4>
Configuration management is at the heart of fast software development. Poorly configured tools waste time, while well-configured tools save it.
As its name implies, Terraform has one purpose in life — to create infrastructure as code in an automated way that speeds up your entire process.
Ansible concerns itself with server-desired state configuration, ensuring that servers are configured to specs. These two technologies are cornerstones of DevOps. Both may seem complex at first, but they’re all based around configuration files written in YAML. 
Terraform takes about a week to learn the basics. <a href="https://www.udemy.com/course/devops-deployment-automation-terraform-aws-docker/" target="_blank" rel="noopener">Udemy offers a great online class</a> that bundles AWS, Terraform, and Docker.
<h4>2. Version control: Git and GitHub (GitLab) — 20 minutes+</h4>
Version control is key to any DevOps endeavour. It lets DevOps Engineers and their team members create and review code faster, without wasting time sharing endless files and iterations.
Git is a standalone product that by default is used on local machines and networks. This is different from GitHub, which facilitates version control in the cloud, with the overhead managed by GitHub itself. In the world of infrastructure as code, version control with products like Git and GitLab are essential.
<a href="https://about.gitlab.com/" target="_blank" rel="nofollow noopener">GitLab</a> is a complete open-source DevOps platform. It helps users deliver software faster, with collaboration and security all rolled into one. Looking to learn more about how to become a DevOps engineer with Git? You can <a href="https://www.udacity.com/course/version-control-with-git--ud123" target="_blank" rel="noopener">learn the basics of Git</a> in minutes if you’re already a programmer. 
<h4>3. Package: Docker (Lambda) — 3 days+</h4>
Packaging is where build management meets release management. It’s where your code and infrastructure come together for deployment.
Without Docker there would be no DevOps. Docker essentially allows DevOps to run code in small isolated containers. That way, building services and replacing services becomes simpler than updating everything in one go (which is very non-DevOps).
Amazon’s Lambda is an alternative to Docker that many companies use instead. Though it’s best to know both tools, Docker is an excellent starting point. You can learn Docker in just a few days. Udemy offers a solid <a href="https://www.udemy.com/course/learn-docker/" target="_blank" rel="noopener">beginner’s course online for DevOps</a>. They also have a <a href="https://www.udemy.com/course/docker-and-kubernetes-the-complete-guide/" target="_blank" rel="noopener">Docker class bundled with Kubernetes</a>.
<h4>4. Deploy: Jenkins (CodeDeploy) — 2 days+</h4>
During deployment, you’ll take your code from version control to users of your application. Automation is a key component of this step, and Jenkins is the central way to automate.
Jenkins allows automation for all manner of tasks, including running build tests and making decisions based on whether code passes or fails the build process. You can also use Jenkins for more mundane purposes, like centralized management of scripts and executing commands via SSH (and other authentication pathways).
It’s a tool to automate those frequent and boring tasks that computers can do better than even the best DevOps engineer could. Some companies choose CodeDeploy over Jenkins, making it another useful DevOps tool to learn.
You can learn to use Jenkins in just a few days. Udemy offers a great <a href="https://www.udemy.com/course/jenkins-from-zero-to-hero/" target="_blank" rel="noopener">Jenkins class online</a> for DevOps engineers.
<h4>5. Run: ECS (Kubernetes) — 1 day</h4>
Kubernetes is DevOps bread and butter. It starts with Docker and adds extra functionality and tools. For instance, it lets the administrator ensure that several copies of a container image are running. That way, if a single VM or host is lost, the service is still available.
ECS and Kubernetes perform valuable services like this in the background. They deliver several automated DevOps tools that allow useful additions to manage containers, and their availability. They also add important items such as introducing role-based access control and more centralized auditing and management functionality.
See <a href="https://developer.ibm.com/series/kubernetes-learning-path/" target="_blank" rel="nofollow noopener">IBM’s Kubernetes learning path and guide</a> for a 13-hour course.
<h4>6. Monitor: ELK Stack (Prometheus) — 2 days</h4>
Once your new application is up and running, you’ll need a real-time view of its status, infrastructure, and services. To this end, DevOps engineers love ELK.
ELK provides all the base components for effective log management and search functionality. It’s Elasticsearch, Logstash, and Kibana — three open source applications offered by the <a href="https://www.elastic.co/what-is/elk-stack" target="_blank" rel="nofollow noopener">Elastic</a> company.
ELK takes data from multiple sources, and lets you visualize it by using useful charts and graphs. Its rival platform, Prometheus, is just as important for a DevOps engineer to understand. You can learn to use the ELK Stack in just a few days with <a href="https://www.udemy.com/course/elasticsearch-logstash-kibana-learn-elasticsearch-search-server/" target="_blank" rel="noopener">Udemy’s 4-star online class</a>.
Those are the basics of how to become a DevOps engineer. Now let’s look into why Git matters so much, and how to get a DevOps job.

One more word on GitHub as a shortcut to starting a career in DevOps. GitHub is essentially the CV of the DevOps world. Any DevOps hiring person will check out your GitHub profile as a very first step and point of contact. Yet it’s easy to learn GitHub and other DevOps tools while you create your virtual CV at the same time.

Knowing how to become a DevOps engineer doesn’t stop with skills. The next step in your DevOps engineer career path is getting the job. That sounds daunting, but if you’ve got software development experience, the skills above, and a few DevOps achievements for your resume, you’re well on your way to getting hired.
Here’s how to get into DevOps.
<h3>Rewrite your DevOps resume</h3>
The first step in getting a DevOps job is to rewrite your resume. A DevOps resume doesn’t need to show years of experience. As this excellent <a href="https://zety.com/blog/devops-resume-example" target="_blank" rel="noopener">DevOps resume guide</a> shows, start with a reverse-chronological format. Then in your work history, education, and projects section, list achievements, including:
<ul>
<li style="font-weight: 400;" aria-level="1">Development tasks from past jobs</li>
<li style="font-weight: 400;" aria-level="1">Side projects in development, IT, Agile, scripting, or automation</li>
<li style="font-weight: 400;" aria-level="1">Volunteer work in coding or distribution</li>
<li style="font-weight: 400;" aria-level="1">Projects in Terraform or other DevOps tools</li>
<li style="font-weight: 400;" aria-level="1">Linux/Unix projects</li>
<li style="font-weight: 400;" aria-level="1">Scripting in Python or Ruby</li>
<li style="font-weight: 400;" aria-level="1">Tasks completed with AWS, Jenkins, Maven, etc.</li>
</ul>
Start each resume bullet point with an action verb like developed, wrote, created, built, deployed, etc. And use numbers to show how many projects, deployments, scripts, tests, containers, and how many customers, team members, etc.
The more you show DevOps achievements in your history, with measurable details, the higher your chance of getting hired. Knowing how to become a DevOps cloud engineer is all about showing your projects and accomplishments.
<h3>Apply to lots of DevOps jobs</h3>
Finding a DevOps job is a numbers game. If you apply to three jobs, you won’t hear back from any. If you apply to 50, you’ll get a few responses and maybe an interview. Plan to hear back from about one in every 30 applications, and get interviewed by one in every 100.
In other words? You’ll need to apply to a lot of DevOps jobs. Probably something like 300 in a month to get one job (about 14 every weekday). But — you can vastly boost your chance of getting hired if you lean on networking. The easiest way? Start connecting with DevOps engineers on LinkedIn.
Then — don’t ask them for a job. Just ask if you can chat with them about their cool career. About 20% will be glad to share their success. You’ll learn tons about how to start a career in DevOps. And surprise surprise — some will even introduce you to their contacts.
<h3>Shun the unicorns</h3>
Don’t worry about being front-and-center in a DevOps job at Google, Amazon, or another giant company. Everybody clamors to get hired at those firms, creating stifling competition. Don’t be afraid to pursue a DevOps job at a less glamorous firm. Once you’ve got a little experience under your belt, then you can go unicorn hunting.
<h3>Consider working your way up</h3>
Is DevOps a good career for freshers? Not really. Don’t count on landing an entry-level DevOps job. DevOps is, by nature, an advanced position that requires highly skilled candidates. But — don’t let that discourage you. One of the best DevOps career paths is to start as a software developer or IT specialist in a company that also hires DevOps engineers.
If your current employer doesn’t hire DevOps pros, consider switching to one that does. Don’t stay entry-level for long. Three to six months is plenty. Once you’ve logged that time, commit to applying internally to DevOps positions in your new company. During your entry-level tenure, work to build accomplishments that look good on a DevOps resume.

Those are the basics of how to become a DevOps engineer. Though becoming a DevOps engineer takes persistence and passion, it’s not rocket science. Anyone with the drive (and a little time) can follow the DevOps career path, learn the necessary skills in five months, and get a DevOps job in one month. With the right skillset and job search strategy, you can be in your DevOps dream job very soon.

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

What Are Terraform Modules and How to Use Them

Though becoming a DevOps engineer takes persistence and passion, it’s not rocket science. See this article if you are interested in a career in DevOps.

how-to-become-devops-engineer

How to Become a DevOps Engineer in Six Months

How to Become a DevOps Engineer in 6 Months: Comprehensive Guide

Terraform makes it easier to grow your infrastructure and keep its configuration clean. But, as the infrastructure grows, a single directory becomes hard to manage.
That’s where Terraform modules come in. 
In this post you will learn what Terraform modules are, how to use them, and what problems they solve.

A Terraform module is a collection of standard configuration files in a dedicated directory. Terraform modules encapsulate groups of resources dedicated to one task, reducing the amount of code you have to develop for similar infrastructure components.
Some say that Terraform modules are a way of extending your present Terraform configuration with existing parts of reusable code reducing the amount of code you have to develop for similar infrastructure components. Others say that the Terraform module definition is a single or many .tf files stacked together in their own directory. Both are correct.
Module blocks can also be used to force compliance on other resources—to deploy databases with encrypted disks, for example. By hard-coding the encryption configuration and not exposing it through variables, you’re making sure that every time the module is used, the disks are going to be encrypted. 
A typical module can look like this:

As you can see, practically any Terraform configuration is already a module in itself. If you run Terraform in this directory, those configuration files would be considered a root module. It means that this configuration is the base of your operation, a core that you can expand further.

OK, now that you know what a Terraform module is, let’s take a look at a step-by-step process of creating them. So, let’s get started!
<h3>Step 1 &#8211; Declare that you want to use Terraform modules</h3>
To use a Terraform module, you have to first declare that you wish to use it in your current configuration. To do this, use the module block and provide the appropriate variable values:

As you’re adding the variables, there are a few arguments that you should keep an eye on: their source, version, and four meta-arguments.
<h3>Sources</h3>
Terraforms modules can be stored either locally or remotely. The `source` argument will change depending on their location. For example, if the module you wish to call is stored in a directory named “terraform-test-module” located in the same place as your root module directory, your root configuration would look like this:

But, if you want to keep the module in a VCS (let’s assume git and GitHub), the source will need to point to the correct repository containing the appropriate version of the module that you’re calling:

Terraform modules can also be stored in so-called registries. Registries are places where you can find modules published by fellow Terraform users, or where you store the ones you have created—either privately, for your company/yourself, or publicly, for everyone to enjoy. A Terraform module called from a registry might look like this:

Please note that the URL scheme depends on the registry provider. For example, imagine that you wish to include a VPC module stored in the Spacelift registry in your configuration:

As you’ve probably noticed, those two examples are a bit different from one another. A big advantage of the Spacelift’s registry is that it provides an example for each module. This means that you can check whether the source argument in your configuration is correct. Additionally, you can grab the entire example and use it as a template, filling in the blanks, and starting your work right away!
<h3>Versions</h3>
Versioning enables you to control what module changes should be introduced into your infrastructure. Why is it useful? It helps prevent the damage of your infrastructure caused by unpredictable updates or faulty code. You probably know from experience that any update of software, packages, or applications on a production server can go wrong. This can also happen to Terraform modules, if they’re not kept under control.
The syntax for version constraints is simple. Simply put, a version is a string containing one or more conditions. 
The first part is an operator:
<ul>
<li style="font-weight: 400;" aria-level="1">“=” (or no operator) means “Only one version—this specific version.”</li>
<li style="font-weight: 400;" aria-level="1">“!=” translates to “Other versions are fine, except this one here”</li>
<li style="font-weight: 400;" aria-level="1">“&gt;, &gt;=, &lt;, &lt;=” are used for comparisons. For example, “Use any version newer than 1.0.0, but older than 1.1.0”</li>
<li style="font-weight: 400;" aria-level="1">“~&gt;” is quite interesting. This operator allows only the rightmost part of the version number to increment. In other words, “~&gt;2.6.0” would mean that you wish to use the newest patch version of the module (2.6.&lt;anything&gt;), but not the newer minor or major versions (2.7.0 or above).</li>
</ul>
The second part of the syntax is the version number. Although it isn’t absolutely required (except when using registries), it’s best to stick to the <a href="https://semver.org/" target="_blank" rel="noopener">Semantic Versioning convention</a>—it’s easy to understand and very transparent. One look at the version, and you know where you are.
As you might have already noticed, there is an exception to the “keep things versioned” rule—in two of the examples above, the version argument is defined. In one, it&#8217;s not. The reason for this is that Terraform considers modules loaded from the same source repository as being of the equal version to the caller. Local modules, by the way, need no version constraints whatsoever.
<h3>Meta-Arguments</h3>
Meta-arguments are special arguments that change the behavior of Terraform when parsing the declared module. Currently, there are four of them in active use:
<ul>
<li style="font-weight: 400;" aria-level="1">“Count” and “for_each” are used to create multiple instances of the same module or resource. More on this (as well as functions and expressions) in our next article.</li>
<li style="font-weight: 400;" aria-level="1">“providers”— this meta-argument allows you to directly declare which provider the module should use for its operation. This comes in handy if you have two cloud service accounts and you want to create resources bound to the secondary. In order to achieve that, you need to properly design your Terraform module so that it takes the provider as an argument and passes it along, like this:</li>
</ul>
&nbsp;

<ul>
<li>“depends_on”—usually, Terraform handles implicit dependencies quite well, but sometimes they aren’t enough. If you need to declare that something should be created before something else, use this meta-argument to define an explicit boundary between resources or modules.</li>
</ul>
<h3>Step 2 &#8211; Declare Module Outputs</h3>
Sometimes you might need to use the values that are available in the already created resources. A Terraform module completely encapsulates those resources, and here’s how they can be accessed. 
First, declare in your Terraform module that the selected value should be available as an output:

Then, call this value like this:

The module outputs are not passed on from the resources by default—so if you don’t declare an output, it won’t exist.
<h3>Step 3 &#8211; Taint Terraform Modules</h3>
Sometimes you might need to recreate some or even all component parts of the Terraform module. As there is no way of flagging an entire module that needs to be recreated, you will need to manually taint every resource that was created by the module. While it may seem like a downside, it is actually a feature that offers additional protection against human error. What’s more, you will rarely need to taint an entire Terraform module.
To taint the resources that were created by the example module presented above, try this: 
terraform taint module.example.aws_example_resource.example_something
<h3>Step 4 &#8211; Test Modules</h3>
Whether a blessing or a curse, Terraform’s code is still code, and should be properly tested. It is absolutely crucial. But when done manually, it can be quite a chore. Luckily, Spacelift, alongside other upgrades and extensions, provides automated module testing and you will absolutely love it. 
Terraform modules managed by the Spacelift registry get tested every time you push a new commit. They are applied, deleted, and you get all of the details on the run. If something fails along the way, the entire test fails, too. If everything goes smoothly, the test is successful. The entire process is automatic, but if you feel like playing around with it, you can even write your own tests, such as this one:

Customizable automated testing—what’s not to love here?

Alright, now that you know how to use Terraform modules and what to keep an eye on when doing it, let’s see what problems Terraform modules solve.
<h3>1) Code Repetition</h3>
As your <a href="https://spacelift.io/blog/5-ways-to-manage-terraform-at-scale" target="_blank" rel="noopener">Terraform infrastructure grows in scale</a>, the code will need to do so as well. Copy-pasting an entire stack of code whenever you need more than a single instance of something isn’t scalable or efficient. It’s a waste of many things, time in particular.
<h3>2) Lack of Code Clarity</h3>
Copy-pasting isn’t clean either. Good code is readable, and great code documents itself. A modular approach addresses all those pesky details. A configuration of connecting modules dedicated to particular tasks is much easier to read and understand. 
<h3>3) Lack of Compliance</h3>
When you create a Terraform module in compliance with appropriate standards and best practices, whenever you reuse it, it follows the same right pattern. No matter if it’s encryption, redundancy, or lifecycle policies—practices configured inside the module will be enforced, so that you won’t have to do it again personally.
<h3>4) Human Error</h3>
When you copy-paste or create a group of resources from scratch, it’s easy to make a mistake, like rewriting or renaming something. To make sure that doesn’t happen, create a single Terraform module, test it, then use it in multiple places to check whether all of the elements are correct. It’s easier to check and test what you type into a single block than scroll, jumping from one place to another, and so on. 
As you can see, there are a lot of advantages to using Terraform modules, so long as they aren’t overused. Find the right balance and keep it.

The logic of Terraform modules may seem a bit complicated at first, but in the end is a simple and efficient way of building your infrastructure quickly and reliably. If you want to step up your efforts, check out <a href="https://spacelift.io/" target="_blank" rel="noopener">Spacelift</a> and the additional features it offers, which extend and perfect the modular approach. 
Cross-organization private module sharing and the above-mentioned module testing automation will help you get the most out of your configuration and make its development a lot smoother. 
Enjoy writing your code and growing your infrastructure, and have a productive day!

How to Use Terraform Variables (Locals, Input, Output, Environment)

How to Manage Active Directory Objects with Azure AD Provider for Terraform

Terraform modules are a way of extending your present Terraform configuration with already existing parts of reusable code, to reduce the amount of code you have to develop for similar infrastructure components. Others would say that the module definition is a single or many .tf files stacked together in their own directory. Both sides would be right.

Ernesto Garbarino

Categories

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

Read also

How to Become a DevOps Engineer in Six Months

What Are Terraform Modules and How to Use Them