So, this Do-it-Yourself approach
has a couple of potential downsize at least.
And that is what I meant when I mentioned trade-offs
at the beginning of this module.
Sometimes you have to choose whether you want full control
and also the responsibility that comes with it
or if you are fine with less control
because you'll have the benefit of less responsibility.
And in this concrete scenario,
this could mean that we switch away
from this totally self-managed service
or this self-managed remote host
to a third party managed solution.
So instead of running our own machines, for example,
running our own EC2 instances,
we might wanna use a managed service.
Because as I mentioned already
for our own machines, our own remote hosts,
we have to create and manage them ourselves.
We have to keep them updated
and possibly also monitor and scale them ourselves.
If our application grows and we get more incoming traffic,
we have to ensure on our own
that we somehow deal with that traffic
and we ensure that our application doesn't go down.
Now, don't get me wrong,
this is not always bad.
It's great if you have that knowledge,
if you are an experienced administrator and cloud expert,
but if you're not,
you risk running a setup which might be unstable
and maybe also insecure.
And that's why we might go for a managed service,
for managed remote hosts or machines as I like to call them
and here AWS ECS could be a service that helps us.
ECS is a service offered by Amazon
and it stands for Elastic Container Service
and as the name implies,
it is a service that helps us with managing containers.
With launching them, running them,
monitoring them and so on.
And again,
just to make this clear,
other cloud providers also have similar services.
For example, Microsoft Azure also has container services
which make managing containers easier
and which take care of that heavy lifting
and that server management for you.
So it's not just AWS,
I'm just picking AWS as an example here.
Now, the advantage of using such a managed service
is that the entire creation management,
updating, monitoring, scaling,
all of that is simplified
because a third party service, in this case AWS,
takes care about it
and we just need to tell AWS
how it should take care about that.
And therefore using such a managed service is great
if you simply want to deploy an application
or in this case a container,
because you then don't have to worry
about all the detailed setup work.
And that's what I mean.
We have less controlled then,
but we also have less responsibility
and less chances of messing something up.
However, I also wanna emphasize at this point
that switching to some managed service,
no matter if it's by AWS or by any other provider,
means that you don't just use Docker anymore,
instead, you now use a service provided by a cloud provider
and you have to follow the rules of that service
you could say.
That simply means that deploying containers
and running containers
is now not done with the Docker command anymore
because now we don't install Docker on some machine anymore
that's the entire idea behind a managed service,
but instead it means that we now will need to use the tools
the cloud provider gives us
for the specific service we wanna use.
And I will show this at the example of AWS ECS.
This Elastic Container Service by AWS in the next lectures.
It's just one possible example
and therefore these steps shown there
will only work for that service.
But of course I can't cover every service
by every cloud provider in this course.
also since this is not a cloud development course
but a Docker course.
I still wanna show you over the next lectures,
how you could take what you learned
and migrate that into the rule set
a specific service gives you or forces on you
so that you see how you still work with containers
and images,
but how you now use them in conjunction
with such a managed service.
And therefore what you'll learn over the next lectures
will help you not just with this specific service,
but with any service by any cloud provider
because they all will have their own documentation,
their own rules,
and you need to be flexible to follow these rules.
And you will see an example over the next lectures.
And that again is dad's trade off.
You can manage everything on your own.
You can set up a remote machine on your own
and install Docker on it
and run all these Docker commands you already know,
but you don't have to manage everything your on your own.
Or you use that managed service
as you will see it over the next lectures
and you have to follow their rules so to say.
Nonetheless, we'll of course still be working
with containers
and therefore what you'll learn about that still applies.
That doesn't change.
It'll just be some different commands which we execute.