Now I will say that services like ECS,
which we used in the deployment section
can help us with these problems.
And to some extent, we already used
the help AWS ECS provides without even noticing it.
For example, the ECS service will automatically check
the health of our containers,
so it will see if there are still up and running
and it will automatically restart containers
when they crash.
And that is something we did see in action
throughout the deployment section when our container,
for example, failed to connect to a database
and therefore was restarted and restarted and restarted.
So AWS offers this to us, and when using ECS
it's very easy to take advantage of that.
And even though we didn't really utilize that a lot,
AWS ECS, also would help us with auto scaling.
So with dynamically, increasing and decreasing
the number of container instances in the end,
which are up and running
to help us handle incoming traffic spikes, for example.
And it then also has a tool called a load balancer,
which we also did set up to have a unchanging IP address
or a domain we could use for testing,
which does actually not just give us this domain,
which never changes,
but which would also ensure
that if you got incoming traffic,
that traffic is split evenly
across all running container instances,
in case you have more than one running container instance.
So services like AWS ECS
already help us solve the problems I just outlined,
which is another strong reason
for turning towards such managed services
instead of manually deploying everything.
But of course, we still have one downside,
one disadvantage when using a service like AWS ECS,
we are basically locked into that service.
If we use a specific cloud service by some cloud provider,
no matter which cloud provider that is,
we are kind of locked into that service.
At the example of ECS,
the problem which we have
is that we need to configure everything as defined by AWS.
AWS, for example, things and clusters, tasks and services,
and we need to set the options, AWS lets us set.
So whatever we set up there will then work for AWS ECS,
and we can define it here in this visual user interface
in the AWS console or all the work with a command line tool
like the ecs-cli, which we haven't used,
but we don't have to use that console if we don't want to,
we can also use the command line
to create all these resources.
And we can also actually define configuration files
where we basically write down the configuration
we wanna have for our ECS cluster and tasks.
And then we can use that AWS ECS-CLI to pick up
on these configuration files
and create the appropriate cloud resources based on that.
So we don't have to use that UI,
we can also use conflict files and therefore maybe speed up
the entire deployment process,
but we will always be locked into this specific AWS service,
which means if we wanna switch to another service
by another cloud provider,
the conflict files we wrote for AWS ECS
won't work there because this is AWS specific.
The settings defined here will work with AWS ECS,
but not with some service
offered by Microsoft Azure, for example.
So we're locking ourselves into AWS and AWS ECS
if we start working with it
and we need to learn the specifics of that service
the specific terms and the configuration options we can set.
And if we wanna switch to another provider,
we have to learn the specifics of that provider
and the service offered by that provider,
and we manually have to translate the configuration
we used for AWS ECS to that service by some other provider,
if we wanna switch.
So just knowing Docker won't be enough,
we also have to learn about AWS ECS
or whichever service we're using.
Now, of course, this might be totally fine
if you know that you wanna stick with AWS,
you're happy with it,
and once you learn how to work with ECS,
of course, that's just a skill you have
and you will be fine.
So this might not be a huge problem necessarily,
but of course it can be an issue,
and that's where Kubernetes us can help us.