1
00:00:00,000 --> 00:00:03,140
Hey there! I wanted to tell you about a new podcast we got going over here at Pivotal.

2
00:00:03,260 --> 00:00:05,800
It's called That Moment. Don't get confused like I was initially.

3
00:00:06,060 --> 00:00:07,960
It's not the moment. It's called That Moment.

4
00:00:08,060 --> 00:00:10,280
That Moment explores the pivot that changes everything,

5
00:00:10,560 --> 00:00:12,680
moments that open doors for discovery and growth,

6
00:00:12,760 --> 00:00:15,040
but also brings the looming possibility of failure.

7
00:00:15,220 --> 00:00:18,160
Each show features different leaders and innovators sharing their stories

8
00:00:18,160 --> 00:00:19,880
and taking risks in business life.

9
00:00:19,980 --> 00:00:21,680
It's, you know, classic Pivotal stories.

10
00:00:21,860 --> 00:00:25,660
Also, it's fancy with all the cross-fading music and optimized editing.

11
00:00:26,040 --> 00:00:27,160
It's really some good pro stuff.

12
00:00:27,160 --> 00:00:30,620
So if you're interested in those kind of stories about how people are wangling their way

13
00:00:30,620 --> 00:00:34,060
through all this digital transformation, DevOps, cloud-native stuff,

14
00:00:34,140 --> 00:00:36,600
go subscribe to That Moment wherever you get your podcast.

15
00:00:36,940 --> 00:00:40,680
But, you know, for your weekly dose of unprofessional old-school podcast rambling,

16
00:00:40,980 --> 00:00:41,900
let's get on with the show.

17
00:00:42,020 --> 00:00:46,480
Well, Richard, this morning, you know, my daughter is not sleeping through the night

18
00:00:46,480 --> 00:00:49,500
despite sleeping on one of those very comfortable internet mattresses,

19
00:00:49,580 --> 00:00:52,200
which you'll see how this gets in.

20
00:00:52,220 --> 00:00:54,100
I later took a nap on that.

21
00:00:54,100 --> 00:00:58,620
But she gets up at the night and, I don't know, she's afraid of ghosts or something.

22
00:00:58,760 --> 00:00:59,780
I don't know where this comes from.

23
00:00:59,920 --> 00:01:00,560
There's no ghosts.

24
00:01:01,240 --> 00:01:05,000
I guess she hasn't learned science yet, but it's only about four.

25
00:01:05,640 --> 00:01:07,460
And anyways, I couldn't go back to sleep.

26
00:01:07,540 --> 00:01:08,600
It was like 2.30 a.m.

27
00:01:08,600 --> 00:01:15,320
So the question I have for you, well, one, I'm assuming that you're not some sort of superhuman

28
00:01:15,320 --> 00:01:18,880
and that you can actually go back to sleep 100% of the time.

29
00:01:18,940 --> 00:01:23,160
I'm assuming maybe you've got like two nines on go-to-sleep ability as the SLA.

30
00:01:23,400 --> 00:01:25,660
But when you can't go back to sleep, what do you do?

31
00:01:25,960 --> 00:01:27,540
How do you spend your time?

32
00:01:29,360 --> 00:01:32,840
Yeah, I usually get up because I just can't stand staring there.

33
00:01:33,020 --> 00:01:34,540
And then I start thinking about things to do.

34
00:01:34,600 --> 00:01:38,120
So sometimes you quick put on the TV downstairs or I'll do a little work and hope to get sleepy,

35
00:01:38,260 --> 00:01:39,040
which never works.

36
00:01:39,340 --> 00:01:40,240
And then I'm just up the whole time.

37
00:01:40,660 --> 00:01:40,900
Yeah?

38
00:01:41,360 --> 00:01:41,520
Yeah.

39
00:01:41,600 --> 00:01:43,800
Are you a big TV person?

40
00:01:45,620 --> 00:01:47,600
You know, late-night infomercials.

41
00:01:47,620 --> 00:01:49,960
I'm sure you probably have a whole sleeve of Ginsu knives.

42
00:01:50,220 --> 00:01:50,420
Yeah.

43
00:01:50,420 --> 00:01:51,340
Or maybe a juicer.

44
00:01:51,520 --> 00:01:56,720
Do you have any of those green fry pans from the dump lady?

45
00:01:57,760 --> 00:01:59,000
Is she still advertising?

46
00:02:01,360 --> 00:02:01,920
Yeah, no.

47
00:02:02,000 --> 00:02:03,880
You know, actually, I haven't bought any late-night things before.

48
00:02:03,880 --> 00:02:05,620
So I'm only joking from non-experience.

49
00:02:05,800 --> 00:02:06,960
But, you know, those things are compelling.

50
00:02:07,160 --> 00:02:10,100
By the end, you're ready to lose weight and cut shoes with a knife.

51
00:02:10,400 --> 00:02:11,540
Oh, cut shoes with a knife.

52
00:02:11,600 --> 00:02:12,400
That's my favorite.

53
00:02:14,040 --> 00:02:15,560
How about yourself, guest?

54
00:02:15,760 --> 00:02:20,640
What do you do when you can't get back to sleep and you really should get back to sleep?

55
00:02:21,920 --> 00:02:27,020
I find the cold side of the pillow and just reflecting on the day.

56
00:02:27,440 --> 00:02:28,040
Oh, man.

57
00:02:28,220 --> 00:02:29,180
Cold side of the pillow.

58
00:02:30,240 --> 00:02:33,400
You know, if you're ever going to write a memoir, you need to put that in there somewhere.

59
00:02:33,700 --> 00:02:36,020
Chapter 32, cold side of the pillow.

60
00:02:36,760 --> 00:02:37,540
That would be good.

61
00:02:37,620 --> 00:02:39,280
Well, why don't you introduce yourself briefly, guest?

62
00:02:40,420 --> 00:02:42,340
Hey, so I'm Ben LaPlanche.

63
00:02:42,500 --> 00:02:46,080
I work for Pivotal, one of the directors on the product management team and based in London.

64
00:02:47,480 --> 00:02:47,840
Indeed.

65
00:02:48,160 --> 00:02:50,580
So what did you guys have for breakfast this morning?

66
00:02:50,740 --> 00:02:51,700
They're bringing breakfast, right?

67
00:02:53,160 --> 00:02:53,480
Yeah.

68
00:02:54,360 --> 00:02:55,440
It's actually kind of American.

69
00:02:55,620 --> 00:02:57,480
Had some, like, kind of breakfast burritos.

70
00:02:57,900 --> 00:02:58,320
It's kind of good.

71
00:02:58,480 --> 00:03:00,340
It reminded me of the Cloud Foundry Summit, actually.

72
00:03:00,720 --> 00:03:01,000
Yeah.

73
00:03:01,160 --> 00:03:05,680
Now, did they have the white tortillas on there or were they going with some sort of rainbow tortilla?

74
00:03:06,020 --> 00:03:06,880
Did you have, like, wheat?

75
00:03:06,980 --> 00:03:07,200
No.

76
00:03:07,640 --> 00:03:07,960
Spinach?

77
00:03:08,100 --> 00:03:09,620
No, it was the white ones.

78
00:03:09,740 --> 00:03:10,460
Oh, solid.

79
00:03:10,700 --> 00:03:10,980
Solid.

80
00:03:11,380 --> 00:03:11,980
Sausage in there.

81
00:03:12,340 --> 00:03:13,380
Man, that's old school.

82
00:03:13,500 --> 00:03:14,640
That's genuine right there.

83
00:03:14,920 --> 00:03:15,640
I like it.

84
00:03:15,880 --> 00:03:16,120
Yeah.

85
00:03:16,520 --> 00:03:18,500
I like that you consider burritos American.

86
00:03:20,220 --> 00:03:24,000
It's whatever you always seem to have in the office whenever I come out to San Francisco

87
00:03:24,000 --> 00:03:25,440
or to Cloud Foundry Summit.

88
00:03:25,800 --> 00:03:26,660
There's breakfast burritos.

89
00:03:27,100 --> 00:03:27,260
Yeah.

90
00:03:27,420 --> 00:03:31,600
Well, I mean, you know, to your point, Richard, little known fact, the burrito was originated

91
00:03:31,600 --> 00:03:35,140
in Turin in the late 1300s, I think.

92
00:03:35,240 --> 00:03:35,740
Isn't that true?

93
00:03:36,360 --> 00:03:37,240
Hence burrito.

94
00:03:37,480 --> 00:03:37,820
I don't know.

95
00:03:38,140 --> 00:03:38,320
No.

96
00:03:38,620 --> 00:03:38,800
Yeah.

97
00:03:38,900 --> 00:03:39,740
Come from the containers.

98
00:03:40,000 --> 00:03:41,100
Stay for the burrito knowledge.

99
00:03:41,360 --> 00:03:42,420
That's this podcast.

100
00:03:42,820 --> 00:03:43,080
Yeah.

101
00:03:43,180 --> 00:03:47,800
Well, speaking of burrito knowledge, we'll have, you know, we have been on to talk about

102
00:03:47,800 --> 00:03:50,200
some exciting stuff here in the second half.

103
00:03:50,220 --> 00:03:52,000
But we've got a little spate of news.

104
00:03:52,000 --> 00:03:58,900
As I've been saying recently, we're, well, I think tomorrow we will officially, by, you

105
00:03:58,900 --> 00:04:00,540
know, science, be entering August.

106
00:04:01,120 --> 00:04:04,540
Would you say that calendar stuff is science or is that more social?

107
00:04:05,020 --> 00:04:05,640
I don't know.

108
00:04:06,280 --> 00:04:06,980
I guess it's derived from science.

109
00:04:06,980 --> 00:04:07,700
Yeah, there's a map.

110
00:04:08,080 --> 00:04:09,020
I guess it's science too.

111
00:04:09,100 --> 00:04:09,260
Sure.

112
00:04:09,680 --> 00:04:12,620
You know, I had someone correct me this week and I was, they were talking about some sort

113
00:04:12,620 --> 00:04:14,660
of addition thing and I was like, oh, math is hard.

114
00:04:14,740 --> 00:04:16,340
And then they were like, you mean arithmetic.

115
00:04:16,680 --> 00:04:18,200
I was like, whoa, I'm sorry.

116
00:04:19,520 --> 00:04:19,740
Yeah.

117
00:04:20,060 --> 00:04:21,240
You seem like a lot of fun.

118
00:04:21,240 --> 00:04:27,820
I was told no math vocabulary was going to be involved, but, uh, but yeah, so, uh, this

119
00:04:27,820 --> 00:04:29,060
is a little bit of news here.

120
00:04:29,140 --> 00:04:29,760
Some good stuff.

121
00:04:29,800 --> 00:04:33,800
I mean, I think, uh, I think last week, all the, all the big, I think finally all the big

