CloudFormation is the core functionality provided by Amazon Web Services in the area of expressing infrastructure as code. One can write the infrastructure design in either JSON and YAML (with similar syntax keywords); there is also a template designer that may help in putting together the infrastructure elements and their dependencies. The particular details of each resource being defined must be coded out, though.
There are no limitations on the types of resources that can be brought up, as far as I noticed – each resource type provided by Amazon can be coded and subsequently created and provisioned. One can also define an explicit order (e.g. some resource to be created before another), apart from the implicit order that can be deduced (e.g. if an EC2 instance is defined with a IAM Role, the role is always created before the instance). The revert process is also clean: deleting the CloudFormation stack does delete everything created by the stack itself; nothing gets left behind.
Note: This is a text about the project work at one of my previous employments.
Introduction
These days everybody talks about Agile, Automation, DevOps and Continous (whatever), without truly understanding why things have gone in this direction. After all, for many years, a software project had a couple of well-known steps that needed to be followed, like:
Full, thorough planning at the very beginning and from time to time, before significant milestones;
Development, lots of development behind closed doors;
Lots of manual QA work, little automation with some custom-written testing framework written from scratch by one of the developers;
Infrequent releases (e.g. every year or even every other year or so); releases were thoroughly prepared and tested, with code freezes for (sometimes) months before the Day.
Even if everybody knows these days that such approach may have been a bad way of doing things, it actually worked for many years because that was the way the world expected things to work. There were many constraints, e.g:
Note: you can find my comments here for the similar event held in 2015.
Another year, another AWS event; for this year they have changed the venue and brought in more speakers, unfortunately of inferior quality compared to Sebastien Stormacq, the sole speaker from 2015. This year twice as many people registered, roughly 500 people queuing up for the early morning registration.
The main difference from the last year was the presentation content being split into 2 tracks, the “technical” and the “business” rooms, each with their own focus. On the technical side the following topics were covered: