1
00:00:00,000 --> 00:00:04,380
Hello, everyone. Before we start, I just wanted to promote a few upcoming pivotal things through

2
00:00:04,380 --> 00:00:09,060
June, July, and August. We had the Cloud Native Roadshow coming to all sorts of cities. This is

3
00:00:09,060 --> 00:00:13,380
a free day-long event we do with Google that goes over what exactly Cloud Native is and how our

4
00:00:13,380 --> 00:00:18,060
customers are using pivotal and Google technologies and approaches. The cities, and this is a long

5
00:00:18,060 --> 00:00:22,260
list, so get ready. The cities are Stuttgart, Dallas, Denver, LA, Seattle, San Francisco,

6
00:00:22,540 --> 00:00:27,720
Amsterdam, Seoul, Hong Kong, Sydney, and Singapore. There's a big list of dates that you can look at.

7
00:00:27,720 --> 00:00:31,180
You can check out the show notes for a link to it, or if you just want to go and Google for

8
00:00:31,180 --> 00:00:36,280
Pivotal Cloud Native Roadshow, you'll find it pretty easily. We also have Spring Days Atlanta coming up

9
00:00:36,280 --> 00:00:40,760
July 18th and 19th. It's chock full of sessions for developers who want to learn more about the

10
00:00:40,760 --> 00:00:45,840
Spring Framework, Cloud Native style development, and of course, to be fully buzzword compliant,

11
00:00:46,360 --> 00:00:50,700
microservices. If you go to springdays.io, you can get more info, and that's the last Spring Days

12
00:00:50,700 --> 00:00:54,920
we're having so far that we have scheduled this year, so get that one in if you're over in

13
00:00:55,220 --> 00:01:00,680
grits and pork land. It'll be good stuff. Finally, while it's way in the future, we also have Spring

14
00:01:00,680 --> 00:01:05,120
One platform coming up December 4th and 5th. Now, registration just opened recently for this. I

15
00:01:05,120 --> 00:01:09,500
think you might have missed the early bird thing for it, but that's fine. There's also still the CFP

16
00:01:09,500 --> 00:01:14,460
open. It closes on September 1st. Now, what goes on at this conference? Well, it's full of what I

17
00:01:14,460 --> 00:01:19,720
would call the suit track and the technology track. In the suit track, you've got case studies and

18
00:01:19,720 --> 00:01:24,860
managers and developers as well, but organizations talking about how they've transformed their

19
00:01:24,860 --> 00:01:28,700
company and what they're doing with Cloud Native and their organizations, how they're getting good

20
00:01:28,700 --> 00:01:33,500
results by switching over to doing things in more of a pivotal way. But then there's also plenty of

21
00:01:33,500 --> 00:01:38,100
events for those of you out there who enjoy more nerding out and doing technical things to check

22
00:01:38,100 --> 00:01:45,340
out. I'm one of the chairs of the DevOps pipeline and monitoring track that we informally call it.

23
00:01:45,400 --> 00:01:49,520
We've already got lots of excellent talks queued up from the likes of Home Depot, Express Scripts,

24
00:01:49,560 --> 00:01:53,720
Allstate Northern Trust, and of course, plenty of pivotal people. I'll be speaking in that track

25
00:01:53,720 --> 00:01:58,540
if that's anything. So come on there. Again, it's in San Francisco, December 4th and 5th. And if you

26
00:01:58,540 --> 00:02:04,360
just go to springplatform.io, you can check it all out. And with that, enjoy the episode this week.

27
00:02:04,800 --> 00:02:08,220
Well, you know, I like to start with a little weather reporting every now and then. Richard,

28
00:02:08,220 --> 00:02:14,220
it's hot down here. We had July 4th, which I have discovered is our international,

29
00:02:14,580 --> 00:02:18,580
not international. It's the opposite. It's our national holiday of eating too much.

30
00:02:19,640 --> 00:02:25,560
So I think that's the taste of freedom. It's hot dogs, pork chops, steaks. But man,

31
00:02:25,660 --> 00:02:31,220
down here in Austin, it's like, I think we're finally near the, feels like 100 or so degrees

32
00:02:31,220 --> 00:02:36,940
every day. It's crazy. And if you have to be on a big slope that goes down to a lake,

33
00:02:37,320 --> 00:02:41,560
I mean, it had some nice St. Augustine grass, which I always wonder how that's related to,

34
00:02:41,560 --> 00:02:45,120
you know, one of the founding people of Catholicism, but that's a whole other podcast,

35
00:02:45,200 --> 00:02:49,180
I guess. But it had that grass and like, you got to go up and down there with the floats

36
00:02:49,180 --> 00:02:55,020
and, uh, and, and coolers. You ever had to like lift a cooler all the way up and down a hill

37
00:02:55,020 --> 00:02:58,720
while everyone is just like, why are we not drinking beer yet? And you're like,

38
00:02:58,740 --> 00:03:01,080
cause I got this gigantic cooler. I have to lift.

39
00:03:01,900 --> 00:03:06,000
That's right. Yeah. No, it's a, it's only 80 up here. So it's not nearly as bad as your,

40
00:03:06,080 --> 00:03:09,540
your Texas weather. Those coolers though, pretty awkward to carry, especially when they're,

41
00:03:09,620 --> 00:03:10,860
they're full of sloshing things.

42
00:03:10,980 --> 00:03:15,580
Yeah. Yeah. Luckily, luckily I like the kind of things that are heavy initially. And then as you

43
00:03:15,580 --> 00:03:20,260
have more fun throughout the day, you, you, the liquid disappears. And so it becomes lighter.

44
00:03:20,300 --> 00:03:24,800
I think, I think that that's paces well with, with the, the strenuous effort you want to put on

45
00:03:24,800 --> 00:03:29,280
things. That's right. Especially when your strength is faded at the end of a day of drinking and

46
00:03:29,280 --> 00:03:33,740
eating meat. Faded strength. That's right. Well, we have a guest on this episode. Speaking of the

47
00:03:33,740 --> 00:03:39,520
opposite of faded strength, I guess you want to, you want to introduce yourself, uh, briefly.

48
00:03:40,840 --> 00:03:45,600
Yeah, sure. So I'm on this, Duncan Wynn. I run the platform architecture team for the Pacific West

49
00:03:45,600 --> 00:03:51,640
and I've been in pivotal since, uh, pivotal kicked off. Uh, I used to run the field engineering team

50
00:03:51,640 --> 00:03:57,200
in EMEA and I've also done a stint in PCFS working for Dino. Now, now one of my favorite

51
00:03:57,200 --> 00:04:02,580
questions to ask field people is, is what exactly their region means. So what is Pacific West?

52
00:04:03,360 --> 00:04:09,200
So I cover everything up to Richard's area in Seattle, right down to San Diego. And then I cover

53
00:04:09,200 --> 00:04:14,880
over to Denver and Phoenix. So any customer in that geography. So, so it's like all of the West

54
00:04:14,880 --> 00:04:21,500
coast. Not all of the West, the West is broken into like the Midwest and Tola and Oh, I just,

55
00:04:21,600 --> 00:04:26,100
I just mean West coast. If it's all, if I mean, it's all, it's all of the West coast. Yeah. I mean,

56
00:04:26,100 --> 00:04:29,420
there's this American thing of West means more than just the West coast. I cover all of the West

57
00:04:29,420 --> 00:04:33,740
coast. Right, right. See, this is why I like asking it because I find the names fascinating in that

58
00:04:33,740 --> 00:04:38,360
they're a little, little quandary inducing, right? Pacific West coast, which implies the Pacific

59
00:04:38,360 --> 00:04:43,240
nature, but then if you have all of the Pacific side, it's just West coast. But then, like you said,

60
00:04:43,240 --> 00:04:48,640
it's not all of West. So I see how you would derive that it's Pacific is not so much a location as an

61
00:04:48,640 --> 00:04:54,840
adjective for which West. Basically. Yeah. You got it. Makes sense. Okay. I like that. I like coming

62
00:04:54,840 --> 00:05:00,960
up with reverse engineering, the schemes people came up with for naming schemes. It's a, well,

63
00:05:00,960 --> 00:05:08,020
I feel like I've earned my intellectual, uh, giblets for today, if you will. So, uh, speaking of giblets,

64
00:05:08,440 --> 00:05:17,460
right. No, no, no. All the holidays are running together. I think, I think the next one is, uh,

65
00:05:17,460 --> 00:05:23,420
we got labor day. Is that right? I think, right. I think we were now in the American drought of

66
00:05:23,420 --> 00:05:28,180
holidays. Like we had a bunch of them. Then labor day comes up and then, and then Thanksgiving.

67
00:05:28,180 --> 00:05:33,880
Am I forgetting something? Like a Halloween coming up then. And then Thanksgiving, but yeah,

68
00:05:33,880 --> 00:05:36,980
we're halfway through the year. Don't, don't start talking about it. Yeah. You guys are getting

69
00:05:36,980 --> 00:05:39,720
ahead of yourself. We still have to slog through the rest of the summer holidays.

70
00:05:40,160 --> 00:05:44,460
Seriously. Oh yeah. Yeah. There is, there is, you know, I, when I worked at Red Monk, uh,

71
00:05:44,460 --> 00:05:49,960
they were half European or, or maybe a third, depending on how you count, uh, James governor's

