The Steelkiwi team develops more than 25 projects a year. Each project has its own infrastructure, and the money spent on a project’s infrastructure can be huge. Expenses for different environments, equipment, software licenses, and setting up all of these components aren’t trivial and could cost you a pretty penny.
However, the infrastructure of most projects is 80% identical, and it would take a long time to set up all the same systems multiple times. Therefore, we use the infrastructure as code (IaC) approach in order to create and manage infrastructure efficiently, reducing the cost for you. To help us achieve this, we use tools including Terraform and Ansible.
Before we get into explaining how we use these tools, let’s discuss what Amazon Web Services are and how they help us create infrastructure and control configurations with the help of Terraform and Ansible.
Overview of Amazon Web Services
Amazon Web Services (AWS) is the leader in cloud computing. It lets you access 15+ locations for deploying infrastructure. There’s also a flexible system of access to resources and a convenient method of payment known as pay-as-you-go, where you’re charged only for the resources and services you use.
AWS regions and availability zones
There are 15 AWS locations at your disposal, which are available in 12 countries and on 5 (soon to be 6) continents. You can transfer infrastructure between locations.
Multiple services
AWS gives you a lot of services all in one place. These are some of the services we use:
- EC2 (hosting for virtual machines)
- Route 53 (DNS hosting)
- RDS (database)
- CloudFront (content delivery network)
- S3 (cloud file storage)
- Lambda (serverless compute)
- IAM (resource service access)
With IAM, you can limit access to your resources, for example, if you need to let an app or person access files in your bucket. You can give access only for reading or for downloading files without reading. A set of access policies can be created for a person or app.
Pay-as-you-go
If you’re just starting your business, you don’t need big infrastructure and a contract that gives you the right to use massive computing power. With its pay-as-you-go billing, AWS won’t ask you to sign anything or put down some money up front. You can choose the computing power you need right at the moment.
If you’re a large business with hundreds of virtual machines and lots of clients all over the world, AWS will provide you with a different rate that lets you sign a contract and get a good discount on your computing power. But unless you want to rent reserved instances for yourself, you can use pay-as-you-go as long as you need it.
For more details on AWS pricing, go here.
AWS management
AWS provides a few options for accessing the management console: through a browser with a graphical interface, through the AWS console utility, and through the boto module for Python. Many modern automation tools support working with AWS out of the box (such as Terraform and Ansible, which we write about below).
Automation and infrastructure as code
Automated tools in the cloud allow you to flexibly manage resources on distributed systems and modify their scope (scaling) as well as quickly and easily deploy and configure environments for testing. There are many tools for automation, and the choice of a particular one falls on a company. At Steelkiwi, we use Terraform and Ansible.
Infrastructure as code
Infrastructure as code means that all project infrastructure data is stored in the form of scripts in the repository and this data is extracted when needed. Infrastructure as code removes the boundaries between developing an application and creating an environment for it – you can perform all actions directly in the cloud. The main value of this approach is that it lets you deliver infrastructure to where it’s needed while optimizing resources.
Let’s talk about deploying infrastructure from scratch, working with it, and making changes to it. Imagine that at the beginning you only need to create one virtual machine, one bucket, and one CloudFront distribution. You can do this easily using a browser. At this stage, you may face some challenges:
- You won’t have any history, so you won’t be able to track which infrastructure you had one month ago, two months ago, or further back.
- Even if a few people are working on this infrastructure, there may be some misunderstandings. For example, some developers may make some changes but not be aware that someone else is doing the same thing simultaneously, or a developer may make breaking edits, which is much worse.
- You won’t have a rollback point to quickly return your infrastructure to its former state.
Terraform
Terraform from HashiCorp allows you to store infrastructure as code. At Steelkiwi, we create infrastructure for our clients with the help of Terraform and store .tf files in git. We can always see which employee has made changes and what those changes are. When we give our clients their projects, they have all the Terraform files at their disposal.
At Steelkiwi, projects usually have three stages: development, staging, and production. When a DevOps engineer writes .tf files for the development stage, those files can be easily reused for staging and production (after changing the values of variables and adding necessary features).
Ansible
Once you’ve created virtual machines, you need to set up the necessary software and configure the systems. When you have one virtual machine on board with Linux, you can access it via ssh and start configuring it or setting up packages such as apt update && apt install. If you take this approach, you’ll run into the same problems we’ve described in the section about Terraform.
At Steelkiwi, we use Ansible to set up software and configure systems. We have ready-made templates for system configuration. All we need to do is get access to our client’s server and enter the domain name in the Ansible settings.
Additionally, in the case of Terraform, we use Ansible playbooks for different stages of a project.
Code quality
Code must be of high quality. To make sure code is high-quality, you need to test it. But if every developer checks their code, they’ll spend lots of their time on those checks. What’s more, when you check code, you should keep to one standard.
At Steelkiwi, we choose to test code automatically. When a client chooses to us, our developers and DevOps team write a script that determines how the code is checked. We use gitlab, specifically gitlab CI (Continuous Integration). Alongside code, we store the .gitlab-ci.yml file, in which all steps for checking this code are described. Each time developers git push code to the repository, instructions from this file are run. If the code has problems, there will be a specific step indicating “Fail,” and our developers and DevOps team will get a notification about it. And if some step is marked as “Fail,” there won’t be any chance to git merge code to other branches.
Conclusion
Based on our experience, all the methods described in the second part of this article let you reduce the time spent on project support (staging/production, system configuration, and code testing). When we hand in a project to our client, they get Terraform files for managing the existing infrastructure, Ansible playbooks, and gitlab continuous integration at their disposal. Clients can open a file in a text editor and see the state of any server and how the code is being tested.
If you still have a question or want to partner with us, get in touch with one of our sales representatives.
