- Now let's review some best practices.
As you move forward, getting into AWS
as you start thinking about architectures
that will go to AWS and be built within AWS,
as you start to explore in different services,
there are a number of best practices to keep in mind,
to help you ensure that you are building, you know,
the most performant, reliable, secure,
and cost effective infrastructure within AWS.
First would be, and these are in no particular order,
but first, enable scalability.
And so,
scalability allows you to meet demand
when you have it.
So there could come a time when you have more demand
or more work to do, than what you did the day before.
And so by enabling scalability by building a system
that is elastic, by building a system that can respond
to those kinds of changes and enabling you
to scale to meet that rise in demand,
then you can ensure that you will be able to meet it, right?
So you can imagine that if you have no ability to scale
and then at some point you have more demand
than you had previously,
then
at some point that system may very well
experience down time.
The next best practice is to think of our resources
as disposal, right?
So we're leveraging disposable resources
rather than fixed servers.
So coming from traditional IT,
we had fixed servers, we spent a lot of money
and a lot effort, getting that server in that rack,
and we had a particular budget and we're not going to do
anything more with it, we're not going to replace it
for another two to five years, maybe longer, right?
So in traditional IT we had fixed servers
which meant that our processes and our capabilities
were also fixed to some degree.
With AWS
by leveraging just the nature
of on demand resources means that we can now
treat those resources as disposable.
And that give rise to a level of flexibility and agility
and efficiency that we never really had with traditional IT.
By treating them as disposable,
then we have the ability now
to create temporary environments, right?
We no longer have to force our teams to wait in line
to test their applications.
Each team can get a temporary environment
for that application. When the test is done, throw it away.
Disposable resources
now frees us
to just replace the machine
instead of triaging the machine, right?
In traditional IT,
we would have to remote into that machine,
and spend a lot of time and effort, you know,
er, you know, er
essentially babying, treating that machine like our pet
and ensuring that it stays alive.
But in AWS, we simply, if there's an issue, we terminate it,
and allow automated processes to bring that machine
back to life, doing what it's supposed to do.
And if we need that machine in a different state
then we can go back to our machine images,
we can go back to configuration management
and define, and configure that state there.
And of course,
another best practice is to leverage automation.
We want to avoid manual operations
as much as possible, right?
Remember that humans, we make mistakes, you know,
we come to work without enough food, sleep,
we come to work with, you know,
maybe something going on in our lives
that is distracting us from the work that we're doing
and as a result, we make mistakes
and those mistakes cost time, they cost money,
or they potentially could cause some time of security issue.
So by leveraging automation, we can do things
more efficiently, we can do things more cost effectively,
we can do things more securely.
Another best practice is to leverage loose coupling.
Loose coupling, one classic example of loose coupling
is, instead of two different systems being inherently aware
of one another and dependent on one another,
we can put a queue in the middle.
Or a load balancer in the middle.
That way,
by removing the inherent knowledge of those
of each other
those systems can then run independently.
So ideally, if we have multiple systems
we should be able to have an environment
in which one system can be off line
without affecting another systems, right?
That's what loose coupling aims to do.
Where, by leveraging a queue, for example,
one system can publish a message to the queue,
another system reads from it.
That way if either one system is down,
the other system can continue to run.
Another best practice is to prefer services, not servers.
And so, what this speaks to is the fact
that AWS offers a number of fully managed services.
So, think about simple queue service, simple email service,
simple notification service,
think about the relational database service,
Elasticashe, Redshift, and so on.
All of these services
are meant for us
to offload the operational burdens to AWS.
And so by doing that,
we can lower our total costs of ownership,
Because we can have one, may perhaps a smaller team
and then that team is focused
on delivering actual differentiated value to our application
rather than being burdened by managing servers.
A few more best practices here
first would be
choose the right database, right?
A number of applications these days are actually making use
of several different types of databases, right?
It's common for an application to make use
of relational databases, no sequel databases,
in memory caches, and so on, right?
So choosing the right database for the right problem
is key to ensuring that we're going to get
a level of performance and security and durability
that we need in that data.
Another best practice is to avoid single points of failure.
I think that goes without saying
that something we've probably been familiar with
for a long time, but it's important to remind ourselves
that even within AWS, it's possible to have
single points of failure, right?
So, like we talked about earlier,
it's possible to run an application one EC2 instant.
But by doing so,
we have no way of mitigating or tolerating
a failure.
If that one instance fails, we will experience down time
until it's replaced.
And so instead of running an application on one instance,
we can run it on two, or three, or twenty, right?
And put them behind a load balancer
so that if one fails, we still have the others.
And that same pattern applies to a number of things,
not just EC2 instances.
And then of course we want to optimize for cost.
One of the main drivers for moving to AWS
is to lower our cost.
Believe it or not, it's not the number one driver.
The number one driver for most organizations
is to gain access to a level flexibility and agility
that we never had before.
But who wants to spend more money then we need to, right?
So, as we've seen throughout this course,
we have plenty of tools, and plenty of options
to choose in order to build a system that is reliable
performant, secure, and cost effective.
And of course, when it comes to optimizing
whatever we're optimizing for,
this is not something, you know, that we do every so often.
Optimization for cost or for security, or performance,
or reliability is not something we do, you know,
every month, every six months,
it's something that we do every day.
And that's another philosophy
to adopt when coming to AWS.
And that's something that is spoken to quite a bit
in the operation excellence pillar
of the well architected framework.
That optimization is an on-going, constant effort.
And I can speak from personal experience,
that in running many different types of workloads
in production from many organizations,
and helping organizations to strategies
and plan for the cloud,
that this becomes something that we do everyday.
That everyday, you come to work and go:
"how can I make this better than it was yesterday?"
And we have the ability,
looking back on all the things that we've talked about
you can see that we have an easy ability to change our minds
at any time.
If I come in today and I look at the system and I ask
"how can I improve this today,
how can I make it better than it was yesterday"
I don't have to wait for my next budget refresh.
I don't have to wait for, you know, hardware recycle.
I can do it today, I can make changes today.
No decision that I've made so far is set in stone.
And then lastly here, one more, a couple more,
is leverage caching.
We talked about caching when we covered cloudfront.
Remember that with cloudfront we can cache
static and dynamic content at the edge location.
We also talked about caching with elasticache.
With elasticache, we can cache different types of things,
such as data-base result sets in memory.
And the whole point of caching
is to deliver things to the end user faster.
The whole point of caching
is to improve the end user's
experience by lowering latency,
by getting them what they're looking for faster.
And then lastly,
the last best practice that I'll leave you with
is security in layers.
And remember that there are, when you think about layers,
we could imagine that there are different layers,
and I always imagine that there would be
the account layer, there would be the network layer,
and then perhaps the application layer, right?
And so, remember that we are operating within
a shared responsibility model.
The most important thing in there is for you
to be aware of what, whatever you're using,
whatever service you are making use of,
it's important for you to be aware
of what is your responsibility,
versus what is Amazon's responsibility.
And those things change.
According to the service that you're using
and according to the features that you have opted into
And so at the account layer
we have users and groups and roles,
we have policies that can control authorisation.
Within the network layer, we have routing controls,
to control the flow of traffic, to and from the internet ,
or not.
We also have different firewalls mechanisms
like network access control lists,
we have security groups that can open and allow
different types of traffic on different ports.
And then of course, within your application,
your application may make use of temporary credentials
in order to access Amazon's services, right?
So the bast practice here is to ensure
that you are applying security,
the appropriate security features
in each of those layers, right?
So again, as you move forward,
getting to know Amazon web services more,
as you start to explore these services,
and build these services,
keep these best practices in mind.