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:
- This is a manual process.
- It is vulnerable to errors because it is more difficult to manually complete a number of tasks without errors.
- You can’t track what others have done – no version control, no audit process.
- If you need to re-allocate a resource, disaster recovery will take a long time to complete. For example, if you have 50 nodes and something goes wrong, you have to fix them one by one.
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?
- This is a faster deployment strategy – DevOps increases the frequency and speed of product releases.
- Improved product quality – Closer collaboration between development and operations teams, as well as feedback from end users, results in better products.
- Scalable – With DevOps, you can manage your infrastructure and development process at scale.
- Reduced Costs – As maintenance and new upgrades are combined, management and production costs are reduced.
- Reliability – DevOps ensures the quality of application updates and infrastructure changes, so you can consistently sustain a faster pace while maintaining a positive customer experience.
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?”.
- Automation eliminates human error. This means that there is a low risk of misconfiguration.
- You can create new environments literally on demand.
- It is easier to peer review with new team members. It’s much easier to look at someone’s shared code than it is to watch over your shoulder as they make changes to the user interface.
- This allows organizations to scale quickly without much manual work. For example, the difference between preparing 1 instance and preparing 1000 instances is only the change in the value of the counter.
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 Resources: myInstance: Type: AWS::EC2::Instance Properties: # 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
- The indent must be exactly right.
- Check the YAML syntax before deploying – this can be done in the CloudFormation template builder.
- Link to AWS Documentation.
- Determine which properties needed.
- IDs and values of AWS resource references in your AWS console.
- Check the Availability Zone you intend to deploy resources from (the AMI differs depending on the Availability Zone. For example, to deploy an EC2 instance in us-east-1, you must use the AMI from us-east-1. You are guaranteed to get a fallback if you using an AMI from another Availability Zone).
- If you get a rollback/error, look at the Events tab in CloudFormation to see what went wrong.
- If the CloudFormation error help isn’t informative enough, you can open CloudTrail for more help.