WEBVTT
1
00:00:00.960 --> 00:00:08.759
Involve Solve Evolve. Welcome to cloud
Crunch, the podcast for any large enterprise
2
00:00:08.880 --> 00:00:12.919
planning on moving to or is in
the midst of moving to the cloud.
3
00:00:13.439 --> 00:00:20.640
Hosted by the cloud computing experts from
Second Watch, Michael Elliott, Executive director
4
00:00:20.800 --> 00:00:27.280
of Marketing, and Fred Bliss,
CTO of all Things Data at Second Watch
5
00:00:29.120 --> 00:00:37.119
and now here are your hosts of
cloud Crunch. Welcome back to cloud Crunch.
6
00:00:37.280 --> 00:00:40.679
This is Mike Wally, your host
of cloud Crunch. Joining me as
7
00:00:40.679 --> 00:00:44.880
always is my co host Fred Bliss, CTO of All Things Data here at
8
00:00:44.880 --> 00:00:50.240
Second Watch. Welcome Fred hiaol No. And we have a special guest today
9
00:00:50.719 --> 00:00:56.200
joining us as Jesse Sam, Practice
Director Application Modernization here at second Watch.
10
00:00:56.719 --> 00:01:00.359
Welcome Jesse to the hot seat.
Thanks Michael. All right, I see
11
00:01:00.359 --> 00:01:03.040
for the audience. Can you kind
of give a quick synopsis of your background.
12
00:01:03.439 --> 00:01:10.319
Sure. So, I'm a mechanical
engineer turned programmer back when we still
13
00:01:10.359 --> 00:01:15.680
called them programmers, I guess,
and pretty much self taught. Got in
14
00:01:15.719 --> 00:01:21.680
a bullpen with some really smart CS
guys out of college at some startups,
15
00:01:21.920 --> 00:01:26.640
and I just caught the bug.
I've been working in the field for probably
16
00:01:26.799 --> 00:01:34.640
twenty years or so now and progressed
from that programmer level up through cloud architecture,
17
00:01:34.680 --> 00:01:38.079
and now I'm leading the practice here
at second Watch that focuses on application
18
00:01:38.120 --> 00:01:42.480
modernization. Okay, so Jesse,
you stole my line because we were all
19
00:01:42.519 --> 00:01:48.879
just programmers building these huge, monolithic
applications. And you know, the term
20
00:01:49.159 --> 00:01:53.879
programmer has really evolved, but it's
really the focus today is we'ren application development
21
00:01:55.159 --> 00:01:59.799
and how it's kind of evolved.
We use the terms like app mog,
22
00:02:00.120 --> 00:02:04.599
use the terms cloud native development kind
of label this new world. So the
23
00:02:04.719 --> 00:02:08.840
question for you is how did we
get here from the good old days to
24
00:02:09.560 --> 00:02:15.159
the micro service age that were were
simple? I mean, you had a
25
00:02:15.199 --> 00:02:20.360
single programming language that wrote to a
database and it did something. Yeah,
26
00:02:20.560 --> 00:02:24.639
that was easier, but also not
scalable and not very performance sometimes as it
27
00:02:24.680 --> 00:02:29.639
grew larger and larger. But you're
right, that was the architecture of the
28
00:02:29.759 --> 00:02:32.520
day because of a lot of things, a lot of constraints around hardware and
29
00:02:32.599 --> 00:02:40.000
networking, and it was just evolutionary
step in how to write software. So
30
00:02:40.080 --> 00:02:47.719
breaking things apart isn't a new idea. Back before Amazon even existed Amazon Web
31
00:02:47.759 --> 00:02:53.840
Services, that is, people were
trying to break apart these monolithic applications on
32
00:02:53.919 --> 00:03:00.560
prem into services. It went from
RPC to x amount to now we're at
33
00:03:01.080 --> 00:03:06.719
Jason and some other specs out there. We've always tried to do better as
34
00:03:06.759 --> 00:03:12.439
software developers, and now with the
advent of the cloud, service oriented architecture
35
00:03:12.439 --> 00:03:19.840
has turned into micro service architecture where
you can deploy things much faster, much
36
00:03:19.879 --> 00:03:25.199
more isolation, separation of concerns,
single responsibility principle. But it all comes
37
00:03:25.199 --> 00:03:30.800
to play and it just keeps evolving
as the platforms do as well. What
38
00:03:30.879 --> 00:03:37.280
are some of the benefits that business
users I guess organizations in general get out
39
00:03:37.280 --> 00:03:40.759
of this um you know, compared
to how things were over the last twenty
40
00:03:40.800 --> 00:03:46.800
years or so. Features faster.
From a business user perspective, ideally,
41
00:03:46.000 --> 00:03:50.919
the users of your application have no
idea how it's architected, right, but
42
00:03:51.240 --> 00:03:57.479
if they see more features faster,
fixes to broken features faster, they're going
43
00:03:57.520 --> 00:04:00.039
to appreciate that, right. And
then on the back end and of that
44
00:04:00.639 --> 00:04:05.879
from the organizational perspective, if we're
talking about enterprise, I t the enablers
45
00:04:05.919 --> 00:04:12.960
for those benefits of the business user
are the ability to deploy parts of the
46
00:04:13.000 --> 00:04:19.680
application independently and what that gives you
is isolated change and really reduces the scope
47
00:04:19.680 --> 00:04:26.399
of a testing effort, for instance, and it really allows you to scale
48
00:04:26.439 --> 00:04:30.360
those individual pieces to meet the demands
that the users are putting on the application.
49
00:04:31.040 --> 00:04:35.600
You know, going back to your
comment around being able to deploy faster,
50
00:04:36.240 --> 00:04:39.720
you know, I remember the stories
coming out of and I think it
51
00:04:39.839 --> 00:04:45.360
was what Netflix where they were releasing
code, and we go back to my
52
00:04:45.439 --> 00:04:48.399
codebal days, we're releasing code once
a month if you're lucky, they're releasing
53
00:04:48.439 --> 00:04:53.800
code every ten seconds or fifteen seconds
or something like that. And I think
54
00:04:54.360 --> 00:04:59.839
there's a lot to be said around
your ability just to be adaptive and reactive,
55
00:05:00.480 --> 00:05:06.360
not from the user perspective, but
ultimately from an end consumer perspective or
56
00:05:06.399 --> 00:05:12.639
how you meet your business needs to
react to your customers. So where I'm
57
00:05:12.639 --> 00:05:17.920
trying to go with that is you're
talking a lot around the users from the
58
00:05:17.959 --> 00:05:21.959
perspective within the business, but ultimately, what we're trying to get to is
59
00:05:23.240 --> 00:05:30.160
create differentiation in the marketplace for our
customers for their customers, if that makes
60
00:05:30.199 --> 00:05:34.879
sense, right. So, the
same principles apply whether it's an enterprise application
61
00:05:35.040 --> 00:05:41.120
or whether it's a consumer facing application. Consumers want the features faster. They
62
00:05:41.160 --> 00:05:46.720
want bugs fixed faster, and it's
that it's the DevOps philosophy applied to UH
63
00:05:46.920 --> 00:05:55.639
micro services architectural approach that makes that
possible, UM, regardless of of e
64
00:05:55.759 --> 00:06:00.839
commerce or app on a phone or
UH internal line business application. Those architectures
65
00:06:00.879 --> 00:06:04.600
are supporting all of those things now, and all of those users want the
66
00:06:04.639 --> 00:06:09.759
same UH, they want a great
experience. So let's talk a little bit
67
00:06:09.800 --> 00:06:15.439
about DevOps. What what does that
term DevOps really mean? Not from a
68
00:06:15.480 --> 00:06:19.560
definitional perspective, but what it means
for the business. What it means for
69
00:06:19.600 --> 00:06:29.920
the business is a philosophy applied to
the software development process that results in UH
70
00:06:30.120 --> 00:06:38.920
massive amounts of communication between operators and
developers of platforms. It means adopting agile
71
00:06:39.000 --> 00:06:46.560
principles as well as the DevOps philosophy
to to provide UH high quality, isolated
72
00:06:48.000 --> 00:06:51.879
changes that can be pushed out with
such confidence that, like you said,
73
00:06:51.920 --> 00:06:56.079
you can push them out every ten
seconds. It's kind of funny because we
74
00:06:56.120 --> 00:06:59.279
see, um, you know,
over the last ten years, the rise
75
00:06:59.319 --> 00:07:03.800
of DevOps has kind of put more
responsibility I guess in some organizations onto the
76
00:07:03.839 --> 00:07:11.160
developer and given I guess a reason
to no longer need that traditional system administrator.
77
00:07:11.600 --> 00:07:15.319
How do you see the role of
the cysadmin and the developer you know
78
00:07:15.399 --> 00:07:19.639
coming together or you know, what
are the different roles today versus UM where
79
00:07:19.639 --> 00:07:27.079
they were before. That pendulum keeps
swinging back and forth, even even today
80
00:07:27.079 --> 00:07:33.680
where we some companies are empowering development
teams with full stack responsibility including the cloud
81
00:07:33.680 --> 00:07:44.879
infrastructure, including support UH and bug
fixes and like really making a small I
82
00:07:45.000 --> 00:07:50.920
T department out of the teams that
develop these single micro services that are composed
83
00:07:51.000 --> 00:07:57.360
into the larger application. UM swing
the pendulum back the other way, and
84
00:07:57.759 --> 00:08:01.639
we've got enterprises that want separate team
that are handling the cloud infrastructure, separate
85
00:08:01.680 --> 00:08:07.600
from the teams that are developing the
software. I think it's gonna it's gonna
86
00:08:07.639 --> 00:08:11.519
swing somewhere in the middle where we
have the concept of the operators of a
87
00:08:11.560 --> 00:08:18.720
platform that is UH, that is
a separate skill set from developing applications that
88
00:08:18.839 --> 00:08:24.439
run on the platform. We can
see that with Kubernetes today, where these
89
00:08:24.480 --> 00:08:33.879
micro service enabling platforms become require expertise
to care and feed for these things.
90
00:08:33.919 --> 00:08:37.840
That has very little to do with
writing the software that's going to run on
91
00:08:37.840 --> 00:08:41.399
on Kubernetes cluster. So the pendulum
does keep swinging back and forth. But
92
00:08:41.440 --> 00:08:46.720
I think we're gonna land somewhere in
the middle where there is a separation of
93
00:08:46.759 --> 00:08:52.639
skills, but they have to work
tightly together, of course, because you
94
00:08:52.679 --> 00:08:56.720
know, that's the DevOps philosophy,
and if if you don't have those skills.
95
00:08:56.919 --> 00:09:01.080
I think we've seen some examples in
the news of apply chain attacks and
96
00:09:01.279 --> 00:09:05.679
things being made easier for um,
you know, milicious actors to get their
97
00:09:05.720 --> 00:09:09.000
code out there faster without folks knowing. Right, I'm not really sure about
98
00:09:09.039 --> 00:09:15.279
that one I had I hadn't heard
heard that, but yeah, why wouldn't
99
00:09:15.480 --> 00:09:22.120
militious actors be using the same principles
to push their attacks out faster. So
100
00:09:22.200 --> 00:09:26.480
let's let's examine this term cloud native. And I've had people talk to me
101
00:09:26.639 --> 00:09:31.279
that there's cloud native really doesn't exist, it's just a made up term that
102
00:09:31.399 --> 00:09:35.919
we're using. But wanted to get
your thoughts on when we talk about cloud
103
00:09:37.000 --> 00:09:41.200
native, what does that really mean? Cloud native? I don't think it's
104
00:09:41.200 --> 00:09:45.320
a made up term. I think
it describes something pretty real for for software
105
00:09:45.320 --> 00:09:50.559
developers, Um, if you go
in into a development of a new application
106
00:09:50.120 --> 00:09:56.480
with with cloud as a as the
first class uh priority. You're going to
107
00:09:56.600 --> 00:10:01.840
leverage platforms, and you're going to
go all in on a csp and you're
108
00:10:01.879 --> 00:10:07.120
gonna you're going to use all their
integration offerings, all their hosting offerings,
109
00:10:07.440 --> 00:10:11.679
and you're going to write your code
in a way that is native to that
110
00:10:11.840 --> 00:10:16.720
csp UM. To me, cloud
native is a lot of things. There's
111
00:10:16.720 --> 00:10:24.320
a whole uh Kubernetties as cloud native. Yeah, kubernetties is deployments are cloud
112
00:10:24.399 --> 00:10:28.840
native if you choose to run kubernetti
is on top of the csp UM.
113
00:10:28.919 --> 00:10:33.840
Some people refer to cloud native and
they mean serverless, like immediately they think
114
00:10:33.879 --> 00:10:41.720
serverless development. So cloud native is
real and it's a It means to me
115
00:10:41.440 --> 00:10:50.480
that where your code is going to
run becomes a first class uh uh requirement
116
00:10:50.919 --> 00:10:56.960
to the design of the application.
And what do you how do you see
117
00:10:56.000 --> 00:11:01.559
some of these more niche um I
don't know if you call them CSPs,
118
00:11:01.600 --> 00:11:07.960
but more applicate very specific application of
serverist cloud native providers like you know flight
119
00:11:07.000 --> 00:11:11.120
out Io and you know cloud flare
not really a niche one anymore, but
120
00:11:11.039 --> 00:11:16.679
kind of starting to offer their own
uh cloud native services and offerings that are
121
00:11:16.679 --> 00:11:24.279
competing now directly with the big ones. From a developer perspective, UM,
122
00:11:24.480 --> 00:11:28.519
I think that you're that You're right, it is super niche still right now.
123
00:11:28.960 --> 00:11:37.080
But the everybody's trying to provide a
pretty similar experience. You see,
124
00:11:37.399 --> 00:11:43.679
the major CSPs announced something and then
then the next CSP will follow suit,
125
00:11:43.240 --> 00:11:50.480
so they are identical services. But
everyone wants to have the table stakes to
126
00:11:50.600 --> 00:11:54.120
attract the development teams to build on
their on their platforms, and the niche
127
00:11:54.159 --> 00:12:01.840
players will likely just follow suit as
well. So do we end up by
128
00:12:01.080 --> 00:12:07.159
standardizing on one CSP or one of
these niche providers same place we were before
129
00:12:07.279 --> 00:12:15.279
from a monolithic perspective of its inability
to move those applications for another environment.
130
00:12:16.519 --> 00:12:22.799
Well that's the the hot and heavy
religious debate right now. Right Do I
131
00:12:22.840 --> 00:12:28.080
do I containerize everything with the hopes
that I can move it around to the
132
00:12:28.080 --> 00:12:33.840
different CSPs or back home UH and
then back out? Do I want this
133
00:12:33.039 --> 00:12:41.919
ultimate UH flexibility and where I run
my applications or am I going to go
134
00:12:41.000 --> 00:12:48.840
all in on a particular CSP right
everything in a cloud native CSP native way
135
00:12:50.080 --> 00:12:56.720
and gain the efficiencies there. So
the clients that you're coming into interact with
136
00:12:58.440 --> 00:13:03.360
where are they headed? We see
a lot of Kuberneties right now. UM
137
00:13:03.519 --> 00:13:09.679
serverless was groundbreaking to say the least, but over time, the developer experience
138
00:13:11.360 --> 00:13:18.960
around serverless it just it just wasn't
as robust as the development experience around container
139
00:13:18.039 --> 00:13:22.360
rised application. So we we think
servilis is going to cool off a little
140
00:13:22.360 --> 00:13:30.000
bit in favor of Kubernetes and other
container orchestration platforms, but not only because
141
00:13:30.000 --> 00:13:33.840
of the developer experience. It.
That's full circle to the multi cloud ambitions
142
00:13:33.879 --> 00:13:39.120
and the multi cloud being so buzzworthy
right now. UM a lot of driving
143
00:13:39.879 --> 00:13:46.320
folks towards the container experience, and
I think that's that's the focus for us
144
00:13:46.399 --> 00:13:50.639
right now. So let's talk.
You brought up multi cloud and distributed cloud
145
00:13:50.679 --> 00:13:56.960
there, what's your insights on this
trend. I don't think multi cloud or
146
00:13:58.039 --> 00:14:03.559
distributed cloud is going to reach its
promise for a while. UM. Even
147
00:14:03.720 --> 00:14:11.039
even around the container orchestate orchestration platforms, UM, there's not complete parity across
148
00:14:11.240 --> 00:14:18.320
clouds. UM, you still have
to deploy separately. I mean there there
149
00:14:18.320 --> 00:14:22.960
are companies trying to solve this right
single deployments any cloud. There there's software
150
00:14:22.960 --> 00:14:26.240
that you can layer over the top
of all of your your CSPs and try
151
00:14:26.279 --> 00:14:31.039
to get that single pane of glass
on a control plane. But I think
152
00:14:31.039 --> 00:14:35.200
it's going to take a take a
while for that to be really mainstream,
153
00:14:35.320 --> 00:14:46.960
especially around security and like identity management. Making an access or authorization authentication change
154
00:14:48.399 --> 00:14:54.799
in one CSP and propagating that across
to to affect the same deployment and another
155
00:14:54.840 --> 00:14:58.759
CSP. There are a lot of
complicated things that have to have to be
156
00:14:58.799 --> 00:15:03.639
solved for before distributed cloud is really
going to be easy. Um. I
157
00:15:03.639 --> 00:15:09.080
think it's a great goal though,
and I think containerization would be an absolute
158
00:15:09.120 --> 00:15:16.279
requirement at this point to even consider
making that happen. Does that mean in
159
00:15:16.360 --> 00:15:18.879
twenty years we'll have so many abstructions
that nobody will have any idea how it
160
00:15:18.919 --> 00:15:28.919
actually works? Um, CSP as
a public utility? What are the ones
161
00:15:28.919 --> 00:15:33.879
and zeroes? Yeah, I mean
that's the promise, that's the like the
162
00:15:33.000 --> 00:15:37.720
dream of of containerization. Right.
It runs on my laptop, It runs
163
00:15:37.840 --> 00:15:41.279
in Azure, it runs in aw
As, it runs on Google. It
164
00:15:41.440 --> 00:15:48.360
runs refrigerator on your refrigerator. It
runs on a on a stack at a
165
00:15:48.559 --> 00:15:54.960
cell tower on the edge and it
and the developer never has to take that
166
00:15:54.000 --> 00:15:58.840
into consideration at all. And we
can do a whole podcast and on the
167
00:15:58.960 --> 00:16:03.919
security ramifications of it running everywhere around
that. Okay, I'm gonna give you
168
00:16:03.919 --> 00:16:07.480
a couple more friends that you know
gardners identified. One is you know,
169
00:16:07.639 --> 00:16:12.399
composable applications and enterprise, and another
is low code, no code. Wanted
170
00:16:12.399 --> 00:16:18.240
to get your kind of insights on
those two trends. So composable, man,
171
00:16:18.279 --> 00:16:22.600
it can mean, it can mean
so much. Um, I think
172
00:16:22.600 --> 00:16:30.159
when we talk about composable enterprise,
we're talking about UH and enterprise architecture that
173
00:16:30.279 --> 00:16:38.159
involves the connecting of both custom and
off the shelf uh sas is what we
174
00:16:38.799 --> 00:16:42.720
refer to when we say off the
shelf. Nowadays, of course, UM,
175
00:16:42.840 --> 00:16:51.399
we've eaten together the software that runs
your business by leveraging the right service
176
00:16:51.440 --> 00:17:00.080
for the right job versus these huge
monolithic suites of single vendor solutions. So
177
00:17:00.480 --> 00:17:04.559
what that means is when one piece
isn't working, you can take it out
178
00:17:04.880 --> 00:17:08.079
and replace it with another piece.
Right. So, I mean a lot
179
00:17:08.079 --> 00:17:11.480
of things in tech are not literal. Uh. I think when we talk
180
00:17:11.519 --> 00:17:19.200
about compose herble, it's it really
is literally composing your enterprise architecture and the
181
00:17:19.240 --> 00:17:27.079
applications required to run your business from
infinite lego set of of offerings, and
182
00:17:27.559 --> 00:17:36.400
that giving you the flexibility to UH
change and upgrade parts of your enterprise independently.
183
00:17:37.640 --> 00:17:41.640
Now, when we talk about a
composable application from a micro services standpoint,
184
00:17:42.440 --> 00:17:51.839
UH, it's about enterprises being able
to leverage these services to create new
185
00:17:51.920 --> 00:17:59.559
lines of business applications UM by the
virtue of reuse of these single purpose,
186
00:18:00.079 --> 00:18:04.960
very loosely coupled pieces of functionality.
So it can mean a lot of things.
187
00:18:06.400 --> 00:18:10.160
Question for you, Fred, because
we've been talking about at the application
188
00:18:10.279 --> 00:18:15.240
layer, but data just doesn't come
along for free. So what are the
189
00:18:15.279 --> 00:18:19.200
implications as we start to move to
these cloud native that you know, our
190
00:18:19.200 --> 00:18:23.720
audience needs to think about from a
data perspective? I think so long it's
191
00:18:23.759 --> 00:18:29.279
kind of the same thing that that
organizations have needed to think about for the
192
00:18:29.359 --> 00:18:32.480
last you know, ten twenty years
when it comes to their data, which
193
00:18:32.559 --> 00:18:36.920
is UM. You know, make
sure you're collecting the data that you want
194
00:18:37.039 --> 00:18:40.960
and make sure it's accessible and retrievable
so that you can either centralize it or
195
00:18:41.000 --> 00:18:45.559
put it in a place that UM
your various apps can start using it because
196
00:18:45.319 --> 00:18:49.079
you know, I think one of
the big things we're seeing is as as
197
00:18:49.160 --> 00:18:56.480
become more containerized and more distributed and
more single purpose. Um. What we're
198
00:18:56.519 --> 00:19:00.279
creating is a whole bunch of data
silos in the process. And so you'll
199
00:19:00.279 --> 00:19:03.440
have very specific marketing apps that do
one thing, maybe they only do email
200
00:19:03.480 --> 00:19:07.079
campaigns, and then you have another
one that's really good at creating personas.
201
00:19:07.599 --> 00:19:11.960
Now all these applications need to start
sharing data. And if you create this
202
00:19:11.039 --> 00:19:15.200
point to point integration, you take
away one of those applications and boom,
203
00:19:15.240 --> 00:19:19.279
You've just broken the entire spider web
chain of data going all over the place.
204
00:19:21.039 --> 00:19:23.640
So I think what organizations need to
do is start to put plans together
205
00:19:23.759 --> 00:19:29.720
as they start to adopt and modernize
their applications, how are they going to
206
00:19:29.759 --> 00:19:33.559
leverage the data that is uh,
these applications are both collecting and consuming,
207
00:19:33.599 --> 00:19:38.000
and how can they make that data
available UM to the rest of the applications
208
00:19:38.039 --> 00:19:45.000
within the organization Suggesting I mean,
as you're talking to clients, first of
209
00:19:45.000 --> 00:19:48.279
all, is data second class citizen
for them? Are they thinking about that
210
00:19:48.359 --> 00:19:56.119
holistically? So early adopters of of
micro services and the more distributed approach.
211
00:19:56.920 --> 00:20:03.079
UH found out very quickly what happened
when you move the data into purpose built
212
00:20:03.720 --> 00:20:08.519
databases and wall walled off around a
service boundary, it becomes very difficult to
213
00:20:10.519 --> 00:20:17.559
re aggregate that data and report.
And we see the advent of or the
214
00:20:17.680 --> 00:20:27.880
re the re emergence of enterprise service
bus type connections between micro services. UH
215
00:20:29.000 --> 00:20:33.880
so that the right services have copies
of the right data. And now that
216
00:20:33.000 --> 00:20:37.680
just spawns another problem. Right,
So, now you're taken the concept of
217
00:20:37.759 --> 00:20:44.359
single responsibility all the way down to
data persistence, and now you're making copies
218
00:20:44.400 --> 00:20:49.559
of that data. So now this
each of these services grab copies of the
219
00:20:49.640 --> 00:20:56.480
data they need for performance. You've
got an analytics and a reporting uh concern.
220
00:20:56.880 --> 00:21:00.200
So where do where do you get
the data to aggregate to do the
221
00:21:00.319 --> 00:21:02.920
reporting and it and it just goes
on and on from there. Right.
222
00:21:03.279 --> 00:21:10.519
So, early adopters really uncovered this
challenge with a micro service and distributed architecture
223
00:21:11.119 --> 00:21:17.319
and we're still solving that problem as
a as a group of technologists. So
224
00:21:17.400 --> 00:21:23.319
do we still have the term database
administrator or has that been incorporated into the
225
00:21:23.680 --> 00:21:30.599
developers as a part of just what
they're doing, or do they have the
226
00:21:30.680 --> 00:21:36.599
knowledge to understand the impact and ramifications
of these new services with data. It's
227
00:21:36.599 --> 00:21:41.559
another one of those things that like
debops and Sadman's it's a little a little
228
00:21:41.559 --> 00:21:42.559
bit of both. Right, you
get rid of it and put it all
229
00:21:42.559 --> 00:21:47.759
on the developers and uh, you
know there there were certain dB A activities
230
00:21:47.799 --> 00:21:51.519
that have been done over the last
decade that you know, data modeling for
231
00:21:51.559 --> 00:21:53.920
instance, that's something that belongs more
on the business side, co existing with
232
00:21:53.960 --> 00:22:03.359
the developers. UM understanding how to
UM both secure and size and configure your
233
00:22:03.440 --> 00:22:06.640
database and keep it going. Now, a lot of that is shifted to
234
00:22:06.640 --> 00:22:11.640
the cloud service providers, but it
hasn't completely taken it away, um from
235
00:22:11.720 --> 00:22:17.079
the organization's responsibility. So is it
the same big job that it was before.
236
00:22:18.000 --> 00:22:21.599
It depends on how you're hosting everything. Everything is in the cloud.
237
00:22:22.599 --> 00:22:26.319
Um, do you still need a
little bit of it? Yes? Do
238
00:22:26.599 --> 00:22:32.480
organizations find themselves missing some of those
skills? I think definitely us It's it
239
00:22:32.559 --> 00:22:37.400
follows the shared responsibility model, uh
for the csp s right, UM,
240
00:22:37.519 --> 00:22:44.319
what you're referring to, like back
ups and archiving and all these things that
241
00:22:44.400 --> 00:22:48.160
d B as Uh, that was
half of their job and then the other
242
00:22:48.200 --> 00:22:52.240
half of their job was to help
developers get the schema correct and uh,
243
00:22:52.480 --> 00:22:56.519
you know, make a sensible model
of of what's going on in the business
244
00:22:56.960 --> 00:23:03.279
when you go to these managed platforms, and uh, the at the csp
245
00:23:03.440 --> 00:23:07.839
S offer half of your job is
now a checkbox that says, please back
246
00:23:07.880 --> 00:23:15.799
this up in archive it and pushing
the the responsibility for performance and modeling into
247
00:23:15.839 --> 00:23:22.880
the team makes the database minded person
part of that cross functional development team now
248
00:23:22.920 --> 00:23:30.039
instead of sitting with the siss adminds
and and the networking folks. So it's
249
00:23:30.039 --> 00:23:33.640
an evolution of what what that role
can can be. But you're always going
250
00:23:33.680 --> 00:23:38.519
to have to tune in performance,
tune relational database. I mean, that's
251
00:23:38.720 --> 00:23:42.119
somebody always has to do that.
Um, but I think we're going to
252
00:23:42.200 --> 00:23:45.920
find that those folks are going to
be sitting on on the scrum teams versus
253
00:23:45.920 --> 00:23:53.599
sitting in the server rooms the virtual
server room. All right, I'm gonna
254
00:23:53.680 --> 00:23:57.880
kind of wrap this up. How
can our listeners know if they're ready?
255
00:23:59.000 --> 00:24:00.960
And you know, what are some
of the questions they should ask themselves.
256
00:24:02.400 --> 00:24:07.480
So it really doesn't matter if you
feel like you're ready or not. The
257
00:24:07.519 --> 00:24:11.960
impetus is there. You have to
get ready for this and the questions you
258
00:24:11.960 --> 00:24:17.680
should be asking yourself. Are am
I able to release features to the market
259
00:24:18.000 --> 00:24:22.799
fast enough to satisfy users and to
keep up with my competitors? Are my
260
00:24:22.559 --> 00:24:30.920
developers? Are they able to push
out code in a way that is consistent
261
00:24:32.559 --> 00:24:38.799
and high quality and supports that ability
to push these features out faster and faster.
262
00:24:40.480 --> 00:24:45.119
So if you're not ready, get
ready, and thankfully we're here to
263
00:24:45.160 --> 00:24:49.720
help you with that right and from
the application modernization practice at second Watch,
264
00:24:49.839 --> 00:24:55.640
we help clients figure out where to
start on that journey. Because if you're
265
00:24:55.680 --> 00:25:02.640
sitting on hundreds of applications in your
portfolio and you don't have good observe ability
266
00:25:02.680 --> 00:25:04.680
and you don't have a good idea
of what all these things are doing and
267
00:25:04.720 --> 00:25:08.400
what their business value is, it
can be daunting, even if you feel
268
00:25:08.440 --> 00:25:14.640
like you're ready to start. So
regardless of whether you're in the cloud already
269
00:25:14.799 --> 00:25:19.079
or on prem we can help with
that portfolio rationalization and help you get started.
270
00:25:19.640 --> 00:25:23.359
Well. I mean, that's gonna
bring up another question though, Do
271
00:25:23.720 --> 00:25:29.720
organizations and companies have the talent to
do this? We're in the talent shortage
272
00:25:29.839 --> 00:25:32.559
right now. Do they have the
talent to be able to take this on
273
00:25:32.599 --> 00:25:40.240
themselves. It varies obviously, but
overall, I would say that that's a
274
00:25:40.359 --> 00:25:42.799
huge concern. So going back to
are you ready? How do you know
275
00:25:42.839 --> 00:25:45.640
if you're ready for this? That
has to be one of the things that
276
00:25:45.680 --> 00:25:52.319
you take into consideration. Do I
have the culture and the resources in house
277
00:25:52.799 --> 00:26:00.920
to achieve these modernization goals? So
a guided application rationalization process is absolutely necessary,
278
00:26:02.279 --> 00:26:07.359
regardless of whether you can tackle the
implementation and the execution phase or not.
279
00:26:07.000 --> 00:26:12.400
And we're can second Watch help clients
get ready and build up that talent.
280
00:26:12.799 --> 00:26:19.640
So we really pride ourselves on a
do it with you approach over a
281
00:26:19.720 --> 00:26:23.200
do it for you approach. So
when you engage with second Watch and we
282
00:26:23.240 --> 00:26:29.400
get through a rationalization process, we
get through some deep dive assessments on some
283
00:26:29.759 --> 00:26:33.160
good candidates to start your modernization journey. We also can step in and help
284
00:26:33.200 --> 00:26:38.720
your teams actually execute this work,
and we can neither embed with your team.
285
00:26:38.920 --> 00:26:44.240
We can offer a team that execute
side by side with your teams.
286
00:26:44.759 --> 00:26:51.000
We really are flexible and our intent
is to leave the client with the knowledge
287
00:26:51.799 --> 00:26:56.359
and the know how to operate,
enhance, and run these new applications.
288
00:26:56.000 --> 00:27:02.039
All right, last last question,
give us a six story of where we've
289
00:27:02.039 --> 00:27:04.480
been able to go in and help
a client and what did we do,
290
00:27:04.599 --> 00:27:10.519
what did we help them achieve.
So, we had a client that desperately
291
00:27:10.720 --> 00:27:18.200
wanted to migrate off of a licensed
database platform onto something open source and managed
292
00:27:18.240 --> 00:27:22.039
in the cloud. We helped the
client assess the application changes that were would
293
00:27:22.039 --> 00:27:27.799
be required, we help them plan
for that migration, and we actually executed
294
00:27:29.039 --> 00:27:34.880
a successful migration from a very expensive
platform to a much more cost effective solution
295
00:27:36.400 --> 00:27:40.799
on a managed database CSP all right, well, thank you everyone for joining
296
00:27:40.880 --> 00:27:44.640
us here on cloud Crunch. Jesse, I want to say a great appreciation
297
00:27:44.680 --> 00:27:49.599
for you coming on to the podcast. This has been cloud Crunch with Michael
298
00:27:49.640 --> 00:27:55.079
Elliott joining me today as always has
been Fred Bliss, CTO of all Things
299
00:27:55.160 --> 00:28:00.200
Data, with special guests today Jesse
Saying, Practice Director Application Modernization here at
300
00:28:00.240 --> 00:28:08.039
second Watch. Thank you everyone,
appreciate your time. Thanks everyone you've been
301
00:28:08.079 --> 00:28:14.680
listening to cloud Crunch with Michael Elliott
and Fred Bliss. For more information,
302
00:28:14.920 --> 00:28:19.359
check out the blog second watch dot
com, forward Slash cloud dash blog,
303
00:28:19.960 --> 00:28:23.720
or reach out to second Watch on
Twitter and LinkedIn.
1
00:00:00.960 --> 00:00:08.759
Involve Solve Evolve. Welcome to cloud
Crunch, the podcast for any large enterprise
2
00:00:08.880 --> 00:00:12.919
planning on moving to or is in
the midst of moving to the cloud.
3
00:00:13.439 --> 00:00:20.640
Hosted by the cloud computing experts from
Second Watch, Michael Elliott, Executive director
4
00:00:20.800 --> 00:00:27.280
of Marketing, and Fred Bliss,
CTO of all Things Data at Second Watch
5
00:00:29.120 --> 00:00:37.119
and now here are your hosts of
cloud Crunch. Welcome back to cloud Crunch.
6
00:00:37.280 --> 00:00:40.679
This is Mike Wally, your host
of cloud Crunch. Joining me as
7
00:00:40.679 --> 00:00:44.880
always is my co host Fred Bliss, CTO of All Things Data here at
8
00:00:44.880 --> 00:00:50.240
Second Watch. Welcome Fred hiaol No. And we have a special guest today
9
00:00:50.719 --> 00:00:56.200
joining us as Jesse Sam, Practice
Director Application Modernization here at second Watch.
10
00:00:56.719 --> 00:01:00.359
Welcome Jesse to the hot seat.
Thanks Michael. All right, I see
11
00:01:00.359 --> 00:01:03.040
for the audience. Can you kind
of give a quick synopsis of your background.
12
00:01:03.439 --> 00:01:10.319
Sure. So, I'm a mechanical
engineer turned programmer back when we still
13
00:01:10.359 --> 00:01:15.680
called them programmers, I guess,
and pretty much self taught. Got in
14
00:01:15.719 --> 00:01:21.680
a bullpen with some really smart CS
guys out of college at some startups,
15
00:01:21.920 --> 00:01:26.640
and I just caught the bug.
I've been working in the field for probably
16
00:01:26.799 --> 00:01:34.640
twenty years or so now and progressed
from that programmer level up through cloud architecture,
17
00:01:34.680 --> 00:01:38.079
and now I'm leading the practice here
at second Watch that focuses on application
18
00:01:38.120 --> 00:01:42.480
modernization. Okay, so Jesse,
you stole my line because we were all
19
00:01:42.519 --> 00:01:48.879
just programmers building these huge, monolithic
applications. And you know, the term
20
00:01:49.159 --> 00:01:53.879
programmer has really evolved, but it's
really the focus today is we'ren application development
21
00:01:55.159 --> 00:01:59.799
and how it's kind of evolved.
We use the terms like app mog,
22
00:02:00.120 --> 00:02:04.599
use the terms cloud native development kind
of label this new world. So the
23
00:02:04.719 --> 00:02:08.840
question for you is how did we
get here from the good old days to
24
00:02:09.560 --> 00:02:15.159
the micro service age that were were
simple? I mean, you had a
25
00:02:15.199 --> 00:02:20.360
single programming language that wrote to a
database and it did something. Yeah,
26
00:02:20.560 --> 00:02:24.639
that was easier, but also not
scalable and not very performance sometimes as it
27
00:02:24.680 --> 00:02:29.639
grew larger and larger. But you're
right, that was the architecture of the
28
00:02:29.759 --> 00:02:32.520
day because of a lot of things, a lot of constraints around hardware and
29
00:02:32.599 --> 00:02:40.000
networking, and it was just evolutionary
step in how to write software. So
30
00:02:40.080 --> 00:02:47.719
breaking things apart isn't a new idea. Back before Amazon even existed Amazon Web
31
00:02:47.759 --> 00:02:53.840
Services, that is, people were
trying to break apart these monolithic applications on
32
00:02:53.919 --> 00:03:00.560
prem into services. It went from
RPC to x amount to now we're at
33
00:03:01.080 --> 00:03:06.719
Jason and some other specs out there. We've always tried to do better as
34
00:03:06.759 --> 00:03:12.439
software developers, and now with the
advent of the cloud, service oriented architecture
35
00:03:12.439 --> 00:03:19.840
has turned into micro service architecture where
you can deploy things much faster, much
36
00:03:19.879 --> 00:03:25.199
more isolation, separation of concerns,
single responsibility principle. But it all comes
37
00:03:25.199 --> 00:03:30.800
to play and it just keeps evolving
as the platforms do as well. What
38
00:03:30.879 --> 00:03:37.280
are some of the benefits that business
users I guess organizations in general get out
39
00:03:37.280 --> 00:03:40.759
of this um you know, compared
to how things were over the last twenty
40
00:03:40.800 --> 00:03:46.800
years or so. Features faster.
From a business user perspective, ideally,
41
00:03:46.000 --> 00:03:50.919
the users of your application have no
idea how it's architected, right, but
42
00:03:51.240 --> 00:03:57.479
if they see more features faster,
fixes to broken features faster, they're going
43
00:03:57.520 --> 00:04:00.039
to appreciate that, right. And
then on the back end and of that
44
00:04:00.639 --> 00:04:05.879
from the organizational perspective, if we're
talking about enterprise, I t the enablers
45
00:04:05.919 --> 00:04:12.960
for those benefits of the business user
are the ability to deploy parts of the
46
00:04:13.000 --> 00:04:19.680
application independently and what that gives you
is isolated change and really reduces the scope
47
00:04:19.680 --> 00:04:26.399
of a testing effort, for instance, and it really allows you to scale
48
00:04:26.439 --> 00:04:30.360
those individual pieces to meet the demands
that the users are putting on the application.
49
00:04:31.040 --> 00:04:35.600
You know, going back to your
comment around being able to deploy faster,
50
00:04:36.240 --> 00:04:39.720
you know, I remember the stories
coming out of and I think it
51
00:04:39.839 --> 00:04:45.360
was what Netflix where they were releasing
code, and we go back to my
52
00:04:45.439 --> 00:04:48.399
codebal days, we're releasing code once
a month if you're lucky, they're releasing
53
00:04:48.439 --> 00:04:53.800
code every ten seconds or fifteen seconds
or something like that. And I think
54
00:04:54.360 --> 00:04:59.839
there's a lot to be said around
your ability just to be adaptive and reactive,
55
00:05:00.480 --> 00:05:06.360
not from the user perspective, but
ultimately from an end consumer perspective or
56
00:05:06.399 --> 00:05:12.639
how you meet your business needs to
react to your customers. So where I'm
57
00:05:12.639 --> 00:05:17.920
trying to go with that is you're
talking a lot around the users from the
58
00:05:17.959 --> 00:05:21.959
perspective within the business, but ultimately, what we're trying to get to is
59
00:05:23.240 --> 00:05:30.160
create differentiation in the marketplace for our
customers for their customers, if that makes
60
00:05:30.199 --> 00:05:34.879
sense, right. So, the
same principles apply whether it's an enterprise application
61
00:05:35.040 --> 00:05:41.120
or whether it's a consumer facing application. Consumers want the features faster. They
62
00:05:41.160 --> 00:05:46.720
want bugs fixed faster, and it's
that it's the DevOps philosophy applied to UH
63
00:05:46.920 --> 00:05:55.639
micro services architectural approach that makes that
possible, UM, regardless of of e
64
00:05:55.759 --> 00:06:00.839
commerce or app on a phone or
UH internal line business application. Those architectures
65
00:06:00.879 --> 00:06:04.600
are supporting all of those things now, and all of those users want the
66
00:06:04.639 --> 00:06:09.759
same UH, they want a great
experience. So let's talk a little bit
67
00:06:09.800 --> 00:06:15.439
about DevOps. What what does that
term DevOps really mean? Not from a
68
00:06:15.480 --> 00:06:19.560
definitional perspective, but what it means
for the business. What it means for
69
00:06:19.600 --> 00:06:29.920
the business is a philosophy applied to
the software development process that results in UH
70
00:06:30.120 --> 00:06:38.920
massive amounts of communication between operators and
developers of platforms. It means adopting agile
71
00:06:39.000 --> 00:06:46.560
principles as well as the DevOps philosophy
to to provide UH high quality, isolated
72
00:06:48.000 --> 00:06:51.879
changes that can be pushed out with
such confidence that, like you said,
73
00:06:51.920 --> 00:06:56.079
you can push them out every ten
seconds. It's kind of funny because we
74
00:06:56.120 --> 00:06:59.279
see, um, you know,
over the last ten years, the rise
75
00:06:59.319 --> 00:07:03.800
of DevOps has kind of put more
responsibility I guess in some organizations onto the
76
00:07:03.839 --> 00:07:11.160
developer and given I guess a reason
to no longer need that traditional system administrator.
77
00:07:11.600 --> 00:07:15.319
How do you see the role of
the cysadmin and the developer you know
78
00:07:15.399 --> 00:07:19.639
coming together or you know, what
are the different roles today versus UM where
79
00:07:19.639 --> 00:07:27.079
they were before. That pendulum keeps
swinging back and forth, even even today
80
00:07:27.079 --> 00:07:33.680
where we some companies are empowering development
teams with full stack responsibility including the cloud
81
00:07:33.680 --> 00:07:44.879
infrastructure, including support UH and bug
fixes and like really making a small I
82
00:07:45.000 --> 00:07:50.920
T department out of the teams that
develop these single micro services that are composed
83
00:07:51.000 --> 00:07:57.360
into the larger application. UM swing
the pendulum back the other way, and
84
00:07:57.759 --> 00:08:01.639
we've got enterprises that want separate team
that are handling the cloud infrastructure, separate
85
00:08:01.680 --> 00:08:07.600
from the teams that are developing the
software. I think it's gonna it's gonna
86
00:08:07.639 --> 00:08:11.519
swing somewhere in the middle where we
have the concept of the operators of a
87
00:08:11.560 --> 00:08:18.720
platform that is UH, that is
a separate skill set from developing applications that
88
00:08:18.839 --> 00:08:24.439
run on the platform. We can
see that with Kubernetes today, where these
89
00:08:24.480 --> 00:08:33.879
micro service enabling platforms become require expertise
to care and feed for these things.
90
00:08:33.919 --> 00:08:37.840
That has very little to do with
writing the software that's going to run on
91
00:08:37.840 --> 00:08:41.399
on Kubernetes cluster. So the pendulum
does keep swinging back and forth. But
92
00:08:41.440 --> 00:08:46.720
I think we're gonna land somewhere in
the middle where there is a separation of
93
00:08:46.759 --> 00:08:52.639
skills, but they have to work
tightly together, of course, because you
94
00:08:52.679 --> 00:08:56.720
know, that's the DevOps philosophy,
and if if you don't have those skills.
95
00:08:56.919 --> 00:09:01.080
I think we've seen some examples in
the news of apply chain attacks and
96
00:09:01.279 --> 00:09:05.679
things being made easier for um,
you know, milicious actors to get their
97
00:09:05.720 --> 00:09:09.000
code out there faster without folks knowing. Right, I'm not really sure about
98
00:09:09.039 --> 00:09:15.279
that one I had I hadn't heard
heard that, but yeah, why wouldn't
99
00:09:15.480 --> 00:09:22.120
militious actors be using the same principles
to push their attacks out faster. So
100
00:09:22.200 --> 00:09:26.480
let's let's examine this term cloud native. And I've had people talk to me
101
00:09:26.639 --> 00:09:31.279
that there's cloud native really doesn't exist, it's just a made up term that
102
00:09:31.399 --> 00:09:35.919
we're using. But wanted to get
your thoughts on when we talk about cloud
103
00:09:37.000 --> 00:09:41.200
native, what does that really mean? Cloud native? I don't think it's
104
00:09:41.200 --> 00:09:45.320
a made up term. I think
it describes something pretty real for for software
105
00:09:45.320 --> 00:09:50.559
developers, Um, if you go
in into a development of a new application
106
00:09:50.120 --> 00:09:56.480
with with cloud as a as the
first class uh priority. You're going to
107
00:09:56.600 --> 00:10:01.840
leverage platforms, and you're going to
go all in on a csp and you're
108
00:10:01.879 --> 00:10:07.120
gonna you're going to use all their
integration offerings, all their hosting offerings,
109
00:10:07.440 --> 00:10:11.679
and you're going to write your code
in a way that is native to that
110
00:10:11.840 --> 00:10:16.720
csp UM. To me, cloud
native is a lot of things. There's
111
00:10:16.720 --> 00:10:24.320
a whole uh Kubernetties as cloud native. Yeah, kubernetties is deployments are cloud
112
00:10:24.399 --> 00:10:28.840
native if you choose to run kubernetti
is on top of the csp UM.
113
00:10:28.919 --> 00:10:33.840
Some people refer to cloud native and
they mean serverless, like immediately they think
114
00:10:33.879 --> 00:10:41.720
serverless development. So cloud native is
real and it's a It means to me
115
00:10:41.440 --> 00:10:50.480
that where your code is going to
run becomes a first class uh uh requirement
116
00:10:50.919 --> 00:10:56.960
to the design of the application.
And what do you how do you see
117
00:10:56.000 --> 00:11:01.559
some of these more niche um I
don't know if you call them CSPs,
118
00:11:01.600 --> 00:11:07.960
but more applicate very specific application of
serverist cloud native providers like you know flight
119
00:11:07.000 --> 00:11:11.120
out Io and you know cloud flare
not really a niche one anymore, but
120
00:11:11.039 --> 00:11:16.679
kind of starting to offer their own
uh cloud native services and offerings that are
121
00:11:16.679 --> 00:11:24.279
competing now directly with the big ones. From a developer perspective, UM,
122
00:11:24.480 --> 00:11:28.519
I think that you're that You're right, it is super niche still right now.
123
00:11:28.960 --> 00:11:37.080
But the everybody's trying to provide a
pretty similar experience. You see,
124
00:11:37.399 --> 00:11:43.679
the major CSPs announced something and then
then the next CSP will follow suit,
125
00:11:43.240 --> 00:11:50.480
so they are identical services. But
everyone wants to have the table stakes to
126
00:11:50.600 --> 00:11:54.120
attract the development teams to build on
their on their platforms, and the niche
127
00:11:54.159 --> 00:12:01.840
players will likely just follow suit as
well. So do we end up by
128
00:12:01.080 --> 00:12:07.159
standardizing on one CSP or one of
these niche providers same place we were before
129
00:12:07.279 --> 00:12:15.279
from a monolithic perspective of its inability
to move those applications for another environment.
130
00:12:16.519 --> 00:12:22.799
Well that's the the hot and heavy
religious debate right now. Right Do I
131
00:12:22.840 --> 00:12:28.080
do I containerize everything with the hopes
that I can move it around to the
132
00:12:28.080 --> 00:12:33.840
different CSPs or back home UH and
then back out? Do I want this
133
00:12:33.039 --> 00:12:41.919
ultimate UH flexibility and where I run
my applications or am I going to go
134
00:12:41.000 --> 00:12:48.840
all in on a particular CSP right
everything in a cloud native CSP native way
135
00:12:50.080 --> 00:12:56.720
and gain the efficiencies there. So
the clients that you're coming into interact with
136
00:12:58.440 --> 00:13:03.360
where are they headed? We see
a lot of Kuberneties right now. UM
137
00:13:03.519 --> 00:13:09.679
serverless was groundbreaking to say the least, but over time, the developer experience
138
00:13:11.360 --> 00:13:18.960
around serverless it just it just wasn't
as robust as the development experience around container
139
00:13:18.039 --> 00:13:22.360
rised application. So we we think
servilis is going to cool off a little
140
00:13:22.360 --> 00:13:30.000
bit in favor of Kubernetes and other
container orchestration platforms, but not only because
141
00:13:30.000 --> 00:13:33.840
of the developer experience. It.
That's full circle to the multi cloud ambitions
142
00:13:33.879 --> 00:13:39.120
and the multi cloud being so buzzworthy
right now. UM a lot of driving
143
00:13:39.879 --> 00:13:46.320
folks towards the container experience, and
I think that's that's the focus for us
144
00:13:46.399 --> 00:13:50.639
right now. So let's talk.
You brought up multi cloud and distributed cloud
145
00:13:50.679 --> 00:13:56.960
there, what's your insights on this
trend. I don't think multi cloud or
146
00:13:58.039 --> 00:14:03.559
distributed cloud is going to reach its
promise for a while. UM. Even
147
00:14:03.720 --> 00:14:11.039
even around the container orchestate orchestration platforms, UM, there's not complete parity across
148
00:14:11.240 --> 00:14:18.320
clouds. UM, you still have
to deploy separately. I mean there there
149
00:14:18.320 --> 00:14:22.960
are companies trying to solve this right
single deployments any cloud. There there's software
150
00:14:22.960 --> 00:14:26.240
that you can layer over the top
of all of your your CSPs and try
151
00:14:26.279 --> 00:14:31.039
to get that single pane of glass
on a control plane. But I think
152
00:14:31.039 --> 00:14:35.200
it's going to take a take a
while for that to be really mainstream,
153
00:14:35.320 --> 00:14:46.960
especially around security and like identity management. Making an access or authorization authentication change
154
00:14:48.399 --> 00:14:54.799
in one CSP and propagating that across
to to affect the same deployment and another
155
00:14:54.840 --> 00:14:58.759
CSP. There are a lot of
complicated things that have to have to be
156
00:14:58.799 --> 00:15:03.639
solved for before distributed cloud is really
going to be easy. Um. I
157
00:15:03.639 --> 00:15:09.080
think it's a great goal though,
and I think containerization would be an absolute
158
00:15:09.120 --> 00:15:16.279
requirement at this point to even consider
making that happen. Does that mean in
159
00:15:16.360 --> 00:15:18.879
twenty years we'll have so many abstructions
that nobody will have any idea how it
160
00:15:18.919 --> 00:15:28.919
actually works? Um, CSP as
a public utility? What are the ones
161
00:15:28.919 --> 00:15:33.879
and zeroes? Yeah, I mean
that's the promise, that's the like the
162
00:15:33.000 --> 00:15:37.720
dream of of containerization. Right.
It runs on my laptop, It runs
163
00:15:37.840 --> 00:15:41.279
in Azure, it runs in aw
As, it runs on Google. It
164
00:15:41.440 --> 00:15:48.360
runs refrigerator on your refrigerator. It
runs on a on a stack at a
165
00:15:48.559 --> 00:15:54.960
cell tower on the edge and it
and the developer never has to take that
166
00:15:54.000 --> 00:15:58.840
into consideration at all. And we
can do a whole podcast and on the
167
00:15:58.960 --> 00:16:03.919
security ramifications of it running everywhere around
that. Okay, I'm gonna give you
168
00:16:03.919 --> 00:16:07.480
a couple more friends that you know
gardners identified. One is you know,
169
00:16:07.639 --> 00:16:12.399
composable applications and enterprise, and another
is low code, no code. Wanted
170
00:16:12.399 --> 00:16:18.240
to get your kind of insights on
those two trends. So composable, man,
171
00:16:18.279 --> 00:16:22.600
it can mean, it can mean
so much. Um, I think
172
00:16:22.600 --> 00:16:30.159
when we talk about composable enterprise,
we're talking about UH and enterprise architecture that
173
00:16:30.279 --> 00:16:38.159
involves the connecting of both custom and
off the shelf uh sas is what we
174
00:16:38.799 --> 00:16:42.720
refer to when we say off the
shelf. Nowadays, of course, UM,
175
00:16:42.840 --> 00:16:51.399
we've eaten together the software that runs
your business by leveraging the right service
176
00:16:51.440 --> 00:17:00.080
for the right job versus these huge
monolithic suites of single vendor solutions. So
177
00:17:00.480 --> 00:17:04.559
what that means is when one piece
isn't working, you can take it out
178
00:17:04.880 --> 00:17:08.079
and replace it with another piece.
Right. So, I mean a lot
179
00:17:08.079 --> 00:17:11.480
of things in tech are not literal. Uh. I think when we talk
180
00:17:11.519 --> 00:17:19.200
about compose herble, it's it really
is literally composing your enterprise architecture and the
181
00:17:19.240 --> 00:17:27.079
applications required to run your business from
infinite lego set of of offerings, and
182
00:17:27.559 --> 00:17:36.400
that giving you the flexibility to UH
change and upgrade parts of your enterprise independently.
183
00:17:37.640 --> 00:17:41.640
Now, when we talk about a
composable application from a micro services standpoint,
184
00:17:42.440 --> 00:17:51.839
UH, it's about enterprises being able
to leverage these services to create new
185
00:17:51.920 --> 00:17:59.559
lines of business applications UM by the
virtue of reuse of these single purpose,
186
00:18:00.079 --> 00:18:04.960
very loosely coupled pieces of functionality.
So it can mean a lot of things.
187
00:18:06.400 --> 00:18:10.160
Question for you, Fred, because
we've been talking about at the application
188
00:18:10.279 --> 00:18:15.240
layer, but data just doesn't come
along for free. So what are the
189
00:18:15.279 --> 00:18:19.200
implications as we start to move to
these cloud native that you know, our
190
00:18:19.200 --> 00:18:23.720
audience needs to think about from a
data perspective? I think so long it's
191
00:18:23.759 --> 00:18:29.279
kind of the same thing that that
organizations have needed to think about for the
192
00:18:29.359 --> 00:18:32.480
last you know, ten twenty years
when it comes to their data, which
193
00:18:32.559 --> 00:18:36.920
is UM. You know, make
sure you're collecting the data that you want
194
00:18:37.039 --> 00:18:40.960
and make sure it's accessible and retrievable
so that you can either centralize it or
195
00:18:41.000 --> 00:18:45.559
put it in a place that UM
your various apps can start using it because
196
00:18:45.319 --> 00:18:49.079
you know, I think one of
the big things we're seeing is as as
197
00:18:49.160 --> 00:18:56.480
become more containerized and more distributed and
more single purpose. Um. What we're
198
00:18:56.519 --> 00:19:00.279
creating is a whole bunch of data
silos in the process. And so you'll
199
00:19:00.279 --> 00:19:03.440
have very specific marketing apps that do
one thing, maybe they only do email
200
00:19:03.480 --> 00:19:07.079
campaigns, and then you have another
one that's really good at creating personas.
201
00:19:07.599 --> 00:19:11.960
Now all these applications need to start
sharing data. And if you create this
202
00:19:11.039 --> 00:19:15.200
point to point integration, you take
away one of those applications and boom,
203
00:19:15.240 --> 00:19:19.279
You've just broken the entire spider web
chain of data going all over the place.
204
00:19:21.039 --> 00:19:23.640
So I think what organizations need to
do is start to put plans together
205
00:19:23.759 --> 00:19:29.720
as they start to adopt and modernize
their applications, how are they going to
206
00:19:29.759 --> 00:19:33.559
leverage the data that is uh,
these applications are both collecting and consuming,
207
00:19:33.599 --> 00:19:38.000
and how can they make that data
available UM to the rest of the applications
208
00:19:38.039 --> 00:19:45.000
within the organization Suggesting I mean,
as you're talking to clients, first of
209
00:19:45.000 --> 00:19:48.279
all, is data second class citizen
for them? Are they thinking about that
210
00:19:48.359 --> 00:19:56.119
holistically? So early adopters of of
micro services and the more distributed approach.
211
00:19:56.920 --> 00:20:03.079
UH found out very quickly what happened
when you move the data into purpose built
212
00:20:03.720 --> 00:20:08.519
databases and wall walled off around a
service boundary, it becomes very difficult to
213
00:20:10.519 --> 00:20:17.559
re aggregate that data and report.
And we see the advent of or the
214
00:20:17.680 --> 00:20:27.880
re the re emergence of enterprise service
bus type connections between micro services. UH
215
00:20:29.000 --> 00:20:33.880
so that the right services have copies
of the right data. And now that
216
00:20:33.000 --> 00:20:37.680
just spawns another problem. Right,
So, now you're taken the concept of
217
00:20:37.759 --> 00:20:44.359
single responsibility all the way down to
data persistence, and now you're making copies
218
00:20:44.400 --> 00:20:49.559
of that data. So now this
each of these services grab copies of the
219
00:20:49.640 --> 00:20:56.480
data they need for performance. You've
got an analytics and a reporting uh concern.
220
00:20:56.880 --> 00:21:00.200
So where do where do you get
the data to aggregate to do the
221
00:21:00.319 --> 00:21:02.920
reporting and it and it just goes
on and on from there. Right.
222
00:21:03.279 --> 00:21:10.519
So, early adopters really uncovered this
challenge with a micro service and distributed architecture
223
00:21:11.119 --> 00:21:17.319
and we're still solving that problem as
a as a group of technologists. So
224
00:21:17.400 --> 00:21:23.319
do we still have the term database
administrator or has that been incorporated into the
225
00:21:23.680 --> 00:21:30.599
developers as a part of just what
they're doing, or do they have the
226
00:21:30.680 --> 00:21:36.599
knowledge to understand the impact and ramifications
of these new services with data. It's
227
00:21:36.599 --> 00:21:41.559
another one of those things that like
debops and Sadman's it's a little a little
228
00:21:41.559 --> 00:21:42.559
bit of both. Right, you
get rid of it and put it all
229
00:21:42.559 --> 00:21:47.759
on the developers and uh, you
know there there were certain dB A activities
230
00:21:47.799 --> 00:21:51.519
that have been done over the last
decade that you know, data modeling for
231
00:21:51.559 --> 00:21:53.920
instance, that's something that belongs more
on the business side, co existing with
232
00:21:53.960 --> 00:22:03.359
the developers. UM understanding how to
UM both secure and size and configure your
233
00:22:03.440 --> 00:22:06.640
database and keep it going. Now, a lot of that is shifted to
234
00:22:06.640 --> 00:22:11.640
the cloud service providers, but it
hasn't completely taken it away, um from
235
00:22:11.720 --> 00:22:17.079
the organization's responsibility. So is it
the same big job that it was before.
236
00:22:18.000 --> 00:22:21.599
It depends on how you're hosting everything. Everything is in the cloud.
237
00:22:22.599 --> 00:22:26.319
Um, do you still need a
little bit of it? Yes? Do
238
00:22:26.599 --> 00:22:32.480
organizations find themselves missing some of those
skills? I think definitely us It's it
239
00:22:32.559 --> 00:22:37.400
follows the shared responsibility model, uh
for the csp s right, UM,
240
00:22:37.519 --> 00:22:44.319
what you're referring to, like back
ups and archiving and all these things that
241
00:22:44.400 --> 00:22:48.160
d B as Uh, that was
half of their job and then the other
242
00:22:48.200 --> 00:22:52.240
half of their job was to help
developers get the schema correct and uh,
243
00:22:52.480 --> 00:22:56.519
you know, make a sensible model
of of what's going on in the business
244
00:22:56.960 --> 00:23:03.279
when you go to these managed platforms, and uh, the at the csp
245
00:23:03.440 --> 00:23:07.839
S offer half of your job is
now a checkbox that says, please back
246
00:23:07.880 --> 00:23:15.799
this up in archive it and pushing
the the responsibility for performance and modeling into
247
00:23:15.839 --> 00:23:22.880
the team makes the database minded person
part of that cross functional development team now
248
00:23:22.920 --> 00:23:30.039
instead of sitting with the siss adminds
and and the networking folks. So it's
249
00:23:30.039 --> 00:23:33.640
an evolution of what what that role
can can be. But you're always going
250
00:23:33.680 --> 00:23:38.519
to have to tune in performance,
tune relational database. I mean, that's
251
00:23:38.720 --> 00:23:42.119
somebody always has to do that.
Um, but I think we're going to
252
00:23:42.200 --> 00:23:45.920
find that those folks are going to
be sitting on on the scrum teams versus
253
00:23:45.920 --> 00:23:53.599
sitting in the server rooms the virtual
server room. All right, I'm gonna
254
00:23:53.680 --> 00:23:57.880
kind of wrap this up. How
can our listeners know if they're ready?
255
00:23:59.000 --> 00:24:00.960
And you know, what are some
of the questions they should ask themselves.
256
00:24:02.400 --> 00:24:07.480
So it really doesn't matter if you
feel like you're ready or not. The
257
00:24:07.519 --> 00:24:11.960
impetus is there. You have to
get ready for this and the questions you
258
00:24:11.960 --> 00:24:17.680
should be asking yourself. Are am
I able to release features to the market
259
00:24:18.000 --> 00:24:22.799
fast enough to satisfy users and to
keep up with my competitors? Are my
260
00:24:22.559 --> 00:24:30.920
developers? Are they able to push
out code in a way that is consistent
261
00:24:32.559 --> 00:24:38.799
and high quality and supports that ability
to push these features out faster and faster.
262
00:24:40.480 --> 00:24:45.119
So if you're not ready, get
ready, and thankfully we're here to
263
00:24:45.160 --> 00:24:49.720
help you with that right and from
the application modernization practice at second Watch,
264
00:24:49.839 --> 00:24:55.640
we help clients figure out where to
start on that journey. Because if you're
265
00:24:55.680 --> 00:25:02.640
sitting on hundreds of applications in your
portfolio and you don't have good observe ability
266
00:25:02.680 --> 00:25:04.680
and you don't have a good idea
of what all these things are doing and
267
00:25:04.720 --> 00:25:08.400
what their business value is, it
can be daunting, even if you feel
268
00:25:08.440 --> 00:25:14.640
like you're ready to start. So
regardless of whether you're in the cloud already
269
00:25:14.799 --> 00:25:19.079
or on prem we can help with
that portfolio rationalization and help you get started.
270
00:25:19.640 --> 00:25:23.359
Well. I mean, that's gonna
bring up another question though, Do
271
00:25:23.720 --> 00:25:29.720
organizations and companies have the talent to
do this? We're in the talent shortage
272
00:25:29.839 --> 00:25:32.559
right now. Do they have the
talent to be able to take this on
273
00:25:32.599 --> 00:25:40.240
themselves. It varies obviously, but
overall, I would say that that's a
274
00:25:40.359 --> 00:25:42.799
huge concern. So going back to
are you ready? How do you know
275
00:25:42.839 --> 00:25:45.640
if you're ready for this? That
has to be one of the things that
276
00:25:45.680 --> 00:25:52.319
you take into consideration. Do I
have the culture and the resources in house
277
00:25:52.799 --> 00:26:00.920
to achieve these modernization goals? So
a guided application rationalization process is absolutely necessary,
278
00:26:02.279 --> 00:26:07.359
regardless of whether you can tackle the
implementation and the execution phase or not.
279
00:26:07.000 --> 00:26:12.400
And we're can second Watch help clients
get ready and build up that talent.
280
00:26:12.799 --> 00:26:19.640
So we really pride ourselves on a
do it with you approach over a
281
00:26:19.720 --> 00:26:23.200
do it for you approach. So
when you engage with second Watch and we
282
00:26:23.240 --> 00:26:29.400
get through a rationalization process, we
get through some deep dive assessments on some
283
00:26:29.759 --> 00:26:33.160
good candidates to start your modernization journey. We also can step in and help
284
00:26:33.200 --> 00:26:38.720
your teams actually execute this work,
and we can neither embed with your team.
285
00:26:38.920 --> 00:26:44.240
We can offer a team that execute
side by side with your teams.
286
00:26:44.759 --> 00:26:51.000
We really are flexible and our intent
is to leave the client with the knowledge
287
00:26:51.799 --> 00:26:56.359
and the know how to operate,
enhance, and run these new applications.
288
00:26:56.000 --> 00:27:02.039
All right, last last question,
give us a six story of where we've
289
00:27:02.039 --> 00:27:04.480
been able to go in and help
a client and what did we do,
290
00:27:04.599 --> 00:27:10.519
what did we help them achieve.
So, we had a client that desperately
291
00:27:10.720 --> 00:27:18.200
wanted to migrate off of a licensed
database platform onto something open source and managed
292
00:27:18.240 --> 00:27:22.039
in the cloud. We helped the
client assess the application changes that were would
293
00:27:22.039 --> 00:27:27.799
be required, we help them plan
for that migration, and we actually executed
294
00:27:29.039 --> 00:27:34.880
a successful migration from a very expensive
platform to a much more cost effective solution
295
00:27:36.400 --> 00:27:40.799
on a managed database CSP all right, well, thank you everyone for joining
296
00:27:40.880 --> 00:27:44.640
us here on cloud Crunch. Jesse, I want to say a great appreciation
297
00:27:44.680 --> 00:27:49.599
for you coming on to the podcast. This has been cloud Crunch with Michael
298
00:27:49.640 --> 00:27:55.079
Elliott joining me today as always has
been Fred Bliss, CTO of all Things
299
00:27:55.160 --> 00:28:00.200
Data, with special guests today Jesse
Saying, Practice Director Application Modernization here at
300
00:28:00.240 --> 00:28:08.039
second Watch. Thank you everyone,
appreciate your time. Thanks everyone you've been
301
00:28:08.079 --> 00:28:14.680
listening to cloud Crunch with Michael Elliott
and Fred Bliss. For more information,
302
00:28:14.920 --> 00:28:19.359
check out the blog second watch dot
com, forward Slash cloud dash blog,
303
00:28:19.960 --> 00:28:23.720
or reach out to second Watch on
Twitter and LinkedIn.