122
00:04:33,800 --> 00:04:38,600
cloud providers have, have announced their news and, and, uh, you know, uh, it looks like

123
00:04:38,600 --> 00:04:42,640
Google announced a bunch of, uh, how would I characterize it?

124
00:04:42,820 --> 00:04:45,620
Uh, they, they sort of announced some momentum in larger accounts.

125
00:04:45,620 --> 00:04:49,660
Like what was the ad to go back and read this three times, but that there was, uh, they

126
00:04:49,660 --> 00:04:56,120
had three times the number of cloud deals over half a million dollars than they did last

127
00:04:56,120 --> 00:05:02,180
quarter, I think, or then they did ones underneath it, which I, um, as always, I haven't installed

128
00:05:02,180 --> 00:05:05,160
the, um, the Monte Carlo pack for Excel.

129
00:05:05,160 --> 00:05:09,480
So I'm not really sure how to figure out what that means, but it sounds like there's some, uh, big

130
00:05:09,480 --> 00:05:11,060
cloud momentum deals they have.

131
00:05:12,520 --> 00:05:12,920
Yeah.

132
00:05:13,040 --> 00:05:17,620
I mean, you know, Amazon got grief when a few years ago when they kept lumping AWS at the

133
00:05:17,620 --> 00:05:18,600
other bucket.

134
00:05:18,660 --> 00:05:20,060
Like it could, this could be anything.

135
00:05:20,060 --> 00:05:23,980
And now Google and even Microsoft, I guess Microsoft's better now, but still cloud is

136
00:05:23,980 --> 00:05:25,040
very chunky for them.

137
00:05:25,120 --> 00:05:27,160
We'll stick office 365 in there though.

138
00:05:27,480 --> 00:05:31,040
It's hard to pull out what we all think of as cloud from that same with IBM.

139
00:05:31,160 --> 00:05:34,940
IBM says they, you know, are doing bigger business than Amazon now on cloud.

140
00:05:35,260 --> 00:05:39,680
I, it just depends on your math, I guess, going back to what are you including in that

141
00:05:39,680 --> 00:05:40,080
number?

142
00:05:40,080 --> 00:05:41,760
But at least you're including some numbers in Google.

143
00:05:41,760 --> 00:05:43,060
This is also an other bucket.

144
00:05:43,640 --> 00:05:45,180
So it seems like cloud is doing well.

145
00:05:45,340 --> 00:05:45,840
That's great.

146
00:05:46,280 --> 00:05:49,460
But I think we'll look forward to all of these companies being a little more transparent there.

147
00:05:50,140 --> 00:05:53,320
And, you know, I think at this point, like at least just speaking for myself, the thing

148
00:05:53,320 --> 00:05:58,240
that I monitor is, uh, ongoing evidence of the theory of the, uh, we were talking about

149
00:05:58,240 --> 00:06:02,080
this last episode about the, the public cloud Cerebus being formed.

150
00:06:02,260 --> 00:06:06,580
I think, I think, you know, and making sure that, uh, that the theory that it's basically

151
00:06:06,580 --> 00:06:11,700
Amazon Azure and Google as the, the dominant public cloud people, and maybe

152
00:06:11,700 --> 00:06:17,360
hybrid hybrid's a fun new word nowadays, uh, or I shouldn't say new it's returned sort

153
00:06:17,360 --> 00:06:21,380
of like, uh, you ever notice bell bottoms never came back, but you know, I guess, I guess

154
00:06:21,380 --> 00:06:24,140
I've noticed that like, uh, mom pants have come back.

155
00:06:24,460 --> 00:06:30,740
So anyways, uh, it's, it's good to get further input about, uh, if, if those, if those three

156
00:06:30,740 --> 00:06:34,660
are going to be the, the leaders by, I suppose revenue, which I'm not sure how else you would,

157
00:06:34,800 --> 00:06:35,400
you would do it.

158
00:06:35,400 --> 00:06:38,460
And, uh, this, this is certainly in the positive side of that.

159
00:06:39,860 --> 00:06:42,100
Yeah, I think this one will touch on our third news point.

160
00:06:42,220 --> 00:06:46,160
Cause I think these things are related, but the, uh, the second one was, you know, I was

161
00:06:46,160 --> 00:06:47,800
just looking for other interesting things last week.

162
00:06:47,860 --> 00:06:50,080
Everybody's, you know, it's summertime people still shipping software.

163
00:06:50,240 --> 00:06:54,740
So Microsoft shipped a new container service, kind of pay by the second, just deploy a container

164
00:06:54,740 --> 00:06:56,500
and you can still bring your own scheduler.

165
00:06:56,600 --> 00:07:00,220
And I guess you're getting, you're seeing the cloud companies continue to offer different

166
00:07:00,220 --> 00:07:01,180
models of compute.

167
00:07:01,320 --> 00:07:02,600
So it's a neat service for Microsoft.

168
00:07:02,600 --> 00:07:03,140
It's fine.

169
00:07:03,200 --> 00:07:08,200
It's fairly basic, but again, it's always about trying to make the on-ramp easier.

170
00:07:08,520 --> 00:07:10,320
And so it was, uh, just caught my eye.

171
00:07:10,820 --> 00:07:10,900
Yeah.

172
00:07:11,440 --> 00:07:12,480
Yeah, definitely.

173
00:07:12,860 --> 00:07:17,520
And, and then, and then, uh, and then also I think, uh, Microsoft joined the container

174
00:07:17,520 --> 00:07:18,380
service people.

175
00:07:19,060 --> 00:07:19,540
That's right.

176
00:07:19,620 --> 00:07:20,220
We're offering that now.

177
00:07:20,560 --> 00:07:25,040
Now, how, how, how, how would you two describe what a container service is?

178
00:07:25,040 --> 00:07:29,260
I think I was, as I was reading over that, I was realizing that I haven't really seen,

179
00:07:29,260 --> 00:07:31,700
there's been a lot of, are we supposed to call serverless Jeff now?

180
00:07:31,940 --> 00:07:35,460
Or is that too much of an inside joke that there's, there's been a lot of coverage of

181
00:07:35,460 --> 00:07:36,600
what like Jeff is.

182
00:07:36,740 --> 00:07:41,440
And then I suppose we have an assumption of what, uh, traditional public cloud is.

183
00:07:41,440 --> 00:07:41,840
Right.

184
00:07:42,060 --> 00:07:46,140
But I haven't really seen a lot of discussion of like, this is what container service means

185
00:07:46,140 --> 00:07:48,240
other than it's right there in the name.

186
00:07:48,240 --> 00:07:51,840
So like, how, how would, how would y'all two like characterize what a container service

187
00:07:51,840 --> 00:07:53,480
is versus other things?

188
00:07:55,260 --> 00:07:55,580
Yeah.

189
00:07:55,600 --> 00:07:59,000
I mean, I think in essence, Ben, I'll, I'll be interested in your take too, but I mean,

190
00:07:59,280 --> 00:08:02,520
for the most part, just like, you know, I want to run a VM, I want to run a function.

191
00:08:02,520 --> 00:08:05,020
I want to run an application, which is traditional paths.

192
00:08:05,160 --> 00:08:10,300
This is, I have a container, which again, a container kind of has a bit of OS virtualization,

193
00:08:10,460 --> 00:08:13,800
has an application stack potentially embedded and now go run it for me.

194
00:08:13,900 --> 00:08:15,320
And that could be a few hundred bags.

195
00:08:15,380 --> 00:08:19,400
It could be a few gigs depending on how you build it and almost just like a virtual machine,

196
00:08:19,460 --> 00:08:23,200
at least in terms of how it's run by the service, you know, you run this thing for me.

197
00:08:23,280 --> 00:08:26,500
Now, if I want to do more advanced stuff, I have to bring in a scheduler or something

198
00:08:26,500 --> 00:08:27,520
else that runs these things.

199
00:08:27,540 --> 00:08:31,620
If I look at Google container engine, you know, that thing's meant to be a full on scheduler

200
00:08:31,620 --> 00:08:33,140
that you run your containers on.

201
00:08:33,140 --> 00:08:36,880
In this Microsoft case, it's, Hey, just run a container and it has a public IP.

202
00:08:37,040 --> 00:08:37,520
That's cool.

203
00:08:37,800 --> 00:08:38,960
And pay by the second.

204
00:08:39,280 --> 00:08:40,460
Maybe I put my web app in there.

205
00:08:40,580 --> 00:08:42,640
Maybe I put a data service in there for some weird reason.

206
00:08:43,340 --> 00:08:45,980
So, you know, it's take my container and run it for me.

207
00:08:46,040 --> 00:08:47,740
It's all just different levels of abstraction.

208
00:08:49,180 --> 00:08:49,840
Yeah, that's interesting.

209
00:08:50,120 --> 00:08:55,420
I try and reason about the value that it would give me and I land on something like it's compute

210
00:08:55,420 --> 00:08:59,860
as an API because I guess that's what you're really getting out there is you've got different

211
00:08:59,860 --> 00:09:01,980
flexibilities and the types of compute that you need.

212
00:09:03,420 --> 00:09:05,520
So, yeah, I find that quite interesting to think about it that way.

213
00:09:05,820 --> 00:09:06,020
Yeah.

214
00:09:06,180 --> 00:09:12,400
I mean, do y'all think it's fair just to, I mean, take it on face value of like, well,

215
00:09:12,760 --> 00:09:19,260
traditional cloud is VMs as a service and this is containers as a service, right?

216
00:09:19,280 --> 00:09:25,080
It just like runs a different type of packaging of things and there's not really anything more

217
00:09:25,080 --> 00:09:25,940
exotic than that.

218
00:09:26,820 --> 00:09:31,300
Yeah, I mean, there's this kind of ongoing debate of what is the atomic unit of compute?

219
00:09:31,680 --> 00:09:32,600
Is it a container?

220
00:09:32,760 --> 00:09:33,500
Is it a function?

221
00:09:33,820 --> 00:09:35,060
Is it like, what is the thing?

222
00:09:35,160 --> 00:09:36,660
So, yes, it could be a whole VM.

223
00:09:36,920 --> 00:09:40,360
It could be, again, just an application like you deploy to Heroku or Cloud Foundry.

224
00:09:40,460 --> 00:09:42,300
It could be just a container.

225
00:09:42,660 --> 00:09:43,860
I don't think there's one answer.

226
00:09:43,980 --> 00:09:45,080
Like, there's an evolution.

227
00:09:45,240 --> 00:09:48,120
We all end up using containers versus VMs versus functions.

228
00:09:48,160 --> 00:09:52,020
It seems like there's always going to be a continuum, at least for our illustrious careers.

229
00:09:52,400 --> 00:09:53,040
Yeah, no, that's good.

230
00:09:53,180 --> 00:09:55,860
I always like the answer that is basically, don't overthink it.

