- Now let's talk about automation with AWS CloudFormation.
With AWS CloudFormation,
we gain the ability to automate the creation
and management of our infrastructure.
So CloudFormation uses
template-based infrastructure management
where we express our infrastructure as code
and we can do that with a declarative programming.
So the benefit of declarative programming
versus imperative programming is that we essentially
define or declare the resources that we want
and the way that we want them connected and related
and we can do that writing either JSON or YAML.
We don't have to worry about the order of operations,
we don't have to worry about imperative instructions
and we don't have to worry
about serial versus parallel executions.
We simply define in that template
all of the things that we want,
we pass that template to the CloudFormation engine
and allow the CloudFormation engine
to worry about the imperative instruction.
We allow CloudFormation engine to worry
about which resource needs to be built first
before it can then build other resources.
So another benefit of CloudFormation
as opposed to something like OpsWorks
or Beanstalk or third-party tools
is that it offers us access to the full breadth of AWS.
The great majority of AWS resources can be
created, updated, deleted, or managed by CloudFormation,
not everything.
Generally new services that are launched,
new features and new options generally do take
some time to make their way into CloudFormation.
So if you get in there and you find
something that's not available,
it's usually just a matter of time.
So another benefit of CloudFormations is
that because it is template-based,
because we are expressing our infrastructure as code,
we can and ideally should store
that template in source control,
and from there we can apply all the tools and procedures
of software development to our infrastructure.
We can gain the efficiencies of continuous integration
and continuous delivery with our infrastructure.
So by putting it in source control,
we can more easily collaborate on our infrastructure,
or we could fork, we can branch, we can merge.
We could do pull requests where maybe perhaps
one member of our team is writing a template
and another more senior member of the team is doing
a code review before that pull request is actually merged.
So we have the ability to again
apply the same kind of processes
that we were using for good software development.
The other benefit of CloudFormation,
of expressing our infrastructure as code,
is that we now have the ability
to write a template once and then deploy it many times.
You may have
certain types of applications or certain patterns
of infrastructure that are deployed numerous times
within a particular environment
or maybe you have one thing that needs to exist
across different environments like dev,
test, stage, production and so on,
or maybe you want to make use of multiple regions.
So we want the ability to create
an infrastructure in numerous regions,
and instead of creating them manually over and over again,
by writing a template once,
we can very easily deploy it many times,
and then of course we could also create
a library for common architectures.
Of course AWS also offers a related service
called the Service Catalog,
which is based on CloudFormation.
So by creating common architectures in CloudFormation,
we could then make those available
to other members of our team through the service catalog
so that by doing that,
not everyone needs to know how to write CloudFormation.
Perhaps a few members of the team are
really good at CloudFormation and fluent,
and then they can make common things
available to other members of the team,
simply to launch and create.
Another nice thing about CloudFormation is
that it does not impose its own model.
When you have other configuration management tools
like Chef and Puppet and different things,
then a lot of these kinds of tools
tend to impose a particular model
and there's a box within which you have to work.
Really the only thing that CloudFormation is imposing
is the syntax of the JSON or YAML, but beyond that,
you have complete freedom to create
any infrastructure in any way that you see fit.
So once we have a template created,
we could give that template directly
to the CloudFormation engine,
and then have the CloudFormation
engine create those resources,
or we could take it a step further and have
that template go through an entire pipeline.
So let's take a look at a diagram here.
In this diagram, we have our CloudFormation template.
Perhaps we've taken some time to write and define
or declare a number of resources that we want built
and we've defined the ways
in which we want those resources related,
how they connect to one another.
Now and again, like I said,
we could, if we wanted to,
we could send that template directly
to the CloudFormation engine
and have that engine then build out all of those resources
and manage those resources underneath the stack,
but by doing that we miss out on an opportunity
to automate the testing of that template.
So instead of doing that,
instead of sending it directly to the CloudFormation engine,
perhaps we send that, we commit that to CodeCommit.
CodeCommitt is Amazon's private Git repository hosting.
So it's essentially Amazon's answer to GitHub
so we can create private Git repositories within CodeCommit.
We can create future branches, we can merge,
we could create pull requests,
all of those great processes for software development.
So perhaps we do a pull request here
and one member of the team can look
over that template and suggest changes.
Once the team as a whole is satisfied
with that state of the template,
then once it's merged into a particular,
let's say for example merged back into the master branch,
then that merging to the master branch,
we could configure CodePipeline
and we could configure CodePipeline
to pull that template in,
and then pass that template
on to something like CodeBuild or Lambda,
or either way they're both well-suited for doing
these types of automated processes of where we have code
and we need that code to be tested, that code to be built,
and then that code to be deployed.
So here, again our code is expressing our infrastructure.
So the beautiful thing about this particular pattern
is that now we have the ability with CodeBuild or Lambda
to run tests on our infrastructure.
We can use automated tests to ensure that our infrastructure
that is being expressed in a way that satisfies
business policies, security policies,
compliance policies and so on.
So the nice thing about that is
that we can validate our infrastructure
before anything is ever even built.
We can prevent building things
and spending money on resources that we know we will
end up tearing down anyway due to some misconfiguration.
Those are the kinds of things
that automated testing can help us avoid.
Once CodeBuild or Lamda has verified
that our template meets all of our
business requirements, policies and so on,
it can then send that to the CloudFormation engine.
The CloudFormation engine is then responsible for building
the resources that are expressed in the right order.
For many resources,
CloudFormation is already aware that, for example,
before it can launch an EC2 instance into a subnet,
it has to create subnet,
before it can create the subnet,
that it has to create the VPC.
So for many resources, it is aware of dependencies,
it is aware of the order of operation.
Doesn't matter what order they come in in the template,
CloudFormation already knows that.
And then once CloudFormation builds out,
so let's say that we have all of these moving parts here,
let's say that we have VPCs, we have load balancers,
we have S3 buckets, and auto-scaling groups,
we even have moving parts that aren't even
necessarily shown here on the diagram,
but all of these moving parts would then be essentially
managed underneath what we call a stack.
So if we wanted to update that, we could go back,
we could go back here to our template,
make changes to the template,
push that template back through the pipeline
and have CloudFormation update that existing stack.
Then of course we could use this pattern
to ease the development and ease the ongoing testing
and deployments of any environment,
be it development, testing, production,
maybe we are deploying to multiple regions,
and it's also really powerful and really
helpful for temporary environments.
Perhaps developers want to deploy
a feature to an isolated environment
so that they aren't interfering
with dev, stage and production.
So we could use this pattern to very easily deploy
some kind of a temporary environment,
allow that environment to prove some kind of point,
and then when we're done,
all we have to do is come back here to CloudFormation
and tell CloudFormation to delete the stack.
If we delete the stack,
CloudFormation will then remove all of the components,
all of the resources that were included in that stack.
So you can see that CloudFormation
is a very powerful tool for automating the creation
and ongoing management of your resources.
Now another powerful feature of this pattern too is
that CodePipeline,
as things are happening within CodePipeline,
we can receive notifications throughout that process.
All of the lifecycle events that happen
in that CodePipeline process can be sent
through the Simple Notification Service.
And then any kind of testing that's happening here
can send its output through Simple Notification Service,
and then of course the CloudFormation engine
could also send its
lifecycle events,
its status
throughout the lifecycle
of creating these different resources.
So with every step along the way,
whether things succeed or whether something fails,
all of those events being sent
through the Simple Notification Service
could then be sent pretty much anywhere else.
We could have that information, for example,
be fed into a Slack channel so an entire team
is aware of the current state of that deployment,
whether it be to dev, or whether it be to production.
So as you can see,
AWS CloudFormation really gives us
a very powerful platform that we can use
to automate the deployment of our
infrastructure throughout AWS.
One last point here about CloudFormation,
and this is true for automation in general,
whether you use CloudFormation or something else,
such as a third-party tool like Terraform or Ansible,
the only way to truly realize
the full power and benefit of AWS,
the efficiency, the performance,
the agility, flexibility, cost savings and security,
the only way to truly realize and gain all of that
is through automation.
There's no way that you can gain all
of that by doing things manually every time.
So my advice for those of us that are new to AWS
is to really explore these kinds
of automation tools, like CloudFormation,
like third-party tools like Terraform and Ansible,
'cause they in the long-term,
these kinds of automation tools can
really make your life a whole lot easier.