(6 votes, average: 4.50 out of 5)
Loading...Today’s world moves fast, faster than ever! In almost every business context, speed is a key factor, sometimes the most important one.
Every startup wants to be the first to bring its product to market, every company wants to get in front of the competition.
And this is felt the most by us, developers.
Luckily, AWS services make our lives easier, allowing us to develop more efficiently and deploy faster.
Today’s world moves fast, so should your containers! During a PentaBAR event I hosted in Pentalog’s Iasi agency, I offered more information on how to build a docker container with its own CI/CD pipeline Typescript (with the new C.D.K) and AWS services.
We need to be more productive, more efficient, and we can’t wait weeks or months for people in some department, somewhere, to setup a server for our new POC.
So how can we achieve these results?
Two Words: Abstraction and Automation in AWS Services
This is nothing new in the field of software development, however, how can this be applied in the infrastructure world?
This is where “infrastructure as code” comes in.
“Infrastructure as code” is the idea that systems and devices which are used for running software are treated as if they were themselves software.
This brings the following advantages:
- Automation (this is pretty self-explanatory)
- Repeatability (the same code always produces the same infrastructure)
- Versioning (everything is in our git repo and has the same flow as the main software product)
So, let’s take a look at the history of “infrastructure as code” in AWS services:
IAC V1: CloudFormation JSON
In the middle of 2010, AWS launched CloudFormation, a service which:
“… provides a common language for you to describe and provision all the infrastructure resources in your cloud environment. CloudFormation allows you to use a simple text file to model and provision, in an automated and secure manner, all the resources needed for your applications across all regions and accounts. This file serves as the single source of truth for your cloud environment.”
Actually, CloudFormation comes in two parts:
- Templates that describe your infrastructure
- AWS services which take these templates and provisions the infrastructure for you (managing the state as opposed to something like terraform where you are responsible for managing the state in one way or another)
This was quite revolutionary for that time but everybody hated one aspect of it: the templates were JSON!
We all remember the whole JSON vs XML debate: we switched to using JSON since it’s more human readable than XML, it’s easier to parse and, and of course, it saves bandwidth! (Very important for mobile apps!)
But you quickly discover that it’s not that human readable when you have to manage thousands of lines of JSON templates.
Example of a CloudFormation template for an EC2 instance and a security group in JSON format.
IAC V1.1: CloudFormation YAML
As the popularity of the service grew, so did the pain of managing JSON.
In 2016, AWS launched YAML support for CloudFormation which allowed you to:
- Add comments to your code
- Use short form intrinsic functions (from { “Fn::Base64” : valueToEncode } to !Base64 valueToEncode)
It wasn’t perfect but a welcomed improvement, the same template that adds an ec2 instance and a security group now looks like this:
IAC V1.2 Serverless Application Model
Just a few months later in 2016, AWS decided to release SAM which is meant to help you deploy serverless applications more easily.
To be fair, you already could do that with simple CloudFormation, but this made it much, much easier.
For example, creating a lambda function went from this:
To this:
A major improvement for people doing serverless, wouldn’t you say?
Now, SAM does a lot more than this for developers, it has local debugging, built in best practices, etc.
The most interesting part is how it manages to this and the answer is surprising: “Transforms”
“Transforms” are, basically, pre-processors that take your yaml templates and expand the templates.
And the best part? You can create your own transforms!
But I don’t want to get into details on this because the most interesting part comes next!
IAC V2 Cloud Development Kit (CDK)
Take the idea of “pre-processors” and add a real programming language and you get CDK.
Adding a lambda function now looks like this:
Ok, so it wouldn’t pass the usually 120-character limit for code linting as a single line, but still, it’s impressive.
This is where the real abstraction comes in, you can write your infrastructure as higher-level modules and use them as you would with any library.
Interested in learning more about the “Infrastructure as code”, AWS services, and CDK? Post a question as comment and I will answer you.
Read more!