72
00:05:49,960 --> 00:05:55,880
dual nationality. And, uh, the babies, basically there was this policy of like, you should take August off,

73
00:05:55,880 --> 00:06:00,400
which seemed like a, uh, a good way to live. That, that was fun. Cause, and, and the reasoning

74
00:06:00,400 --> 00:06:04,040
professionally was sound. It was like, yeah, nothing really happens in August, at least for an

75
00:06:04,040 --> 00:06:10,620
industry analyst perspective. But you know, we'll see, we'll keep that in mind. So, uh, so back to

76
00:06:10,620 --> 00:06:17,220
the giblets. So you did, you did a fine job. You know, I, I, I've got another, I've got my software

77
00:06:17,220 --> 00:06:21,240
defined talk recording coming up this afternoon. And I was thinking like, man, not, not much has been

78
00:06:21,240 --> 00:06:25,340
happening, but you did an excellent job of rounding up some news, Richard. So, so what, what do you have

79
00:06:25,340 --> 00:06:30,260
for us? Giblet wise this week? Yeah, no, I keep an eye on it. So yeah, the first thing I listed was,

80
00:06:30,260 --> 00:06:35,800
uh, Google cloud expanded to Australia. They just added their Sydney region and Amazon keeps scaling.

81
00:06:36,140 --> 00:06:41,000
Microsoft keeps doing their crazy scaling. I think it's this, again, for me, reminder that it is

82
00:06:41,000 --> 00:06:45,440
nonstop that everyone is going to, this cloud providers are just relentlessly moving around the

83
00:06:45,440 --> 00:06:50,820
globe, adding new locations. You start to look at these maps and say, where don't I have coverage?

84
00:06:50,820 --> 00:06:55,880
Like, where do I have any incentive to use co-location or some of those other providers?

85
00:06:55,880 --> 00:06:59,660
Cause that used to be a regional play. Like, Oh, I'll use colo because they actually have a site here.

86
00:06:59,900 --> 00:07:05,420
It doesn't really apply as much anymore. So very interesting stuff. Good for Google. You know,

87
00:07:05,420 --> 00:07:09,600
they're playing catch up, but I like what they're doing there. That was the first one. I don't know

88
00:07:09,600 --> 00:07:14,840
if you see that Coté as well at Duncan. It just, it's, there's no end to insight. I mean,

89
00:07:14,840 --> 00:07:18,900
Amazon announces things the year ahead of time of where they're coming into the next country and

90
00:07:18,900 --> 00:07:22,600
region. It just seems like you're really chipping away at any benefits some of those regional

91
00:07:22,600 --> 00:07:27,640
providers had. Yeah. It's like you're saying that used to be a, uh, a theoretic point of

92
00:07:27,640 --> 00:07:32,740
differentiation for, uh, companies that wanted to compete against them. But nowadays it's just like,

93
00:07:32,800 --> 00:07:38,680
Oh, you just go open a data center. No problem. Which I shouldn't say no problem, but it is a,

94
00:07:38,680 --> 00:07:44,460
a standard operating procedure that you open all these regional data centers, which I suppose makes

95
00:07:44,460 --> 00:07:51,560
sense. Yeah. The, uh, second one I called out was Microsoft or it was leaked. And then I guess

96
00:07:51,560 --> 00:07:56,140
confirmed that Microsoft's doing a big reorg revamping some of their sales force. And there's

97
00:07:56,140 --> 00:07:59,400
probably, I mean, there's going to be some layoffs involved. It looked like they haven't confirmed the

98
00:07:59,400 --> 00:08:03,660
whole thing, but really a lot of this is they're rearranging around artificial intelligence around

99
00:08:03,660 --> 00:08:08,660
cloud. And I don't know. I think it's a reminder to the traditional sales. When you look at some of the

100
00:08:08,660 --> 00:08:13,180
traditional software vendors who would sell three years out of three-year enterprise agreements and

101
00:08:13,180 --> 00:08:17,800
some of these big deals, the world's changed to a subscription model where I'm, you know, I'm buying

102
00:08:17,800 --> 00:08:22,980
Azure credits and I'm buying and I'm bursting and I'm shrinking. And it's just a different way you sell.

103
00:08:23,120 --> 00:08:28,200
It's a different approach. So traditional sales forces, it's just a different game now. And Duncan,

104
00:08:28,200 --> 00:08:31,700
I don't know your experience. When we think about platform architecture and supporting sales,

105
00:08:31,700 --> 00:08:36,520
but I don't think it's the same anymore of necessarily, let's go play golf and sign big,

106
00:08:36,600 --> 00:08:40,800
large contracts. And we'll check back in a few years and see how you're doing. It seems like

107
00:08:40,800 --> 00:08:46,140
there's much more of a constant trusted advisor sales process. It's not just show up every now and

108
00:08:46,140 --> 00:08:51,500
then. And I get Microsoft just reflecting the reality. So A, I don't play golf. I'm horrendous at

109
00:08:51,500 --> 00:08:54,740
golf. I just don't have the patience to whack the ball back and forth over the whole 10 times.

110
00:08:55,340 --> 00:09:00,980
But yeah, I definitely see there's far more technical focus in the sale. Customers want to go

111
00:09:00,980 --> 00:09:04,860
right into the specifics very, very early on. They want to understand the value proposition.

112
00:09:05,500 --> 00:09:09,720
They want to delve in very deep. They're getting more technically savvy. There's obviously a lot

113
00:09:09,720 --> 00:09:15,140
of open source, so they can do a lot of groundwork upfront, reading around it. And yeah, it's just

114
00:09:15,140 --> 00:09:20,860
far more technical and more relational sale. Yeah. I would just see often see in my own time doing

115
00:09:20,860 --> 00:09:25,140
sales and otherwise, as you would just notice that there was, as you say, more, more technical skill.

116
00:09:25,220 --> 00:09:29,020
You would often walk into a customer who knew more about your product than you did just because it was so

117
00:09:29,020 --> 00:09:33,020
easy to research and use these things ahead of time. There weren't the software gatekeepers

118
00:09:33,020 --> 00:09:38,760
anymore. So anyway, good for Microsoft. You're probably important to shrink in that area and focus

119
00:09:38,760 --> 00:09:39,300
a little tighter.

120
00:09:39,760 --> 00:09:44,380
You sort of answered the question I was going to ask. I read some of those stories and like all

121
00:09:44,380 --> 00:09:51,860
sort of leak confirmed leak stuff. It's not like they got the 50-page planning document that was

122
00:09:51,860 --> 00:09:56,860
used by the Microsoft SVP of sales and just put it up there on SlideShare, right? So you get not all

123
00:09:56,860 --> 00:10:02,200
the details are in there. Is that an EVP or an SVP thing at Microsoft or a corporate vice president?

124
00:10:02,440 --> 00:10:07,260
They got all those types of vice presidents running around. But or at least back when I would go to

125
00:10:07,260 --> 00:10:13,580
their conferences, they would. And yeah, I mean, it is like when I see something like that, like I always

126
00:10:13,600 --> 00:10:19,540
wonder like exactly what the reorganization is and as not what it looks like, but like why you would need to

127
00:10:19,540 --> 00:10:26,440
reorganize. And I guess if the theory is you two are going over is that you have a lot more technical

128
00:10:26,440 --> 00:10:32,180
sales, then there's two points after that. One, I guess you need people who are more technical. So

129
00:10:32,180 --> 00:10:39,740
make sure you have that. And then I guess also the other thing is like that maybe there's a shift in

130
00:10:39,740 --> 00:10:44,960
the way that things like Office and Office 365 are sold, right? If they're, I don't know if this is true

131
00:10:44,960 --> 00:10:49,420
or not, but you know, if they're all more of a SaaS subscription, it's not like every individual goes

132
00:10:49,420 --> 00:10:54,700
there with a credit card to sign up. You still have your large accounts where you go negotiate some

133
00:10:54,700 --> 00:10:59,260
big deal with it. But, but maybe you have a different types of salesperson and the way it's,

134
00:10:59,320 --> 00:11:04,600
it's organized there. And then I guess, I mean, there's always things like, like comp plans and the

135
00:11:04,600 --> 00:11:09,660
way that you cover your region, speaking of Pacific West and all of that stuff. But it's, it's,

136
00:11:09,660 --> 00:11:14,180
it's interesting to see how people organize their sales force because that's, that's always highly

137
00:11:14,180 --> 00:11:19,580
indicative of the type of technology they're selling. And, you know, certainly having, having

138
00:11:19,580 --> 00:11:25,500
looked at the way that, that, that we do our sales force and technical field stuff, it, we, we morph

139
00:11:25,500 --> 00:11:30,000
around pretty quickly to match the way that the customers want to consume things, or I should say

140
00:11:30,000 --> 00:11:34,720
prospects want to think about what they're doing and then customers want to on go consume their

141
00:11:34,720 --> 00:11:39,220
stuff. And it seems like I'm repeating a bit of what y'all were saying, but it seems

142
00:11:39,220 --> 00:11:47,520
like, um, if you have a, a bunch of stuff that's sold as a SaaS, then more or less, there's

143
00:11:47,520 --> 00:11:52,480
like not really that much relationship to have there. It's like the SaaS either does what you

144
00:11:52,480 --> 00:11:56,200
want or not. And then you got to integrate it with some other stuff. And then you're going