231
00:09:56,840 --> 00:09:58,700
It's just running this thing.

232
00:09:58,860 --> 00:09:59,600
Nothing more crazy.

233
00:10:00,400 --> 00:10:04,740
So then always, I think you and I, Richard, always enjoy a good survey.

234
00:10:05,280 --> 00:10:09,120
You know, you get to see if people spell out percent or put the percentage in there.

235
00:10:09,300 --> 00:10:10,120
That's always nice.

236
00:10:10,320 --> 00:10:11,600
You reverse engineer their copybook.

237
00:10:11,740 --> 00:10:16,100
But I had noticed this one, but you found a fun little snippet covering one.

238
00:10:16,500 --> 00:10:17,380
What's in this one?

239
00:10:18,340 --> 00:10:23,040
Yeah, you had another survey, but showed that I think what jumped out at me is so many companies

240
00:10:23,040 --> 00:10:26,980
still saying that not only a small percentage of their workloads are in public cloud, but

241
00:10:26,980 --> 00:10:30,800
not that they're not going, they're just not going as fast as I think we might have anticipated

242
00:10:30,800 --> 00:10:31,700
a few years ago.

243
00:10:31,900 --> 00:10:33,960
And the same two reasons pop up more and more.

244
00:10:34,060 --> 00:10:35,480
It's sort of lock-in and security.

245
00:10:35,580 --> 00:10:40,240
And security is such a remarkably vague thing to complain about because it can be authentication

246
00:10:40,240 --> 00:10:42,900
or data encryption or all kinds of different things.

247
00:10:42,900 --> 00:10:47,260
But to the earlier thing we talked about with earnings, I half wonder if one of the reasons

248
00:10:47,260 --> 00:10:52,080
lock-in has become even more of a concern is now there's multiple viable choices.

249
00:10:52,400 --> 00:10:57,080
So you do feel like, gosh, do I want to bet on a horse when there's a lot of different

250
00:10:57,080 --> 00:10:58,360
choices here in the public cloud?

251
00:10:58,440 --> 00:10:59,580
It's not like Amazon or bust.

252
00:10:59,680 --> 00:11:03,240
I'm like, well, I'll just lock into Amazon because there's nothing else and that's the

253
00:11:03,240 --> 00:11:03,540
best.

254
00:11:03,920 --> 00:11:07,760
Now I've got three, maybe four or five legitimate choices out there.

255
00:11:07,820 --> 00:11:09,400
Is that screwing people up in terms of their planning?

256
00:11:09,500 --> 00:11:13,140
I don't know, but it seems like lock-in and security are still keeping people from going

257
00:11:13,140 --> 00:11:13,560
all in.

258
00:11:13,960 --> 00:11:14,980
That is interesting.

259
00:11:15,240 --> 00:11:20,740
I mean, if anything, it'll, on the buyer's side, maybe elongate your sales process because

260
00:11:20,740 --> 00:11:22,980
you feel the need to go talk to all these different people.

261
00:11:23,740 --> 00:11:25,820
But that is, huh, that is great.

262
00:11:26,480 --> 00:11:26,580
Yeah.

263
00:11:26,800 --> 00:11:28,540
I don't know if there's a paradox of choice thing there.

264
00:11:28,640 --> 00:11:28,980
That's all.

265
00:11:29,080 --> 00:11:32,480
Like when you have one choice, you just pick the cloud and you stay on-prem and you don't

266
00:11:32,480 --> 00:11:33,440
overthink it to that.

267
00:11:33,540 --> 00:11:38,060
But now when I have, again, three and you count IBM and maybe a couple others as legit choices,

268
00:11:38,060 --> 00:11:41,540
is that just slowing me down to your point, maybe making it harder to buy.

269
00:11:41,680 --> 00:11:45,460
And at the same time, I choose to kind of just spread my workloads around, which is good

270
00:11:45,460 --> 00:11:47,920
news for Pivotal because that's part of our value proposition.

271
00:11:48,180 --> 00:11:50,740
But it's interesting to see the industry validate that as well.

272
00:11:51,060 --> 00:11:51,140
Yeah.

273
00:11:51,220 --> 00:11:54,280
It's like, you know, I started making this thing that's basically, I don't know what

274
00:11:54,280 --> 00:11:58,680
it's called, but it's kind of like a, it's like a lasagna except with a bunch of squash

275
00:11:58,680 --> 00:11:59,180
and eggplant.

276
00:11:59,700 --> 00:12:01,980
And I think it's, it's got some fancy name to it.

277
00:12:02,100 --> 00:12:04,220
It's not a Ratatouille, but it's something else.

278
00:12:04,220 --> 00:12:08,840
And like, you go, you go to buy the 24 ounce can of, uh, I don't know how many grams that

279
00:12:08,840 --> 00:12:09,840
is of whole tomatoes.

280
00:12:10,260 --> 00:12:12,180
And it's just like, it's very confusing.

281
00:12:12,500 --> 00:12:14,620
Lots of different tomatoes in the can options.

282
00:12:14,620 --> 00:12:17,020
It's, it almost makes you not want to make this thing.

283
00:12:17,020 --> 00:12:21,560
They get the paradox of tomato choice, but you know, I, I think, I think with these things,

284
00:12:21,560 --> 00:12:23,180
it's always good to add in some context.

285
00:12:23,620 --> 00:12:29,520
And, uh, so I, I was remembering that my old, uh, uh, job, uh, over at four or five, one

286
00:12:29,520 --> 00:12:31,900
research, they own this company called the uptime Institute.

287
00:12:32,240 --> 00:12:35,180
And they did, they'd done a survey earlier that found similar things.

288
00:12:35,180 --> 00:12:37,160
I mean, over a thousand data center people.

289
00:12:37,400 --> 00:12:41,740
And, uh, I think it was, they, they reported the reverse, like the one, the survey you had,

290
00:12:41,740 --> 00:12:47,960
it was like, uh, uh, man, talk about a Monte Carlo simulation, more than 65% of respondents

291
00:12:47,960 --> 00:12:52,800
reported that less than 20% of their workloads, uh, you know, and then I wouldn't get a good

292
00:12:52,800 --> 00:12:54,240
score on the SAT after that.

293
00:12:54,640 --> 00:12:59,240
Uh, but it said that of this thousand or so people that, uh, four or five, one surveyed

294
00:12:59,240 --> 00:13:05,220
about 65% of their oddly enough, same number, uh, uh, asked workloads remained in basically

295
00:13:05,220 --> 00:13:09,180
private cloud, whether it was co-load or, or, uh, things like that.

296
00:13:09,600 --> 00:13:14,520
But I think, I think that does match that's, that's, uh, as always the tempered expectations,

297
00:13:14,520 --> 00:13:21,200
uh, that I tend to have is that in the, um, enterprise space, if you will, that things

298
00:13:21,200 --> 00:13:27,100
are a lot slower as far as all of the workloads, it'd be interesting to have a cut based on brand

299
00:13:27,100 --> 00:13:31,720
new applications, which usually is much, much higher as far as running in public cloud.

300
00:13:31,720 --> 00:13:36,240
Uh, but all of the workloads tend to be, uh, meandering about kind of like, you ever read

301
00:13:36,240 --> 00:13:40,480
that book about the, the guy, the guy who gets an apple and walks around the village and

302
00:13:40,480 --> 00:13:44,640
the apple changes hands all the time, sort of like the slow, uh, slow movement of the

303
00:13:44,640 --> 00:13:44,840
apple.

304
00:13:44,920 --> 00:13:45,720
I should look that one up.

305
00:13:45,920 --> 00:13:46,420
It's delightful.

306
00:13:47,020 --> 00:13:47,800
Sounds filthy.

307
00:13:48,060 --> 00:13:49,020
Yeah, that's good.

308
00:13:49,500 --> 00:13:50,980
I mean, I'm not eating that apple at the end.

309
00:13:51,100 --> 00:13:51,360
Oh yeah.

310
00:13:51,380 --> 00:13:53,280
I never thought of that angle, but yeah.

311
00:13:53,560 --> 00:13:53,700
Yeah.

312
00:13:53,700 --> 00:13:56,260
So that's for my germaphobe model, my ideas.

313
00:13:56,260 --> 00:14:02,180
Uh, I mean, also to that, uh, trying to rewind somehow back from fruit, uh, you wonder that

314
00:14:02,180 --> 00:14:06,420
with some of those numbers in the private cloud, you, you see that that's why Amazon, that's

315
00:14:06,420 --> 00:14:10,460
why all these providers have started to begin to do this hybrid story, this migration story

316
00:14:10,460 --> 00:14:11,140
of snowball.

317
00:14:11,400 --> 00:14:15,240
You have all these data movement tools because they realize you just can't sell cloud first.

318
00:14:15,480 --> 00:14:18,100
You have to sell some way to connect these two things.

319
00:14:18,100 --> 00:14:22,140
And I don't know if that was the realization five, six, eight years ago when all this was really

320
00:14:22,140 --> 00:14:26,040
bursting up, but now it seems like that's got to be the play is how am I getting you there

321
00:14:26,040 --> 00:14:26,540
more easily?

322
00:14:27,160 --> 00:14:27,180
Yeah.

323
00:14:27,440 --> 00:14:27,600
Yeah.

324
00:14:27,600 --> 00:14:28,160
We'll have to see.

325
00:14:28,240 --> 00:14:31,660
But anyway, those, uh, ongoing surveys there always interesting to see.

326
00:14:31,800 --> 00:14:34,820
Well, so Ben, why don't you introduce yourself more thoroughly?

327
00:14:35,020 --> 00:14:36,800
What do you, uh, what do you do around here?

328
00:14:36,940 --> 00:14:42,100
You know, what, uh, when you're not enjoying the, the bounty of the, the, the Western U.S.

329
00:14:42,200 --> 00:14:44,740
cuisine, what, uh, what do you spend your time on?

330
00:14:45,920 --> 00:14:46,320
Nice.

331
00:14:46,520 --> 00:14:51,060
Uh, so, uh, pivotal, I'm responsible for the, uh, the data products that we've got integrated

332
00:14:51,060 --> 00:14:52,800
with the, uh, the cloud foundry platform.

333
00:14:53,580 --> 00:14:54,640
Um, so that's pretty cool.

334
00:14:54,780 --> 00:14:58,320
I'm based in London, got some teams here, got some teams kind of in New York and San

335
00:14:58,320 --> 00:14:59,020
Francisco as well.

336
00:14:59,160 --> 00:15:02,840
So a bit of variety, get to do a bit of traveling around and hanging out with different customers.

337
00:15:03,480 --> 00:15:07,700
Um, when I'm not working on the wonderful world, there's data services, kind of enjoy

338
00:15:07,700 --> 00:15:12,300
a bit of cooking, mainly Indian cuisine, or if I'm out and about trying to find the next

339
00:15:12,300 --> 00:15:13,320
hipster coffee shop.

