Let's look at the building blocks that make up cloud implementations.
Building the cloud is a combination of many
different components working together.
It's based, for example,
on software, as in applications; as well as operating system and virtualization,
for example,
and this includes the applications that face the customer, as
well as the applications used to operate the various operations
such as application program interfaces, drivers and utilities,
operating systems, and hypervisors.
We, of course, rely a lot today on databases and the database management
system that is provided by many of the cloud providers; the hardware that
all of these systems run on, and that of course includes both compute and
storage type of hardware systems.
We rely a lot on networks for all of this to work, broad network access
being one of the essential characteristics of the cloud.
We can understand that the larger the attack surface,
the more difficult it is to defend, and we can see that a cloud
implementation has actually a fairly large attack surface.
There are many different angles of attack that could be used just
from a perspective of equipment and software,
not even looking at things like physical security
and people on top of all of this.
A lot of the advantage that comes from a cloud implementation is
getting all the pieces working well together.
We can call that service orchestration,
that is the arrangement, coordination, and management of all of
these system components that are used by the cloud provider to
provide services to the cloud consumer.
We can see that we've divided this up into three major levels.
The service layer,
which provides access interfaces to the cloud consumer, or user, and of course
that varies a little bit depending on the type of model,
whether it's Software, Platform or Infrastructure as a Service.
We then have the whole idea of the cloud is really resource abstraction.
The user does not need to know or even be aware of the type of hardware
being used to support cloud services. They don't need to know the
operating system, because there's a level of abstraction there that
really insulates and isolates the user,
the cloud consumer, from the cloud service provider, and this resource
abstraction and control layer is an important thing.
We are no longer bound by the type of operating system or
the piece of hardware we're connected to.
Instead, we can be connected to many,
many different pieces of hardware and easily move from
using this piece of hardware to another,
storing our data here,
to storing data somewhere else, and the cloud user doesn't really care
or have any knowledge of where their data is being stored in that
perspective. They may know the geographic location, but not
necessarily the piece of hardware itself.
And this allows the flexibility, this allows us to ensure
that even if one piece of hardware fails,
we can still have service through the other pieces. And, of course,
this resource abstraction is done by the cloud provider in order to
manage the various system components, and they can do this through
things like a hypervisor, for example, and the use of different virtual machines.
Then we have the physical resource layer,
the actual hardware that our system runs on, as well as
the building it runs in, the facility.
And this level includes things like the central processing unit,
networks, firewalls, storage, and heating ventilation and air conditioning.
And this is a diagram used by NIST to try to give an
overview of service orchestration.
We use many different terms when you talk about cloud services, and these
are things you'll see as we go through the course here,
the idea of portability, vendor lock‑in, cloud migration,
cloud backup, hypervisor, virtual machines,
containers, and all of these are different tools used in the
implementation and operations of the cloud, and ones that we should
certainly be familiar with that we will look at in more detail.
So the building blocks of the cloud,
the building that our systems are running in, and of course that requires clean,
reliable power; heating, ventilation,
air conditioning; and of course physical access controls.
We have the hardware that our systems run on, as well as the operating systems,
the hypervisor, network, application program interfaces,
applications, and of course the most important part of all this, the whole
reason for all of this, is data, so we can process and store our data so it
can support business and legal requirements.
Then we have the users. The users may be our employees,
but also the users could be our customers, people we have no control over,
really.
One of the things that's important with all of this is that
we have a well‑architected framework.
In other words, we build all these components so they work well together.
The goal of a well‑architected framework, as defined actually in
this case by Amazon, is operational excellence,
security, reliability, performance efficiency, and cost optimization.
It is important that we can continue to use our cloud services, and
therefore, sustainability is important as well.
So this is how, for example, a good cloud implementation should work.
It works operationally, securely, reliably, for example. The Key Points Review.
In many cases,
it is only when a business uses a cloud access security broker,
or CASB, that they may become aware of how many pieces of cloud
services they're already using.
Many businesses don't actually know how much of the cloud they already are
using, and that of course means that they may not be as aware of some of
the security implications of that as well.
We know that migrating to the cloud is definitely an
excellent option for many organizations,
but not all, and things have to be carefully thought out, what
are the risks, what are the business requirements, before I do
a mass migration to the cloud.