145
00:11:56,200 --> 00:12:01,860
to negotiate some prices on either side, but it's not like, uh, there's a lot of work

146
00:12:01,860 --> 00:12:06,500
there. Like hopefully it's more of a no ops, so to speak situation. And then this leaves

147
00:12:06,500 --> 00:12:10,480
this bulk of stuff that you're going to manage and run on prem on your own. And then that's

148
00:12:10,480 --> 00:12:14,640
more of like, as y'all are saying, the more technical ongoing relationship of things, which

149
00:12:14,640 --> 00:12:19,660
I guess would necessitate changing around how you, uh, do your sales. If, if you are more

150
00:12:19,660 --> 00:12:25,420
application heavy than, uh, sort of like, I don't know, Heathkit toolbox heavy on what

151
00:12:25,420 --> 00:12:25,980
you were selling.

152
00:12:26,700 --> 00:12:31,180
Yeah. I mean, cloud disrupts everything, right? I mean, at this point, even Salesforce is how you

153
00:12:31,180 --> 00:12:35,440
do project planning, how you host software. And so why, why should sales be immune from it? So

154
00:12:35,440 --> 00:12:39,020
again, I think just a recognition of reality, which is sometimes good to see.

155
00:12:40,420 --> 00:12:44,860
Yeah. One of the other things I threw out here was a SpringOne platform coming up in December.

156
00:12:45,120 --> 00:12:50,000
That's the pivotal giant conference that we do all kinds of stuff. It's focused a lot on spring,

157
00:12:50,080 --> 00:12:54,360
but we also dip into the cloud foundry world and gem fire and all kinds of fun stuff. And

158
00:12:54,360 --> 00:12:59,540
I listed because we have a couple of great keynoters now. So Eric Brewer from Google who,

159
00:12:59,540 --> 00:13:05,260
you know, cap theorem fellow came up with all that great engineer, great mind. So really excited to

160
00:13:05,260 --> 00:13:11,360
have him speaking. And then also we got last week, uh, Eric gamma from Microsoft, a technical fellow

161
00:13:11,360 --> 00:13:16,320
there who was one of the founders of eclipse project. Also part of that gang of four design

162
00:13:16,320 --> 00:13:21,760
patterns book now works on the visual studio code and other teams at Microsoft. So just really cool

163
00:13:21,760 --> 00:13:26,960
to have some practitioners and some smart folks kind of bookending the conference and sessions are

164
00:13:26,960 --> 00:13:31,540
starting to come online soon. So just exciting to see a lot of people already signing up. And if you

165
00:13:31,540 --> 00:13:34,480
haven't already, and you're listening to this podcast, then, uh, get on that.

166
00:13:35,000 --> 00:13:38,780
I'm really looking forward to SpringOne platform and SpringOne has always been a very technical

167
00:13:38,780 --> 00:13:44,100
conference, great content, tons of fun. It was fantastic last year to have, um, the cloud foundry

168
00:13:44,100 --> 00:13:48,740
element to it as well with SpringOne. So yeah, I'm super excited. So it's very good stuff.

169
00:13:48,740 --> 00:13:53,840
So I think, you know, while, while I'm like, uh, helping chair one track now per my usual style,

170
00:13:53,840 --> 00:13:58,980
that doesn't mean I'm paying that much attention to anything, but, uh, like, like what's the schedule

171
00:13:58,980 --> 00:14:04,140
for like announcing talks and things like that? Or, or is there one like what, what can people look

172
00:14:04,140 --> 00:14:08,840
forward to there? Question. Yeah, we're still in the call public call for papers. We did a private

173
00:14:08,840 --> 00:14:13,160
one for some internal folks and customers first is to start filling out the schedule, but the public

174
00:14:13,160 --> 00:14:17,080
one I think closes in September. So keep getting your talks in specifically, if you've got some good

175
00:14:17,080 --> 00:14:22,320
stuff on security, uh, implementation patterns, things like that. But then we're going to be

176
00:14:22,320 --> 00:14:26,700
trickling out as, as teams like yourselves, Coté kind of approve talks. We're going to get,

177
00:14:26,780 --> 00:14:30,800
be getting those on the website. So all throughout the summer and then kind of a big push in August,

178
00:14:30,920 --> 00:14:36,260
September, you'll see a lot of talks, almost the final schedule go online. So constantly coming,

179
00:14:36,340 --> 00:14:39,520
you'll have a good sense of kind of the talks we're having, the tracks we're having,

180
00:14:40,020 --> 00:14:43,460
things like that, but it's going to be absolutely chock full. There's, there's just a ton of content.

181
00:14:43,460 --> 00:14:47,720
We've gotten a ton of submissions, which is great. So yeah, at the Duncan's point, it's a fun

182
00:14:47,720 --> 00:14:52,540
conference. It's a great group of people. And, uh, I learned a ton last year. I'm going to go as an

183
00:14:52,540 --> 00:14:58,060
attendee as much as an organizer this year. And if I remember the prerecorded ad thing that just played

184
00:14:58,060 --> 00:15:02,200
at the beginning of this episode, that the listeners were here, I think there's a, there's a discount in

185
00:15:02,200 --> 00:15:05,740
there and a little preview, at least of the talks that I know of, of, of what they are.

186
00:15:05,800 --> 00:15:11,180
So just rewind and then listen to all of our delightful talk about weather, uh, afterwards.

187
00:15:11,380 --> 00:15:14,960
Right. And then, and then you win, I guess enough people sign up a code. Hey, I think you win

188
00:15:14,960 --> 00:15:20,140
something, a trophy, a badge, something like that. I don't think with any of my signup codes for

189
00:15:20,140 --> 00:15:24,740
conferences, they've ever been used. So they're more, it's more, I look at it as just brand advertising,

190
00:15:25,060 --> 00:15:30,060
right? There's no, there's no whatever. I think someone told me that, uh, DevOps stays Minneapolis

191
00:15:30,060 --> 00:15:34,300
people. They use that code, which I don't, I don't know what happened. Some, some strange anomaly.

192
00:15:34,560 --> 00:15:40,480
Well, finally, I think, uh, the last thing you had is that, uh, over there, over there in Kafka land,

193
00:15:40,480 --> 00:15:44,600
they finally, uh, they found, uh, you know, the wooden cup or the Holy grail or whatever.

194
00:15:44,740 --> 00:15:49,860
So, so what's, what's up with this exactly once, uh, reliability they have or delivery.

195
00:15:49,860 --> 00:15:55,840
Yeah. Good, good stuff. So, I mean, the team who helped build Kafka and obviously there's the

196
00:15:55,840 --> 00:16:00,140
open source piece and the commercial piece they support, they made a big splash over supporting

197
00:16:00,140 --> 00:16:05,220
exactly once delivery in the new Kafka engine coming out. And so on one hand, it gets positioned

198
00:16:05,220 --> 00:16:09,680
in the story I linked here as like, ah, they achieved it. My gosh, kudos to everyone. This

199
00:16:09,680 --> 00:16:13,820
has never been done before because in some cases people say exactly once is impossible that you

200
00:16:13,820 --> 00:16:18,360
can't guarantee in a distributed system that the writer will only write the message one time.

201
00:16:18,360 --> 00:16:22,520
And then that consumer will only read it once because, Hey, the network could glitch or I could

202
00:16:22,520 --> 00:16:27,220
fail to process it when I started processing it. And then I get in a weird limbo state or

203
00:16:27,220 --> 00:16:31,860
all kinds of things can happen in a distributed system, but they put together a really good

204
00:16:31,860 --> 00:16:35,960
thing. We linked to a couple of the papers here, some really well-written explained pieces that

205
00:16:35,960 --> 00:16:40,240
there's some asterisks here. Like you've got to be using what they've built to kind of have

206
00:16:40,240 --> 00:16:44,920
the right publisher and how it's read. And if you fan out beyond what's kind of working

207
00:16:44,920 --> 00:16:49,720
in confluent land, you can't guarantee everybody else will only get it exactly once. So there's

208
00:16:49,720 --> 00:16:54,260
some caveats and other systems like Azure's event hubs have done some pieces like this

209
00:16:54,260 --> 00:16:58,540
for a while. Other systems have solved pieces of this, but exactly once is really tough and

210
00:16:58,540 --> 00:17:03,560
distributed systems. What I enjoyed the most was the spirited debates back and forth from

211
00:17:03,560 --> 00:17:07,140
folks. Cause you end up learning a lot of people who have some really cool experience in this

212
00:17:07,140 --> 00:17:10,000
space. So read up on some of those links. It's a, it's well worth your time.

213
00:17:10,280 --> 00:17:14,560
Now, now between the two of you, I'm interested in y'all's response to this. It seems like,

214
00:17:14,560 --> 00:17:19,600
uh, uh, you know, I remember there was this explosion of like no SQL stuff, which never

215
00:17:19,600 --> 00:17:23,940
minding all the semantics of that. There was this explosion of post-relational databases for

216
00:17:23,940 --> 00:17:29,860
everything, uh, going on. And like, I seem to most, I don't know if this is some bias on my part

217
00:17:29,860 --> 00:17:34,560
of whatever, but I seem to mostly only hear about Kafka and sometimes Cassandra nowadays. Like,

