Brien M. Posey: Hi, I'm Brian Posey. And today I
want to talk about why one size doesn't always fit
all, especially when it comes to hyper converged
infrastructure. Before I get going, I want to give
you some idea of where I'm going with this
presentation. I'm going to start out by defining
some basic terms. I'll be talking about things
like traditional infrastructure, and converged
infrastructure. And then from there, I'm going to
talk about how those compared with traditional
hyper converged infrastructure. I'll also be
talking about the pros and cons of hyper converged
infrastructure, and how disaggregated hyper
converged infrastructure improves upon standard
hyper converged infrastructure, or HCI, as it's
often referred to. Before I get into the main part
of this presentation, I just want to take a moment
and introduce myself and give you a little bit of
information about my background. Again, my name is
Brian Posey, and I'm a freelance technology author
and speaker. I'm also a 19 time Microsoft MVP.
Before I went freelance, I worked as a network
administrator for some of the largest insurance
companies in America. I was also the lead network
engineer for the United States Department of
Defense at Fort Knox. And I worked as a CIO for a
national chain of hospitals and health care
facilities. In addition to my IT background, I've
also spent the last several years training as a
commercial astronaut candidate in preparation for
a mission to study polar mesospheric clouds from
space. So that's just a little bit about me. Let's
get on with the presentation. So I want to begin
the discussion by talking a little bit about
traditional infrastructure. Traditional
infrastructure, at least for the purposes of this
discussion, could be thought of as the old way of
doing things. Although in all fairness,
traditional infrastructure is still very widely
used today. The idea behind traditional
infrastructure is that an organization purchases
all of the various data center components
individually. This includes things like servers,
storage, network components, and things like that.
Now, keep in mind that in a traditional
infrastructure, the organization has the luxury of
mixed matching components. So they might purchase
a server from one vendor, they might purchase
storage hardware from someone else, and they could
even purchase network hardware from yet another
vendor. Of course, they also have the option of
purchasing these components from a common vendor.
The point is that in a traditional infrastructure,
all of the components are purchased individually.
There are two main advantages to using traditional
infrastructure. The first advantage is granular
component selection. In other words, because
everything is being purchased individually, the IT
department has the option of choosing the exactly
the components that they want to use. If there is
a specific server that they think would be
especially well suited to servicing a particular
workload, then they can certainly use that server.
Likewise, with the storage and with other
components. However, this isn't the only advantage
to traditional infrastructure. The other advantage
is that component purchases could be spread out
over time. Now, this probably isn't something that
would happen during the initial acquisition. But
as hardware refreshes occur over time, those
purchases can be spread out. For example, a lot of
organizations will purchase a new server every
three to five years, well, server hardware can be
expensive. So at the five year mark, when the
organization purchases new servers, they might not
necessarily want to purchase new storage in the
same year. So they might do that the next year,
and then purchase new networking hardware the year
after that, and then move back to purchasing new
server hardware on the next cycle. So that way,
the organization isn't having to purchase all new
data center equipment all at once. So those are
the two main advantages to traditional
infrastructure. Of course, there
are also some significant disadvantages associated
with using the traditional infrastructure model.
One of the primary disadvantages to using this
approach is that there's no guarantee that the
components that you purchase are going to be
performance matched to one another. suppose for a
moment that you were to purchase two different
components. These can be anything maybe a server
and storage, or storage and networking, it doesn't
really matter for the purpose of this example. But
let's suppose that one of those components was
really high end, whereas the other was a bit more
modest in scope. In this example, the two
components are not performance matched. And as a
matter of fact, the more modest component would
hold back the performance of the high end
component. So what that actually means is that
even though you spent a lot of money on a high end
component, you're not going to get the maximum
benefit out of that component because the other
components can't keep up with it. So that's what I
mean when I say that components may not be
performance matched. Now it is possible to have
performance match components in a traditional
infrastructure. But in order to do so the IT staff
has to do a lot of hard work to make sure that
they're purchasing components that mesh well with
one another and that are performance matched, it's
not something that's going to happen
automatically. Another potential disadvantage is
that it might be impossible to take advantage of
new features. This is especially true in the
rolling refresh model that I described a moment
ago, in which new server hardware is purchased one
year and then storage the next year, the network
components the next year, and so on. Because when
you purchase new hardware, that new hardware is
likely going to include new features. But if
you're bringing that new hardware into your data
center to run alongside existing hardware, that's
aging and is going to be refreshed in the next
year or two, there's a good chance that the aging
hardware isn't going to be able to support the new
features on the newly purchased hardware. So
eventually, of course, you'll be able to take
advantage of those features when you purchase the
next round of new hardware. But that newly
purchased next round of new hardware is probably
going to contain new features as well that you
might not being able to readily use. So that's
just something to think about. One more issue
that's commonly experienced in the traditional
infrastructure environment. And an issue that I've
experienced personally several times is that
getting technical support can be difficult. This
is especially true if you're mixed matching
products from various vendors. Because what might
happen is that one vendor might blame another
vendor for the problems that you're having. If for
example, you purchase a server from one vendor and
storage from another, you might have the server
vendor blaming the storage vendor for your
problems, or vice versa. In any case, when vendors
start blaming one another, it can become extremely
difficult to get the help that you need and get
your issue resolved. So you can avoid a lot of the
vendor fingerpointing by purchasing hardware from
a common vendor. Now that I've spent a little bit
of time talking about traditional infrastructure,
I want to turn my attention to converged
infrastructure, which you'll sometimes see
abbreviated as CI converged infrastructure is
similar to traditional infrastructure in that it
uses components such as compute, storage, and
network. But one thing that's really different
between converged infrastructure and traditional
infrastructure is that the components all come
from a single vendor, and their performance
matched. Not only that, but the components are
actually certified to work together, and they're
sold as a complete system. Some people have
referred to this as the appliance approach to
networking, because you get compute storage and
network resources all as a package deal sold under
a single SKU. Now, it's worth noting that even
though the components are sold as a set, they can
be used individually if an organization is so
inclined. For example, an organization could take
the server from a converged infrastructure set and
use it as a standalone server if they had a need
to do that. But the big takeaway from converged
infrastructure is that the converged
infrastructure components are sold as a set from a
single vendor, and all the components are
guaranteed to work together and their performance
matched. Perhaps more importantly, the vendor acts
as the sole source of technical support. So you
don't have to worry about the whole vendor
fingerpointing issue. All the components come from
one vendor who guarantees them to work together
and that vendor also guarantees that they will
support those components should issues arise in
the future. So now I want to turn my attention to
hyper converged infrastructure, or HCI, as it's
often called HCI has a lot of similarities to
converged infrastructure. But there are several
key differences that you need to be aware of. Like
converged infrastructure HCI is sold as a bundle
from a single vendor.
The HCI bundle consists of storage, compute and
network resources that are all performance matched
and certified to work together. One of the key
differences between HCI and converged
infrastructure however, is that whereas converged
infrastructure components can be used separately
should the need arise. HCI is tightly integrated
into a node model. When you purchase HCI, you
generally receive an empty chassis, and a series
of nodes. And each one of these nodes is a modular
component consisting of compute storage and
network resources that plugs into the chassis. So
because the hardware is integrated into a node, it
can't be separated out and used individually.
Another major difference between HCI and converged
infrastructure is that HCI places a major emphasis
on software. As a matter of fact, the HCI vendors
ultimate goal is to make the hardware nearly
invisible, and focus almost solely on the
software. So having said that, though, HCI tends
to be designed for a very specific purpose. For
example, there are HCI deployments that are
designed specifically for virtualization. There
are also HCI deployments that are meant for
desktop virtualization, or for backup or for
various other purposes. The point being, though,
that HCI deployments are purpose built. So what
this means is that when you purchase an HCI
deployment, you're not just purchasing hardware,
you're also getting software. So take, for
example, an HCI deployment that's designed for
virtualization. Typically, what you would receive
with such a deployment is a server chassis,
multiple nodes to go in that chassis. And then you
would also typically receive a hypervisor, a
management component, something like Microsoft
System Center, Virtual Machine Manager or VMware
vCenter, server, something like that. And then you
would also typically receive a software component
that's designed to help you to manage the
individual nodes. So this is a hardware management
tool that's specifically designed for the hyper
converged infrastructure deployment. As you can
imagine, there are a number of advantages
associated with using HCI. One such advantage is
that HCI is designed to be really easy to deploy
far easier than a traditional system. As a matter
of fact, you can unbox an HCI deployment in the
morning, and be running workloads on it by the
afternoon. It's that easy to set up. But HCI is
also meant to be easy to operate. Remember, one of
the goals that the vendors have behind their HCI
deployments, is to place the emphasis on the
software rather than the underlying
infrastructure. So this means that admins are free
to focus on workloads things like virtual machines
or virtual desktops, rather than having to
constantly monitor the underlying hardware.
Additionally, HCI packages are often built on
commodity hardware. Now, in the beginning, nearly
all HCI packages relied on commodity hardware
today, there are some more premium packages out
there. But the fact that you can get HCI packages
that are built on commodity hardware, means that
you can help to keep the price low. And then
finally, HCI is meant to be scalable. Remember,
HCI consists of a series of nodes that plug into a
chassis. So anytime that you need to scale, all
you have to do is purchase additional nodes and
plug those nodes in. Now, yes, there is a limit to
the number of nodes that a chassis can
accommodate. But you can deploy multiple chassis,
and then fill those chassis up with nodes as you
need to scale your workloads. Even though HCI is
designed to be comparatively inexpensive, and to
be easy to deploy and operate, there are some
disadvantages associated with using it. So let's
talk about some of those disadvantages. One such
disadvantage is that some vendors don't allow the
individual components to be upgraded. Now, what do
I mean by that? Well, you've got to remember that
every vendor has their own way of doing things.
But some vendors don't allow you to do component
level upgrades within the HCI infrastructure.
suppose for a moment that you decide that your
servers need more memory, you may or may not,
depending on the vendor, be able to install
additional memory into a server module. Likewise,
if you decide that you need more storage space,
you might be prevented from installing larger hard
disks in side a storage module.
Another potential disadvantage is that because HCI
depends so heavily on software HCI is generally
designed for a specific purpose and might not be
able to be used for anything else. And then
finally, the node design limits your options for
getting better performance. Remember, HCI is
designed to be modular. So if you need to scale a
workload or you need increased performance, the
way that you would typically do that is by
purchasing and installing additional nodes. And
the same thing also goes for storage. If you need
increased storage capacity, then the way that you
would typically do that is by purchasing
additional nodes, each of which come with
integrated storage. This is going to be a
particularly important point to keep in mind as we
go along and begin talking about disaggregated
hyper converged infrastructure. Now that I've
spent a little bit of time talking about hyper
converged infrastructure, or HCI, I want to turn
my attention to a newer technology called
disaggregated hyper converged infrastructure, or D
HCI. For short. D HCI is sometimes referred to as
HCI 2.0. As you've probably guessed from the 2.0
designation, D HCI, is vastly superior to HCI. It
offers all of the same benefits that you receive
with HCI but it also addresses many of the pain
points that have come to be associated with the
original HCI technology. Perhaps the biggest
advantage to D HCI, which I'll go into in more
depth in just a moment, is that it gives you the
ability to pay only for what you need. You know,
over the last several years consumption based it
has become really popular, because it gives you a
pay as you go model and allows you to only pay for
what it is that you actually need. And that's
exactly what D HCI does for you. It delivers that
consumption based it pricing to your HCI
environment. So what do I mean by consumption
based pricing? Well, as you'll recall, one of the
big shortcomings to HCI was that the only way to
scale was to add additional nodes. And sometimes
this meant paying for things that you didn't
really need. suppose for a moment that an
organization realizes that they need to add
additional storage to their HCI deployment. Well,
typically, the individual hard disks aren't going
to be upgradable. So the organization has no
choice but to purchase additional notes. Now the
problem with that is that each node consists of
not just storage, but also compute and network
resources. So by adding nodes as a way of
expanding storage, the organization is effectively
paying for compute and network resources that it
really doesn't need. The advantage to switching to
a disaggregated model is that it allows you to
avoid paying for these hardware resources that you
don't actually need. In a disaggregated
environment, the individual components can be
upgraded individually. So if for example, an
organization realizes that they need to add
storage capacity, they don't have to go out and
purchase a new node, they can simply upgrade the
storage module instead. And the main benefit of
that, obviously, is that it reduces the
organization's cost. But a secondary benefit is
that the organization may end up having fewer
nodes that they have to manage. Because after all,
if you can increase your storage capacity without
adding additional nodes, then you're ultimately
going to end up with fewer nodes that you have to
take care of. And that reduces your overall
hardware cost, and it can reduce your licensing
cost as well. Another way that you may be able to
reduce your node count is by using more powerful
hardware. Remember what the original HCI
deployments were often based on commodity
hardware. The idea was to keep the hardware
relatively inexpensive, so that anytime
organizations needed to add capacity, they could
simply install an additional node. Well, with D
HCI. You're not necessarily limited to commodity
hardware. Yes, commodity hardware does exist. But
it's also possible to get powerful enterprise
grade hardware. So because the hardware can be
more powerful, you can end up needing fewer nodes
than you would if you were relying exclusively on
commodity hardware. So with that said, I wanted to
wrap up this presentation by pointing you toward a
resource that you might find helpful. I wrote an
article for techtarget on disaggregated hyper
converged infrastructure as it compares to
traditional HCI. This article is a technical
examination of what the pending demise of hyper
converged infrastructure, one Dido and the rise of
disaggregated hyper converged infrastructure means
for things like planning, buying, deployment and
management, and I've provided a link to the
article at the bottom of the slide. So I hope you
found this presentation to be helpful. I'm Brian
Posey. Thanks for watching.