provisioning cloud infrastructure with CloudFormation

The process of deploying and managing cloud infrastructure can be carried out in one of two modes. The infrastructure can be deployed either through interactive options, referred to in the slang as ClickOps, or through some form of automation. ClickOps is a way to manually provision resources based on the user interface. This means that everything has a graphical user interface through which you can explore the available services and manually click on the console to provide the infrastructure.

But why deploy resources to the cloud with ClickOps?

For starters, this is the easiest way to get started in the cloud. Also, for the most part, it’s a no-code process. That is, you do not need to write code to deploy your services.

Despite these advantages, ClickOps has serious drawbacks, and here are some of them:

DevOps to the rescue!

Long ago in a galaxy far far away, traditional software development was carried out between two different teams – the development team and the operations team. Both teams kept to themselves and pursued different and sometimes conflicting goals. The developers were interested in creating content, while the operations team was more concerned about stability and reliability. Agile methodology led to the emergence of DevOps. DevOps brings together once divided and sometimes conflicting teams, thereby eliminating this problem of confusion between them. There is an old debate about whether DevOps is a culture or a feature, but for the purposes of this article, I will limit myself to how DevOps sees AWS.

DevOps is a combination of cultural principles, practices, and tools that enhance an organization’s ability to deliver applications and services at high speed: product development and improvement is faster than organizations using traditional software development and infrastructure management processes.

What are some of the benefits of DevOps?

Answers to common questions

As more companies adopt agile methodology, DevOps (and others) will continue to play a key role in the cloud and technology in general.

What exactly are DevOps engineers responsible for?

DevOps engineers are responsible for the infrastructure. Infrastructure here does not mean a traditional office, but the hardware and software that runs products and applications. DevOps engineers are responsible for proactively automating and maintaining the infrastructure, which helps reduce the time and cost of ClickOps we talked about earlier.

Another question that is often asked is, do DevOps engineers need to code?

The classic response of an engineer is according to the situation. There are heated industry debates here, and it all depends on the environment and team structure. Often there are workflows that include both ClickOps and scripts or the creation of an entire platform.

Automate boring tasks

Much of DevOps is about automation rather than manually provisioning cloud infrastructure. Therefore, the question arises: “Why is automation important?”.

Software Development Life Cycle (SDLC) and Infrastructure Life Cycle (ILC)

The software development life cycle is the end-to-end life cycle of software. It is broken down into six phases of analysis, design, development, testing, deployment, and maintenance. Common tools used in SDLC are Git, CI/CD, Linters and Jira.

ILC is almost the same as SDLC, except that it is geared towards your infrastructure. In the infrastructure life cycle, we see an endless cycle of continuous improvement. Common infrastructure lifecycle tools include infrastructure as code, configuration management, GitOps, and CI/CD.

Infrastructure as Code (IaC)

IaC is a technique that we could use to automate the provisioning and deployment of cloud infrastructure through scripting. IaC tools are usually configured using YAML, JSON, HarshiCorp configuration language. For AWS, the three important infrastructure-as-code tools are CloudFormation, Cloud Development Kit (CDK), and Terraform.

Here is the YAML code that you can use to deploy an Amazon EC2 instance using CloudFormation.

AWSTemplateFormatVersion: 2010-09-09
    Type: AWS::EC2::Instance
      # You'll have to grab the image ID for the EC2 intsance for your preferred region
      #This image ID is for Canada central-1 for Amazon Linux 2
      ImageId: ami-01d29fca5bdf8f4b4
      #You'll need to grab the default security group ID in your AWS account
      SecurityGroupIds: ["sg-0c8ba2b706e2581e0"]
      #You'll need to grab a subnetID in the default security group's associated VPC
      SubnetId: subnet-0a6311ab0cdf8fa1b
      InstanceType: t2.micro

CloudFormation Tips and Tricks for YAML

Similar Posts

Leave a Reply