218
00:17:34,560 --> 00:17:38,820
are those like, is that kind of all that's going on around there or is there other things

219
00:17:38,820 --> 00:17:42,980
and, and like, like why what's, what's, what's been the story with all that, that y'all two

220
00:17:42,980 --> 00:17:49,580
encounter? I mean, tons of stuff in no SQL land besides Cassandra, you've got, obviously Mongo

221
00:17:49,580 --> 00:17:54,680
is still super popular. You've got all the kind of cloud specific things, whether that's to some

222
00:17:54,680 --> 00:18:00,220
extent, you know, DIMO DB in, in Amazon or Azure equivalents, Google equivalents for kind of

223
00:18:00,220 --> 00:18:04,540
unstructured sort of data. But then, you know, for messaging, that's where Kafka is

224
00:18:04,540 --> 00:18:09,640
gone crazy. And RabbitMQ continues to be arguably the most popular messaging engine in the world.

225
00:18:09,840 --> 00:18:14,140
So you're seeing more open source flavor for those things, no doubt about it versus, but then you

226
00:18:14,140 --> 00:18:19,360
look at the cloud things and Dynamos proprietary, you know, spanners, relatively proprietary in

227
00:18:19,360 --> 00:18:24,100
Google land, even though it's kind of SQL-y. So it's an interesting space. You don't have a lot of

228
00:18:24,100 --> 00:18:28,420
commercial software being shipped for around databases. That's new. A lot of the innovations

229
00:18:28,420 --> 00:18:33,840
happening in open source, but a lot of cool as a service offerings are fairly proprietary in both the

230
00:18:33,840 --> 00:18:36,920
messaging and the storage space. But Duncan, what do you see there?

231
00:18:37,720 --> 00:18:42,060
Yeah, we used to be really prescriptive in the field and say, don't use your messaging engine for

232
00:18:42,060 --> 00:18:46,700
a cache and don't use your cache as a message bus. But we are seeing a bleeding there. You look at

233
00:18:46,700 --> 00:18:50,440
things like Redis, they now have a messaging component in Redis where historically it was a

234
00:18:50,440 --> 00:18:57,080
fantastic caching technology. We still have our own as well with things like Gemfire and Geode and the

235
00:18:57,080 --> 00:19:01,700
ability to cache and then have the distribution over a wide area network is really fantastic. So it's a

236
00:19:01,700 --> 00:19:06,680
very hot space. Products morphing, product changing, you've got these religious camps focusing on one or

237
00:19:06,680 --> 00:19:06,980
the other.

238
00:19:08,640 --> 00:19:12,980
Yeah, wild stuff. So anyway, it's a good thing to read up on. Lots of great stories. Last week,

239
00:19:13,020 --> 00:19:17,200
some good hacker news conversations. And maybe that leads into your last piece, because I love reading

240
00:19:17,200 --> 00:19:22,660
the comments when it comes to hacker news. I also adore reading the comments on any Coté register post.

241
00:19:22,960 --> 00:19:29,240
Yeah, yeah, it's where I go when I want to take myself down a few pegs. That's good stuff. Yeah,

242
00:19:29,320 --> 00:19:34,900
well, you know, I write a more or less monthly piece, except since it's a European publication to do a

243
00:19:34,900 --> 00:19:40,280
callback in August, because apparently no one reads anything in August over there. And then December,

244
00:19:40,800 --> 00:19:47,560
for obvious reasons, because he got Boxing Day, I don't really know what that is. And, and so the one

245
00:19:47,560 --> 00:19:53,420
the one I did this month was on, I don't know how to filter and select DevOps consultants, which really,

246
00:19:53,620 --> 00:19:58,740
as one of the astute commenters wrote, applies to any type of consultant, but but that's fine.

247
00:19:59,380 --> 00:20:07,360
But yeah, I think I think I talked with Matt Walburn, who used to work here for a short stint. He's now

248
00:20:07,360 --> 00:20:13,340
over at Amazon. But notably for this, he worked at the on one of the DevOps, I don't know, teams or

249
00:20:13,340 --> 00:20:18,880
groups over at Target for a while. And he gave some advice about finding them. And then also our very

250
00:20:18,880 --> 00:20:25,160
own Bridget, who, you know, she she surveys lots of people doing DevOps stuff at conferences. So she

251
00:20:25,160 --> 00:20:29,520
kind of spoke on that topic. And, you know, the advice in there is what you would expect. Like,

252
00:20:29,940 --> 00:20:35,540
unless the vendor has a vendor has sort of like, aggregated people who actually have firsthand

253
00:20:35,540 --> 00:20:40,720
experience, it's good to find people who have firsthand experience, not just pure theoreticians and

254
00:20:40,720 --> 00:20:47,680
everything like that. But yeah, you can go check that out. And as as my, my boss, Andrew Schaefer,

255
00:20:47,940 --> 00:20:54,760
wrote to me, you know, apparently the the volume is working for as one of the commenters wrote about.

256
00:20:54,960 --> 00:21:00,820
So I think there's there's some good descriptions of, of my theoretic toolkit for writing these pieces

257
00:21:00,820 --> 00:21:07,600
to your comment point. But yeah, good stuff. So we'll be honest, I, yeah, I sent a link to your post to

258
00:21:07,600 --> 00:21:11,320
someone on my team and said, you know, you should read the comments, because this is arguably our

259
00:21:11,320 --> 00:21:15,140
audience. Sometimes we do have some, you know, the register seems to have the grouchy sysadmin

260
00:21:15,140 --> 00:21:19,100
audience, which, you know what, that's still a voice. And those are people who still have legitimate

261
00:21:19,100 --> 00:21:23,820
complaints mixed in with the snark. So I actually like reading them, because specifically, that is

262
00:21:23,820 --> 00:21:28,960
the people we fight against sometimes in accounts who look at us as just kind of a unicorn promise to

263
00:21:28,960 --> 00:21:31,680
come in and save things. So we should know what those folks are thinking.

264
00:21:32,180 --> 00:21:37,600
Yeah, I, you know, I think I think that's a good, that's, that's a good turning a frown upside down

265
00:21:37,600 --> 00:21:41,980
content wise there that you just pulled off. But I think, I think that if you were to mind the

266
00:21:41,980 --> 00:21:47,640
comments, they, you know, the number one thing they're, they're sick of over there in register

267
00:21:47,640 --> 00:21:53,040
comment land is like, what the hell is DevOps? Like, and why it sounds like the same thing it always is,

268
00:21:53,040 --> 00:21:57,360
which is like, and I poke fun at people in those columns every now and then, I often do some

269
00:21:57,360 --> 00:22:01,900
parenthetical little wave to like, you've been doing this since the days of abacuses or whatever. But

270
00:22:01,900 --> 00:22:08,600
they, and it is kind of true, like, it's hard to find a satisfying definition of DevOps. Like I was

271
00:22:08,600 --> 00:22:15,700
just reading through, I was starting to read through speaking of a 50 page document, the 58 page PDF of

272
00:22:15,700 --> 00:22:23,080
the 2017 DevOps report. And there's, there's, there's some pretty good sort of like thrusts at

273
00:22:23,080 --> 00:22:27,460
defining DevOps. There's one chart in particular, they do the, there's some name for this, but

274
00:22:27,460 --> 00:22:32,840
they do these good, um, uh, they're not causal. They're very careful. Never say that, but sort of

275
00:22:32,840 --> 00:22:38,820
like predictive charts of like, if you follow these things that causes you to do these things, which

276
00:22:38,820 --> 00:22:45,860
causes success. And that's kind of a good summary of DevOps stuff. But, uh, if you're kind of cynical,

277
00:22:45,860 --> 00:22:50,900
it's easy to look at all of the stuff around what cloud native and DevOps is. If you don't get

278
00:22:50,900 --> 00:22:56,560
very technical and say like, so basically this is computers except working very well,

279
00:22:56,700 --> 00:23:02,880
right? Like, and automating a lot of stuff. And it's, it's sort of like finally doing all this

280
00:23:02,880 --> 00:23:08,700
stuff that the, uh, the computer should do well, which I think, um, to, to that point, right? Like

281
00:23:08,700 --> 00:23:13,120
the, the, the, the, I think, especially with us and other people who want to help explain why you

282
00:23:13,120 --> 00:23:16,880
would do things in this new way. And maybe this is a good segue to the book is like, we were talking

283
00:23:16,880 --> 00:23:22,580
about this with, uh, with Tony and, uh, and, and, uh, and John in the last episode, I think about

284
00:23:22,580 --> 00:23:27,200
like, so what exactly is cloud native ops? Right. And, and, you know, we got to a pretty good

285
00:23:27,200 --> 00:23:31,720
definition of a list of like, here's some exact specific things you do that are different in the

286
00:23:31,720 --> 00:23:36,420
technologies that are different that make it a cloud native thing or a DevOps sort of thing.

287
00:23:36,680 --> 00:23:41,140
So, uh, as you say, it's a good reminder to look in those comments about how you, you always need

288
00:23:41,140 --> 00:23:46,260
to be pretty specific with SysApi people about what exactly is different and why it changes things.

289
00:23:46,260 --> 00:23:51,040
And then, as I would say, why that allows your, uh, your, your meatware behavior to change and be

290
00:23:51,040 --> 00:23:56,140
better. Yeah. Good stuff. I'm doing an intro to DevOps for the agile Alliance conference in

