AWS Cloud-formation for beginners, Part 1 Intro.

                               

AWS Is the market leader in cloud services with the biggest number of services amongst the big 3 (Google, Amazon, Microsoft). 

As a Devop these days, infrastructure as code is common practice. you explicitly define your infrastructure, without application logic. In some environments, forming up of certain processes and procedures can be quite complex 

code does not lie

AWS provides a lot of granularity in controlling the infrastructure opposed to other IAAS providers (For example Heroku), the configuration of this massive behemoth of a cloud framework called AWS can be quite tedious. Luckily for us, Amazon invented cloud-formation. CF service includes provisioning, rollbacks, conditional steps and many more features which are crucial for building an automated and robust infrastructure

CloudFormation is a block of Json or YAML files, defining the current infrastructure state, It is not dynamic in the sense that if you do not change the code, your physical infrastructure will not change (not by CloudFormation is any case). CloudFormation has the ability to update underlying resources yet EC2 instances can only be configured at instantiation or at certain advances methodologies.

When working with CloudFormation to manage your AWS framework, you MUST do the changes with CloudFormation, one of the design elements of the system is that its, static, if you change one of the resources bypassing CloudFormation update, when you update that resource the next time, you will be out of sync and fail.

Resources

1. Documentation is key, Amazon has very good documentation for all that CloudFormation can do, detailed and updated. 
2. AWS CloudFormation Blog
3. AWS CloudFormation forum
4. Uncle google.

When writing the scripts, you can use any text editor or IDE that supports JSON/YAML (you can also do it in VI, it's just a text file).

Design

AWS Cloudformation used to be either a huge file of JSON script, the way it worked was so that one template, defined the entire infrastructure. Even when you use the "nested stack" feature, on updates, the stack and all of its descendants were being updated.

Whats the problem?

CloudFormation is the definition of your production infrastructure, if this goes wrong, shit hits the fan... you would want to avoid accidents, yes, we are all human, and most of the changes that you do, do not need to affect the entire network.

On big stacks, it might be a simple typo that wipes your backups or rolls your servers versions. You would want to contain changes as much as possible.

For Example, Stack B is Nested in A. 

1. You transfer a parameter from A to B on stack initiation. 

2. Update stack B, Change the parameter value

3, Update stack A (without changing the parameter to the value of the nested stack) would refresh stack B resource using the parameter to its original value. causing unwanted updates.

cross stack references

While going with the one file/nested stack approach is legitimate approaches In order to produce a more simple and scalable solution with less risk, you would want to use the "Cross stack reference" feature.

It would provide you with a layered infrastructure that each entity in the layers can be managed separately, while still maintaining global consistency within the system. This is a very powerful feature when done right.

Pricing

CloudFormation is free to use for all its features, but a word of advice... when you are is testing/development stages, you are going to perform many rollbacks and modifications to your template. most of the times you will create/delete/update instances and other services that do bare a charge. Try to minimize the scope of each update so you will not create/destroy a lot of resources all the time, this can come out to be quite expensive as Amazon charges by the hour (Note that the recently announced that they are moving to charge by the second)

Competition

There are not many competitors in the Infrastructure as code domain, its CloudFormation and Terraform. you can always write your own script but I would highly advise against it unless it is absolutely impossible otherwise. Some might tell you about the chef/ansible/puppet projects... yes you can "rape" them to do your work, but that's not what they are intended to do so you will end up with a bad solution.

I am currently working on the next post in the tutorial, "Making your first stack". 

If you liked this post, upvote/resteem.