340
00:15:13,860 --> 00:15:17,040
So, uh, that's always fun when I get to visit San Francisco and New York.

341
00:15:17,260 --> 00:15:18,880
So if you've got any recommendations, let me know.

342
00:15:18,880 --> 00:15:23,100
Now, now we'll get to the tech stuff soon, but to stick to this theme of randomness that

343
00:15:23,100 --> 00:15:26,260
I've introduced, how, what is like the criteria?

344
00:15:26,700 --> 00:15:30,000
What, what, what flips the bit of hipster coffee shop?

345
00:15:31,280 --> 00:15:37,880
If I can go into a coffee shop and ask for a piccolo and not get a strange look, then I

346
00:15:37,880 --> 00:15:38,560
know I'm onto a winner.

347
00:15:38,880 --> 00:15:39,180
Okay.

348
00:15:39,400 --> 00:15:43,400
And now of course this begs the question, what, what, other than a flute, what is a piccolo?

349
00:15:43,400 --> 00:15:50,940
So piccolo is a, it's an espresso based coffee where you have the same amount of foamed milk

350
00:15:50,940 --> 00:15:52,020
as you do espresso.

351
00:15:52,400 --> 00:15:54,000
So you've got like a one-to-one relation ratio.

352
00:15:54,340 --> 00:15:58,960
So it's great if you like the flavor of espresso and you like drinking coffee, not just for kind

353
00:15:58,960 --> 00:16:01,040
of the caffeine kick, but also to enjoy it.

354
00:16:01,260 --> 00:16:04,040
Now, it's not so big that you feel ill afterwards.

355
00:16:04,300 --> 00:16:06,480
Now, just to clarify, is it a piccolo or a piccolo?

356
00:16:07,520 --> 00:16:07,880
Piccolo.

357
00:16:08,120 --> 00:16:08,520
Piccolo.

358
00:16:08,660 --> 00:16:12,720
Now, how, how, and I'm sorry, we'll get out of this quickly, but how do you, how, how,

359
00:16:12,820 --> 00:16:16,860
how is that distinguished from a cappuccino and a cortado?

360
00:16:17,220 --> 00:16:17,580
Cortada?

361
00:16:19,420 --> 00:16:19,740
Yeah.

362
00:16:19,860 --> 00:16:21,760
So I think cortado is probably the closest.

363
00:16:22,100 --> 00:16:25,080
To be honest, I think a lot of coffee shops, they're almost kind of interchangeable.

364
00:16:25,700 --> 00:16:27,200
Cappuccino, in my mind, would be a lot bigger.

365
00:16:27,340 --> 00:16:28,120
So there's a lot more milk.

366
00:16:28,320 --> 00:16:31,720
You've got kind of your, your different layers of milk in there and your chocolate sprinkles

367
00:16:31,720 --> 00:16:32,140
on top.

368
00:16:32,420 --> 00:16:34,500
So it's a good drink, but just not my preference.

369
00:16:34,720 --> 00:16:34,960
Okay.

370
00:16:35,080 --> 00:16:40,040
So a cappuccino is kind of like a nod to a milkshake as, as like a piccolo.

371
00:16:40,260 --> 00:16:42,600
Piccolo is more like, maybe more like a kombucha.

372
00:16:42,720 --> 00:16:44,180
It's sort of like this hardcore thing.

373
00:16:44,480 --> 00:16:49,260
It's not intended to be anything reminiscent of, of pleasurable unless you're into that kind

374
00:16:49,260 --> 00:16:49,620
of thing.

375
00:16:51,060 --> 00:16:51,420
I don't know.

376
00:16:51,560 --> 00:16:51,920
I like it.

377
00:16:52,060 --> 00:16:53,520
I'll see how, I'll see how that works.

378
00:16:53,620 --> 00:16:53,880
Piccolo.

379
00:16:54,020 --> 00:16:55,140
I'm going to start ordering that.

380
00:16:55,640 --> 00:16:55,900
All right.

381
00:16:56,000 --> 00:16:56,460
That's good.

382
00:16:56,860 --> 00:17:00,840
I'm too much of a rube to apparently go out for food with either Ben or David Brooks or anyone

383
00:17:00,840 --> 00:17:02,140
because I don't know these food choices.

384
00:17:02,480 --> 00:17:03,920
That's good to know.

385
00:17:04,720 --> 00:17:10,060
Hey, it's interstitial mid-roll stuff.

386
00:17:10,260 --> 00:17:13,000
I just wanted to promote a few upcoming pivotal things here.

387
00:17:13,080 --> 00:17:16,960
Through June, July, and August, we have the Cloud Native Roadshow coming to all sorts of

388
00:17:16,960 --> 00:17:17,200
cities.

389
00:17:17,660 --> 00:17:21,780
This is a free day-long event we do with Google that goes over what exactly Cloud Native is

390
00:17:21,780 --> 00:17:25,180
and how our customers are using pivotal and Google technologies and approaches.

391
00:17:25,440 --> 00:17:27,620
The cities, and this is a long list, so get ready.

392
00:17:27,620 --> 00:17:32,820
The cities are Stuttgart, Dallas, Denver, LA, Seattle, San Francisco, Amsterdam, Seoul, Hong Kong,

393
00:17:32,940 --> 00:17:33,760
Sydney, and Singapore.

394
00:17:34,300 --> 00:17:36,600
There's a big list of dates that you can look at.

395
00:17:36,860 --> 00:17:38,500
You can check out the show notes for a link to it.

396
00:17:38,520 --> 00:17:42,760
Or if you just want to go and Google for Pivotal Cloud Native Roadshow, you'll find it pretty

397
00:17:42,760 --> 00:17:43,140
easily.

398
00:17:43,400 --> 00:17:46,520
We also have Spring Days Atlanta coming up July 18th and 19th.

399
00:17:46,780 --> 00:17:50,460
It's chock full of sessions for developers who want to learn more about the Spring Framework,

400
00:17:50,560 --> 00:17:51,820
Cloud Native style development.

401
00:17:52,360 --> 00:17:55,960
And of course, to be fully buzzword compliant, microservices.

402
00:17:56,280 --> 00:17:58,460
If you go to springdays.io, you can get more info.

403
00:17:58,580 --> 00:18:01,760
And that's the last Spring Days we're having so far that we have scheduled this year.

404
00:18:01,880 --> 00:18:05,180
So get that one in if you're over in Grits and Porkland.

405
00:18:05,380 --> 00:18:06,240
It'll be good stuff.

406
00:18:06,420 --> 00:18:11,040
Finally, while it's way in the future, we also have SpringOne platform coming up December

407
00:18:11,040 --> 00:18:11,820
4th and 5th.

408
00:18:11,960 --> 00:18:13,820
Now, registration just opened recently for this.

409
00:18:13,940 --> 00:18:16,740
I think you might have missed the early bird thing for it, but that's fine.

410
00:18:17,060 --> 00:18:19,040
There's also still the CFP open.

411
00:18:19,180 --> 00:18:20,800
It closes on September 1st.

412
00:18:20,860 --> 00:18:22,280
Now, what goes on at this conference?

413
00:18:22,460 --> 00:18:26,500
Well, it's full of what I would call the suit track and the technology track.

414
00:18:26,660 --> 00:18:31,540
In the suit track, you've got case studies and managers and developers as well, but organizations

415
00:18:31,540 --> 00:18:35,880
talking about how they've transformed their company and what they're doing with Cloud Native

416
00:18:35,880 --> 00:18:39,400
and their organizations, how they're getting good results by switching over to doing things

417
00:18:39,400 --> 00:18:40,820
in more of a pivotal way.

418
00:18:40,820 --> 00:18:45,580
But then there's also plenty of events for those of you out there who enjoy more nerding out

419
00:18:45,580 --> 00:18:47,140
and doing technical things to check out.

420
00:18:47,260 --> 00:18:54,120
I'm one of the chairs of the DevOps pipeline and monitoring track that we informally call

421
00:18:54,120 --> 00:18:54,240
it.

422
00:18:54,300 --> 00:18:58,400
We've already got lots of excellent talks queued up from the likes of Home Depot, Express Scripts,

423
00:18:58,440 --> 00:19:01,400
Allstate Northern Trust, and of course, plenty of pivotal people.

424
00:19:01,560 --> 00:19:03,640
I'll be speaking in that track if that's anything.

425
00:19:03,880 --> 00:19:04,700
So come on there.

426
00:19:04,780 --> 00:19:07,080
Again, it's in San Francisco, December 4th and 5th.

427
00:19:07,080 --> 00:19:11,160
And if you just go to springplatform.io, you can check it all out.

428
00:19:11,220 --> 00:19:13,280
And with that, enjoy the episode this week.

429
00:19:16,680 --> 00:19:17,360
All right.

430
00:19:17,500 --> 00:19:19,000
So yeah, so tech stuff.

431
00:19:19,660 --> 00:19:22,600
Ben, managed service data services.

432
00:19:22,700 --> 00:19:25,260
So you mentioned that we do the data services here, that you run them.

433
00:19:25,320 --> 00:19:27,960
And we've had some different ones over the time, over the year.

434
00:19:28,100 --> 00:19:32,440
So I mean, specifically, what data services, and sometimes we refer to them as managed,

435
00:19:33,280 --> 00:19:34,040
do we offer?

436
00:19:34,120 --> 00:19:36,880
What does Pivotal offer in the box if you're a PCF customer?

437
00:19:37,740 --> 00:19:40,360
Yeah, so we've got four main products that we're focused on at the moment.

438
00:19:40,940 --> 00:19:46,200
So the first one is our Pivotal Cloud Cache product, which is based on Pivotal's GenFi

439
00:19:46,200 --> 00:19:49,400
product, or Geode, if you're looking at the open source distribution.

440
00:19:50,320 --> 00:19:54,320
We've also got RabbitMQ, so the popular open source messaging system.

441
00:19:55,060 --> 00:19:56,980
We have a MySQL product.

442
00:19:57,600 --> 00:19:59,720
And lastly, we've got Redis integration as well.

443
00:20:00,780 --> 00:20:04,800
You mentioned interesting words there in terms of like the managed data services.

444
00:20:05,340 --> 00:20:10,320
I think when people first hear managed, they think typically kind of outsourced.

445
00:20:10,440 --> 00:20:14,080
You've got another team kind of outside your building who's running those for you.

446
00:20:14,800 --> 00:20:16,900
That's not what we're referring to here.

447
00:20:17,840 --> 00:20:21,380
We're talking about kind of platform-managed data services.

448
00:20:22,120 --> 00:20:23,280
So kind of think of Bosch.

449
00:20:23,820 --> 00:20:28,340
Bosch is almost human, and that's what we're talking about here when we mean managed data

450
00:20:28,340 --> 00:20:28,760
services.