291
00:23:56,140 --> 00:24:01,520
Orlando, uh, next month. So I'm both terrified and excited because I don't know how I want to cover

292
00:24:01,520 --> 00:24:05,680
that. I need to, uh, I need, I need to go check out your, uh, it's not paralysis. What's the

293
00:24:05,680 --> 00:24:11,400
learning service that you have a, a thing in? Plural site. Yeah. Yeah. I still need to go check

294
00:24:11,400 --> 00:24:15,760
out your plural site thing. That's an overview of DevOps. If only to, uh, if only to steal some of

295
00:24:15,760 --> 00:24:21,320
the content for, for such things. Yeah. That's how we work. Well, good. Yeah. So Duncan, so let's

296
00:24:21,320 --> 00:24:26,080
talk about it. So you have a new book. Congratulations. Writing books is hard. Yeah. I have a new book.

297
00:24:26,640 --> 00:24:30,680
Yeah. So tell us about that. Why, I mean, why do this? There's lots of books out there. There's,

298
00:24:30,780 --> 00:24:34,860
I think a few on cloud foundry. So did you see some sort of like, Hey, we're not talking about this

299
00:24:34,860 --> 00:24:38,740
enough. I should write a book that explains the guts of cloud foundry. Can you kind of tell us

300
00:24:38,740 --> 00:24:44,140
where the book came from? Yeah, sure. So, um, that's interesting. So I'm not actually aware of

301
00:24:44,140 --> 00:24:48,560
another deep dive book on cloud foundry, but the other part of writing a book is it's hard. It takes

302
00:24:48,560 --> 00:24:54,060
time. So I actually started this back in 2014, if you believe, and I was working on cloud foundry,

303
00:24:54,120 --> 00:24:59,380
PCF version one. So one point, one point zero, one point one, um, implementing it for a customer.

304
00:24:59,680 --> 00:25:05,360
And we came across loads of operational, um, infrastructure type issues that no one had

305
00:25:05,360 --> 00:25:09,840
described. There's no documentation at that level. And at that time, which went into the depths of

306
00:25:09,840 --> 00:25:14,740
how you manage your routing tier, your GTMs, your LTMs and all that stuff, and how you structure for

307
00:25:14,740 --> 00:25:19,640
high availability and what your backup and restore process should be like. Over the years, we've now baked

308
00:25:19,640 --> 00:25:26,060
this into the product. But back then we just had to learn on the job. I had a hundred page document in

309
00:25:26,060 --> 00:25:30,140
word with all my notes. And I was speaking to Andrew Clay Schaefer, and we thought this would

310
00:25:30,140 --> 00:25:34,740
actually be a good idea for a book. So we reached out to O'Reilly and generally started to, or gradually

311
00:25:34,740 --> 00:25:40,680
started to convert all that material into a book. As it was a three year project, you can imagine the

312
00:25:40,680 --> 00:25:44,520
project is the product. So cloud foundry has changed a huge amount of that time.

313
00:25:46,360 --> 00:25:50,780
Right. Yeah. That's crazy. How'd you keep up with that? I mean, every time that you finished

314
00:25:50,780 --> 00:25:54,820
in that last period on a chapter, did you get new release notes and start cursing at the sun?

315
00:25:55,400 --> 00:26:00,060
Yeah. So some of it being very specific and detailed, you had to refactor. So the stuff

316
00:26:00,060 --> 00:26:05,200
on DEAs, a whole chapter on DEAs just got ripped out and replaced by Diego. Bosch has changed a huge

317
00:26:05,200 --> 00:26:09,140
amount. So refactor the Bosch chapter. But the thing with refactoring, every time you go through

318
00:26:09,140 --> 00:26:14,600
that process, you realize there are systematic patterns which you can draw from. So you start to

319
00:26:14,600 --> 00:26:19,380
abstract up. Instead of talking about a specific implementation like Conshure, you talk about

320
00:26:19,380 --> 00:26:25,280
distributed locks and internal service discovery. So by abstracting up, the general concepts stay the

321
00:26:25,280 --> 00:26:29,260
same and it doesn't really matter too much how they're implemented. So what I've tried to do with

322
00:26:29,260 --> 00:26:34,400
the book is talk around the key considerations of cloud foundry. Obviously, it goes into some depth

323
00:26:34,400 --> 00:26:39,540
around the components and the value of each component, what they do, how they interrelate. But it also

324
00:26:39,540 --> 00:26:43,860
starts to talk about the patterns, like what specific parts you need to back up and how you

325
00:26:44,020 --> 00:26:48,800
restore and how you structure for HA and DR and how you operate the platform, that sort of stuff.

326
00:26:48,800 --> 00:26:54,260
And that should hopefully be longer lived.

327
00:26:54,260 --> 00:26:57,480
I didn't realize I had this question until we were talking about like, who's the audience for it? Is it people

328
00:26:57,480 --> 00:27:03,680
operating it or people who want to know what cloud foundry is or who developed for it? But who's your... I

329
00:27:03,680 --> 00:27:07,580
probably, as always do, I always do with the Riley books, I probably shouldn't have skipped that section

330
00:27:07,580 --> 00:27:11,360
entitled, who this book is for, when I was reading through it.

331
00:27:11,360 --> 00:27:12,360
Everyone skips it every time.

332
00:27:12,360 --> 00:27:13,360
Yeah, yeah.

333
00:27:13,360 --> 00:27:24,360
It's really for the cloud operator. So thinking about working on Dino's team in PCFS, and we go and do dojos, six weeks on the ground, helping customers get stood up with cloud foundry, often bleeding into data operations.

334
00:27:24,360 --> 00:27:46,980
It's for that sort of audience. The cloud foundry operator who needs to stand up a resilient version of cloud foundry, they need to link it into their user management, they need to have a good backup and DR strategy, they need to onboard new users, new projects, they need to augment cloud foundry with additional services, they need to set the routing policies and everything else. It's that sort of operator that's really the target audience.

335
00:27:48,360 --> 00:28:03,240
No, that makes sense. Yeah. And just to confirm a little bit of what you're saying, I mean, definitely, I think, to use another book series, there certainly has been a missing manual around cloud foundry ops out there. So that's good that that's filling that in.

336
00:28:04,000 --> 00:28:18,260
Yeah, Richard, first about the space. So this is actually my second book, but really, it's the first book. And as part of this book, I wrote a couple of chapters up front positioning the value of cloud foundry. And my editor said that the technical folks, the operators aren't going to care

337
00:28:18,260 --> 00:28:43,260
care about the value and the positioning and the theory around DevOps and cloud native apps and microservices and all that good stuff, all the stuff, that space that cloud foundry plays, and so suggested taking that content out and turning it into something more digestible for the C suite, the CTO, CIO. And so I had a six month segue, where I took those two chapters and turned that into this mini book. And that was the book that was released about a year and a half ago now.

338
00:28:43,960 --> 00:28:53,320
Yeah, I think I think that's a that's a very popular book for our downloads right next to another another odyssey of a book, the cloud native Java book.

339
00:28:54,840 --> 00:29:09,080
That's right, your own book, okay, with the cloud native arc journey you've got going on there. So yeah, little books are good. Yeah, we need big books. I mean, that's, you know, this one, Duncan, you weren't probably going to write a mini book on some of these topics, we get four chapters just for Bosch.

340
00:29:09,080 --> 00:29:33,080
Yeah, so I mean, that's pretty unique stuff, right? I mean, there's the Bosch.io site, there's some other conference presentations, but there's not a whole lot of centralized information on using Bosch. Do you feel like we've tried to spend the last year, bringing Bosch down to earth for people, so they don't feel like they just have to become YAML architects to use Bosch. But, you know, was that part of your intent that you spent a good portion of the book on Bosch? Obviously, that was intentional.

341
00:29:33,080 --> 00:29:49,080
Yeah, so I was trying to have mercy on my audience. There was one chapter on Bosch, it was something like 60 pages long, it was just too much to digest. And so I broke it into discrete chapters. So it starts with an overview on the value of Bosch and what Bosch is, and then it goes into Bosch releases and Bosch deployments, and then Bosch constructs.

342
00:29:49,080 --> 00:30:05,080
So it breaks the concepts of Bosch down so that people can dip into the relevant section. But again, this has been a work in progress, right? So back in 2014, 2015, Bosch was very different. Bosch.io wasn't a thing. And the documentation around Bosch was very different.

343
00:30:05,080 --> 00:30:20,080
So I spent a long time with Dimitri walking through the documentation, walking through what we've learned in the field and trying to reconcile the two. And Dimitri and the Bosch team have done a fantastic job with Bosch 2.0, with Bosch.io and the Bosch documentation.

344
00:30:20,080 --> 00:30:28,080
So Bosch, in terms of both how it's presented and also the usability of Bosch, you know, dramatically changed over the last year or so.

345
00:30:28,080 --> 00:30:40,420
Yeah, that's great. One thing, yeah, please. So I was, you know, I've written a couple of books myself, and I realized that there's often things you appreciate more, sometimes less, I guess, when you're done about the technology you're writing about at the end.

346
00:30:40,420 --> 00:30:55,640
So when you finished this, after especially the odyssey you've been on with when you started it, was there something about CF where you went, gosh, we don't talk about this enough, or this is kind of plumbing, but really helpful stuff that maybe people don't appreciate the log regator, or they don't appreciate things like that?

