WEBVTT
1
00:00:01.360 --> 00:00:08.480
Involve, Solve Evolve. Welcome to
cloud Crunch, the podcast for any large
2
00:00:08.640 --> 00:00:13.320
enterprise planning on moving to or is
in the midst of moving to the cloud.
3
00:00:13.800 --> 00:00:20.600
Hosted by the cloud computing experts from
second Watch. Michael Elliott, Executive
4
00:00:20.640 --> 00:00:27.679
director of Marketing and Fred Bliss,
CTO of all Things Data at second Watch
5
00:00:29.480 --> 00:00:50.240
and now here are your hosts of
cloud Crunch. Welcome back to a new
6
00:00:50.280 --> 00:00:54.399
season of cloud Crunch. In this
season, we're going to focus on AWS
7
00:00:54.479 --> 00:00:58.799
Reinvent, one of the biggest cloud
conference is probably the biggest cloud conference in
8
00:00:58.840 --> 00:01:03.560
the world, kicking off in the
Ubery now. Our intent is to enable
9
00:01:03.600 --> 00:01:07.920
you, the viewer, the opportunity
to immerse yourself and how cloud has evolved
10
00:01:07.920 --> 00:01:11.959
since last year on topics like preparing
and building a center of excellence, extracting
11
00:01:12.000 --> 00:01:19.400
data insights, managing a cloud dative
environment, and data center evacuation. Joining
12
00:01:19.400 --> 00:01:23.120
me today is Jeff mckinnish, Vice
President Managed Cloud Services at second Watch.
13
00:01:23.480 --> 00:01:27.400
Welcome to cloud Crunch, Jeff,
Thank you. Michael. All right,
14
00:01:27.519 --> 00:01:33.920
so you and I have gone back
a few years in the data center industry.
15
00:01:34.040 --> 00:01:38.040
Both have a little bit experience around
that, but that world has evolved
16
00:01:38.200 --> 00:01:42.640
and not only that the world has
evolved, not only managing in a cloud
17
00:01:42.719 --> 00:01:47.680
environment, but how we start to
look at that cloud environment from a cloud
18
00:01:47.799 --> 00:01:51.319
native perspective. I would like to
kind of just have a conversation a little
19
00:01:51.359 --> 00:01:56.120
bit to start off with, what
have you seen as really changed in managing
20
00:01:56.319 --> 00:02:02.599
a cloud environment. The change in
paradig I'm from from typical service management framework
21
00:02:02.640 --> 00:02:09.159
to um true cloud native deployments means
that things like change management, release management
22
00:02:09.800 --> 00:02:16.639
all fundamentally shift from an I T
LAD exercise to a business led exercise,
23
00:02:16.759 --> 00:02:23.639
and resources are no longer static,
They're ephemeral. So you've heard the term
24
00:02:23.719 --> 00:02:29.960
pets versus cattle, I mean typical
enterprise workloads. They're the crown jewels of
25
00:02:30.039 --> 00:02:34.280
the enterprise and you protect them for
for obvious reasons. But when you have
26
00:02:34.360 --> 00:02:38.120
a problem with a truly cloud native
app, the paradigm is to redeploy in
27
00:02:38.199 --> 00:02:45.759
its entirety. So that that's a
fundamental shift not only in the software management
28
00:02:45.800 --> 00:02:51.599
framework, but also if you're if
you're truly deploying resources on demand in the
29
00:02:51.680 --> 00:02:55.759
actual infrastructure deployment, well that that
that brings up I mean you talk about
30
00:02:55.759 --> 00:03:02.360
the DevOps, does that shift,
Who's managing that environment from I T to
31
00:03:02.599 --> 00:03:07.879
more of a hybrid role I T
and developers. It does because it's a
32
00:03:07.919 --> 00:03:15.280
consumer lead enterprise, right the the
app owners and and the folks controlling the
33
00:03:15.319 --> 00:03:20.919
DevOps pipeline are the ones who are
fundamentally spinning up and spinning down infrastructure.
34
00:03:22.039 --> 00:03:27.919
So you get in and you you
raise a good point. Configuration management also
35
00:03:28.000 --> 00:03:35.080
becomes a much less static exercise.
So when you when you spin up X
36
00:03:35.159 --> 00:03:39.319
number of instances for you know,
a given workload, sometimes by the hour,
37
00:03:40.000 --> 00:03:45.639
you're no longer dealing with static instances
that are that are you know,
38
00:03:46.240 --> 00:03:49.520
your I P map stays the same, et cetera, and everything goes to
39
00:03:49.560 --> 00:03:53.520
a host that you know and and
go to every day. Hosts are ephemeral.
40
00:03:53.599 --> 00:03:58.520
Resources are ephemeral. That's the nature
of cloud. If you truly want
41
00:03:58.520 --> 00:04:02.199
to want to recognize the you know, the power of the cloud. In
42
00:04:02.319 --> 00:04:06.919
terms of budget control, and with
that is a double edged sword. If
43
00:04:06.960 --> 00:04:11.639
you don't set budgets, if you
don't have the proper controls in place,
44
00:04:12.159 --> 00:04:16.839
your spend can go wildly out of
control without you realize. Again, so
45
00:04:16.920 --> 00:04:21.319
it's a different management paradigm in total, which is not static. By its
46
00:04:21.399 --> 00:04:29.399
nature. Where do you think the
industry is on this change and and starting
47
00:04:29.399 --> 00:04:32.720
to think this way? Are we
are we still early stages or adoption started
48
00:04:32.759 --> 00:04:40.560
to really occur. I I think
that the SAS vendors and the people who
49
00:04:40.680 --> 00:04:45.279
adopted cloud in the beginning, which
is really the developer community, is well
50
00:04:45.360 --> 00:04:49.879
on its way. The enterprise is
really breaking into this space. And and
51
00:04:49.920 --> 00:04:57.480
part of the reason for that is
most of the of the common enterprise apps
52
00:04:57.600 --> 00:05:00.319
from the big software vendors are not, by the very nature cloud native.
53
00:05:00.759 --> 00:05:04.959
So if you go when you look
at any of the e RP packages that
54
00:05:05.040 --> 00:05:11.720
have been out for eons, they
really don't have container based deployments. They
55
00:05:11.720 --> 00:05:15.439
don't lend themselves in the way that
they're deployed to this ephemeral you know,
56
00:05:15.600 --> 00:05:20.240
resources on demand paradigm. And so
that shift will occur over time, and
57
00:05:20.279 --> 00:05:26.199
it's very likely will come in the
form of things like bring your own cloud
58
00:05:26.240 --> 00:05:31.720
for SASS, so you're essentially running
as SASS package inside of your own cloud.
59
00:05:31.839 --> 00:05:35.079
That that would probably be the place
that I would see that happen first.
60
00:05:38.040 --> 00:05:43.120
Where are we going to be around
skill set to actually manage these types
61
00:05:43.160 --> 00:05:47.079
of environment? I mean we we
hear about how hard hiring is and even
62
00:05:47.120 --> 00:05:51.879
for our industry trying to find the
right people to bring in. Do you
63
00:05:51.920 --> 00:05:56.680
know traditional enterprises, where are they
at and trying to find the skill set
64
00:05:56.720 --> 00:06:01.000
to be able to manage this type
of environment. Trudal enterprises are still focused.
65
00:06:01.040 --> 00:06:04.439
I mean coming out of the data
center, they still have that skill
66
00:06:04.519 --> 00:06:11.160
set um in house. So they'll
have operating system people typically, they'll have
67
00:06:11.399 --> 00:06:15.399
network people that are familiar with physical
devices. You know, they may have
68
00:06:15.480 --> 00:06:18.120
some of their own cloud people if
they've if they started to adopt cloud,
69
00:06:18.560 --> 00:06:25.199
when they start to deploy, develop
and deploy truly cloud native apps, that
70
00:06:25.240 --> 00:06:29.720
brings in a whole new dimension of
skill sets, specifically around things like DevOps
71
00:06:30.240 --> 00:06:33.800
uh, specifically around things like you
know, how do you manage containers?
72
00:06:33.839 --> 00:06:38.879
How do you manage pipelines? But
people that have been in the industry,
73
00:06:38.959 --> 00:06:44.360
like ourselves, they're not going to
evolve into this this new norm that's becoming.
74
00:06:44.759 --> 00:06:47.759
So where are we finding the talent? Are they coming out of college
75
00:06:47.759 --> 00:06:51.319
with that talent or not even college, are coming out of high school learning?
76
00:06:51.319 --> 00:06:57.199
There's that what's your thoughts around that? I actually think that many of
77
00:06:57.240 --> 00:07:00.800
the people in the enterprise do want
to evolve in the direction and the place
78
00:07:00.879 --> 00:07:06.800
that that they need help is specific
skills and augmentation in and around their model
79
00:07:06.879 --> 00:07:12.560
in order to complete it. So
the cost of acquisition of those skills is
80
00:07:12.600 --> 00:07:15.600
fairly high if you just go buy
everything off the street, particularly when you
81
00:07:15.680 --> 00:07:20.480
multiply it out by the number of
of shifts in a week that you need
82
00:07:20.519 --> 00:07:26.079
to cover it for. So what
what I've seen in my experience as enterprises
83
00:07:26.120 --> 00:07:30.079
that do have good developers, and
they have you know, they've brought in
84
00:07:30.360 --> 00:07:34.560
you know, sec ops and dove
ops type people, but they find themselves
85
00:07:34.680 --> 00:07:41.439
very quickly in the position where they
have to make decisions between managing all of
86
00:07:41.480 --> 00:07:47.360
that complexity and focusing on their core
business right. And and that's where you
87
00:07:47.439 --> 00:07:53.680
see the new evolution of services coming
in where you know a lot of customers
88
00:07:53.680 --> 00:07:57.079
say, you know what, I
don't want to manage the in production version.
89
00:07:57.199 --> 00:08:01.800
I don't want to manage the pipelines
and and all of the Kubernetes clusters.
90
00:08:01.839 --> 00:08:07.199
I want to focus on building the
next revision of my applications to fundamentally
91
00:08:07.319 --> 00:08:13.800
enable my business. And that's really
where the service services opportunity around management of
92
00:08:13.439 --> 00:08:18.600
cloud native comes in, So let's
let's dive into that a little bit.
93
00:08:18.600 --> 00:08:26.279
So when and you're right, it's
more about enterprises looking to focus their energy
94
00:08:26.439 --> 00:08:30.519
on things that are going to enable
the business to be better, to solve
95
00:08:30.560 --> 00:08:35.799
business problems, to create revenue for
the company, and not managing that environment.
96
00:08:35.879 --> 00:08:41.039
So when you start to look for
outsourcing cloud management, what traditionally should
97
00:08:41.159 --> 00:08:45.759
people be thinking about. What should
a c XO be thinking about As far
98
00:08:45.799 --> 00:08:52.440
as looking at that right managed service
provider to hand the keys over to manage
99
00:08:52.480 --> 00:08:56.360
that, I think it's it's a
matter of where do they have their own
100
00:08:56.360 --> 00:09:01.600
expertise and where do they need help
scaling the typical areas where you see companies
101
00:09:01.600 --> 00:09:09.159
struggle or things like identity management,
particularly whenever it's um split between multiple on
102
00:09:09.320 --> 00:09:15.720
prem and cloud environments, because hybrid
cloud is a real thing. Microsoft seems
103
00:09:15.720 --> 00:09:18.240
to be in practically every shop we
go to, as do one or more
104
00:09:18.279 --> 00:09:24.759
other major CSPs. Plus they typically
have some sort of on site or endpoint
105
00:09:24.039 --> 00:09:28.639
identity management issue they have to weave
into that. So they need to be
106
00:09:28.679 --> 00:09:33.679
looking for for vendors or for for
partners who can help them with how do
107
00:09:33.720 --> 00:09:39.480
they do identity management and how do
they maximize their usage of cloud and really
108
00:09:39.519 --> 00:09:46.720
recognize the benefits of of cost saving
through their implementation, So that that really
109
00:09:48.200 --> 00:09:54.240
spans out into how do you effectively
deploy and manage within the cloud and the
110
00:09:54.320 --> 00:09:58.600
control as as I mentioned previously,
the control paradigm and the cloud is completely
111
00:09:58.639 --> 00:10:03.120
different because things can be spun up
and spun down easily. It's not like
112
00:10:03.159 --> 00:10:05.759
you have to go buy something and
stick it in a rack like you used
113
00:10:05.799 --> 00:10:13.639
to. So when when a prospect
comes to you to evaluate your capability,
114
00:10:13.919 --> 00:10:20.639
what are the three things that they're
going to ask you around your capability that
115
00:10:22.200 --> 00:10:26.360
to differentiate you from anyone else out
there? I think first and foremost they're
116
00:10:26.440 --> 00:10:31.320
they're they're going to ask about our
expertise in the cloud, how we automate
117
00:10:31.360 --> 00:10:37.440
around the cloud, What what do
we have in terms of pre built configurations
118
00:10:37.480 --> 00:10:43.600
in um automation to help them not
only with deployment, but also observe ability
119
00:10:43.639 --> 00:10:48.279
and management of that cloud infrastructure.
And that's that's really where we focus a
120
00:10:48.320 --> 00:10:56.159
lot of our time because everything in
the cloud can be manipulated or or deployed
121
00:10:56.279 --> 00:11:00.679
or revoked with code. So infrastructure
is code is a real thing. You
122
00:11:00.679 --> 00:11:03.639
can spin up entire cloud environments and
destroy them in the span of an hour
123
00:11:05.480 --> 00:11:11.440
with the right terraform code. And
so you really start to view configuration management
124
00:11:11.960 --> 00:11:16.960
and the deployment exercise as a coding
and change management of code exercise. Those
125
00:11:18.000 --> 00:11:26.159
are the that's the holy grail of
management within the cloud is really getting to
126
00:11:26.200 --> 00:11:30.440
the point where you don't have people
in the cloud console manipulating all the time.
127
00:11:30.480 --> 00:11:33.639
And we're not there yet. Nobody
nobody's acent there that doesn't have a
128
00:11:33.720 --> 00:11:39.559
single workload that they focus on.
So the plethora of applications we typically deal
129
00:11:39.639 --> 00:11:43.480
with, not every one of them
is going to be completely cloud enabled.
130
00:11:43.519 --> 00:11:48.600
And and the thing that you need
in a partner is someone who can help
131
00:11:48.639 --> 00:11:52.440
you get from whatever state you're in
and work towards the idealized state that you
132
00:11:52.519 --> 00:11:58.759
seek and help you define what that
is, because it's strategy. Moving into
133
00:11:58.759 --> 00:12:01.159
the cloud is really a strad energy
it's not a data center move it it's
134
00:12:01.240 --> 00:12:05.639
it's no longer a you know,
plock from point A to point B.
135
00:12:05.879 --> 00:12:11.480
And in fact, if it's coded
correctly, if you if you make yourself
136
00:12:11.600 --> 00:12:16.759
portable, then that gives you the
option later on to do arbitrage for cloud
137
00:12:16.840 --> 00:12:22.360
cost to cross clouds, which is
the next evolution of the whole the whole
138
00:12:22.360 --> 00:12:26.879
concept of hybrid cloud. We see
it in our largest enterprise customers because they're
139
00:12:26.960 --> 00:12:33.240
literally in the process of of resource
arbitrage between the cloud vendors based on what
140
00:12:33.279 --> 00:12:39.039
their specific needs are for each Worklet
so let's let's kind of wrap up one
141
00:12:39.080 --> 00:12:43.200
thing that I recall, as you
know, being in the industry as long
142
00:12:43.240 --> 00:12:46.720
as I've been, is people were
afraid of the cloud for a number of
143
00:12:46.759 --> 00:12:52.639
reasons, one of which was security. Another one of which is that lock
144
00:12:52.759 --> 00:13:00.639
in component. So let's talk a
little bit about security and how security has
145
00:13:00.799 --> 00:13:05.159
evolved in managing that cloud environment.
And then secondly around are you locked in?
146
00:13:05.240 --> 00:13:09.879
So when you turn over the keys, do you allow someone to manage
147
00:13:09.919 --> 00:13:13.120
that environment? It could be a
multi cloud environment as well. Is there
148
00:13:13.159 --> 00:13:18.559
a risk for lock in that once
you hand over those keys, you'll never
149
00:13:18.600 --> 00:13:22.200
get those keys back. I think
that a lot of that depends on your
150
00:13:22.240 --> 00:13:28.159
portability strategy. So as you as
you build things in the cloud, and
151
00:13:28.279 --> 00:13:33.639
if you're if you're simply using VMS
or Kubernetes clusters, those are not cloud
152
00:13:33.679 --> 00:13:37.320
specific. I mean, there's there's
idiosyncrasies of each one, but realistically those
153
00:13:37.320 --> 00:13:43.679
things are portable. And that's that's
a far cry from if you go and
154
00:13:43.720 --> 00:13:48.000
you implement on some specific pass service
that has its own language, you know,
155
00:13:48.120 --> 00:13:52.519
some specific flavor of a database.
So what you see customers doing who
156
00:13:52.519 --> 00:14:00.759
are truly seeking portability is using things
like UM industry standard open source platforms like
157
00:14:00.799 --> 00:14:09.759
post GRUSS for database, UM keeping
their technology UM platform independent. That's that
158
00:14:09.840 --> 00:14:13.320
also plays over into things like the
technologies they use to deploy. Because terror
159
00:14:13.360 --> 00:14:18.559
form, although the providers, the
specific syntax reach provider might be slightly different,
160
00:14:18.879 --> 00:14:22.600
you can port from one to the
other rather easily, versus something like
161
00:14:22.639 --> 00:14:28.639
a cloud formation template which is specific
to AWS. I want to thank Jeff
162
00:14:28.679 --> 00:14:33.759
for joining us today to discuss modern
cloud operations managing a cloud native environment.
163
00:14:33.840 --> 00:14:37.480
That one final word in this conversation, Jeff, that you kind of brought
164
00:14:37.600 --> 00:14:41.879
up you talk about how cloud is
obeying More's law. I'd love you to
165
00:14:41.200 --> 00:14:45.360
love for you to kind of kind
of kind where does that come from?
166
00:14:45.360 --> 00:14:48.759
Because you know, everyone's familiar with
Moore's law as far as ability of compute
167
00:14:48.759 --> 00:14:52.360
power to double. But where where
do you where do you see that in
168
00:14:52.480 --> 00:14:56.639
cloud as far as Cloud obeying More's
law. If if you were to look
169
00:14:56.679 --> 00:15:01.679
at where Cloud was ten years ago
or even five years a go, the
170
00:15:01.840 --> 00:15:05.679
service catalog, so so the number
of independent services. Just take AWS for
171
00:15:05.720 --> 00:15:09.039
instance, or Google or any of
the others, but I'll pick on AWS.
172
00:15:11.240 --> 00:15:18.080
Their service catalog every year just burgeons. There's more and more things that
173
00:15:18.120 --> 00:15:22.200
can be taken advantage of in order
to enable the customer. And that's a
174
00:15:22.240 --> 00:15:26.440
good thing. But I think that's
where again, it's not static. The
175
00:15:26.559 --> 00:15:33.639
universe of possibilities changes every day,
and that's where a valued, entrusted cloud
176
00:15:33.639 --> 00:15:39.840
partner can help a customer, a
client really get the most out of their
177
00:15:39.840 --> 00:15:43.879
spend. And that's what it's really
it's it's not just about spend, but
178
00:15:43.919 --> 00:15:48.200
that's a big part of it.
Enterprises ten fifteen years ago went from a
179
00:15:48.320 --> 00:15:54.519
capital expenditure model to an operating expenditure
model. That was the nature of cloud.
180
00:15:54.559 --> 00:15:58.480
They didn't want data centers, it
wasn't their core business. They didn't
181
00:15:58.480 --> 00:16:02.120
want capital expenditure us wrapped up in
it. So they went to an operating
182
00:16:02.159 --> 00:16:07.639
expense model. Cloud grew and now
you see that there are there are literally
183
00:16:07.720 --> 00:16:11.559
hundreds, if not thousands, of
services underneath the covers. It's not just
184
00:16:11.759 --> 00:16:18.840
VMS and block storage and objects storage. It's multiple flavors of databases, you
185
00:16:18.879 --> 00:16:22.480
know, functions, services that can
be taken advantage of to do specific things
186
00:16:22.559 --> 00:16:30.600
in your environment. So the deployed
application really becomes a composite across you know,
187
00:16:30.840 --> 00:16:36.080
code that's written and running on vms
or containers, past services, sas
188
00:16:36.080 --> 00:16:45.399
services, functions. It literally becomes
a very complex ecosystem. And that complexity,
189
00:16:45.440 --> 00:16:49.960
that level of capability, really is
following similar to Moore's law. It's
190
00:16:51.000 --> 00:16:56.799
it's it's doubling every time we turn
around. Awesome. Well, no,
191
00:16:56.960 --> 00:16:59.759
absolutely, and I appreciate that.
Jeff and I want to thank our audience
192
00:16:59.799 --> 00:17:03.119
for tuning into our show. This
podcast is intended to add value to any
193
00:17:03.200 --> 00:17:08.880
large enterprise that is planning on moving
to or is currently focusing on leveraging the
194
00:17:10.000 --> 00:17:15.039
value of the cloud. Send your
comments or suggestions to cloud Crunch at second
195
00:17:15.079 --> 00:17:22.599
watch dot com. I'm Michael Elliott. Thank you. You've been listening to
196
00:17:22.720 --> 00:17:27.200
cloud Crunch with Michael Elliott and Fred
Bliss. For more information, check out
197
00:17:27.240 --> 00:17:33.440
the blog second watch dot com,
forward Slash cloud dash blog, or reach
198
00:17:33.440 --> 00:17:37.599
out to second watch on Twitter and
LinkedIn
1
00:00:01.360 --> 00:00:08.480
Involve, Solve Evolve. Welcome to
cloud Crunch, the podcast for any large
2
00:00:08.640 --> 00:00:13.320
enterprise planning on moving to or is
in the midst of moving to the cloud.
3
00:00:13.800 --> 00:00:20.600
Hosted by the cloud computing experts from
second Watch. Michael Elliott, Executive
4
00:00:20.640 --> 00:00:27.679
director of Marketing and Fred Bliss,
CTO of all Things Data at second Watch
5
00:00:29.480 --> 00:00:50.240
and now here are your hosts of
cloud Crunch. Welcome back to a new
6
00:00:50.280 --> 00:00:54.399
season of cloud Crunch. In this
season, we're going to focus on AWS
7
00:00:54.479 --> 00:00:58.799
Reinvent, one of the biggest cloud
conference is probably the biggest cloud conference in
8
00:00:58.840 --> 00:01:03.560
the world, kicking off in the
Ubery now. Our intent is to enable
9
00:01:03.600 --> 00:01:07.920
you, the viewer, the opportunity
to immerse yourself and how cloud has evolved
10
00:01:07.920 --> 00:01:11.959
since last year on topics like preparing
and building a center of excellence, extracting
11
00:01:12.000 --> 00:01:19.400
data insights, managing a cloud dative
environment, and data center evacuation. Joining
12
00:01:19.400 --> 00:01:23.120
me today is Jeff mckinnish, Vice
President Managed Cloud Services at second Watch.
13
00:01:23.480 --> 00:01:27.400
Welcome to cloud Crunch, Jeff,
Thank you. Michael. All right,
14
00:01:27.519 --> 00:01:33.920
so you and I have gone back
a few years in the data center industry.
15
00:01:34.040 --> 00:01:38.040
Both have a little bit experience around
that, but that world has evolved
16
00:01:38.200 --> 00:01:42.640
and not only that the world has
evolved, not only managing in a cloud
17
00:01:42.719 --> 00:01:47.680
environment, but how we start to
look at that cloud environment from a cloud
18
00:01:47.799 --> 00:01:51.319
native perspective. I would like to
kind of just have a conversation a little
19
00:01:51.359 --> 00:01:56.120
bit to start off with, what
have you seen as really changed in managing
20
00:01:56.319 --> 00:02:02.599
a cloud environment. The change in
paradig I'm from from typical service management framework
21
00:02:02.640 --> 00:02:09.159
to um true cloud native deployments means
that things like change management, release management
22
00:02:09.800 --> 00:02:16.639
all fundamentally shift from an I T
LAD exercise to a business led exercise,
23
00:02:16.759 --> 00:02:23.639
and resources are no longer static,
They're ephemeral. So you've heard the term
24
00:02:23.719 --> 00:02:29.960
pets versus cattle, I mean typical
enterprise workloads. They're the crown jewels of
25
00:02:30.039 --> 00:02:34.280
the enterprise and you protect them for
for obvious reasons. But when you have
26
00:02:34.360 --> 00:02:38.120
a problem with a truly cloud native
app, the paradigm is to redeploy in
27
00:02:38.199 --> 00:02:45.759
its entirety. So that that's a
fundamental shift not only in the software management
28
00:02:45.800 --> 00:02:51.599
framework, but also if you're if
you're truly deploying resources on demand in the
29
00:02:51.680 --> 00:02:55.759
actual infrastructure deployment, well that that
that brings up I mean you talk about
30
00:02:55.759 --> 00:03:02.360
the DevOps, does that shift,
Who's managing that environment from I T to
31
00:03:02.599 --> 00:03:07.879
more of a hybrid role I T
and developers. It does because it's a
32
00:03:07.919 --> 00:03:15.280
consumer lead enterprise, right the the
app owners and and the folks controlling the
33
00:03:15.319 --> 00:03:20.919
DevOps pipeline are the ones who are
fundamentally spinning up and spinning down infrastructure.
34
00:03:22.039 --> 00:03:27.919
So you get in and you you
raise a good point. Configuration management also
35
00:03:28.000 --> 00:03:35.080
becomes a much less static exercise.
So when you when you spin up X
36
00:03:35.159 --> 00:03:39.319
number of instances for you know,
a given workload, sometimes by the hour,
37
00:03:40.000 --> 00:03:45.639
you're no longer dealing with static instances
that are that are you know,
38
00:03:46.240 --> 00:03:49.520
your I P map stays the same, et cetera, and everything goes to
39
00:03:49.560 --> 00:03:53.520
a host that you know and and
go to every day. Hosts are ephemeral.
40
00:03:53.599 --> 00:03:58.520
Resources are ephemeral. That's the nature
of cloud. If you truly want
41
00:03:58.520 --> 00:04:02.199
to want to recognize the you know, the power of the cloud. In
42
00:04:02.319 --> 00:04:06.919
terms of budget control, and with
that is a double edged sword. If
43
00:04:06.960 --> 00:04:11.639
you don't set budgets, if you
don't have the proper controls in place,
44
00:04:12.159 --> 00:04:16.839
your spend can go wildly out of
control without you realize. Again, so
45
00:04:16.920 --> 00:04:21.319
it's a different management paradigm in total, which is not static. By its
46
00:04:21.399 --> 00:04:29.399
nature. Where do you think the
industry is on this change and and starting
47
00:04:29.399 --> 00:04:32.720
to think this way? Are we
are we still early stages or adoption started
48
00:04:32.759 --> 00:04:40.560
to really occur. I I think
that the SAS vendors and the people who
49
00:04:40.680 --> 00:04:45.279
adopted cloud in the beginning, which
is really the developer community, is well
50
00:04:45.360 --> 00:04:49.879
on its way. The enterprise is
really breaking into this space. And and
51
00:04:49.920 --> 00:04:57.480
part of the reason for that is
most of the of the common enterprise apps
52
00:04:57.600 --> 00:05:00.319
from the big software vendors are not, by the very nature cloud native.
53
00:05:00.759 --> 00:05:04.959
So if you go when you look
at any of the e RP packages that
54
00:05:05.040 --> 00:05:11.720
have been out for eons, they
really don't have container based deployments. They
55
00:05:11.720 --> 00:05:15.439
don't lend themselves in the way that
they're deployed to this ephemeral you know,
56
00:05:15.600 --> 00:05:20.240
resources on demand paradigm. And so
that shift will occur over time, and
57
00:05:20.279 --> 00:05:26.199
it's very likely will come in the
form of things like bring your own cloud
58
00:05:26.240 --> 00:05:31.720
for SASS, so you're essentially running
as SASS package inside of your own cloud.
59
00:05:31.839 --> 00:05:35.079
That that would probably be the place
that I would see that happen first.
60
00:05:38.040 --> 00:05:43.120
Where are we going to be around
skill set to actually manage these types
61
00:05:43.160 --> 00:05:47.079
of environment? I mean we we
hear about how hard hiring is and even
62
00:05:47.120 --> 00:05:51.879
for our industry trying to find the
right people to bring in. Do you
63
00:05:51.920 --> 00:05:56.680
know traditional enterprises, where are they
at and trying to find the skill set
64
00:05:56.720 --> 00:06:01.000
to be able to manage this type
of environment. Trudal enterprises are still focused.
65
00:06:01.040 --> 00:06:04.439
I mean coming out of the data
center, they still have that skill
66
00:06:04.519 --> 00:06:11.160
set um in house. So they'll
have operating system people typically, they'll have
67
00:06:11.399 --> 00:06:15.399
network people that are familiar with physical
devices. You know, they may have
68
00:06:15.480 --> 00:06:18.120
some of their own cloud people if
they've if they started to adopt cloud,
69
00:06:18.560 --> 00:06:25.199
when they start to deploy, develop
and deploy truly cloud native apps, that
70
00:06:25.240 --> 00:06:29.720
brings in a whole new dimension of
skill sets, specifically around things like DevOps
71
00:06:30.240 --> 00:06:33.800
uh, specifically around things like you
know, how do you manage containers?
72
00:06:33.839 --> 00:06:38.879
How do you manage pipelines? But
people that have been in the industry,
73
00:06:38.959 --> 00:06:44.360
like ourselves, they're not going to
evolve into this this new norm that's becoming.
74
00:06:44.759 --> 00:06:47.759
So where are we finding the talent? Are they coming out of college
75
00:06:47.759 --> 00:06:51.319
with that talent or not even college, are coming out of high school learning?
76
00:06:51.319 --> 00:06:57.199
There's that what's your thoughts around that? I actually think that many of
77
00:06:57.240 --> 00:07:00.800
the people in the enterprise do want
to evolve in the direction and the place
78
00:07:00.879 --> 00:07:06.800
that that they need help is specific
skills and augmentation in and around their model
79
00:07:06.879 --> 00:07:12.560
in order to complete it. So
the cost of acquisition of those skills is
80
00:07:12.600 --> 00:07:15.600
fairly high if you just go buy
everything off the street, particularly when you
81
00:07:15.680 --> 00:07:20.480
multiply it out by the number of
of shifts in a week that you need
82
00:07:20.519 --> 00:07:26.079
to cover it for. So what
what I've seen in my experience as enterprises
83
00:07:26.120 --> 00:07:30.079
that do have good developers, and
they have you know, they've brought in
84
00:07:30.360 --> 00:07:34.560
you know, sec ops and dove
ops type people, but they find themselves
85
00:07:34.680 --> 00:07:41.439
very quickly in the position where they
have to make decisions between managing all of
86
00:07:41.480 --> 00:07:47.360
that complexity and focusing on their core
business right. And and that's where you
87
00:07:47.439 --> 00:07:53.680
see the new evolution of services coming
in where you know a lot of customers
88
00:07:53.680 --> 00:07:57.079
say, you know what, I
don't want to manage the in production version.
89
00:07:57.199 --> 00:08:01.800
I don't want to manage the pipelines
and and all of the Kubernetes clusters.
90
00:08:01.839 --> 00:08:07.199
I want to focus on building the
next revision of my applications to fundamentally
91
00:08:07.319 --> 00:08:13.800
enable my business. And that's really
where the service services opportunity around management of
92
00:08:13.439 --> 00:08:18.600
cloud native comes in, So let's
let's dive into that a little bit.
93
00:08:18.600 --> 00:08:26.279
So when and you're right, it's
more about enterprises looking to focus their energy
94
00:08:26.439 --> 00:08:30.519
on things that are going to enable
the business to be better, to solve
95
00:08:30.560 --> 00:08:35.799
business problems, to create revenue for
the company, and not managing that environment.
96
00:08:35.879 --> 00:08:41.039
So when you start to look for
outsourcing cloud management, what traditionally should
97
00:08:41.159 --> 00:08:45.759
people be thinking about. What should
a c XO be thinking about As far
98
00:08:45.799 --> 00:08:52.440
as looking at that right managed service
provider to hand the keys over to manage
99
00:08:52.480 --> 00:08:56.360
that, I think it's it's a
matter of where do they have their own
100
00:08:56.360 --> 00:09:01.600
expertise and where do they need help
scaling the typical areas where you see companies
101
00:09:01.600 --> 00:09:09.159
struggle or things like identity management,
particularly whenever it's um split between multiple on
102
00:09:09.320 --> 00:09:15.720
prem and cloud environments, because hybrid
cloud is a real thing. Microsoft seems
103
00:09:15.720 --> 00:09:18.240
to be in practically every shop we
go to, as do one or more
104
00:09:18.279 --> 00:09:24.759
other major CSPs. Plus they typically
have some sort of on site or endpoint
105
00:09:24.039 --> 00:09:28.639
identity management issue they have to weave
into that. So they need to be
106
00:09:28.679 --> 00:09:33.679
looking for for vendors or for for
partners who can help them with how do
107
00:09:33.720 --> 00:09:39.480
they do identity management and how do
they maximize their usage of cloud and really
108
00:09:39.519 --> 00:09:46.720
recognize the benefits of of cost saving
through their implementation, So that that really
109
00:09:48.200 --> 00:09:54.240
spans out into how do you effectively
deploy and manage within the cloud and the
110
00:09:54.320 --> 00:09:58.600
control as as I mentioned previously,
the control paradigm and the cloud is completely
111
00:09:58.639 --> 00:10:03.120
different because things can be spun up
and spun down easily. It's not like
112
00:10:03.159 --> 00:10:05.759
you have to go buy something and
stick it in a rack like you used
113
00:10:05.799 --> 00:10:13.639
to. So when when a prospect
comes to you to evaluate your capability,
114
00:10:13.919 --> 00:10:20.639
what are the three things that they're
going to ask you around your capability that
115
00:10:22.200 --> 00:10:26.360
to differentiate you from anyone else out
there? I think first and foremost they're
116
00:10:26.440 --> 00:10:31.320
they're they're going to ask about our
expertise in the cloud, how we automate
117
00:10:31.360 --> 00:10:37.440
around the cloud, What what do
we have in terms of pre built configurations
118
00:10:37.480 --> 00:10:43.600
in um automation to help them not
only with deployment, but also observe ability
119
00:10:43.639 --> 00:10:48.279
and management of that cloud infrastructure.
And that's that's really where we focus a
120
00:10:48.320 --> 00:10:56.159
lot of our time because everything in
the cloud can be manipulated or or deployed
121
00:10:56.279 --> 00:11:00.679
or revoked with code. So infrastructure
is code is a real thing. You
122
00:11:00.679 --> 00:11:03.639
can spin up entire cloud environments and
destroy them in the span of an hour
123
00:11:05.480 --> 00:11:11.440
with the right terraform code. And
so you really start to view configuration management
124
00:11:11.960 --> 00:11:16.960
and the deployment exercise as a coding
and change management of code exercise. Those
125
00:11:18.000 --> 00:11:26.159
are the that's the holy grail of
management within the cloud is really getting to
126
00:11:26.200 --> 00:11:30.440
the point where you don't have people
in the cloud console manipulating all the time.
127
00:11:30.480 --> 00:11:33.639
And we're not there yet. Nobody
nobody's acent there that doesn't have a
128
00:11:33.720 --> 00:11:39.559
single workload that they focus on.
So the plethora of applications we typically deal
129
00:11:39.639 --> 00:11:43.480
with, not every one of them
is going to be completely cloud enabled.
130
00:11:43.519 --> 00:11:48.600
And and the thing that you need
in a partner is someone who can help
131
00:11:48.639 --> 00:11:52.440
you get from whatever state you're in
and work towards the idealized state that you
132
00:11:52.519 --> 00:11:58.759
seek and help you define what that
is, because it's strategy. Moving into
133
00:11:58.759 --> 00:12:01.159
the cloud is really a strad energy
it's not a data center move it it's
134
00:12:01.240 --> 00:12:05.639
it's no longer a you know,
plock from point A to point B.
135
00:12:05.879 --> 00:12:11.480
And in fact, if it's coded
correctly, if you if you make yourself
136
00:12:11.600 --> 00:12:16.759
portable, then that gives you the
option later on to do arbitrage for cloud
137
00:12:16.840 --> 00:12:22.360
cost to cross clouds, which is
the next evolution of the whole the whole
138
00:12:22.360 --> 00:12:26.879
concept of hybrid cloud. We see
it in our largest enterprise customers because they're
139
00:12:26.960 --> 00:12:33.240
literally in the process of of resource
arbitrage between the cloud vendors based on what
140
00:12:33.279 --> 00:12:39.039
their specific needs are for each Worklet
so let's let's kind of wrap up one
141
00:12:39.080 --> 00:12:43.200
thing that I recall, as you
know, being in the industry as long
142
00:12:43.240 --> 00:12:46.720
as I've been, is people were
afraid of the cloud for a number of
143
00:12:46.759 --> 00:12:52.639
reasons, one of which was security. Another one of which is that lock
144
00:12:52.759 --> 00:13:00.639
in component. So let's talk a
little bit about security and how security has
145
00:13:00.799 --> 00:13:05.159
evolved in managing that cloud environment.
And then secondly around are you locked in?
146
00:13:05.240 --> 00:13:09.879
So when you turn over the keys, do you allow someone to manage
147
00:13:09.919 --> 00:13:13.120
that environment? It could be a
multi cloud environment as well. Is there
148
00:13:13.159 --> 00:13:18.559
a risk for lock in that once
you hand over those keys, you'll never
149
00:13:18.600 --> 00:13:22.200
get those keys back. I think
that a lot of that depends on your
150
00:13:22.240 --> 00:13:28.159
portability strategy. So as you as
you build things in the cloud, and
151
00:13:28.279 --> 00:13:33.639
if you're if you're simply using VMS
or Kubernetes clusters, those are not cloud
152
00:13:33.679 --> 00:13:37.320
specific. I mean, there's there's
idiosyncrasies of each one, but realistically those
153
00:13:37.320 --> 00:13:43.679
things are portable. And that's that's
a far cry from if you go and
154
00:13:43.720 --> 00:13:48.000
you implement on some specific pass service
that has its own language, you know,
155
00:13:48.120 --> 00:13:52.519
some specific flavor of a database.
So what you see customers doing who
156
00:13:52.519 --> 00:14:00.759
are truly seeking portability is using things
like UM industry standard open source platforms like
157
00:14:00.799 --> 00:14:09.759
post GRUSS for database, UM keeping
their technology UM platform independent. That's that
158
00:14:09.840 --> 00:14:13.320
also plays over into things like the
technologies they use to deploy. Because terror
159
00:14:13.360 --> 00:14:18.559
form, although the providers, the
specific syntax reach provider might be slightly different,
160
00:14:18.879 --> 00:14:22.600
you can port from one to the
other rather easily, versus something like
161
00:14:22.639 --> 00:14:28.639
a cloud formation template which is specific
to AWS. I want to thank Jeff
162
00:14:28.679 --> 00:14:33.759
for joining us today to discuss modern
cloud operations managing a cloud native environment.
163
00:14:33.840 --> 00:14:37.480
That one final word in this conversation, Jeff, that you kind of brought
164
00:14:37.600 --> 00:14:41.879
up you talk about how cloud is
obeying More's law. I'd love you to
165
00:14:41.200 --> 00:14:45.360
love for you to kind of kind
of kind where does that come from?
166
00:14:45.360 --> 00:14:48.759
Because you know, everyone's familiar with
Moore's law as far as ability of compute
167
00:14:48.759 --> 00:14:52.360
power to double. But where where
do you where do you see that in
168
00:14:52.480 --> 00:14:56.639
cloud as far as Cloud obeying More's
law. If if you were to look
169
00:14:56.679 --> 00:15:01.679
at where Cloud was ten years ago
or even five years a go, the
170
00:15:01.840 --> 00:15:05.679
service catalog, so so the number
of independent services. Just take AWS for
171
00:15:05.720 --> 00:15:09.039
instance, or Google or any of
the others, but I'll pick on AWS.
172
00:15:11.240 --> 00:15:18.080
Their service catalog every year just burgeons. There's more and more things that
173
00:15:18.120 --> 00:15:22.200
can be taken advantage of in order
to enable the customer. And that's a
174
00:15:22.240 --> 00:15:26.440
good thing. But I think that's
where again, it's not static. The
175
00:15:26.559 --> 00:15:33.639
universe of possibilities changes every day,
and that's where a valued, entrusted cloud
176
00:15:33.639 --> 00:15:39.840
partner can help a customer, a
client really get the most out of their
177
00:15:39.840 --> 00:15:43.879
spend. And that's what it's really
it's it's not just about spend, but
178
00:15:43.919 --> 00:15:48.200
that's a big part of it.
Enterprises ten fifteen years ago went from a
179
00:15:48.320 --> 00:15:54.519
capital expenditure model to an operating expenditure
model. That was the nature of cloud.
180
00:15:54.559 --> 00:15:58.480
They didn't want data centers, it
wasn't their core business. They didn't
181
00:15:58.480 --> 00:16:02.120
want capital expenditure us wrapped up in
it. So they went to an operating
182
00:16:02.159 --> 00:16:07.639
expense model. Cloud grew and now
you see that there are there are literally
183
00:16:07.720 --> 00:16:11.559
hundreds, if not thousands, of
services underneath the covers. It's not just
184
00:16:11.759 --> 00:16:18.840
VMS and block storage and objects storage. It's multiple flavors of databases, you
185
00:16:18.879 --> 00:16:22.480
know, functions, services that can
be taken advantage of to do specific things
186
00:16:22.559 --> 00:16:30.600
in your environment. So the deployed
application really becomes a composite across you know,
187
00:16:30.840 --> 00:16:36.080
code that's written and running on vms
or containers, past services, sas
188
00:16:36.080 --> 00:16:45.399
services, functions. It literally becomes
a very complex ecosystem. And that complexity,
189
00:16:45.440 --> 00:16:49.960
that level of capability, really is
following similar to Moore's law. It's
190
00:16:51.000 --> 00:16:56.799
it's it's doubling every time we turn
around. Awesome. Well, no,
191
00:16:56.960 --> 00:16:59.759
absolutely, and I appreciate that.
Jeff and I want to thank our audience
192
00:16:59.799 --> 00:17:03.119
for tuning into our show. This
podcast is intended to add value to any
193
00:17:03.200 --> 00:17:08.880
large enterprise that is planning on moving
to or is currently focusing on leveraging the
194
00:17:10.000 --> 00:17:15.039
value of the cloud. Send your
comments or suggestions to cloud Crunch at second
195
00:17:15.079 --> 00:17:22.599
watch dot com. I'm Michael Elliott. Thank you. You've been listening to
196
00:17:22.720 --> 00:17:27.200
cloud Crunch with Michael Elliott and Fred
Bliss. For more information, check out
197
00:17:27.240 --> 00:17:33.440
the blog second watch dot com,
forward Slash cloud dash blog, or reach
198
00:17:33.440 --> 00:17:37.599
out to second watch on Twitter and
