Now, I do have a note about using databases
with Docker and deploying them most importantly.
You absolutely can manage your own database containers
as we're doing it at the moment.
Because at the moment we do have this MongoDB container
up and running.
And as you've learned,
also when we used it locally on our host machine,
this container internally creates a database, starts it,
and allows us to connect to it through port 27017.
Now, we can absolutely use
and manage our own database containers,
but there are a couple of potential downsides and issues.
For example, scaling and managing availability
can be challenging.
Since it's a database, we need to be prepared that multiple
read/write operations could occur simultaneously.
So we might need multiple database containers
with the same configuration and working on
the same database files up and running simultaneously,
which poses brand new challenges.
Because we of course also then need to ensure
that these different database containers work
on one and the same database.
So that they are synchronized across each other.
And one database is not managing data
which another database doesn't know.
So scaling database containers means more
than just running two containers at the same time.
In addition, and related to that,
we could have problems with performance,
especially during traffic spikes.
Especially if we don't handle scaling
and we just have one database container
which you should do all the work.
And even if we leave aside this performance scaling issue
another problem we could be facing is that we have
to take care about backups and security.
That means that we of course wanna ensure that our data
is secure and can't accessed without our permission.
And we also need to ensure that the data
is backed up regularly so that we can roll back
to an older backup in case some data should be lost.
And these are all database-specific challenges
we have to be aware of.
And we ultimately have to tackle
if we are using a database in production.
Locally on our host machine,
these problems all don't matter.
We don't have traffic spikes there.
We don't care about backups there,
but in production they do.
And that's why for databases specifically,
you again might wanna consider switching from managing
your own databases and bringing your own database containers
to a managed database service.
For relational databases, like MySQL databases,
DREs, AWS RDS for example.
Another service offered by AWS.
RDS stands for Relational Database Service.
For MongoDB, there is MongoDB Atlas as service offered
by the MongoDB company.
And this is something which you might wanna consider
if you are building your own application.
You can always manage everything on your own.
It's the same discussion we had earlier
about deployment in general.
But with that,
we are back to this trade off here
in the bottom right corner.
You can manage everything on your own.
And if you know what you're doing,
this might be perfect because then you have full control
and you can fine-tune everything exactly as you need it.
And you might be able to achieve a great solution.
But if you're not an expert on the topic,
you might mess things up.
You might end up with a suboptimal
and maybe also a more expensive solution.
And that of course would be bad.
That's why as I've just mentioned for relational databases
you could look into services like AWS RDS,
of course other cloud providers
also have their own solutions for that.
And for MongoDB specifically, you can visit mongodb.com,
the website of the MongoDB company
where you don't just learn how to work
with MongoDB and how you could install it locally.
But where you can also dive into MongoDB Atlas.
One of the solutions they are offering,
which is a cloud-based MongoDB service
which already takes care about scaling, performance,
and backups for you.
And which therefore makes using MongoDB very, very easy.
This has nothing to do with containers.
I mean, maybe they use containers under the hood.
We don't know, but you don't need to bring
your own Mongo container for that.
But it will make working with MongoDB way easier for you
if you're not a MongoDB administration expert,
which you most likely aren't.
I ain't one either.