347
00:30:55,680 --> 00:31:01,320
Was there anything, when you finished the book, you said, I hope people pay more attention to this component, that this actually helps them more than they realize?

348
00:31:02,440 --> 00:31:13,200
Yeah, there's a few. I mean, we were just talking Bosch is really underrated. A couple of people reached out to me on Twitter and said, you know, Bosch isn't actually part of the Cloud Foundry Foundation, you know, back in the day, and therefore I shouldn't put it in the book.

349
00:31:13,200 --> 00:31:19,960
And I think it's such an intrinsic part of Cloud Foundry. It makes Cloud Foundry on the operational side just second to none.

350
00:31:19,960 --> 00:31:29,720
And for me, it's really front and center. So I felt it vital to talk about Bosch. Other things, people just, there's tons of confusion around containers and Docker and build packs.

351
00:31:29,720 --> 00:31:49,360
And so spending some time with Ben Hale on build packs and Jules on Docker and Glenn Normington and all those folks, just exploring the trade-offs between Docker and containers and build packs, and when you should use an image versus just pushing a raw artifact, that was actually very impactful for me to get that talk track down and then explain it to other people.

352
00:31:49,360 --> 00:32:00,880
Other things like routing, what Cloud Foundry does at the routing layer, I think is really cool looking at all the routing services that have come into play and just understanding more about the routing mechanisms is very impactful.

353
00:32:00,880 --> 00:32:08,440
I started to go into a lot of depth on the UAA. So again, the UAA becomes really important as well, especially for people who want to integrate with their existing user stores.

354
00:32:09,320 --> 00:32:18,200
Yeah, I mean, you just teased it, right? But do you have, for our listeners, kind of that take on build pack versus that more container image centric way of pushing applications?

355
00:32:18,400 --> 00:32:23,820
Do people should have rules of thumb? Is there all or nothing or scenarios where you should favor one or the other?

356
00:32:24,440 --> 00:32:31,040
Yeah, there's definitely times when one works better than another. So the key thing to note is that Cloud Foundry supports both.

357
00:32:31,040 --> 00:32:41,100
Like in the general marketplace, a lot of people, I still think, see Cloud Foundry as not or anti-Docker and not supporting Docker, whereas actually we supported Docker images for some time with Diego.

358
00:32:41,740 --> 00:32:47,160
I've worked with a customer recently where just building their complicated application on the fly.

359
00:32:47,160 --> 00:32:53,400
So it was a PHP app with a Perl module and something else in there. Just trying to compile that on the fly was really difficult.

360
00:32:53,540 --> 00:32:58,800
So Dockerizing that application made it far quicker just to get on to Cloud Foundry to then refactor.

361
00:32:59,520 --> 00:33:08,580
But by and large, if you can have a smaller footprint you actually deploy, if you just take your application artifact, push it to Cloud Foundry and let Cloud Foundry containerize that for you,

362
00:33:08,780 --> 00:33:14,820
there's really less surface area to deal with, there's less concern for the developer, there's less security scanning that needs to go on.

363
00:33:14,820 --> 00:33:19,340
So it's a more streamlined process overall if you can get away just pushing the application artifact.

364
00:33:20,940 --> 00:33:29,620
So speaking of, there's a weird connection to like paying attention to the grumpy people and the register comments.

365
00:33:30,260 --> 00:33:38,500
But, and at the danger of, I mean, hopefully this won't turn into too much of the usual like, you know, pivotal hyping stuff, despite this being our podcast.

366
00:33:38,620 --> 00:33:52,680
But like, I often think that, um, so, so there's a lot of discussion in the cloud native area and it feels like a lot of it is sort of like talking about what's under the hood of various container orchestration things out there.

367
00:33:53,140 --> 00:34:01,640
And oddly, the, the sort of like simplicity that Cloud Foundry tries to bring, um, to running your own applications.

368
00:34:01,640 --> 00:34:14,540
Like in the first part of your book, you know, you spend a lot of time basically saying like, we try to make it so you never have to open the hood essentially, or, or, you know, you don't have to change the oil every time you go out to drive to use that metaphor.

369
00:34:15,080 --> 00:34:25,440
Um, and there's a weird, like kind of to Ian's point, like, it feels like there's a weird marketing disadvantage where there's just sort of like, you don't need to worry about those things.

370
00:34:25,440 --> 00:34:26,980
So stop worrying about them.

371
00:34:26,980 --> 00:34:34,480
Um, and then everyone in the register comments is like, but I like worrying about those things and yeah, that's, that is the thing, right?

372
00:34:34,560 --> 00:34:43,280
So a lot of, uh, you know, it operators and engineers enjoy playing around with the nuts and bolts and we make it really easy to do the right thing.

373
00:34:43,280 --> 00:34:46,400
So by using a platform, the developers can just come along and push.

374
00:34:46,520 --> 00:34:48,660
They don't have to worry about all this operational overhead.

375
00:34:48,820 --> 00:34:54,880
So my experience is often the developers are crying out for something like Cloud Foundry or if not pivotal Cloud Foundry,

376
00:34:55,060 --> 00:35:01,580
but it's the operators who want to push back and say, look, we actually want to build the stuff ourselves because it gives us job security and it's more fun.

377
00:35:02,120 --> 00:35:02,480
Yeah.

378
00:35:02,640 --> 00:35:09,160
And, and, and, and it seems like a lot of what's going on in your book is, is almost like filling in all that stuff.

379
00:35:09,580 --> 00:35:15,180
Like, like, like, and, and it'd be interesting to hear like, like, like ongoing, like, uh, how, how you approach this as well.

380
00:35:15,180 --> 00:35:21,360
But there's almost like, uh, to use Google SRE terms, there's a, there's this black box, right?

381
00:35:21,360 --> 00:35:29,580
Like the way, the way you could think about something like Cloud Foundry is like, it's this black box that I don't really need to worry about its internals and how it operates.

382
00:35:29,780 --> 00:35:31,180
I just should use it.

383
00:35:31,440 --> 00:35:44,080
And it's almost like a little bit like, uh, I haven't finished reading your book self admittedly, but, but there, there's to some extent what, what your book's doing and having so many chapters on Bosch is like, well, let's make it kind of like a translucent box.

384
00:35:44,120 --> 00:36:03,940
Like if you're really interested in all the internals and how you can muck about in there, you can go free, you can feel free to go do that, or you can just keep treating it like a black box, which I think is why it feels like it's starting to fill in that middle part of like, I don't know if you're, if you're obsessed with like how all these little wing dings and everything works, like you can get in there and wing ding yourself as much as you want.

385
00:36:04,780 --> 00:36:05,100
Yeah.

386
00:36:05,100 --> 00:36:13,860
And I thought that was one of the interesting things, Duncan and Coté about the book was on one hand, I mean, go back to the SRE book, arguably Cloud Foundry tries to eliminate toil, right?

387
00:36:13,860 --> 00:36:19,880
I'm trying to get rid of the dumb undifferentiated work that SLOG wears me down and Cloud Foundry takes care of a lot of that.

388
00:36:19,960 --> 00:36:24,660
But what you pointed out, Duncan, in the book was things like HA, which, you know what, robots don't set that up for me.

389
00:36:24,720 --> 00:36:30,160
I have to think about an HA strategy and maybe robots do some failover, but I have to think about architecture.

390
00:36:30,420 --> 00:36:32,700
I have to think about how I deploy this and that's good.

391
00:36:32,740 --> 00:36:36,300
And that's good sysadmin, you know, infrastructure ops mindset.

392
00:36:36,560 --> 00:36:43,220
And then the machine just runs in a lot of cases, but there's, I think you did a good job of pointing out where do you need to come in and fiddle?

393
00:36:43,600 --> 00:36:44,780
Is that a good thing?

394
00:36:45,000 --> 00:36:46,720
Where do operators have some benefit?

395
00:36:46,920 --> 00:36:48,180
That's the whole thing with Cloud Foundry.

396
00:36:48,260 --> 00:36:51,360
It doesn't eliminate the operator need and it doesn't actually remove that fun.

397
00:36:51,420 --> 00:36:52,680
It just raises the value a lot.

398
00:36:53,340 --> 00:36:55,720
So you're not tinkering around with things like container orchestration.

399
00:36:55,840 --> 00:36:57,500
You let the platform do what it does best.

400
00:36:57,940 --> 00:36:59,940
You're not dealing with endless log aggregation.

401
00:37:00,060 --> 00:37:06,240
You're just piping it out into, you know, a centralized repository for all your logs and you can focus on that more high value thing.

402
00:37:06,320 --> 00:37:14,600
So how do you truly get active active and how you synchronize the data and how you set up your users for that and how you expose all this back end services and how you migrate some of those legacy apps.

403
00:37:15,320 --> 00:37:21,400
Off really expensive, unsupported middleware onto a unified platform, which is fully open source and fully supported.

404
00:37:22,180 --> 00:37:23,480
And so it just raises the bar.

405
00:37:23,580 --> 00:37:25,500
It means the operators still do tons of cool stuff.

406
00:37:25,580 --> 00:37:27,060
They just focus on something that's high value.

407
00:37:27,680 --> 00:37:28,280
Yeah, a lot more fun.

