Earlier in this course,
we took a look at a quick overview of the essential
characteristics of the cloud.
Let's look at them in a little more detail.
And for this, I'm going to rely on the NIST special publications,
800‑145 and 146.
Those are free documents, and they give us a good,
fairly well‑recognized standard we can use.
The first of those essential characteristics was broad network access.
That means we have network‑based connectivity between the cloud consumer and
cloud service provider that is essential for this all to work.
Now the idea it was called the cloud in the early days was because
whenever we drew network diagrams back in the 1990s,
we always drew the internet as a cloud.
And so the idea of cloud services was really just the marketing
of saying we're going to use internet‑based or internet types of
connectivity in order to be able to communicate with then the
data hosting organization.
So the term cloud really referred to the internet.
So we know that for many organizations today,
we very much benefit from being able to use really
inexpensive connectivity rather than leased lines,
for example.
One of the things about the internet is that it is fairly redundant.
It's fairly robust.
Certainly there have been some outages and so on,
but usually they're only in a small region,
but there's always still that risk of a single point of failure,
the connection from the last point of the telecom
providers building to our office.
It's sometimes called the last mile or the subscriber loop.
The idea is that that may be a single point of failure.
So a large cloud service provider will usually make sure
they at least have redundant connectivity.
But even that can be difficult to maintain.
Things get moved around.
And there's been cases where companies believe they had
redundant fibers only to find that the fibers,
even though they are from two different telecom providers,
were actually in the same cable in the same trench.
The other thing is to make sure we have enough capacity.
We certainly have seen a great increase in the amount of data we transfer,
and we have to ensure that the cloud carrier will be able to
support peak demands of traffic as well.
The other challenge we have is that we have many
different types of endpoint devices, well,
even different types of mobile phones, everything from,
of course, different operating systems, but you know,
that's not all.
We have many devices connecting to the cloud now from all
sorts of Internet of Things devices,
and each of those can have its own proprietary languages,
its own proprietary needs.
And so when we look at the cloud carrier and broad network access,
we have to be able to ensure we can support all those
various types of endpoint devices as well.
The idea of on‑demand self‑service is the ability of
the cloud consumer to change their, should we say,
contracted usage of the cloud without going through all kinds of
administrative negotiations and contracts.
The idea now is that the cloud consumer can increase or
decrease their requirements for compute,
processing, storage, and network services automatically.
And we all know that many of us have done this.
You can easily add something on,
and you don't have to negotiate with a salesperson or whatever or
in any way interact with cloud provider staff.
And that's much better than the old mainframe days where we had to
negotiate for months to get a few more MIPS,
or millions of instructions per second, or a new logical partition and so on.
One of the greatest advantages, of course, to the cloud is resource pooling.
The fact that we used the example before,
we can have 15 companies that each had their own data center,
now they use one data center.
That gets rid of 15 air conditioning units,
diesel generators, backup batteries,
15 companies all managing their own physical access,
each one having their own spare parts.
No, we now share one facility in a multi‑tenant model.
Now this, of course, brings in a concern.
My data is in the same building as maybe my competitors data.
But the advantage is we have pooled resources.
Instead of me needing to have enough spare capacity to meet peak needs,
I am able to access a pool of spare capacity that I can use when I need,
and I release when I don't need.
So this, of course,
includes everything from equipment such as memory and processing.
But the other thing that many companies struggle with today,
of course, is staff.
Where do we find knowledgeable staff to support all of our IT needs?
Well, if I can use a cloud provider,
they have staff there that is dealing with different
types of IT support for many companies.
They have experience, and, of course, we have economies there of scale and so on.
We also have, of course, the network where we're able to use a shared network,
but this is, again, where we have to look at enough capacity and so on.
We share memory.
The problem with that is I want to make sure that there's no
residual data left on a piece of equipment that could then be
accessed in property by somebody else.
We can, of course, have a private type of cloud off‑site.
Of course, onsite we can have one, but when we deal with private offsite,
we're renting some floor space from a large cloud service provider,
and we have our own equipment in there that may be in a cage of some type.
And the cloud provider provides all of the physical facility,
network power, heating, ventilation, air conditioning,
physical access, but we don't have resource pooling.
In this case, the hardware, the memory,
and so on that we have purchased and installed at the cloud
service provider's premises is for us only,
and we don't have easy access always to additional resources.
So the idea here is we still have pooling,
but only the infrastructure, the building level we could say.
Now they, of course,
do have the advantage that they can provide staff and support for us.
Another of the advantages, of course, is rapid elasticity.
Rapid elasticity refers to the ability of the consumer
to be able to access or provision,
but also then to release service capabilities automatically,
part of this self‑service according to demand.
So the idea here is that an organization is able to acquire greater
bandwidth processing and storage capabilities very easily,
but also release them when they don't need them.
So we can meet peak needs at certain times of the year and not pay for
those pieces of equipment the times we're not using them.
We also have then the ability to do things like cloud bursting.
Maybe I have a private cloud,
but I realize I have a peak demand that I need additional resources,
so I would be able to actually migrate some of my services
temporarily onto a public cloud type of environment.
Measured service is important.
We pay for what we use.
That means we don't pay for what we don't use,
but it also means that quickly we can end up paying for a lot of
stuff we're using that maybe we shouldn't be.
So the idea here of building and monitoring is that I don't have the
initial capital expense of some of the equipment,
but I'm able to only pay for the resources that I'm
actually using at any one time.
Of course,
this doesn't apply to a private cloud because that's
my equipment that I've purchased.
The one advantage sometimes of that though is that if I'm
working with a large cloud service provider,
they're probably getting a far better price on a
lot of their hardware than I am,
and it could be we're even using them to provision equipment
for our private cloud if it's an off‑premise.
Again, there's so many different types of deployments.
The one thing that you'll see later on that becomes a
factor in this is what we call VM sprawl.
And this is where, as an organization, we spin up a virtual machine.
When we spin that up,
a certain number of resources are allocated to us for
our use of that virtual machine, and we start paying for those.
Let's say that a few moments later we don't need that and
the technician walks away and they leave that still as
dedicated resources that we pay for.
And this is a very common problem that companies have.
It's called VM sprawl.
We end up and I've seen cases of hundreds of virtual machines that have never
been used or haven't been used in years that company is paying for because
they're not cleaning up and releasing those as well.
So that's one of the disadvantages of measured service.
It's too easy to use too many resources without realizing
what we're using and what it's costing us.