451
00:20:29,200 --> 00:20:30,960
So what does management entail then?

452
00:20:31,040 --> 00:20:32,440
So what are we doing on behalf?

453
00:20:32,540 --> 00:20:36,320
So if I'm just a, you know, you listed four very popular open source things.

454
00:20:36,800 --> 00:20:38,500
So, hey, I'm a good technologist.

455
00:20:38,620 --> 00:20:39,780
I can stand up MySQL.

456
00:20:40,080 --> 00:20:42,620
I can deploy a Rabbit container.

457
00:20:42,620 --> 00:20:44,080
That's not hard work necessarily.

458
00:20:44,520 --> 00:20:45,880
So what is this adding to that?

459
00:20:46,000 --> 00:20:46,920
Why would I use this?

460
00:20:47,520 --> 00:20:47,960
Sure.

461
00:20:48,640 --> 00:20:53,740
So we're using Bosch, the technology underneath, the same technology we use to deploy Cloud

462
00:20:53,740 --> 00:20:54,520
Foundry.

463
00:20:54,900 --> 00:20:58,100
And what that really gives us is that kind of infrastructure portability.

464
00:20:58,800 --> 00:21:01,520
Almost gives us that kind of platform as code mentality.

465
00:21:02,040 --> 00:21:07,120
So we get all of the benefits of Bosch, where it's really strong around things such as day

466
00:21:07,120 --> 00:21:07,440
two.

467
00:21:07,840 --> 00:21:14,240
So our ability to kind of roll out updates to these services, our ability to pass

468
00:21:14,240 --> 00:21:17,580
to patch the stem cells to the underlying operating system.

469
00:21:18,380 --> 00:21:20,800
All of that flexibility is really powerful for us.

470
00:21:21,020 --> 00:21:26,000
And it allows us to then bake in the rest of the day two stuff that you would expect, such

471
00:21:26,000 --> 00:21:31,480
as the ability to upgrade without losing data, the ability to do things like rolling upgrades.

472
00:21:31,960 --> 00:21:36,060
All of that we get from basing it around kind of a Bosch deployment.

473
00:21:36,060 --> 00:21:39,140
And these are all super critical value-add activities.

474
00:21:39,940 --> 00:21:44,300
But that's not necessarily where the value is for your customers.

475
00:21:44,820 --> 00:21:49,740
So we want to make sure that these activities are done in a reliable and repeatable way.

476
00:21:50,740 --> 00:21:55,120
And that's where all of the stuff that people have come to know and love from Cloud Foundry

477
00:21:55,120 --> 00:21:59,900
itself, we're trying to bring the same operational mindset to the data services as well.

478
00:22:01,020 --> 00:22:01,260
Yes.

479
00:22:01,300 --> 00:22:04,320
I mean, you touched on kind of the build and run phase then.

480
00:22:04,400 --> 00:22:08,300
So we're saying really the value is, again, when I've used these, I can use CF create service

481
00:22:08,300 --> 00:22:10,080
and then build out these things.

482
00:22:10,120 --> 00:22:12,180
The idea is that it's very repeatable to build.

483
00:22:12,300 --> 00:22:17,380
And I'm not asking different teams to set up credentials or what the right proper settings

484
00:22:17,380 --> 00:22:20,720
are for clustering for certain cases that we're provisioning at all.

485
00:22:20,780 --> 00:22:22,220
But then the runtime too, right?

486
00:22:22,220 --> 00:22:23,160
Because Bosch takes care of it.

487
00:22:23,200 --> 00:22:27,200
If that node happens to fall over, Bosch can resurrect it and bring it back online.

488
00:22:27,300 --> 00:22:29,520
So again, that management is meant to be no touch, right?

489
00:22:30,020 --> 00:22:30,140
Yeah.

490
00:22:30,420 --> 00:22:31,000
Yeah, absolutely.

491
00:22:31,340 --> 00:22:34,040
So you touch on some of the powerful things there, such as the recovery.

492
00:22:34,180 --> 00:22:34,500
Absolutely.

493
00:22:34,840 --> 00:22:38,960
And that goes up the stack for us from things like the process monitoring that Bosch gives

494
00:22:38,960 --> 00:22:42,720
us through Monit, like you say, all the way up to kind of the Resurrector if the VMs go

495
00:22:42,720 --> 00:22:42,960
away.

496
00:22:44,200 --> 00:22:45,120
That's really powerful.

497
00:22:45,720 --> 00:22:49,820
You touched on one of my favorite features there around the CF create service as well.

498
00:22:51,000 --> 00:22:53,900
That is where I believe the value is.

499
00:22:53,980 --> 00:22:57,980
And we want to enable that self-service mentality for the application developers.

500
00:22:58,840 --> 00:23:04,040
So if we can provide that as a service and allow customers to focus there,

501
00:23:04,520 --> 00:23:09,340
and we bring the rest of this stuff to the party for them, that's, I think, a real differentiator.

502
00:23:10,420 --> 00:23:15,160
And so, I mean, just as from the top instead of going from the bottom with stuff.

503
00:23:15,280 --> 00:23:20,700
So when you look at across all those services that you're managing in there, like what do

504
00:23:20,700 --> 00:23:22,200
you think the more popular ones are?

505
00:23:22,400 --> 00:23:26,960
Like what are people using out there of the ones, that little clutch that you're working

506
00:23:26,960 --> 00:23:27,240
on?

507
00:23:29,000 --> 00:23:32,420
So RabbitMQ is a really popular product.

508
00:23:32,760 --> 00:23:37,700
We see a lot of people using this, especially as they're adopting kind of microservices mindset.

509
00:23:38,640 --> 00:23:43,320
If you look at a lot of our Spring examples and documentation, even things like Spring Cloud

510
00:23:43,320 --> 00:23:47,580
Services, Spring Cloud Dataflow, example applications, they've all got Rabbit integrations.

511
00:23:47,820 --> 00:23:51,440
So there's a really strong groundswell there, which is really cool to see.

512
00:23:52,940 --> 00:23:58,340
We find that messaging in general is quite popular of enterprises, but they're used to a different

513
00:23:58,340 --> 00:24:00,220
type of technology and almost a different mindset.

514
00:24:00,780 --> 00:24:04,720
So you can have some really interesting conversations of people there around how they can take some

515
00:24:04,720 --> 00:24:10,140
of those concepts of kind of asynchronous messaging and bring it to microservices and then backing

516
00:24:10,140 --> 00:24:14,700
that with things like RabbitMQ on the platform and combining that with the other pieces we have.

517
00:24:15,340 --> 00:24:17,540
That I find to be a really compelling story.

518
00:24:19,140 --> 00:24:24,940
The pencil cloud cache, that's one that's really resonating with customers at the moment

519
00:24:24,940 --> 00:24:29,500
as well, talking about where it's appropriate to use caching in your application.

520
00:24:30,100 --> 00:24:33,460
Again, it's one of those things that a lot of people are familiar with and already using

521
00:24:33,460 --> 00:24:38,340
kind of in their enterprise or platform kind of stacks, but really helping them rethink

522
00:24:38,340 --> 00:24:42,540
where you can use it and how you can be a bit more self-service with that.

523
00:24:42,940 --> 00:24:47,020
Again, layering it on with the other tools in your box, such as RabbitMQ or maybe a bit

524
00:24:47,020 --> 00:24:50,680
of MySQL, you can start to build up more of a relevant architecture.

525
00:24:52,360 --> 00:24:59,220
And so when you're running these managed services, like what's the expectation of, well, I don't

526
00:24:59,220 --> 00:24:59,420
know.

527
00:24:59,660 --> 00:25:00,760
Let me ask this a different way.

528
00:25:00,960 --> 00:25:04,500
In the traditional world, you might have a DBA who runs your database.

529
00:25:05,260 --> 00:25:10,020
And in this sort of world, whether it's like the queues that you have or various data stores,

530
00:25:10,280 --> 00:25:13,000
like how are things in practice?

531
00:25:13,440 --> 00:25:17,840
Like do you have dedicated people who are babysitting those or not?

532
00:25:17,920 --> 00:25:20,580
Or like how does that all kind of fit in as far as staffing?

533
00:25:20,660 --> 00:25:20,860
Sure.

534
00:25:21,960 --> 00:25:24,000
Yeah, that's a really interesting question.

535
00:25:25,640 --> 00:25:27,320
Can I paint you my vision?

536
00:25:27,660 --> 00:25:27,820
Yeah.

537
00:25:27,820 --> 00:25:28,800
And what we're seeing with customers?

538
00:25:28,960 --> 00:25:31,720
And then you can see how different customers kind of level up in that.

539
00:25:31,920 --> 00:25:36,360
I think this early in the week, it's all vision until we meet the practicality of trying

540
00:25:36,360 --> 00:25:37,540
to wrap up at the end of the week.

541
00:25:37,600 --> 00:25:38,520
So let's go for it.

542
00:25:39,100 --> 00:25:41,300
This is a piccolo-fueled vision.

543
00:25:44,300 --> 00:25:47,280
So you're familiar with kind of the balance team concepts, right?

544
00:25:47,380 --> 00:25:47,660
Of course.

545
00:25:47,740 --> 00:25:51,460
Where you want to have that team that's got all of the skills and responsibilities in

546
00:25:51,460 --> 00:25:51,720
there.

547
00:25:52,160 --> 00:25:56,900
And when you start layering on the whole, you build it, you run it, you learn from it mentality,

548
00:25:56,900 --> 00:25:58,740
that really gives that sense of empowerment.

549
00:25:59,780 --> 00:26:03,700
And to me, that's how you, as well as all of the agile kind of lean techniques that you

550
00:26:03,700 --> 00:26:07,340
get and product management, et cetera, there's a lot of things in there that allow you to

551
00:26:07,340 --> 00:26:08,140
kind of move fast.

552
00:26:09,420 --> 00:26:14,640
So if you started the question with saying, how does that compare to how enterprise is

553
00:26:14,640 --> 00:26:15,860
using these things at the moment?

554
00:26:16,480 --> 00:26:21,720
And the favorite customers to go and talk to are the ones that have really adopted and

555
00:26:21,720 --> 00:26:25,720
embraced the concept of CF push and having these balanced teams.

556
00:26:25,720 --> 00:26:27,580
And they're absolutely flying along.

557
00:26:27,860 --> 00:26:29,480
They're doing all this good lean stuff.

558
00:26:29,560 --> 00:26:32,880
It's all very user-centered and they're knocking features out and everybody's having a great

559
00:26:32,880 --> 00:26:33,200
time.

560
00:26:33,920 --> 00:26:36,360
And then you start looking at where the friction is in that process.

561
00:26:36,860 --> 00:26:40,720
And it typically tends to be around all of their off-platform integrations.

562
00:26:41,100 --> 00:26:43,740
So things like, we wanted to start this new project.

