- So now let's review a use case
of running container-based microservices.
Okay, so we have in a particular region here,
in this particular example, we're using us-east-2,
in the Ohio region, and we have a couple
of availability zones, and we will be leveraging
the Amazon Elastic Container Service.
And so, the first thing that we do
is we go to the ECS service, and we create a cluster.
Within ECS, a cluster is really a logical grouping
of applications that will be deployed together,
that will run alongside one another,
and you can have multiple clusters.
Now, it is possible to use Fargate,
which is a service that allows us
to deploy containers to that cluster
without managing any EC2 instances whatsoever.
And for many applications, that might be perfectly fine.
There are times, though, when you want access
to technologies that are only available on EC2 instances,
such as high-performing CPUs, GPUs, FPGAs,
or high-performance networking,
or more than 30 gigs worth of memory.
And so if we decided to run EC2 instances
within the cluster, then we could deploy those,
and you'll see here that we're deploying those
across multiple availability zones
for the sake of high-availability fault tolerance
being resilient to the loss of an availability zone.
And now these instances, we can configure these instances
to essentially join this cluster
and now, all of these instances,
however many we have, whether it's two or 20 or 200,
they, as far as centrally, become, through the cluster,
they become a single pool of resources.
And we don't need to worry about
all of the fine logic and steps necessary
to actually get a container running
on an individual instance.
All of that is abstracted away by the ECS service,
which is essentially a scheduler.
And so we deploy to the cluster,
ECS handles the fine details of determining
which instance is currently capable
of supporting the resources that we need for that container,
be it CPU, memory, volumes, and so on.
And then of course, if we're running EC2 instances,
then we would probably want to wrap those
in an Auto Scaling group.
We will talk much more about Auto Scaling later on
in lesson seven, but for now, suffice it to say
that Auto Scaling is, in the least,
a way for us to maintain a fixed number of machines.
We can do much more with it,
but in this particular scenario we may say,
well, we only want two EC2 instances in this cluster,
and if one were to fail,
then Auto Scaling could terminate it
and then replace it with a new one.
And then of course, as we deploy containers to the cluster,
the scheduler will then determine
which instance those containers run on.
So our containers will be deployed to these instances.
And so we would go to ECS
and we would configure a service or a task
and say, hey, we want this container to be running
and ECS will then do all of the underlying logic
in order to deploy that to a particular instance.
So we as developers,
we worry about deploying to the cluster.
ECS handles what it takes to actually
get that container running on an instance.
In this particular scenario, as it looks right now,
we have one container running.
So we have one instance of one application.
And there are plenty of times when that's appropriate.
You may have a background task
that does something very quickly, and then it goes away.
But you may have, in other situations,
you may want to run replicas of that application.
So you're running the same exact application
in two different containers, and so by doing that,
we can configure ECS to make that happen
and say, well, hey, I want two
or four or eight containers
or replicas of this application running.
ECS is also aware of availability zones,
and so it will make its best attempt
to maintain a balance of those containers
across those availability zones,
while also being aware of the capabilities
and the available resources of our EC2 instances.
And so again, this could be two replicas of an application
doing background processing
or it could be two replicas of a web API,
some kind of a web application
that's meant to run for a long period of time,
listening for requests and handling web requests.
And so in that regard, if these were part of
some kind of an API, a web application,
then we would probably want
to put them behind a load balancer
so that we can point our users to the load balancer
and then it would distribute traffic
among those backend containers.
We will talk much more
about load balancing later on as well.
And then of course, we need a way for the load balancer
to be aware of these containers.
And so by leveraging the load balancing
in combination with ECS,
we can configure the Elastic Container Service
to coordinate not only the placement of containers,
but also the registering of those containers
with the load balancer.
So ECS will tell the load balancer,
hey, you have these two containers available
on this port and for this particular application.
And then once that registration has happened,
then those containers become
what we would call targets for the load balancer.
Requests coming in could then be distributed
among those two containers.
And of course, we could keep going
and add other applications
that are also registered with the load balancer.
So we can run just about any number of applications
in this same cluster.
And so we have multiple replicas of multiple applications
all running side by side within the same cluster.
And then of course at some point,
we may experience a failure, some kind of an error
within our application.
It could be a race condition that caused the application
to just fail and the process to exit.
It could be the fact that the process
used more memory than what we allocated,
and then that process was killed.
And so either way, regardless of how,
if our process, if our application were to exit,
then the container essentially goes away,
and now we have a discrepancy here.
We have configured, in this case,
we've configured the Elastic Container Service
to maintain, say, two containers,
but now we only have one.
So ECS will say, all right, let's replace that one
with a new one.
It will notice that one has failed
and then replace it with a new one.
And so ECS is maintaining the containers.
If one fails, it replaces it.
We can also scale the number of containers
by updating the service within ECS.
And then Auto Scaling is doing that same thing
for our EC2 instances.
And then, of course, as far as EC2 instances go,
they don't have to be the same instances.
They could be a blend
of several different types of instance.
You could have a cluster that's comprised
of a C5 large, an M5 extra large,
an R5 triple extra large, right?
So you don't necessarily have to have
the same kind of EC2 instances.
There are a lot of advantages to that.
We can talk more about billing later on,
but the effects on billing could be
that you can always, always get the cheapest instance.
And we'll talk more about ways of getting,
saving money on EC2 later on as well.
And then of course we have developers that are writing code,
and we need to get that code deployed
as a container into this environment.
And so that would probably first start
with some kind of version control system.
We will talk more about code commit later on
as an Amazon service that solves this.
And then the pushing to this version control
or the, say the merging of a pull request,
that action could then trigger a CI/CD pipeline.
We have a lot of options here.
We could use Jenkins, we could use
third-party subscription services
like Travis CI, CircleCI, Bamboo.
The list goes on.
We also have an Amazon native service called CodePipeline,
which we will talk in detail about later on as well.
And then of course, so the end result
of that CI/CD pipeline
would be deploying a container
into this cluster.
And so essentially, the CI/CD pipeline goes to ECS
and updates an existing service with a new image.
So we're saying, ECS, hey, here's a new image.
Replace the existing containers
with new containers that are running my new version
based on this new image.
And so the benefit of containers
is that we can get a very fast deployment.
Another benefit is that we could even run,
not only can we run multiple applications side by side,
we can run multiple versions of the same application
side by side.
So if we wanted to support older browsers or older clients
for a longer period of time, then we could very easily
run multiple versions of the same application.
And then, of course, our CI/CD pipeline
is generating events.
At life cycles along the way, things are happening.
Things are passing, things are failing.
We might have tests that are running
and they pass, they fail.
We have builds that are happening
and they pass and they fail.
And we have deployments,
and they fail or they succeed.
And so we want to know
exactly what's happening along the way.
And the same with ECS.
Once the CI/CD pipeline passes,
and then ECS attempts to deploy that,
that process could fail or it could succeed.
And so there are all of these life cycle events
that are happening within these two services
and we would want some kind of a way
of getting those notifications
back to our developer.
So if our tests failed, get that information
back to the developer so they can write their code,
get it back into version control,
and push it through the process again.
If tests pass, but the build failed,
notify the developer so they can start it all over again.
And then, of course, if the CI/CD pipeline was a success,
it would also be possible for ECS to fail.
But either way, by piping in all of these notifications,
then we enable our developers to see
in pretty much real time exactly what's happening
along the way.
And so, as far as these notifications go,
we will talk more later
about the simple notification service
as a way of collecting these kinds of notifications
from different Amazon services
and then getting them to a single,
or even multiple endpoints,
whether it be a developer or an HTTP endpoint
that might be running in the third party or on premises.
And so we have a lot of options
in running container-based microservices within AWS.
We don't have to use ECS.
We could use, ultimately ECS is a scheduler,
and there are other schedulers.
We could run Apache Mesos on EC2.
We could run Docker Swarm on EC2 or Kubernetes on EC2.
What I like about Amazon ECS
is that it's a fully-managed service.
But then we also have ECS for Kubernetes,
which is also a fully-managed service.
So you have a lot of options.
If you would prefer Kubernetes as opposed to ECS,
then we can very easily do that as well,
and this process is basically the same.
Not a whole lot would change.
The only thing that would change
would be essentially the syntax
by which we inform ECS versus EKS
on how to do what we're trying to do.
And so I've been in situations and production scenarios
where we could go from
developer pushing, merging a pull request,
testing, building, publishing the Docker image to a repo,
and then deploying a container into production.
I've seen that whole thing take less than 10 minutes,
and it's really a beautiful thing
when you get to a point like this
where you can deploy to production at will,
at any time, and get those,
those notifications in real time,
allowing your developers to iterate very quickly.
So for anyone looking to deploy
microservices within AWS,
and especially if you're looking at containers,
I would highly encourage you
to look at all of the options around containers
such as ECS and ECS for Kubernetes.