-: In the last section
we created a new Elastic Beanstalk Environment
for our multi container Docker application.
It looks like my application has successfully been created
but before we start working with this thing at all,
I wanna have a quick discussion on something
that it seems like we kind of left out
in all of our Docker run file stuff,
and all of our Travis stuff so far as well.
So inside of our Docker run file,
like I said at the end of last section,
we appear to have no references to any containers
that are running Postgres or Redis
as we had previously set up
inside of the Docker composed file.
So let's talk about why that is.
All right, so I'm gonna show you a couple diagrams.
I wanna first remind you about the overall architecture
of our development environment.
We had said, yeah
we got the Nginx, the Express, Worker, all that stuff.
And then most notably we had the Reddest container
and the Postgres container as well.
So in the development environment
we were running these two data services
inside of containers.
But as we move over to a production environment,
we're going to change up this architecture
in a pretty significant way.
Now, we're gonna make this architecture change
for a very good reason.
So let me show you first a diagram
that's gonna tell you a little bit about the architecture
and then I'll tell you many reasons
about why we're gonna take this alternate approach
in production.
Okay, so first off the diagram
here's what our architecture is going to be
in the production environment.
So we're still gonna have the Nginx routing server,
the Nginx file server, the Express API,
and the worker and those are all going to be running
inside of our Elastic Beanstalk instance.
We've already wired up the definition
for all four of these containers
inside of that Docker run AWS.JSON file.
The instance of Redis and the instance of Postgres,
that are going to be serving data for our application,
however,
will not be inside of the Elastic Beanstalk instance.
Instead, we are going to rely upon two external services
to fulfill all of our data needs for our application.
The two services that we're going to use are
called AWS Relational Database Service,
very frequently abbreviated as simply RDS,
and Amazon ElastiCache.
These are two services that are kind of general in nature.
And when I say general in nature,
I mean that they're not customized specifically
for using with Elastic Beanstalk,
they're not customized to be specifically used
with containers.
They can be used with just about
any type of application out there you can think of,
whether or not it uses Elastic Beanstalk,
or whether or not it uses containers.
So they are general data services
that can used with just about any application.
All right, so let's talk about why we're going to be using
these services to host our copy of Redis
and our copy of Postgres.
So there's a couple of very good reasons
that we might choose to use these outside services
rather than creating our own containers manually
and using our own containers for housing
Redis or our Postgres instances.
So in the case of ElastiCache,
got a couple of very good reasons to use this service
as opposed to making our own copy
of Redis and hosting it inside of that instance.
So first off,
ElastiCache is going to automatically
create an instance of Redis for you.
This is a absolute professional grade Redis,
so it's got all the settings, all the configuration,
that you would ever expect to have
in a production deployment of Redis.
And the common theme here is going to be that
there are many settings set up by default for you,
that are probably going to be very beneficial
for your application that you might not even know exist.
In other words, you and I might not be Redis experts.
We might not really know how to use Redis properly
in a production environment
but Amazon has a lot of engineers,
like entire teams of engineers,
who are absolute like doctorates,
like they have their PhD essentially on Redis,
and they know exactly how to set this thing up
for a production deployment, or a production environment.
And that's kind of the running theme
around why we would choose to use
these external services for managing all of our data.
These teams at AWS, they know how to set this stuff up
and they know how to manage it extremely well.
Now, above that, with ElastiCache,
it's extremely easy to scale.
So as you might imagine,
if our application one day got really really popular
and we saw that for whatever reason our Redis instance
was crashing all the time
because our container,
or the hardware allocated to our container,
was insufficient,
well that might be a little bit of a pain
for you and I to scale.
We would have to figure out some way to allocate
more resources to the container,
we would have to figure out some way
to restart the container without losing any data.
Definitely a little bit of a headache there.
But with ElastiCache, we can essentially just say,
hey, I think we need some more hardware here,
I think that we need to upgrade the amount of memory
or the processor or whatever it might be.
And ElastiCache is going to automatically
manage that upgrade path for you
and you don't have to worry about
doing a bunch of manual configuration or stuff like that.
We get built in logging, built in maintenance,
if there are security patches around Redis,
AWS is going to automatically apply them for you.
You're going to get automatic logs generated.
You don't have to worry about getting logs
out of your container
and somehow reporting them to some outside service.
In addition, very closely related to the first item up here
that we spoke about,
yeah, we're definitely concerned about security
inside of our application,
and we've done a couple of things
to upgrade the security of our containers.
However, with ElastiCache,
chances are they probably have a better idea
around security than we do.
And so I kind of feel a little bit more comfortable,
kinda delegating all these responsibilities off to AWS
rather than trying to manage security on my own
for this particular service.
Now, this last one right here
this is one of the real big ticket items,
this is one of the big reasons
that you might choose to use when these
outside data services.
We have a application architecture set up right now
that is completely reliant upon Elastic Beanstalk,
and totally reliant upon making use of containers.
I don't know what our application life cycle is going to be.
In other words, I don't know how long my application
might need to be deployed and maintained.
It's entirely feasible that at some point in time
in the future, we might decide to migrate off
Elastic Beanstalk and go off to some other service.
And when we do that migration
it's going to be a lot easier to migrate away.
If we are making use of ElastiCache,
because it's completely decoupled from Elastic Beanstalk.
ElastiCache doesn't care where you're making a connection
to it from.
It could be from Elastic Beanstalk,
it could be from some Kubernetes cluster
it could be from some random EC2 instance.
All ElastiCache cares about
is that you are making a connection to it.
And so it'll be much easier to make changes
to our application in the future
or entirely change the architecture
if we're making use of this outside service.
Now, essentially all the same points apply
to the Relational Database Service as well.
Everything totally related as well.
Yeah, they got these teams who know
really, really really well how to set up Postgres
for production deployments.
They make it really easy to scale, log, security.
Now, the real big ticket item here, however,
is this point right here.
So something that does not get very frequently covered
in a lot of courses, even courses that I make,
is making backups of your database.
In other words, making a backup of all the records
in your database in case anything goes wrong
at some point in the future.
Setting up automated backups
is not the easiest thing in the world, and in many cases,
if you wanna get some easy service to do it for you,
you actually have to pay a little bit extra for that.
And I'm talking about if you're using
like a third party add-on
that's going to attach to your container
and make automated backups or whatever might need to happen.
AWS RDS, or Relational Database Services,
has automated systems for taking backups for you.
And if you ever decide,
oh no, we've got some data corruption,
or we did something really, really wrong
inside of our application in the production environment,
it's like one or two button clicks
to roll back your database to one of those backups.
And so with AWS RDS and makes life just incredibly
easy when you start thinking about maintenance of data
and data security.
So that's kinda my spiel.
It might sound like I'm a huge fan boy of AWS
or something like that.
In reality, no, I'm not a huge fan of AWS one bit,
to be totally honest with you.
I think that many aspects of it
are rather challenging to work with,
I'm not the biggest fan.
However, I still do recommend making use
of these outside services
anytime that you're working with say Postgres or Redis
or Memcache or any type of outside data service
I do recommend that you try making use of these services
wherever possible,
'cause they're gonna do a lot of stuff for you
that is by default kind of challenging to do on your own.
Now, one last thing I wanna say here,
yes, these services do cost a little bit of extra money,
but to be honest, if you are making a serious application,
we're talking about like dollars per month
for running a Postgres instance,
and dollars per month of running a Redis instance.
As a software engineer your time is worth money,
and it might take you an entire day or an entire week
to set up and maintain Postgres and Redis
in a very appropriate fashion inside of Elastic Beanstalk.
And so that one day or that one week,
well, that time that you're spending, that is money.
Your time is worth money. And so at the end of the day,
it kind of is worth justifying to say,
yeah, we're gonna spend like 10 bucks or 20 bucks per month
on a Postgres instance hosted through RDS,
rather than trying to maintain it on our own.
All right, now, very last thing I wanna say here,
so having said all that,
yeah, I'm kind of advocating making use
of these automated services, but having said all that,
this is a course about getting a application
running using containers.
So our next project is going to set up Redis and Postgres
in a production environment from scratch.
We're not gonna make use of any external service.
So although I do recommend
that you use the external services,
I still want you to understand
how we can set up an application
that doesn't use them at all,
if you want to essentially strike it out on your own.
Or if you're ever hosting on an environment
that doesn't provide these kind of managed solutions.
For example, like let's say DigitalOcean.
DigitalOcean doesn't have automatically managed copies
of Redis or Postgres available
and you would have to manage those instances yourself.
So we are gonna go through an example
of how you would set all this stuff up on your own
in a production environment as well.
But at the same time in this example,
I just wanna show you both ways.
That's pretty much what it comes down to.
Okay, so enough of me rambling on about this.
Let's take a quick pause right here.
When we come back to the next section,
we're gonna start setting up a instance of ElastiCache,
instance with Relational Database Services,
and then learn how to wire them up
over to Elastic Beanstalk
So quick break and I'll see you in just a minute.