We are here to uncover the good, the
bad and the ugly of the It industry.
My name is Robin Jones, and
this is Convergence by cato networks.
One of the most mysterious, serious, and
yet popular buzzwords in It today is
cloud computing or simply the cloud.
But what is the cloud actually?
How does It architecture affect the
way your organization can grow?
Should all your applications run on a
public or private cloud or both?
In this episode, we will leave you with the
knowledge you need to have a friendly conversation with
your colleagues about the main cloud architecture types.
We will be hosting dane Jackson, Kato
Network senior Manager of Professional Services.
To demystify the enigma of the cloud.
Let's get started.
Welcome, Dane.
Thank you for joining me today. Thanks for having me.
Great to be here. A pleasure.
So for all the viewers at home,
let's learn a bit about yourself.
How did you get to where you are today?
What is your journey?
I've got a pretty diverse journey of my
career over the last 20 years or so. In It.
Started off in higher education here in the
United States, working for a large university.
Moved around a little bit there and got a
lot of really great exposure from some I believe
we closely call them Unix gray beard.
The guys who I'm talking about know who they are.
So we got a really great opportunity
at the very large scale university.
Academic systems.
Moved on from there into strategy consulting, merger
and acquisition, carve out, energy and utility.
Got a lot of great experience on strategy
and how to execute on major transformations around
organizations that are either splitting or emerging together.
I feel like that really kind
of defined my business acumen.
Moved on from there into large enterprise, supporting one
of the largest hotel chains in the world.
Got a real great understanding of scale and
how to operate at a global level.
I feel like if the combination of those things, while
it's not really a straight line in a career, really
helped define who I am today and feel like it
kind of maybe by accident gave me a really great
foundation to continue building my career.
That is great to know.
And from your career path, it seems that you are what
we call in the industry a seasoned veteran or an expert.
So I was wondering if there are new
grades for me than the beard here. It's a journey.
Eventually we all become greybeards.
You either live long enough to defeat eunuchs
or you become the eunuchs master yourself.
That's just generally how tech works.
So I'm relatively well, what's the term?
I'm quite a bit of an idiot and I'm still learning
the ways of technology and security and all that fun.
So I want to start by asking you kind of an
embarrassing but simple question, and that is what is the cloud?
What does it mean to us?
I actually really like this
question for the wrong reason.
It's because everybody has a different answer to it.
When we first started talking about doing the podcast,
I had to really stop and remember that we've
been asked this question in probably a decade.
What is the cloud?
Because when you Google it or when you
search around, you find 2030 different answers.
Some are similar, some have just nuanced changes,
while others are just like dramatically different.
And a lot of it depends on
the perspective of who's saying it.
Are they an enterprise talking about
using Cloud host by somebody else?
Or are they actually like a cloud provider talking
about the services they offer to their customers?
In my mind, and it's most simple way of putting it,
cloud is just a more modern way of offering It services.
It's just the next generation of the way we do
things evolving from classic standalone servers through the various iterations
into Cloud being the new way to do it.
I think realistically, at a business level,
cloud is all about speed and agility.
The old ways we talk about running servers, we
literally back in the day, I want to spin
up a new Microsoft Exchange Server, new database server.
You literally had to make a phone call and wait for
somebody to grab a server out of a box, rack up
Rails, put the thing inside the Rails, powered up image, it
connected to the network, all this handcrafted stuff.
And that's what we wanted to get away from
because it was slow, it lacked agility, it would
take weeks, if not months to provision and the
business could no longer afford that kind of approach.
It became too critical to the business
to be working at that level. That sounds great.
So you're saying that the idea of the Cloud is to
abstract from physical to a logical space, is that correct?
That's a component of it.
I mean, I don't think necessarily
Cloud has to be that abstract. In my opinion.
You can run Cloud on say, bare
metal where you're doing just in time
provisioning and you're doing other things.
The key becomes how do you achieve speed and agility?
Which could be Provisioning auto Provisioning servers
where they just boot up, they grab
a Pixie boot, they fully image.
And the key for speed and agility may be
that you just need to have 30, 40 servers
sitting in Iraq ready to go unprovisioned and you
have to keep more lead, more lead resources available.
So it's not explicitly about virtualizing and getting
away from physical as much as it's about
changing the way we build out our infrastructure
in my opinion, in order to achieve it.
That said, that's most often achieved through virtualization
and those kinds of functions, whether it's at
a virtual machine level or it's thinking more
newer constructs like containers and stuff like that.
The big thing in my mind that I used to define Cloud
is I have my three core tenants that I define cloud with.
Like I said, you Google around, you'll
see people who have different tenants.
They may be similar, they may be different,
they may have more, they may have less.
But realistically I define it as on demand
consumption is the big one of me.
You just have to be able to click a button
and start consume no more than submit the ticket, wait
for the box to get open, wait for the server
to get put up in the rack, etc. Etc.
Sorry, you describe the cloud or Uber
eats there because that's generally like you
can abstract this to your food too.
As long as they're fast, they got to be scalable too.
So that's my next one there.
You got to be highly scaled, so you got to have a
lot of drivers bringing that food to all the people too.
So on demand consumption, and a big
part of on demand consumption is automation
is a core component of that tenant.
And then monitoring observability.
You want to be able to see this thing
cradle to grave from the moment you start deploying
it while you're running it to when you go
to decommission whatever it is running on the cloud.
That's the core attributes of consumption.
Highly scalable, adding capacity can't be a big thing.
You just have to be able to
scale repetitiously consistently without major disruption.
I think I quoted it here in my notes.
Scaling out the platform cannot be a big deal,
it just has to be part of operations.
You mentioned earlier that the cloud can sometimes be
deployed on Tim and you can pixie boot things.
So what would be the difference between say,
a data center and a private cloud?
Well, private and public really have
nothing to do with cloud.
It's just a matter of where the stuff is running.
So even some of our biggest public
cloud providers offer bare metal hosted services.
That's becoming kind of a thing for people who
are doing especially like high performance computing where I
don't even want the overhead of a virtualization, a
hypervisor, be it type one, type two, whatever.
I don't even want that on the box.
I just want the box to boot up into
whatever my HPC platform operating system is, start taking
jobs, and then when I want to upgrade it,
I literally rebuild the whole box from scratch.
Because even the minimal overhead that a hypervisor adds is
still wasted when I'm going to consume every bit of
Ram, every bit of CPU cycle doing a single job
or distributed job, whatever, a single purpose.
So there's no reason to even
have the virtualization layer on it.
Just run bare metal and you just have to
be able to provision quickly and scale quickly.
So if we're provisioning quickly and scaling quickly this
might sound like a silly question, but does that
mean all SaaS services are always cloud and cloud
is always SaaS or are they decoupled?
I have a favorite quote and I was trying to figure out a
way to fit this in here, and I don't know that I ever
figured out a way to fit it, but it was what is it?
All bourbons are whiskey, but
not all Whiskies are bourbon.
So I feel like that kind of as a general level kind
of gets my point here where it's cloud is not IAS, but
IAS is cloud or Paz is cloud or SAS is cloud.
Those things run on cloud platforms.
So when you say infrastructure as a service or
platform as a service, or software as a service,
that's all about the level of abstraction that the
consumer is receiving from the cloud provider.
Now, whether it's public or private, that is purely
an attribute of am I going to a third
party, a public cloud and giving them a credit
card saying, hey, swipe this thing, run my numbers
and start billing me for whatever I consume?
Or am I going to my internal infrastructure team and
saying, hey, build me out a cloud platform in our
data center using our hardware and tell me when it's
ready and I consume it in the same sort of
on demand manner as I do public.
It's all about that.
So public versus private isn't really about cloud
as much as cloud is about those tenants.
You mentioned that you've been doing this for,
say, ten years and you haven't been asked,
what is the cloud in ten years?
So if we were to look five years from now, do
you think the entire landscape will look as we are today?
Do you have any predictions of how things would grow?
Because honestly, I'm a tad confused about
the entire mystery of the cloud.
I much prefer being able to hold things and
touch things because then I know where they are.
So where do you think we're headed?
I think we've already seen the
beginning of the next five years.
I don't think the next five years, in my opinion,
as far as and I speak, as applied, what are
real businesses doing with their real business services?
I'm not talking about what's everybody going to start thinking
about and selling and trying to get us to do
in five years and think about really what's going to
happen with businesses who are out there doing making widgets
and shipping boxes, that kind of thing.
And the reality is we've already
started there, which is reconsidering our
movement from the private infrastructure.
I don't say cloud because a lot of
us that are running services and applications and
storing data inside private facilities aren't cloud.
They are an old school way of doing things.
They might be running virtualization, but they haven't
finished connecting the full on demand consumption.
Or maybe the third time I was
going to bring up is resiliency.
The infrastructure may just not be to that level
of resiliency yet because resiliency is not about the
fact that you want to block from ever having
failure, but it's how you deal with failure.
And a lot of our legacy infrastructure,
it can survive failures, but it's rough.
90 seconds of outage or five minutes of outage or
a day of recovery for backup, things like that.
We just don't have that kind of resiliency we
need yet in order to be truly cloud.
So a lot of companies said, hey, this stuff
that's out on public cloud, that has these core
tenants fully developed, fully delivered, this is a better
place to run my applications, my services, and arguably
it is from a purely technological sense.
But what happened was we went and we just
grabbed the forklift and started shoving everything we've got
under the hood out into the cloud.
And then we got done and we turned around
and finally went and grabbed the bill in the
mail and went, wow, this is significantly more expensive.
And I would argue part of that sticker
shock is because cloud quantifies the cost so
well, whatever the number at the bottom of
the bill is, that's what it's costing?
Whereas when we build our own infrastructure, we kind
of tend to wash expenses and things, head count,
what's the cost for the person to be in
the data center putting labels on cables?
And what's the cost to buy a new server?
When did we buy it?
Do we buy it up front on the large capital expenditure
or do we buy a piecemeal after the original deployment?
Those things tend to get really difficult from a financial
perspective to quantify public cloud, really put it in our
face exactly what it costs to run these things.
So now that we've seen finally this total summarization
of cost, we in my opinion are starting to
turn around and look at our applications and go,
what is costing the most to run out here?
Does it really belong out here at a technical
level, at a business level, at a financial level?
Does it belong in public cloud or did it
do better, did it perform better, technically perform better?
Is it faster for the users
or does it financially perform better?
Is it cheaper to run
in your traditional infrastructure?
And once we start to figure those things out.
We'll start to rebuild our private infrastructure in a
private cloud model in order to bring those services
back into the on prem location where our costs
tend to be a little more fixed.
A little more controlled.
Don't have the third party overhead attached to them.
And we can achieve a better synergy between
the cost of public cloud versus private cloud. I equate.
The analogy of we live in a house
and we've been hoarding all these systems, we
were completely packed and nobody could move.
And then we started to finally move all these bits
and pieces out and now we finally have enough room
in our house in order to see the walls, see
the floor, see where the kitchen is, and we can
renovate and we can get an idea.
And as the analogy goes, we can
renovate in an open floor plan concept.
Now, which is the idea of public cloud, which
is that flexibility and be able to have much
more space to work in and not be constrained
in these tiny rooms like we had originally built.
That reminds me of a children's book I'm currently
running by Julia Donaldson, where somebody brings in, they're
unhappy with the size of the house, so they
bring in cows, pigs and sheep.
And eventually when they remove everybody from the house,
everything feels a lot bigger and a lot better.
You lose sight of your capacity if you're
just trying to add services on top.
Personally, I've been burned several times, forgetting to turn off
cloud, rung VMs, and then being hit with a nice
substantial bill at the end of the month.
Thank you Microsoft, thank you other cloud providers.
So that's wonderful.
So yourself, you're in a professional service
capacity and you have industry experience.
So what best practices?
Do you advise people to move
from private to public cloud?
Or do you have any examples where people
had to roll back to one or the
other because they've mishandled the deployment?
I can kind of use an example of what works well in
public cloud and what kind of motivates to come back from.
Some examples I've seen, where it's these really
large static servers, thinking 816, 32 CPU cores,
thinking 128, 256 gig of Ram.
A lot of it's running older systems, older,
maybe legacy software, maybe in house software.
And moving from private to public was purely
a component of moving a virtual machine.
There was no optimization.
There's no optimization to be had.
The box is in its current state, what it
is, just to put it in its most simple.
Running it on somebody else's hardware is
just a matter of increased cost.
There's no scalability.
So you think about like an application.
You have an application that's business safe
during the middle of the night.
It's the idle 08:00 a.m., the business open,
the application ramps up really hard, and you
need 5678 instances of the application to handle
the whole load of the users.
And then 05:00 p.m.
Comes around, the business closes, and
then the utilization ramps back down.
When you scale like that, that becomes a
great opportunity for public cloud because it pays.
You can consume, you spin up the servers when you
need them, you spin them down when you don't need
them, and you save that cost during your idle time.
You only need those servers running when you need them.
The old way we used to do it was we spun
up all five, six, whatever the greatest common denominator was, and
we didn't let them sit there and run all the time.
So being able to reassess our applications, identify
applications that fit that model and can be
either adapted or natively supported is the hope.
And as we develop more native support for the
Scalability concept will come out to be able to
ramp up, ramp down and the cost.
Follow that ramp up and ramp down
where you don't have those opportunities.
Being in an infrastructure or private infrastructure tends not
always, but often times it tends to be cheaper
because you can just buy the box, let it
capitalize like we normally do and it can be
financially cheaper to run because you don't have that
overhead of public cloud.
That's usually where I say for people to look at it.
You've got to assess your applications and do they fit
or are we just moving them to move them?
Which to my previous point can actually provide value
because it gets the application of the server.
Moving it up to the public cloud can get it out
of the way for a bit, migrate it out to somebody
else's infrastructure, let it run, free up the space in your
home data center, rebuild as a private cloud with those core
tenants of Scalability resiliency on demand consumption.
Rebuild that infrastructure back at
home, then move it back.
So you're just renting the apartment while
you move all your boxes out.
Let the things continue to live in the apartment for
a while, the public cloud, rebuild your home in the
new way of cloud, then move it back.
Get the value of both.
Once you have that opportunity to rethink your
infrastructure and just use that other place to
move it as a temporary hold in storage
comes at a cost, but it's not permanent.
It's there temporarily and you can bring it back
to where you can have the best fit, financially
speaking, for the long term once you're ready.
So you're effectively saying it's important to do a
capacity analysis, network monitoring for usage and consumption before
executing on a strategy, is that right?
I would say start with the applications honestly.
You just really got to understand how they work.
You can't really know how much capacity you
need until you know how the application behaves.
So there's really it's a matter of sitting down and
think about our application because I feel like we've been
so used in the past to just putting the CDROM
in the drive next install it installs and then it
performs horribly and we tune it and it performs horribly
and we tune it and we keep touching it and
poking it and adjusting it until it finally performs right
and then we don't touch it the new way.
We need to kind of go in up front with
a better understanding of what does this need, how much
resources does it need, and deploying with intent rather than
deploying and then figuring it out after the fact.
But I thought the entire It space
operated on the workaround as a basis.
If you have a bug you just find a workaround.
You just stick it together with Elma's glue and
sticky tape and you never touch it anymore. It's fixed.
It's fixed.
I thought that's the way.
So you've given some very insightful topics here Dane.
Thank you.
I've got a final question I'd like to throw
your way and this might be slightly outerband, but
what is something you know now you wish you
knew at the beginning of your career?
Early on in my career when I was
working in higher education here in the US.
I had a concept and I'm not going to lay
claim to coin the term, but I had an idea
and we were actually calling it cloud computing.
We had a data center, we had some servers, we had
some tenants in a commercial and research park and we had
the idea hey, can we use the extra capacity we have
lying around and give it to our tenants?
These were very small companies, one, two, maybe three
people at most for most of them and they
would have all their critical applications running on a
server, sitting on the floor of their office.
And it terrified me.
The idea of if it ever rained and flooded,
a fire alarm goes off and the office flooded,
this box is going to flood and be destroyed.
I don't know if they have good backups.
I don't know if they have another server.
I don't know how long it's going to
take to order one and get it built
up and redeployed and all their stuff recovered.
Even if they do have good backups and we said
can we just offer them at a very low cost,
a fraction of the server, a virtual core core on
the server, a chunk of the Ram on the server
and they could get data center class facilities, air conditioning
power, redundancy cleaned power even.
Not just raw grid power, high speed fiber optic
internet connectivity because we own the fiber infrastructure between
all these people we can offer all this stuff.
That was really kind of neat but I
didn't have the foresight to see where it
was going, where that idea could go.
And I wish I'd had that foresight to see
just how far it could be taken up into
what we see now with especially the largest public
cloud providers and how they do it.
It would have been so great even
if I didn't execute on it.
Just to kind of be like yeah I saw
this coming and have that sense of awareness.
But yeah, I couldn't see past the problem in front
of me at that time and I wish I had.
The unofficial father of the cloud sits before us.
Fantastic.
You don't need Platform as a service.
We need Dan as a service with thought leadership.
You never know, we could have
had cloud 15 years earlier.
That's great to hear.
So Dan, thank you very much for joining us today.
It's been very insightful and I
hope you have a great day.
Thank you much good to be here. Thank you.
That was all for our episode today.
I hope you've come away feeling
a little more educated and empowered.
In case you've forgotten, I'm Robin johns and
you've been listening to convergence by cato networks.
Don't forget to hit subscribe and
I'll see you next time.