563
00:26:43,940 --> 00:26:45,560
We knocked out the basic API.

564
00:26:45,960 --> 00:26:51,900
We mocked up kind of the iOS kind of UI and all that kind of design flow in a week.

565
00:26:52,240 --> 00:26:54,320
And then it took us a month to get access to a database.

566
00:26:55,020 --> 00:26:55,340
Right.

567
00:26:55,620 --> 00:27:00,240
And that's because of the usual organizational kind of boundary silos, all of the things that

568
00:27:00,240 --> 00:27:00,920
we're kind of used to.

569
00:27:01,060 --> 00:27:02,640
I'm sure you've covered in depth on here before.

570
00:27:03,860 --> 00:27:09,260
So my vision is that when you take a lot of the transformational stuff and learnings that

571
00:27:09,260 --> 00:27:13,700
we've done with application teams in general and start applying that to data, you can take

572
00:27:13,700 --> 00:27:15,880
the same patterns and achieve a really powerful outcome.

573
00:27:16,800 --> 00:27:23,580
So the dream is that in those balanced teams, the app developers now also have perhaps a DBA

574
00:27:23,580 --> 00:27:28,200
hanging out in there who can help up-level and kind of pair, if you're into that kind of

575
00:27:28,200 --> 00:27:33,880
thing with all the application developers and teaching them not just how to use MySQL, but

576
00:27:33,880 --> 00:27:35,200
how to optimally use it.

577
00:27:35,580 --> 00:27:41,060
And ideally do a lot of the data operations themselves as well, such as determining when

578
00:27:41,060 --> 00:27:45,440
appropriate is to scale versus actually go and kind of rewrite that query, for example.

579
00:27:46,580 --> 00:27:49,940
And that to me just continues to round out that balanced team concept.

580
00:27:50,840 --> 00:27:56,880
Now, I think you still end up with what we kind of refer to as the data specialist, which

581
00:27:56,880 --> 00:28:01,700
might be a smaller team of DBAs that are more central, who are kind of keeping their lights

582
00:28:01,700 --> 00:28:06,140
on and looking across all of the many MySQL instances out there.

583
00:28:06,380 --> 00:28:10,720
But the goal is to make their job as amazing as possible with all of the platform tooling

584
00:28:10,720 --> 00:28:15,660
so that, again, they can continue to focus on the value-add activities that those balanced

585
00:28:15,660 --> 00:28:16,880
teams are trying to hit.

586
00:28:17,220 --> 00:28:20,860
Yeah, you know, this is an interesting accidental topic here.

587
00:28:20,920 --> 00:28:23,180
I mean, this function comes up a lot.

588
00:28:23,340 --> 00:28:29,860
And it seems to me in the balanced team world, the, well, we need a phrase for whatever this

589
00:28:29,860 --> 00:28:33,360
interloping tech expert person is, right?

590
00:28:33,440 --> 00:28:39,720
Because it's sort of like, in theory, it's sort of handy to say, like, we could take another

591
00:28:39,720 --> 00:28:40,840
topic like security.

592
00:28:40,980 --> 00:28:42,640
You should just have a security person there.

593
00:28:42,640 --> 00:28:48,900
But there's probably like kind of a consultative role where whether it's a sort of like a data

594
00:28:48,900 --> 00:28:54,700
sort of expert or, or a security person or someone who just kind of like has perhaps a residency,

595
00:28:54,700 --> 00:29:01,280
you know, a temporary residency in there to, to, I don't know, I don't know, it's a combination

596
00:29:01,280 --> 00:29:06,760
of like advising and training about doing these things.

597
00:29:06,760 --> 00:29:10,660
And, and to get meta, I like to think about this as kind of the set of responsibilities

598
00:29:10,660 --> 00:29:14,740
that that team needs, because if that's a new team, or perhaps it's a really advanced

599
00:29:14,740 --> 00:29:18,820
use case for social security or the data products, then you might bring in that kind of SME or

600
00:29:18,820 --> 00:29:19,760
that domain expert.

601
00:29:20,040 --> 00:29:26,120
But over time, I think, and again, in the balanced team concept, the goal would be to kind of up

602
00:29:26,120 --> 00:29:31,040
level everybody else and share those responsibilities around and kind of teach everybody the relevant

603
00:29:31,040 --> 00:29:32,040
skills that you need to.

604
00:29:33,740 --> 00:29:34,100
Right.

605
00:29:34,760 --> 00:29:35,600
No, I like that.

606
00:29:35,700 --> 00:29:39,500
I think that's a, you see a lot more of that, even with ops teams, again, not that ops goes

607
00:29:39,500 --> 00:29:43,780
away either, but some of the activities you'd have to do, maybe that low level work gets

608
00:29:43,780 --> 00:29:44,580
automated a bit.

609
00:29:44,660 --> 00:29:47,080
Now your higher level expertise actually comes in handy.

610
00:29:47,220 --> 00:29:49,540
So it's, yeah, it's fun to talk about that.

611
00:29:49,600 --> 00:29:52,860
One of the other things, you know, I think that's interesting, maybe related to this is

612
00:29:52,860 --> 00:29:56,240
recently we, we shipped this sort of on demand broker.

613
00:29:56,400 --> 00:29:59,460
Our team built that at Pivotal and then we've open sourced it as well.

614
00:29:59,460 --> 00:30:04,300
How does that change the game from this idea of having maybe single shared clusters that

615
00:30:04,300 --> 00:30:09,120
everybody uses and manages to this sort of, hey, you know, you get a cache and you get

616
00:30:09,120 --> 00:30:12,540
a database and you get a cache and everybody can stand up their own instance of things.

617
00:30:12,600 --> 00:30:13,960
How did that kind of change things?

618
00:30:14,000 --> 00:30:16,540
And I guess summarize for folks what the on-demand broker is.

619
00:30:17,240 --> 00:30:17,640
Yeah, sure.

620
00:30:18,100 --> 00:30:22,860
So the on-demand broker is the CF create service command that Richard mentioned earlier.

621
00:30:22,860 --> 00:30:28,160
That allows an app developer when they run that command to basically self-service provision

622
00:30:28,160 --> 00:30:33,560
their own Bosch deployment or dedicated instance, as we refer to it, of one of those services.

623
00:30:33,980 --> 00:30:37,760
So that means they've now got kind of tenancy isolation at the resource level.

624
00:30:37,940 --> 00:30:39,860
So their own set of VMs, for example.

625
00:30:40,860 --> 00:30:44,600
And back to the kind of the pre-provisioned multi-tenancy world.

626
00:30:44,940 --> 00:30:49,880
What we really found there was that looks quite similar to the way a lot of these customers

627
00:30:49,880 --> 00:30:57,540
are operating today in terms of having a centrally managed and run, say, big database, for example.

628
00:30:58,440 --> 00:31:04,860
And that works fine when you know the constraints, that you know all of the applications that are

629
00:31:04,860 --> 00:31:10,300
going to be on there and that you know all of the kind of constraints around uptime, for example.

630
00:31:10,860 --> 00:31:16,660
And you're happy with having a slower moving, more change control kind of pace.

631
00:31:17,500 --> 00:31:21,760
And of course, there's also issues in there around kind of noisy neighbors and kind of people

632
00:31:21,760 --> 00:31:23,420
accidentally overrunning the cluster.

633
00:31:24,380 --> 00:31:28,880
So that didn't really kind of fit with the flow that we want to encourage app developers

634
00:31:28,880 --> 00:31:31,740
and back to the balanced teams concept to be working in.

635
00:31:32,300 --> 00:31:35,820
We really wanted to get people into more of this flexible mindset.

636
00:31:36,500 --> 00:31:40,220
One of the things I love about hanging out with Pivotal Labs developers is you hear them talk

637
00:31:40,220 --> 00:31:42,240
a lot about choosing the right tool for the job.

638
00:31:43,220 --> 00:31:46,220
So the on-demand broker is something that allows us to do that.

639
00:31:46,880 --> 00:31:50,580
So if you've got two different application teams at a customer and they both need MySQL,

640
00:31:51,180 --> 00:31:55,320
then they can go into the Cloud Foundry marketplace and choose the service plan that is relevant

641
00:31:55,320 --> 00:31:55,820
for them.

642
00:31:56,480 --> 00:32:00,660
And because of the power of the platform, the on-demand broker and Bosch, they can get stamped

643
00:32:00,660 --> 00:32:05,460
out in the different kind of VM sizes or different MySQL configurations are needed for them.

644
00:32:06,140 --> 00:32:11,300
And by doing that and decentralizing some of that, it really allows the app developers to

645
00:32:11,300 --> 00:32:12,100
move a bit faster.

646
00:32:12,360 --> 00:32:15,920
They can iterate faster, which means they can focus on the business value.

647
00:32:16,420 --> 00:32:20,500
And of course, you've removed a lot of the concerns around accidentally stepping on each

648
00:32:20,500 --> 00:32:21,320
other's toes, for example.

649
00:32:22,160 --> 00:32:23,460
Is there a cost to that, though?

650
00:32:23,580 --> 00:32:24,880
I mean, besides licensing, I guess.

651
00:32:25,120 --> 00:32:31,440
But I mean, this idea of having this sort of just now explosion of instances, if you will.

652
00:32:31,520 --> 00:32:34,660
Now, operationally, I think we talk about the story of these are Bosch managed.

653
00:32:34,780 --> 00:32:37,620
So the incremental cost of adding another database is near zero.

654
00:32:38,400 --> 00:32:43,160
But is there a sort of cost of kind of can we accidentally switch too quickly to this model

655
00:32:43,160 --> 00:32:49,700
of maybe slower moving but centrally managed clusters to kind of per microservice databases,

656
00:32:50,020 --> 00:32:51,240
caches, even messaging?

657
00:32:51,620 --> 00:32:51,920
I don't know.

658
00:32:51,960 --> 00:32:53,040
Where do you see that spectrum?

659
00:32:53,280 --> 00:32:54,520
What would you have to look out for?

660
00:32:55,260 --> 00:32:55,660
Yeah, sure.

661
00:32:55,760 --> 00:32:58,740
It's interesting seeing different customers adopt this approach.

662
00:33:00,140 --> 00:33:04,540
And if you find a customer who's taking kind of their big classic monolith and breaking

663
00:33:04,540 --> 00:33:09,700
that down, then the challenge there is to start to find the seams in that as you're defining

664
00:33:09,700 --> 00:33:13,820
the APIs for the different parts of the service and identifying which of those could be split

665
00:33:13,820 --> 00:33:17,560
out into their own kind of databases or messaging systems.

666
00:33:18,260 --> 00:33:21,460
And for the customers I spend time hanging out with at the moment, you find

667
00:33:21,460 --> 00:33:26,120
that some of them have always still got a connection to their big legacy off-platform

668
00:33:26,120 --> 00:33:26,900
database.

