Welcome to Module number three. In this module, we will continue on the path of more and more automation. Declarative versus imperative automation is very important topic and contrast and comparison. AWS CLI and SDK, they are example of an imperative style, and with imperative style, there might be a few issues.
The problems with imperative styles are they're not simple to understand. So when you're looking at a shell script, if it's more than five, seven, maybe 10 lines, it becomes harder to think what are the end results of this infrastructure of this script, being at the Node.js SDK script or AWS Bash shell script.
Then, you might have some racing conditions. So let's say you're launching an EC2 instance in two subnets and they need to connect to an RDS instance and be behind the load balancer. What goes first? Maybe it's an RDS and then ELB and then EC2 instance.
Before you launch your EC2 instances, you need to have certain dependencies, so how you will ensure it with AWS CLI. Maybe you can wait, but what if it's broken? Then you need to roll it back. So there are some unpredictable results. There is some potential for unpredictable results. Also, it's not optimal if you have to wait for something. Maybe you can instead do something in parallel, which would be totally fine. All this is solved by using CloudFormation.
Meet CloudFormation. It's a proprietary AWS technology to allow you declare your infrastructures. What is CloudFormation? So, first of all, it's a special format. You can use JSON or YAML file. With this format, with special CloudFormation format, you would write your blueprint. Then, the AWS technology will take those blueprints and resolve the dependencies. It will ask you for certain parameters, and basically, it will provision everything. It's a declarative service, so JSON, YAML, they're declarative languages. It's good, because there's very little mistake and it's very predictable. There's very little opportunity for mistakes.
There's the visual editor, as well. You don't have to create JSON manually by hand. You can use a visual editor, or you can use one of those samples to start your own infrastructure. Or you can get a sample, such as a Docker Enterprise Edition. It's one of the examples. You can get it from a marketplace.
Speaking of the advantages of CloudFormation it's declarative, but it's also flexible, because you can specify certain parameters and also mapping of those parameters which would be resolved at a later stage. You do not have to hard code everything in your template, which makes your templates/blueprints very, very flexible. It's very easy to use, especially with the web designer in the web console.
Infrastructure as a code, that's the main principle. You can version your JSON file all day long. It's going to be just fine. It's going to work just brilliantly. Supported by pretty much all services and all AWS resources. You can create new users. You can create new identity access management roles. Obviously, EC2 instances, RDS instances. Can customize it with certain parameters, use a drag-and-drop interface.
Then, one more benefit is that your whole infrastructure would be either created entirely, 100%, or not created at all. This is very, very good. Most of the times, we would have 20, 30, maybe 50 different resources, different interdependencies in your infrastructure. So you obviously don't want to keep 49 of them if 1 out of 50 fails and then keep paying for those 49. Your infrastructure would not be complete. It's going to be missing parts. So you want to either have 100% or not have anything at all, and that's exactly what CloudFormation will do. It will roll everything back, even if you have just one of those resources. So it's great, great, great for those purposes.
Obviously, it's very easy to replicate, because you can just get your CloudFormation blueprint and you can deploy it many, many times in many different accounts, in many different environments, such as regions.