- [Raf] Hi there, I'm Raf.
In the previous videos, Alana started the conversation
about continuous integration,
and the AWS Services you can use
to leverage a way to develop something
in a collaborative manner, from the source code
to build and test.
She also talked about CodePipeline,
the AWS service that can be used
to orchestrate your continuous integration workflow,
stitching together in CodeCommit and CodeBuild,
to automatically have the build done,
and tested according to the pushes in the Git repository.
In this video, I am going to talk about the next steps,
to move your pipeline to the next level,
with the usage of infrastructure as code.
Logging in the AWS Management Console
and manually provisioning your environments
is not ideal due to many reasons.
It gets easier if you are the only one managing
a simple environment in your personal account,
but as you start working professionally with it,
as a part of our DevOps team,
it rapidly becomes more challenging.
Automation is key, and infrastructure as code
is the process of managing and provisioning environments
through code in a declarative way.
Let me ask Alana something, and you will understand
what I mean by using the word declarative here,
in the infrastructure-as-code context.
Alana, I have something to ask you.
What do you do when you go to a coffee shop,
looking for an espresso?
Option A. You ask the cashier,
I would like to have an espresso please,
or option B. You start giving detailed instructions
to the barista, in terms of what they should do
in order to get your espresso.
Like, you start giving instructions like,
getting the coffee beans,
grinding with a specific granularity, tamper,
put in the portafilter,
turn on the machine for 25 seconds, et cetera.
- [Alana] Well, if the barista is capable of
making an espresso, I would definitely prefer option A.
- [Raf] So do I, right?
That's what I mean by using infrastructure as code,
in a declarative way.
The reason why I am saying all of this,
is because since you can interact with AWS services
programmatically, by using the AWS SDKs or the AWS CLI,
you can create your infrastructure through shell scripts,
although it gives you more control,
because you are exactly specifying the very fine details,
of what you want.
It is way less convenient,
because you also need to concern with complexity,
such as managing changes, auditing, rollbacks,
in case of failures, infrastructure, consistency,
and much more.
AWS CloudFormation is a service
that allows you to declare your infrastructure
in a text file.
In that file, you say what you want,
pass it to the service,
and CloudFormation brews the coffee,
I mean, the environment, for you.
This file can be authored in JSON or YAML.
Once you input a file
and ask CloudFormation to create a stack,
CloudFormation starts creating the infrastructure for you.
In the CloudFormation nomenclature,
we call that file a template,
and infrastructure components, a stack.
So, a template is something you define,
and a stack is infrastructure that actually gets created.
This is what a CloudFormation template looks like.
The Resources part is where you declare
what AWS services you want.
If you want to create an S3 bucket,
you can declare a resource of the type, AWS::S3::Bucket.
The CloudFormation documentation
has a list of the supported properties
for every single AWS service that supports CloudFormation,
which has almost every service.
This is the documentation page
for the resource AWS::S3::Bucket.
I prefer using YAML because it's simple for me to read,
and you can see that a bucket can be created
simply by specifying the bucket name as a property.
All right, a CloudFormation template
can be as simple as that, just creating a bucket.
Pretty simple.
You can submit that to CloudFormation,
and ask it to create a stack out of it.
Once the stack finishes with no errors,
you will have the bucket created,
as declared in the template.
Now, here comes one of the coolest part.
What if, in addition to that S3 bucket,
you also want to have a DynamoDB table?
Pretty simple, you just edit the template,
add the resource, AWS::DynamoDB::Table,
and submit it again to CloudFormation.
But this time, you will do an update stack operation.
Update stacks are awesome.
CloudFormation receives the updates from the template,
and says: now, in addition to the bucket,
the user wants a DynamoDB table.
Let me create it, and voila.
It updates the infrastructure for you.
Same thing with deletions.
If you want to remove something from your infrastructure,
you can remove from the template and do an update stack.
CloudFormation will calculate the delta,
and make the infrastructure match
what is desired on the template.
- [Alana] But Raf, S3 buckets and DynamoDB tables
may contain data from your users.
What if you want to delete a stack,
but retain some of the resources?
Because when you delete a stack,
CloudFormation will erase all the resources
associated with the stack,
and sometimes you want to erase some resources,
but not others, right?
- [Raf] That's right.
When you delete a stack, CloudFormation
erases every resource defined on that stack.
And that's why some of the resources
allow you to define an action when you delete this stack.
For example, this S3 bucket has a deletion policy
defined as Retain,
which will make CloudFormation reserve
that specific resource upon stack deletion.
The usage of this is actually a best practice
every time you define a resource
that will be used as a database, like an RDS instance,
an Elasticsearch cluster, or a DynamoDB table.
CloudFormation is very powerful.
We could spend hours and hours talking about its features,
but we have to move on in our DevOps journey.
So I strongly recommend you taking a look
at the CloudFormation documentation.
Having the ability to write a template
and have the infrastructure created is super powerful.
Since we are talking about having a CI/CD pipeline,
you can have CloudFormation templates,
in a CodeCommit repository,
and whenever you do a push with a change,
CodePipeline orchestrates the environment change
by executing an update stack as part of the deployment.
When we start doing this practice,
we have developers operating the infrastructure,
and this is actually where the word DevOps come from,
developers who also operate.
And because developers are good with code,
when we talk about infrastructure as code,
developers are the expert.