408
00:37:28,380 --> 00:37:29,740
I mean, and you'll have the same thing.

409
00:37:29,840 --> 00:37:36,740
I know some people can say, well, you know, these sort of run yourself software platforms are going to give way at some point to just a pure play public cloud.

410
00:37:36,860 --> 00:37:43,620
Like, why would you build and run your own platform, even if it's Cloud Foundry, when I can just use fill in the blank from a public cloud provider?

411
00:37:43,620 --> 00:37:51,240
But I think, again, to your point, many of those things you just listed out, setting up HA strategies, doing data replication, figuring out how you do app migration.

412
00:37:51,240 --> 00:37:59,220
That is identical, regardless of where you're doing it, and Cloud Foundry does give you some flexibility of where you're running that and a consistent experience everywhere.

413
00:37:59,420 --> 00:38:08,340
So these are universal problems, but luckily we're trying to all raise our gaze to things that matter a lot more than, you know, tweaking registry settings on a Windows box.

414
00:38:09,200 --> 00:38:17,220
And Coté, to your point, having some visibility into how things like Diego works and how containers work is important because if things go wrong, you need to be able to debug.

415
00:38:17,360 --> 00:38:18,980
You need to understand the flows of communication.

416
00:38:18,980 --> 00:38:23,680
You need to know what to look at, how the networks are configured, what components calling out to what component.

417
00:38:23,960 --> 00:38:27,740
And by having an appreciation of that, it really helps with the troubleshooting.

418
00:38:27,900 --> 00:38:37,840
So my aim about exposing some of those internals around Diego, and there's a big 50-page chapter on how Diego works, is to really help the operator go in very deep, very quickly if they need to then do some troubleshooting.

419
00:38:38,320 --> 00:38:40,200
Yeah, no, I mean, that's good.

420
00:38:40,340 --> 00:38:48,700
And it comes through in even the scant sections I read is, I think to phrase what you're saying another way.

421
00:38:48,980 --> 00:39:00,500
And weaving in my experience with talking with resistive ops people is they need some way to build up trust in, as we would say, the platform or trust in the new technology.

422
00:39:01,500 --> 00:39:14,580
And they need to do that even before they get to the point where they're learning the new things, or at least translating their old way of thinking, their current way of thinking about how they manage IT to a new way.

423
00:39:14,580 --> 00:39:34,260
And as an example, I thought the, you know, you have, you kind of have this brief discussion of how, what application instances are, AIs are, and how they're a different way of thinking about things than a server, you know, on a server-based thing or whatever, and, or a socket or even a VM, and why we would think about things in that way.

424
00:39:34,260 --> 00:39:42,000
And this comes up a lot going back to sales organization and pricing, because we price things based on AIs, which befuddles people a lot initially.

425
00:39:42,680 --> 00:39:51,560
But it does seem like they're at the ops level, like once you build up trust in the system, because it's not a black box, then you can kind of understand how the components move.

426
00:39:51,660 --> 00:39:55,140
And then that gets to, you know, to kind of switch a little bit.

427
00:39:55,560 --> 00:40:10,420
I mean, something that, that, that I'm kind of realizing as we're talking about it is, is a lot of above the value line ops wise is more managing the distributed applications, your, your, your organization's running than really managing the infrastructure it all runs on.

428
00:40:10,620 --> 00:40:20,120
And it seems like, I don't know, I mean, if that framing is good, that seems like a framing that, that to push people towards more is like, as you all are both saying, like, you're still doing a lot of operation stuff.

429
00:40:20,420 --> 00:40:32,440
You're just not managing infrastructure, you still have to come up with the way that you're going to have high availability and the way you're going to recover from failure and the policies that you need to have, like, you know, resilience and all of that stuff.

430
00:40:32,440 --> 00:40:35,980
You're just not really worrying about like, storage so much.

431
00:40:36,160 --> 00:40:40,600
I mean, there is kind of worrying of that, but you're more worrying about all the services that you're pulling together.

432
00:40:41,180 --> 00:40:53,860
And kind of from a developer perspective, you're, the operations people are sort of like taking some of those responsibilities that developers maybe used to worry about because they were way up in developer land.

433
00:40:54,320 --> 00:41:02,160
And instead doing that work probably better than most run-of-the-mill developers could do if they're actually planning out and managing services for them.

434
00:41:03,500 --> 00:41:06,000
Yeah, and Tony Hansman's got this line, get your business back.

435
00:41:06,120 --> 00:41:08,980
And that's absolutely pertinent for the developers and the lines of business.

436
00:41:09,120 --> 00:41:19,000
If they can just focus on their business instead of curating Docker images and understanding how container orchestration works and dealing with all the low-level concerns, they just focus on their business logic.

437
00:41:19,180 --> 00:41:22,540
The lines of business, the business owner really can move with high velocity.

438
00:41:22,540 --> 00:41:34,700
And then it should be more fun for the developer as well because they're developing meaningful business code at that point and making a direct, tangible difference to the business rather than just dealing with middleware and container orchestration concerns and the like.

439
00:41:35,480 --> 00:41:41,240
Yeah, now you mentioned, you know, if someone could read that book and go through and go, gosh, this all seems big and complicated.

440
00:41:41,520 --> 00:41:42,940
Like, there's just a lot of moving pieces.

441
00:41:43,080 --> 00:41:43,720
This thing's a beast.

442
00:41:44,120 --> 00:41:46,400
And on one hand, you could say, well, sure, it's a platform.

443
00:41:46,580 --> 00:41:51,020
I mean, you don't necessarily learn how Amazon works just by point and clicking on your first try.

444
00:41:51,020 --> 00:41:54,320
Like, there's a bunch of subsystems you have to think about, monitoring, whatever.

445
00:41:54,880 --> 00:41:57,580
So, sure, Cloud Foundry is a lot of things going on.

446
00:41:58,020 --> 00:42:02,480
How do developers then not look at this as, I have to learn a whole lot of stuff to use this?

447
00:42:02,540 --> 00:42:03,980
I mean, kind of that dev experience.

448
00:42:04,100 --> 00:42:11,680
How do you encourage people to start using the platform and not, you know, as you say, you can treat this like a black box if you want to or you can pull back the curtains.

449
00:42:11,900 --> 00:42:14,020
As a developer, though, how does this not feel intimidating?

450
00:42:14,780 --> 00:42:15,960
That's a really good question.

451
00:42:16,160 --> 00:42:17,420
I've tried to address that up front.

452
00:42:17,420 --> 00:42:21,560
So, the book is very explicitly not for developers, and I'll talk about this in a preface.

453
00:42:21,700 --> 00:42:27,460
It's really for the Cloud Foundry operator, the person who stands up Cloud Foundry and is responsible for all those data operations.

454
00:42:28,120 --> 00:42:33,100
And that means, as a developer, you're really free to understand the interaction with the platform.

455
00:42:33,280 --> 00:42:34,320
So, things like CF push.

456
00:42:34,400 --> 00:42:35,640
How do I push my application?

457
00:42:36,400 --> 00:42:38,400
How are environment variables exposed?

458
00:42:38,680 --> 00:42:40,180
How do I get access to my logs?

459
00:42:40,240 --> 00:42:41,260
How do I bind to services?

460
00:42:41,820 --> 00:42:45,460
And the footprint and the area to understand there is really very small.

461
00:42:45,460 --> 00:42:50,640
And so, my view is the developer experience when using Cloud Foundry is very, very quick.

462
00:42:51,140 --> 00:42:52,840
And we expedite that with a couple of things.

463
00:42:53,020 --> 00:42:57,720
We obviously have Pivotal Web Services where they can sign up and get some familiarity using Cloud Foundry.

464
00:42:58,080 --> 00:43:07,020
There's also Bosch Lite where they can stand up like a local version of Cloud Foundry if they want to, or they have PCF Dev where they can just download a vagrant image of Pivotal Cloud Foundry and get going.

465
00:43:07,460 --> 00:43:12,520
So, from the dev experience, hopefully, we've done a great job making that very, very easy.

466
00:43:12,960 --> 00:43:21,520
For the operator, to your point that Cloud Foundry comes across big, scary, complicated, we can't hide the fact that it is a complicated distributed system.

467
00:43:21,900 --> 00:43:35,140
But when I look at how we've broken Cloud Foundry into a set of subsystems and CF deployment, which is the new way Cloud Foundry is all packaged up, has done a great job breaking everything into isolated components rather than this big monolithic release.

468
00:43:35,560 --> 00:43:40,080
So, now you have a separate UAA, you have a separate Diego release, and, you know, everything's componentized.

469
00:43:40,580 --> 00:43:47,520
We've done a great job defining very clear boundaries, very clear flows of interaction between these subsystems.

470
00:43:48,020 --> 00:43:56,820
And so, for someone like an operator coming in cold, you can start at a high level understanding each discrete subsystem at a high level and how they interact.

471
00:43:57,280 --> 00:44:02,580
Then you have the freedom to dig into logging in isolation or Diego into isolation or UAA or routing.

472
00:44:03,200 --> 00:44:07,240
And you can pick and choose the areas of Cloud Foundry which you want to focus on.

473
00:44:10,680 --> 00:44:11,040
Awesome.

474
00:44:11,040 --> 00:44:21,700
So, one of the other things that you mentioned in there, and we talk a lot about in Cloud Foundry land, but it's, you know, I don't think we use the word contracts as much anymore between the layers because sometimes it has a legalistic sense.