669
00:33:27,660 --> 00:33:30,500
And that's fine because that's relevant for that part of that application.

670
00:33:30,640 --> 00:33:31,880
It's got different types of constraints.

671
00:33:32,460 --> 00:33:34,780
So you can end up with a bit of a mix there.

672
00:33:35,600 --> 00:33:43,040
In terms of the cost, I mean, aside from the resource cost that you get here, you do inherently get

673
00:33:43,040 --> 00:33:48,260
a bit more of a kind of more of a collection of MySQL instances associated with that application.

674
00:33:48,640 --> 00:33:53,700
I think that comes back to the balanced team again, and they're being responsible for running

675
00:33:53,700 --> 00:33:54,080
these.

676
00:33:54,080 --> 00:34:00,220
And you've got to view that cost in kind of respect to the value that it's really unlocking

677
00:34:00,220 --> 00:34:03,420
for them as well in terms of their ability to be a bit more flexible here.

678
00:34:04,240 --> 00:34:05,140
That makes sense.

679
00:34:05,920 --> 00:34:10,420
One of the, you know, as you have so many of the choices you talked about here with databases

680
00:34:10,420 --> 00:34:11,360
within our platform.

681
00:34:11,480 --> 00:34:15,140
But then if you look at the market, I mean, Cloud Foundry offers tons of stuff, right?

682
00:34:15,140 --> 00:34:18,540
I can use DynamoDB in Amazon.

683
00:34:18,700 --> 00:34:20,560
Obviously, I can use Cosmos in Azure.

684
00:34:20,760 --> 00:34:24,820
I can use all sorts of things in multiple databases, plus bring in great ecosystem things

685
00:34:24,820 --> 00:34:25,840
like Cassandra and others.

686
00:34:25,980 --> 00:34:31,200
So how am I supposed to really choose, if I'm a developer, between the cloud provider's

687
00:34:31,200 --> 00:34:32,260
native database, right?

688
00:34:32,260 --> 00:34:36,340
I'm going to use Dynamo, I'm going to use RDS, or I'm going to use just kind of a standalone

689
00:34:36,340 --> 00:34:40,440
outside instance that I just do a lightweight broker to that I manage outside the platform,

690
00:34:40,440 --> 00:34:42,560
or then actually a Bosch-managed service.

691
00:34:42,640 --> 00:34:45,980
Now, maybe you touched on it there that there's going to be, you know, the answer is always

692
00:34:45,980 --> 00:34:46,600
it depends.

693
00:34:46,820 --> 00:34:47,860
I get that.

694
00:34:47,860 --> 00:34:51,420
But, you know, in some cases, you may have that line of business database that shouldn't

695
00:34:51,420 --> 00:34:52,000
go anywhere.

696
00:34:52,300 --> 00:34:55,700
But then you have a more lightweight microservice that now defines some new data entity.

697
00:34:55,860 --> 00:34:57,460
And that thing should have its own database.

698
00:34:57,860 --> 00:35:00,700
It's kind of, where do you choose, you know, how do you pick the spectrum?

699
00:35:00,820 --> 00:35:04,740
How do you decide to go native with the cloud provider versus saying, look, I know I'm running

700
00:35:04,740 --> 00:35:09,340
on Amazon, but I'm still going to use the PCF MySQL service because I like to have the

701
00:35:09,340 --> 00:35:11,480
same abstraction on every cloud.

702
00:35:11,900 --> 00:35:13,820
What are your thoughts on how you make those selections?

703
00:35:14,560 --> 00:35:14,980
Yeah, sure.

704
00:35:14,980 --> 00:35:18,760
So I think you could start this conversation with a couple of different angles.

705
00:35:19,380 --> 00:35:23,500
I mean, if you go at it from the app developer angle, and we just focus on the tool that

706
00:35:23,500 --> 00:35:29,040
they're choosing, say a SQL offering versus a no SQL offering, then I think that depends

707
00:35:29,040 --> 00:35:33,980
on the app developers actually understanding the different kind of pros and cons of choosing

708
00:35:33,980 --> 00:35:39,960
those technologies and making the most responsible decision in terms of which one they choose.

709
00:35:41,100 --> 00:35:47,560
If you think about the services API contracts, which is one of the most powerful things in

710
00:35:47,560 --> 00:35:54,480
Cloud Foundry, I think, that powers the Cloud Foundry marketplace, then actually the app developer

711
00:35:54,480 --> 00:35:59,640
shouldn't care or even know where that database has been provisioned.

712
00:36:00,280 --> 00:36:05,300
And that, I think, is really powerful because if you've, say, got a MySQL offering that is

713
00:36:05,300 --> 00:36:10,760
powered by the Pivotal offering and, say, a NoSQL offering like DynamoDB that's actually

714
00:36:10,760 --> 00:36:14,180
on Amazon, they can both appear in the marketplace side by side.

715
00:36:14,520 --> 00:36:19,020
And the app developer can choose them and they get the same kind of CF create service, CF bind

716
00:36:19,020 --> 00:36:19,880
service experience.

717
00:36:20,820 --> 00:36:25,620
Now, from the operator's perspective, the teams that are really offering this platform as a

718
00:36:25,620 --> 00:36:30,060
product internally, I think they're the ones that can then make that decision around whether

719
00:36:30,060 --> 00:36:35,000
it's appropriate just to expose all of the RDS offerings or perhaps mix and match.

720
00:36:36,300 --> 00:36:41,700
Some of the criteria that I've seen customers choose there is around kind of whether they care

721
00:36:41,700 --> 00:36:44,980
about cloud lock-in or whether they care about portability.

722
00:36:46,340 --> 00:36:48,500
Sometimes it comes down to skill set as well.

723
00:36:49,060 --> 00:36:51,320
Like MySQL is a technology that's been around for a long time.

724
00:36:51,520 --> 00:36:56,020
A lot of our customers have got highly skilled employees and DBAs are really adept at running

725
00:36:56,020 --> 00:36:56,660
these things.

726
00:36:56,900 --> 00:37:02,160
So they'll tend to lean towards some of the more Bosch-managed stuff where they can be freed

727
00:37:02,160 --> 00:37:05,540
up a bit to go and work more with app developers but still retain some of the control.

728
00:37:06,120 --> 00:37:07,580
So there's a few different criteria there.

729
00:37:08,060 --> 00:37:09,180
Does that answer your question?

730
00:37:09,640 --> 00:37:10,160
It does.

731
00:37:10,160 --> 00:37:13,700
Yeah, I mean, it seems like in a lot of cases, if there's a differentiating reason to use

732
00:37:13,700 --> 00:37:15,640
a native cloud service, do that.

733
00:37:15,860 --> 00:37:18,100
Either that's for operational purposes or functionality.

734
00:37:18,400 --> 00:37:23,480
Otherwise, it can be helpful to have that same sort of portable option everywhere I go, especially

735
00:37:23,480 --> 00:37:24,120
if it's managed.

736
00:37:24,260 --> 00:37:27,040
I'm not really signing up for a lot of operational headaches.

737
00:37:27,180 --> 00:37:28,360
So that was good.

738
00:37:28,940 --> 00:37:29,340
Absolutely.

739
00:37:29,480 --> 00:37:33,440
And where you see customers running kind of PCFs across different infrastructures as well,

740
00:37:33,820 --> 00:37:37,080
then we've got customers who are using the same RabbitMQ products, the same MySQL

741
00:37:37,080 --> 00:37:39,160
one across both of those infrastructures as well.

742
00:37:39,160 --> 00:37:43,700
So just get that consistency of experience, both the operator and the app developer as well.

743
00:37:44,700 --> 00:38:00,640
You know, something that if you've been with a Pivotal customer for a while, you know, we've talked to you about HA and high availability of data solutions and what to think about in those and the kind of products we offer.

744
00:38:00,760 --> 00:38:01,280
Are they clustered?

745
00:38:01,400 --> 00:38:02,240
Are they single instance?

746
00:38:02,240 --> 00:38:03,780
How do I do cross-region?

747
00:38:03,780 --> 00:38:04,960
How do I do cross-site?

748
00:38:05,260 --> 00:38:09,380
Like there's a lot of considerations now and things like Gemfire work across regions.

749
00:38:09,520 --> 00:38:13,640
So there's things to factor in there and certain relational databases, you can set some things up.

750
00:38:13,820 --> 00:38:16,600
But how do you think, because I know you have some good opinions on this.

751
00:38:16,680 --> 00:38:20,620
So how do you think about HA with managed services like these?

752
00:38:20,660 --> 00:38:26,200
Are there any changes to how I traditionally design, you know, that clustered solution?

753
00:38:26,200 --> 00:38:30,260
Do I, are there certain criteria that maybe I don't, shouldn't put the same weight on?

754
00:38:30,520 --> 00:38:33,680
Kind of what's a modern approach to thinking of HA with data solutions?

755
00:38:34,420 --> 00:38:34,900
Yeah, sure.

756
00:38:35,080 --> 00:38:38,160
So this is one of my favorite conversations to have with customers.

757
00:38:39,400 --> 00:38:47,280
One of the things that we often start with is talking about the definition and trying to get that shared understanding of what high availability means to people.

758
00:38:47,800 --> 00:38:54,460
Because often high availability is conflated with clustering or having redundant components such as lead a follower.

759
00:38:55,240 --> 00:38:57,560
Whereas actually high availability is a behavior.

760
00:38:58,580 --> 00:39:02,540
So if you look at the classic definition, it's actually talking about what's your tolerance to uptime.

761
00:39:02,940 --> 00:39:05,400
It's like how many nines does your application need?

762
00:39:05,900 --> 00:39:07,020
And that's really interesting.

763
00:39:07,700 --> 00:39:14,720
Because clustering and redundant architectures, things like that, are a great way of helping you achieve a higher degree of uptime.

764
00:39:15,260 --> 00:39:21,380
But there are also different considerations and different implementations that you can choose, as you were kind of alluding to there.

765
00:39:22,440 --> 00:39:30,000
So when I have this conversation and we get that shared understanding, I like to then try and tease the problem apart and understand what people's expectations are.

766
00:39:31,220 --> 00:39:42,020
I find that in the world of kind of a monolithic kind of application connected to an off-platform database, that these things end up with really high SLAs.

767
00:39:42,440 --> 00:39:44,820
And that's because people don't change them.

768
00:39:45,180 --> 00:39:47,360
So you want to impose some kind of strict contracts.

769
00:39:47,560 --> 00:39:52,620
But also there's like really specialist teams that are running these things and forcing you to go a bit slower.

770
00:39:54,060 --> 00:40:09,080
If you think about a lot of the concepts that we talk about in the cloud, and particularly with microservices, in terms of you should expect failure and design for it, and you should be building resiliency into your application and kind of your architecture as a whole.

771
00:40:09,400 --> 00:40:18,660
And then combining that with, okay, I've got my microservices architecture, I understand the different kind of domain areas inside that.

