- Now let's review some application management services.
The first service here that we wanna talk about
is AWS Elastic Beanstalk.
Now, we talked about earlier CloudFormation.
If you think of these services
on a scale of absolute control, on one hand,
and absolute convenience on another,
CloudFormation would be near the far end of control
and Elastic Beanstalk would be
on the very far end of convenience.
So, we get a lot of convenience with Elastic Beanstalk,
but certainly nowhere near the amount of control
that we get with AWS CloudFormation.
So Elastic Beanstalk is what we would consider
an application management platform,
it provides very easy entry into Amazon Web Services.
There's a couple of ways
that we could think about Elastic Beanstalk.
One way is that, you know, it's ideal for developers,
there are plenty of folks out there
that all they wanna do is write their application
and see it run, they don't want to bother
with managing servers or resources,
they don't want to install Engine ACS
or Apache or PHP, they just want to write their application
and hand it off and allow some other service
to manage the underlying infrastructure for them.
So in that case developers simply upload their application,
they can choose from a number of different platforms,
like Java, .NET, Node.js, Docker among others,
and by uploading their application
to the Elastic Beanstalk service,
the Beanstalk service will handle the creation
of resources and the ongoing management
of those resources automatically.
So, when we upload our application
we can choose to have it load balanced,
in which case Elastic Beanstalk
will create the ELB and manage that for us.
If we want our application to be auto scaled,
which we'll talk more about later,
we can choose that as well.
Elastic Beanstalk handles capacity provisioning
and monitoring, all automatically in the background for us,
there is really no degree of infrastructure management
that we have to worry about.
So, another way to think about AWS Elastic Beanstalk
is for IT teams that just have a lot to do
and we don't necessarily have time
to design, deploy and manage these resources independently.
Perhaps we have more important things to do
with other systems and we just want to take
a particular application that was handed to us
and use Elastic Beanstalk as a way to save time,
just get it into Amazon and trust
that the Elastic Beanstalk service
will keep that application highly available
and fault-tolerant.
The next service that I wanna talk about is AWS OpsWorks.
So again, if we go back to that scale
of convenience versus control
where on the very far side of convenience
we have Elastic Beanstalk
and on the very far side of control we have custom scripts
that we write, somewhere in the middle,
you know, giving us a little more convenience,
but still absolute control is CloudFormation
and then giving us more convenience
but slightly less control is AWS OpsWorks.
Now OpsWorks is somewhat similar to Beanstalk
in that it is an application
or what we might call a configuration management platform,
it's still going to give us a high degree of convenience,
but a whole lot more control
than we get with Elastic Beanstalk.
Now, when we talked about AWS CloudFormation
one point that I made there was that CloudFormation
does not impose any specific model of deployment
or operations, it's wide open,
we can do what we want.
But OpsWorks does have a model,
it's based on these ideas
of stacks, layers and applications.
These are based on Chef recipes,
so for those of us that might be familiar with Chef,
we have access to running Chef recipes,
which we might call configuration as code.
We're gonna get more control than Elastic Beanstalk,
but we're going to get a narrower range of resources
than we would have access to with AWS CloudFormation.
But we still get to say that, within our stacks,
we're going to have control over all of the infrastructure
that is being managed, the infrastructure
and the applications that are being managed.
Within a stack we have layers,
so each layer represents the particular types of instances
and related resources.
So one architecture might be classic three tier architecture
where you have load balancers out front,
you have application servers,
and then in the back you have database servers,
so perhaps each one of those is its own layer,
where one layer describes your load balancer,
another layer describes the particular types of instances
you want being used for your application
and then yet a third layer is describing the types
of database resources that you want.
And again, the all of those layers together
would be represented by one stack.
And then of course we have our applications.
So in that example, that second layer,
we would deploy an application to that layer
or to the instances in that layer
by leveraging Chef recipes that can control exactly how
and when our application gets deployed.
And then of course once we deploy our applications
into these layers and into these stacks
the OpsWorks service will continue to maintain
our application health by replacing instances that fail.
It can also help us to automate the management
around scaling and capacity provisioning as well.
So, OpsWorks is ideal for, you know,
IT admins, DevOps engineers,
those who want convenience in their infrastructures,
but want more control than what we get
with AWS Elastic Beanstalk.
So those are our application management services.