475
00:44:21,820 --> 00:44:29,800
But that there's kind of expectations between different layers of the components that we do have an opinion that does get put on how you should build apps and things like that.

476
00:44:29,880 --> 00:44:37,180
So, you know, as you talked about in the book and as you think about Cloud Foundry in general, are opinions a bad thing?

477
00:44:37,300 --> 00:44:38,520
When are they a good thing?

478
00:44:38,640 --> 00:44:43,260
You know, how is that in favor of a developer or an operator when they're thinking of building and running systems like this?

479
00:44:44,340 --> 00:44:46,160
I think opinions is a really good thing.

480
00:44:46,160 --> 00:44:51,600
Cloud Foundry is definitely a structured, opinionated platform, and we have strong opinions on how you should do software delivery.

481
00:44:51,740 --> 00:44:56,000
I mean, Pivotal as a whole is transforming the way the world builds software, and you cannot do that without strong opinions.

482
00:44:56,640 --> 00:45:01,140
But the beauty of Cloud Foundry is that it's not just opinionated, it's also open.

483
00:45:01,580 --> 00:45:04,220
And so it leaves choice at the right areas.

484
00:45:04,220 --> 00:45:09,020
So we talked earlier, you have the choice to use Docker where you can push your application artifact.

485
00:45:09,620 --> 00:45:10,920
You have choice on service brokers.

486
00:45:11,120 --> 00:45:13,380
You have choice on which cloud provider you deploy to.

487
00:45:13,900 --> 00:45:16,400
You have choice on how you structure HA.

488
00:45:16,600 --> 00:45:20,140
So there are a number of critical decisions which we still have strong opinions on.

489
00:45:20,380 --> 00:45:24,640
Both the platform and platform architecture teams have strong opinions on these.

490
00:45:24,760 --> 00:45:27,380
But we also leave flexibility where it matters to the customer.

491
00:45:29,420 --> 00:45:36,040
Well, I think as a last question, so what's your favorite part of the book?

492
00:45:36,700 --> 00:45:38,900
Is there some part that you're like, oh, this part's great?

493
00:45:38,980 --> 00:45:39,540
Like, you know me.

494
00:45:40,220 --> 00:45:45,700
Maybe you don't, but I'm always trying to put stupid jokes in and allusions to things that I'm pretty sure only I do.

495
00:45:45,700 --> 00:45:52,400
But you got any, like, fun Easter eggs or just some favorite part where you're like, man, I really nailed how that creepy clam works.

496
00:45:52,760 --> 00:45:54,780
Like, what are you most proud of in there?

497
00:45:55,360 --> 00:46:01,420
Some of the stuff, like the really deep guts I had to remove because the book was just getting ridiculous in length.

498
00:46:01,620 --> 00:46:05,700
In terms of what's still in the book, in my favorite part, I like the ending, the what's next, the roadmap.

499
00:46:05,900 --> 00:46:11,600
I spent some time with Yui and a number of other people in engineering talking about some of the possibilities of Cloud Foundry.

500
00:46:11,940 --> 00:46:16,960
And when you look at the progression of Cloud Foundry from 2014 to now, you can see how far it's come.

501
00:46:17,460 --> 00:46:21,580
But you can also see what's on the horizon and some of the things which may be coming down the pipeline.

502
00:46:21,720 --> 00:46:23,520
Isolation zones are something that's come recently.

503
00:46:24,000 --> 00:46:27,180
But there's a load of other stuff that Cloud Foundry could start to stray into.

504
00:46:27,880 --> 00:46:29,440
And that's really exciting for me.

505
00:46:30,500 --> 00:46:30,720
All right.

506
00:46:30,780 --> 00:46:31,720
Well, thanks for being on.

507
00:46:31,880 --> 00:46:36,300
What's the best way to, like, for people to get a copy of the book?

508
00:46:36,500 --> 00:46:38,220
I mean, just, like, all the usual things?

509
00:46:38,280 --> 00:46:39,580
Or is there something that's better than that?

510
00:46:39,980 --> 00:46:42,720
Do you get some, like, bonus material if you go somewhere else?

511
00:46:44,000 --> 00:46:45,120
There's no bonus material.

512
00:46:45,300 --> 00:46:48,080
So O'Reilly are actually sunsetting their direct distribution.

513
00:46:48,080 --> 00:46:51,000
So I think if you want a copy of the book, there's some on Pivotal Store.

514
00:46:51,520 --> 00:46:55,500
So if you're on Pivotal, you can get some from there or Amazon.com.

515
00:46:55,960 --> 00:46:56,140
Yeah.

516
00:46:56,360 --> 00:46:56,560
Yeah.

517
00:46:56,560 --> 00:46:57,420
I started reading it.

518
00:46:57,740 --> 00:47:02,160
I don't know if we still do this, but I, for some reason, have some Safari subscription through Pivotal.

519
00:47:02,380 --> 00:47:03,200
So I was just reading it through there.

520
00:47:03,200 --> 00:47:03,760
Yeah, you can get on Safari.

521
00:47:04,300 --> 00:47:05,840
So O'Reilly is a safari where you can get it from.

522
00:47:05,920 --> 00:47:06,020
Yeah.

523
00:47:06,260 --> 00:47:06,520
Yeah.

524
00:47:06,580 --> 00:47:06,940
Yeah.

525
00:47:07,200 --> 00:47:07,520
All right.

526
00:47:07,580 --> 00:47:08,480
Well, thanks for being on.

527
00:47:08,620 --> 00:47:09,220
That was good stuff.

528
00:47:09,260 --> 00:47:13,280
We'll put a link to the book, Cloud Foundry, colon, the definitive guide.

529
00:47:13,540 --> 00:47:13,740
Right.

530
00:47:14,120 --> 00:47:15,840
And, you know, you can look it up.

531
00:47:15,840 --> 00:47:20,580
But it is, I think, you know, you got the little Cloud Foundry book that we talked about earlier.

532
00:47:21,080 --> 00:47:23,440
We always give that one out at conferences a lot.

533
00:47:23,560 --> 00:47:29,900
And that's the one I always recommend to people if they don't really know what all is going on in the Pivotal Cloud native area.

534
00:47:30,460 --> 00:47:36,020
As you were saying, it's a good overview of, like, why you would care about all of this stuff in a digestible form.

535
00:47:36,660 --> 00:47:44,200
So, also, if people want to follow, you know, not only the book, but if they want to putter around with you on the internet, you got a Twitter account or anything like that?

536
00:47:44,960 --> 00:47:45,240
Yeah.

537
00:47:45,400 --> 00:47:46,420
Where can they find you?

538
00:47:47,360 --> 00:47:49,420
So, yeah, just go to Don't Win and see me on Twitter.

539
00:47:50,080 --> 00:47:50,420
All right.

540
00:47:50,900 --> 00:47:51,960
That's two N's, right?

541
00:47:52,160 --> 00:47:52,740
I got that right?

542
00:47:53,180 --> 00:47:53,300
Yeah.

543
00:47:53,380 --> 00:47:54,300
W-R-N-N.

544
00:47:54,500 --> 00:47:55,000
There you go.

545
00:47:55,400 --> 00:47:55,720
All right.

546
00:47:55,800 --> 00:47:59,300
Well, as always, thanks for listening to Pivotal Conversations.

547
00:47:59,800 --> 00:48:01,640
We'll be back next week with something.

548
00:48:01,780 --> 00:48:14,580
If you want to find the most recent episodes, the RSS feed to listen to, and I guess the most unrecent episodes, all the old ones, the best place to go is soundcloud.com slash Pivotal Conversations with no space or underbar.

549
00:48:15,020 --> 00:48:16,660
We've got all sorts of fun stuff there.

550
00:48:16,900 --> 00:48:21,480
You know, we've alluded to a couple episodes, like the one about cloud native ops last week.

551
00:48:21,920 --> 00:48:30,060
There's some from actual customers like Allstate and others talking about their experience using all of this stuff and just changing how their organization does in general.

552
00:48:30,060 --> 00:48:36,660
You can also find how to subscribe to it if you go into iTunes or Overcast or whatever Stitcher is, all these places.

553
00:48:37,040 --> 00:48:38,660
That's always the best thing to do is subscribe.

554
00:48:39,160 --> 00:48:47,700
And if you have the time, it's always good to go write a little review in iTunes or, even better, just refer to your friends or other people who you think might be interested in it.

555
00:48:47,760 --> 00:48:50,900
You can email us at podcast at pivotal.io.

556
00:48:51,120 --> 00:48:54,440
And if someone wanted to see you on Twitter, Richard, where would they go?

557
00:48:55,520 --> 00:48:59,360
You can always find me at rseroter on the Twitters.

558
00:48:59,580 --> 00:48:59,980
That's right.

559
00:49:00,040 --> 00:49:09,660
And it's a very good real-time feed of all the interesting news that I haven't found yet and we'll find about next week when I hurriedly do some prep and read through the show notes.

560
00:49:10,140 --> 00:49:13,160
So I'm in Twitter as Coté, just C-O-T-E.

561
00:49:13,320 --> 00:49:14,960
And we'll see everyone next time.

562
00:49:15,160 --> 00:49:15,680
Bye-bye.