772
00:40:19,160 --> 00:40:21,460
You can then start to get a bit more granular about it.

773
00:40:21,460 --> 00:40:27,760
And that's really interesting, because you can almost end up with different levels of uptime per part of your microservice.

774
00:40:28,620 --> 00:40:44,700
So that then translates into me for having this shared responsibility between the application team and also the database team on deciding where it is the right place to build in some of this resiliency and choose the right redundancy in terms of components.

775
00:40:46,420 --> 00:40:53,140
Yeah, because you know firsthand there's complexity in setting up a highly available relational database, right?

776
00:40:53,200 --> 00:40:56,940
I mean, it's different even than these sort of consensus-based systems or NoSQL ones.

777
00:40:57,040 --> 00:41:13,680
So I think to your point there is that sometimes easier, not easier, but there's a trade-off to say, look, I'll make some sacrifices on the data tier because I can introduce caching or I can do asynchronous messaging or I can do some other things that protect me against maybe a database blip that prevent me from over-architecting the data tier.

778
00:41:13,680 --> 00:41:16,780
And maybe this is the same question, I'm just having another run at you.

779
00:41:16,920 --> 00:41:31,080
But like, so when you are like negotiating the SLAs, so to speak, or I don't know if they're SLOs, I need to go back and read my SRE stuff because I've forgotten what an SLO way, you know, whatever EOL like music stuff.

780
00:41:31,500 --> 00:41:36,920
Anyways, like what are the like tools you have in the toolbox, right?

781
00:41:36,920 --> 00:41:45,700
Like when it comes to, I mean, just pick one of the managed services or something, but it's sort of like, well, if you want one more nine, we're going to have to build a data center.

782
00:41:45,980 --> 00:41:47,920
Or is it that straightforward?

783
00:41:48,080 --> 00:41:54,720
Is it sort of like, you know, like you meet with someone to fix your kitchen and they're like, well, if you want granite countertops, we're going to have to do this.

784
00:41:54,720 --> 00:41:58,780
And you're like, oh, hey, buddy, I'll take the linoleum then, right?

785
00:41:58,860 --> 00:42:07,520
But like, is there sort of like a set set of things that are sort of on the table if you want more resiliency and HA and things like that?

786
00:42:07,520 --> 00:42:09,660
Or is it just sort of like, you know, crazy town?

787
00:42:09,960 --> 00:42:11,040
Each project is different.

788
00:42:11,960 --> 00:42:16,280
I think each project is different, but there's definitely some commonality that you can bring to it.

789
00:42:16,780 --> 00:42:25,680
And if you've designed your microservices to be independent, again, by all of the practices that we'd expect people to, then you should be able to reason about those pieces independently.

790
00:42:26,160 --> 00:42:31,120
So if you then want to select something like a MySQL leader follower offering off the shelf, that's fantastic.

791
00:42:31,860 --> 00:42:47,020
If there is a small window of opportunity where perhaps the deployment's happening and the nodes are changing roles, for example, then, of course, you can start layering on other pieces on top, such as caching for the most kind of critical parts to that application.

792
00:42:47,400 --> 00:42:57,160
Or maybe even thinking about how you can fail gracefully with inside your application so that you can continue to read, but your rights are just kind of stacked up somewhere else to the side.

793
00:42:58,040 --> 00:43:00,020
And this is where I like to think about it in terms of responsibility.

794
00:43:01,020 --> 00:43:06,260
Like the whole microservices, you must be this tall to go on the ride mentality kind of applies here as well.

795
00:43:07,040 --> 00:43:12,220
That as an app developer, you could push everything down to the data tier if you wanted.

796
00:43:13,100 --> 00:43:18,360
So offloads that responsibility to somebody else, perhaps going back to a centralized team model.

797
00:43:18,620 --> 00:43:22,640
Or you could meet in the middle and use more of one of these more flexible architectures.

798
00:43:23,560 --> 00:43:30,640
Or at the far extreme, we've got some customers who are looking at some really interesting things around the way that they actually architect their application.

799
00:43:31,020 --> 00:43:44,580
So using things like event sourcing and CQRS, for example, to really give them a really powerful architecture there, which allows them to use really simple data stores, such as single node MySQLs or single node Redisys, for example.

800
00:43:44,820 --> 00:43:58,560
And in an attempt to comically, brutally summarize it, like is getting resiliency in data more about like how many safety nets you want to deploy?

801
00:43:58,780 --> 00:44:02,320
Or is it something more basic like, well, this is just a better hard drive?

802
00:44:02,560 --> 00:44:05,140
I mean, I guess, or is that kind of the same sort of thing?

803
00:44:05,200 --> 00:44:10,120
Because as we're going over these things, it's sort of like, well, you want to add in this caching in case something goes wrong.

804
00:44:10,180 --> 00:44:12,140
And you want to add this thing in case something goes wrong.

805
00:44:12,240 --> 00:44:25,340
And it seems like in thinking through evaluating this stuff, like if you have the right kind of mentality of like, what we're talking about is how much money you want to spend on handling failure versus spending money on higher quality stuff.

806
00:44:25,340 --> 00:44:28,460
I don't know. I mean, is that is that anywhere near the right way to think about that?

807
00:44:29,800 --> 00:44:33,120
Uh, yeah, kind of. I mean, it's good enough for me then.

808
00:44:33,920 --> 00:44:40,080
I see where you're coming from. And I think I go back to what's the customer value.

809
00:44:40,080 --> 00:44:52,640
So if that balanced team is responsible for, say, a particular part of their application, then as well as really understanding their customers, they should also understand the business rules behind that.

810
00:44:53,020 --> 00:44:56,240
So what does it mean if part of that application goes down?

811
00:44:56,640 --> 00:45:04,860
If you really understand that, then I think influences your architecture from kind of the top down, the top kind of being the customer behavior that you want to achieve.

812
00:45:05,220 --> 00:45:16,000
And if you end up with a kind of a NoSQL store behind the scenes for part of the microservice, because that's what you need in terms of the availability over consistency there, then that's fantastic.

813
00:45:16,820 --> 00:45:32,920
If you really need kind of strong consistency for another part on your SQL offering, then you might be better off with something like a leader follower setup and accept the small windows of downtime, a couple of minutes a week, for example, and architect your application to be able to code for that.

814
00:45:33,760 --> 00:45:43,220
Now, that makes sense. So it's not only like thinking about safety net things, but it's sort of there are there are well proven ways for your data not to get lost.

815
00:45:43,720 --> 00:45:47,780
Some of them have constraints they impose on your application.

816
00:45:48,480 --> 00:46:02,240
So what we should understand is like it goes back to that thing of like, how good do you really need this to be based on based on the constraints that are going to be imposed on you or the costs that you're going to be have you're going to have, which I don't know.

817
00:46:02,300 --> 00:46:27,980
I mean, at least to me is reminiscent of the old, the ancient sort of, I think it's scrum, I forget, but there's there's some scrum notion of like a, a story is just a reminder to have a conversation later, which, which is sort of a way of saying like, yeah, you should go talk to people and figure out what they actually need on these things instead of just blanketing, like, we have 100% availability, and that'll be $5 million, which sounds kind of nice.

818
00:46:27,980 --> 00:46:56,880
Yeah. And yeah, it really does. Although a little bit expensive. But again, if you go back, if you go back to the SRE model, like that's really cool of bringing that up, like when the teams then have to build these things, and they understand the kind of customer behavior they want to get to, and then they understand the complexity of choosing and pushing a lot of this stuff down into the data tier or kind of finding the right balance between the app and the data tier, then I think that firsthand experience as well will influence thinking.

819
00:46:57,980 --> 00:47:12,980
Yeah, that makes sense. Well, good. I'm glad I could provide. This is the phrase that I'm going to use for I don't know what I'm talking about. So I'm playing the role of Caillou, if you remember that guy. But I'm glad I could play the role of straight man to people who know a lot more about it than I do.

820
00:47:12,980 --> 00:47:41,780
I think I think we're gonna have to update the list, Richard, in I think in order things I don't know about networking, security and data. So yeah, we got that. I think I think maybe the only thing I'm an expert on is pagination. So we could we could put that down there. But hey, thanks for being on. I think this is good stuff. And not only did we learn about how you should remember to have a conversation about negotiating thing, but I've got some new way to torment the baristas around Austin.

821
00:47:41,980 --> 00:47:51,980
That I can deploy out, which I think is always handy. And hey, if you ever need any consulting on burritos, or other Tex-Mex food, I my service is free of charge.

822
00:47:53,080 --> 00:48:06,420
Nice. If there were I think I'm kind of an ambassador for melted cheese plate food. I'll put that out there. But anyhow, if people want to follow up with you, or you know, follow you in Twitter, stuff like that, you got you got some deets to give them.

823
00:48:06,420 --> 00:48:11,040
Yeah, I am Ben underscore Laplanche on Twitter.

824
00:48:12,100 --> 00:48:15,520
Did you decide on the underscore or was the non underscore taken?

825
00:48:18,720 --> 00:48:22,080
It was so long ago, I set it up. I can't remember. I think somebody had already taken it.

826
00:48:22,360 --> 00:48:24,120
Yeah. And my favorite is when the underscore is the beginning.

827
00:48:24,120 --> 00:48:33,860
At least you didn't do the Laplanche like, yeah, or you do like the underscore and then like 2014 to recognize when you signed in, which now seems ridiculous. So I'm glad you didn't do that either.

828
00:48:34,180 --> 00:48:42,120
Yeah, those are good. I think I think it's I think it's maybe the generation before us, who's always putting dates like years into their login names.

829
00:48:42,360 --> 00:49:04,080
I don't know. That's my theory. We'll have to see if that pans out. Well, as always, thanks for listening. This has been Pivotal Conversations. If you want to find the back catalog of what we have, a little link to subscribe and this episode and a little arrangements we have, you can go to soundcloud.com slash Pivotal Conversations, no underscore in there, just just no spaces or anything.

830
00:49:04,300 --> 00:49:32,280
Also, every Thursday, more or less, when we've met in our SLAs, or I don't know if it's an SLO, we post on pivotal.io slash podcast and we'll have the full show notes there. I went and looked up that that thing, that recipe I was trying to remember, where you can get overwhelmed by tomatoes. We'll put a link to that. And and also the coffee and other related things. And it's always great if you actually just if you haven't already just subscribed to this so it automatically gets downloaded and you'd be doing us a favor.

831
00:49:32,280 --> 00:49:54,640
If you tell people word of mouth about this or word of Twitter or even LinkedIn. I check in there every now and then. It's a very thriving community. But it's always nice to make sure that if you enjoy this program, other people you might know about will find it as well. We've got a program going, Richard. We're going old school with the vocab here. But with that, we'll see everyone next time. Bye bye.