1
00:00:00,640 --> 00:00:05,520
Welcome to a special episode of the Cloud Native in 15 Minutes podcast, where over the

2
00:00:05,520 --> 00:00:08,920
extended holiday season, we'll be sharing some of the highlights from the show's first

3
00:00:08,920 --> 00:00:09,640
six months.

4
00:00:10,240 --> 00:00:14,800
I'm Derek Harris from Pivotal, and if you follow the show on the Intersect site, Pivotal.io

5
00:00:14,800 --> 00:00:18,780
slash intersect, you know I put together a blog post for every episode where I pull some

6
00:00:18,780 --> 00:00:20,400
of my favorite excerpts from the interview.

7
00:00:20,880 --> 00:00:24,700
What you might not realize, however, is that those quotes are quite often condensed and

8
00:00:24,700 --> 00:00:25,540
edited for clarity.

9
00:00:25,720 --> 00:00:30,040
And so what I want to do here is provide those same quotes with a little more context

10
00:00:30,040 --> 00:00:33,160
and more flavor, more audio flavor of the actual conversation.

11
00:00:33,500 --> 00:00:38,460
This first best of episode features highlights regarding cloud native application architectures

12
00:00:38,460 --> 00:00:44,200
and development and specific technologies ranging from Kafka to Kubernetes to SQL, and it features

13
00:00:44,200 --> 00:00:50,020
some of the co-founders or creators of Kubernetes, Kafka, MongoDB, CockroachDB, and Snyk, as

14
00:00:50,020 --> 00:00:53,140
well as Pivotal's own cloud native expert, Cornelia Davis.

15
00:00:53,480 --> 00:00:57,580
And I should note that I omitted some highlights in the name of keeping this episode at least

16
00:00:57,580 --> 00:01:03,520
in the ballpark of 15 minutes, but the TLDR version is that enterprises are very interested

17
00:01:03,520 --> 00:01:06,380
in running seemingly everything on top of Kubernetes.

18
00:01:06,540 --> 00:01:10,060
So everything we talked about here, people want to run on top of Kubernetes.

19
00:01:10,600 --> 00:01:15,280
And one quick reminder before we get into the highlights, if you enjoy the podcast, please

20
00:01:15,280 --> 00:01:20,000
share it with your friends or family or more likely colleagues and rate it in the app or

21
00:01:20,000 --> 00:01:21,340
platform of your choice.

22
00:01:21,560 --> 00:01:22,000
Thank you.

23
00:01:22,220 --> 00:01:27,220
Up first, we have Neha Narcady, the co-founder and CTO of Confluent and one of the creators

24
00:01:27,220 --> 00:01:32,080
of Apache Kafka during her tenure at LinkedIn, explaining how Kafka relates to any number

25
00:01:32,080 --> 00:01:37,460
of other cloud native technologies, including microservices, IoT, and even the public cloud.

26
00:01:38,620 --> 00:01:39,840
Yeah, that's a great question, Derek.

27
00:01:39,900 --> 00:01:44,680
In fact, you know, I somehow think that we're getting to experience a really interesting period

28
00:01:44,680 --> 00:01:49,980
in technology where there are several really significant paradigm shifts playing out all

29
00:01:49,980 --> 00:01:50,980
at the same time, right?

30
00:01:51,040 --> 00:01:54,100
And that's happening because companies are digitizing themselves.

31
00:01:54,340 --> 00:01:55,520
You mentioned a few, right?

32
00:01:55,880 --> 00:02:01,140
Be it adoption of the public cloud or breaking the monolith into microservices, the rise of

33
00:02:01,140 --> 00:02:07,740
mobile first real-time customer experiences, internet of things, or the move from batch to real-time.

34
00:02:07,840 --> 00:02:13,280
The most interesting thing about Kafka, and I think the reason for its steep rise in adoption,

35
00:02:13,280 --> 00:02:17,860
is that it is the common thread that enables all of those paradigm shifts.

36
00:02:17,860 --> 00:02:21,120
You know, it is the new backbone for event-driven microservices.

37
00:02:21,500 --> 00:02:25,320
The MQs don't scale, and the databases weren't built for streaming data.

38
00:02:26,060 --> 00:02:28,140
Kafka is the bridge to the public cloud, right?

39
00:02:28,180 --> 00:02:32,220
A lot of folks use it to stream data across on-prem and cloud environments.

40
00:02:32,860 --> 00:02:38,000
It obviously enables real-time data transfer, and that helps while building IoT applications.

41
00:02:38,660 --> 00:02:43,120
But really, it is the new foundation for all data in a company, giving them a full picture

42
00:02:43,120 --> 00:02:49,720
of not just historical data, which they already had, but that as well as visibility into events

43
00:02:49,720 --> 00:02:53,420
taking place in real-time and how that is changing the historical data.

44
00:02:53,800 --> 00:02:58,980
That's really, I think, the key reason why event streaming is being picked up by the Fortune

45
00:02:58,980 --> 00:03:03,000
100 companies, and Kafka is becoming the foundation of their data.

46
00:03:03,500 --> 00:03:09,360
And here is Neha explaining event streaming and why that is becoming such a popular architecture.

47
00:03:10,320 --> 00:03:14,700
Yeah, I think, you know, historically, there were two main data hubs for a company.

48
00:03:15,300 --> 00:03:21,420
For transactional data, you had the databases, and for analytics, you had the data warehouse,

49
00:03:22,000 --> 00:03:22,180
right?

50
00:03:22,280 --> 00:03:28,140
So, you know, that really sufficed when technology was, you know, one of the key things that a

51
00:03:28,140 --> 00:03:29,020
company did.

52
00:03:29,420 --> 00:03:35,080
But now that every company sees themselves as a technology and a data company, you really

53
00:03:35,080 --> 00:03:38,980
have to take a new look at how data is treated in a company, right?

54
00:03:39,060 --> 00:03:44,540
So it's no longer treated as, you know, just something that goes to rest and is queried when

55
00:03:44,540 --> 00:03:45,060
you need it.

56
00:03:45,060 --> 00:03:50,480
It actually needs to be treated as, you know, streams of information as they happen in the

57
00:03:50,480 --> 00:03:54,680
real world that can be studied and reacted to as that happens, right?

58
00:03:54,820 --> 00:03:58,960
So if you look at databases and warehouses, they were actually not built for streams of

59
00:03:58,960 --> 00:03:59,380
information.

60
00:03:59,380 --> 00:04:01,840
They were built for data that goes to rest.

61
00:04:02,080 --> 00:04:06,980
And that's really the fundamental change in the event streaming architecture is the ability

62
00:04:06,980 --> 00:04:11,780
to store, process, move data as it arrives as streams of information.

63
00:04:12,100 --> 00:04:17,260
And that really requires a new foundation, you know, a continuous commit log and the ability

64
00:04:17,260 --> 00:04:18,900
to do stream processing.

65
00:04:20,360 --> 00:04:25,520
Up next, we have Joe Beda, one of the creators of Kubernetes during his time at Google and

66
00:04:25,520 --> 00:04:30,980
now a principal engineer at VMware, explaining in his mind, the difference between cloud computing

67
00:04:30,980 --> 00:04:32,840
and cloud native computing.

68
00:04:33,300 --> 00:04:37,260
I think it's helpful here to tease apart like cloud versus cloud native.

69
00:04:37,480 --> 00:04:42,540
In my mind, cloud is running on somebody else's infrastructure, or at least something that

70
00:04:42,540 --> 00:04:45,540
somebody else is managing for you in sort of private versus public cloud.

71
00:04:45,860 --> 00:04:48,760
But as a user, you're like, I'm not worrying about the nitty gritty details.

72
00:04:49,320 --> 00:04:55,580
Generally, it's about API driven, self-service in that you don't have to talk to anybody.

73
00:04:55,780 --> 00:04:58,820
I like to call public cloud, not talking to a sales guy as a service.

74
00:05:00,000 --> 00:05:04,100
And then it's a last thing, meaning that, you know, there's a lot of room to essentially

75
00:05:04,100 --> 00:05:08,040
bring new techniques because you can have infrastructure on demand.

76
00:05:08,560 --> 00:05:09,180
So that's cloud.

77
00:05:10,400 --> 00:05:13,520
Cloud native in my mind then is what are the techniques?

78
00:05:13,660 --> 00:05:14,480
What is the structure?

79
00:05:14,680 --> 00:05:19,300
What is the set of tools that you use so that you can take the best advantage of?

80
00:05:19,320 --> 00:05:27,800
How do you actually take those new capabilities that cloud offers and, you know, apply those

81
00:05:27,800 --> 00:05:32,500
to your organization and then take that to the fullest extent that makes sense over time?

82
00:05:32,660 --> 00:05:32,760
Right.

83
00:05:32,820 --> 00:05:34,140
So that, I think, is cloud native.

84
00:05:34,260 --> 00:05:39,480
And so you see a lot of big companies, you know, I'm using air quotes here, move to cloud

85
00:05:39,480 --> 00:05:43,660
and they'll spend millions of dollars and like months and months or years of time.

86
00:05:43,660 --> 00:05:47,520
And then they'll get the whole thing done and they'll be like, how come we didn't magically

87
00:05:47,520 --> 00:05:48,520
turn into Netflix?

88
00:05:49,040 --> 00:05:49,160
Right.

89
00:05:49,220 --> 00:05:51,000
Which is like the poster child for Amazon.

90
00:05:51,360 --> 00:05:51,460
Right.

91
00:05:51,480 --> 00:05:55,700
And the reason being is that they are physically running on cloud, but they haven't actually

92
00:05:55,700 --> 00:05:58,020
changed their practices, changed the way they do stuff.

93
00:05:58,060 --> 00:06:02,460
So they brought all their old sort of processes, their old ways of doing things, and they're just

94
00:06:02,460 --> 00:06:03,940
now running on somebody else's computers.

95
00:06:04,140 --> 00:06:09,820
And here's Joe again, this time responding to my statement that organizations who aren't

96
00:06:09,820 --> 00:06:15,860
familiar with Kubernetes and cloud native development risk cutting themselves on sharp edges using

97
00:06:15,860 --> 00:06:17,840
pure open source Kubernetes.

98
00:06:18,580 --> 00:06:19,820
Well, I think that's true.

99
00:06:19,920 --> 00:06:26,160
But also the flexibility of Kubernetes means that they can, they don't have to be purists.

100
00:06:26,500 --> 00:06:30,800
There's room to compromise as they look to adapt their old stuff into their new stuff.

101
00:06:30,800 --> 00:06:31,040
Right.

102
00:06:31,080 --> 00:06:36,780
Like, you know, we have a very large financial services company and they had a sort of home

103
00:06:36,780 --> 00:06:41,060
built big data ish sort of batch processing system.

104
00:06:41,320 --> 00:06:46,060
They're looking to move that stuff to Kubernetes, but there's a lot of roadblocks if they were

105
00:06:46,060 --> 00:06:48,600
going to go to a sort of purist type of route to this.

106
00:06:48,680 --> 00:06:52,980
But the flexibility of Kubernetes means that they can, they can start getting used to it.

107
00:06:52,980 --> 00:06:58,000
They can start moving forward without having to necessarily, you know, rip and replace

108
00:06:58,000 --> 00:06:59,080
everything that they've been doing.

109
00:07:00,340 --> 00:07:08,000
And next we have Elliot Horowitz, the co-founder and CTO of MongoDB explaining why it is that

110
00:07:08,000 --> 00:07:13,820
organizations or developers choose MongoDB and frankly choose non-relational databases in

111
00:07:13,820 --> 00:07:14,100
general.

112
00:07:14,580 --> 00:07:17,100
I think, you know, I think it comes down to a few things.

113
00:07:18,240 --> 00:07:24,300
One is there's a lot of places where, you know, the data model for an application just doesn't

114
00:07:24,300 --> 00:07:25,900
fit into a relational data model.

115
00:07:25,900 --> 00:07:27,800
And then MongoDB is sort of a no-brainer.

116
00:07:28,280 --> 00:07:33,040
There are cases where none of the relational databases scale to the kinds of volumes people

117
00:07:33,040 --> 00:07:33,380
need.

118
00:07:33,960 --> 00:07:35,280
I mean, that's a great use case for MongoDB.

119
00:07:35,440 --> 00:07:39,560
There are cases where certain features like being able to put data spread around the world

120
00:07:39,560 --> 00:07:43,720
in a single cluster are a critical feature, whether, you know, either for compliance reasons

121
00:07:43,720 --> 00:07:44,580
or latency reasons.

122
00:07:44,740 --> 00:07:48,160
And you want to keep data in different countries and close to users.

123
00:07:48,360 --> 00:07:51,840
And that's something where only something like MongoDB could really satisfy it.

124
00:07:52,120 --> 00:07:54,860
It's not really people who are saying, oh, I've got an Oracle database.

125
00:07:54,960 --> 00:07:57,160
Let me just swap it out with Mongo just for fun.

126
00:07:57,580 --> 00:07:57,760
Right?

127
00:07:57,780 --> 00:07:58,420
It's a lot of work.

128
00:07:58,900 --> 00:08:02,920
And so it really comes down to some business problem, some real problem saying, I've got

129
00:08:02,920 --> 00:08:03,620
a problem here.

130
00:08:03,960 --> 00:08:07,480
My answer is doing a re-architecture inside of Oracle and figuring out a totally different

131
00:08:07,480 --> 00:08:12,260
way to use Oracle or moving to MongoDB and making my life, you know, my developers' lives

132
00:08:12,260 --> 00:08:12,840
a lot easier.

133
00:08:13,320 --> 00:08:18,040
And here's Elliot explaining why MongoDB tends to be a popular choice as a data store for microservices,

134
00:08:18,300 --> 00:08:24,420
as well as IoT and kind of novel data use cases where MongoDB is picking up steam.

135
00:08:24,940 --> 00:08:29,940
MongoDB tends to be used in a lot of microservices use case because it fits very well to the paradigm

136
00:08:29,940 --> 00:08:34,660
of, you know, hey, I've got this application, this application or this service is going to

137
00:08:34,660 --> 00:08:38,120
use this kind of a data model and, you know, have a very tight mapping.

138
00:08:38,460 --> 00:08:42,660
It's very easy to have lots of, you know, MongoDB instances that can scale with a service

139
00:08:42,660 --> 00:08:44,920
and therefore it works well.

140
00:08:45,160 --> 00:08:50,280
A lot of companies we see take these big monolithic applications built on Oracle and their

141
00:08:50,280 --> 00:08:54,880
way off of this monolithic environment is to, you know, peel off services one at a

142
00:08:54,880 --> 00:08:59,100
time and as they do that, they tend to often move them to MongoDB as well, right?

143
00:08:59,120 --> 00:09:04,940
So take this, you know, a hundred different applications using the same database, start

144
00:09:04,940 --> 00:09:05,980
pulling off services each one.

145
00:09:06,060 --> 00:09:08,240
As they pull off a service, they also move the data to MongoDB.

146
00:09:08,820 --> 00:09:09,680
That's pretty common.

147
00:09:10,360 --> 00:09:15,120
We're used in a lot of big data cases and a lot of IoT cases, you know, where people are

148
00:09:15,120 --> 00:09:19,780
putting in a ton of sensor data, streaming data, whether it's, you know, sensors or financial

149
00:09:19,780 --> 00:09:20,180
data.

150
00:09:20,800 --> 00:09:25,120
So it works well in that paradigm largely because it scales very effectively and because

151
00:09:25,120 --> 00:09:28,720
of the data model, again, because you can put arbitrary data in there.

152
00:09:28,980 --> 00:09:33,340
So as your sensors change, as the world around you changes, the database doesn't have to change

153
00:09:33,340 --> 00:09:33,660
with it.

154
00:09:33,720 --> 00:09:35,600
It just sort of naturally evolves with you.

155
00:09:36,900 --> 00:09:41,340
And up next, we have one of my colleagues, Cornelia Davis, vice president of technology

156
00:09:41,340 --> 00:09:46,460
at Pivotal, explaining the evolution of platform as a service or PaaS from something focused

157
00:09:46,460 --> 00:09:51,720
solely on the developer use case to something that thinks about the whole application lifecycle.

158
00:09:51,720 --> 00:09:55,880
So from infrastructure to security, all the way up to, again, the application.

159
00:09:56,140 --> 00:10:02,340
What I think we've learned, and so what has really changed, is that our understanding of

160
00:10:02,340 --> 00:10:08,220
the potential value that something like a platform as a service can bring goes so far beyond making

161
00:10:08,220 --> 00:10:14,200
Cornelia's life easier, making the developer's life easier, and takes you all the way to the

162
00:10:14,200 --> 00:10:15,900
entire lifecycle of the application.

163
00:10:16,580 --> 00:10:22,200
So it's not just about development, but it's actually about deployment to production, operating

164
00:10:22,200 --> 00:10:28,480
in production, resilience in production, and even the developer workflow is considered a

165
00:10:28,480 --> 00:10:32,940
production activity because as soon as that environment goes down, then you can't be shipping

166
00:10:32,940 --> 00:10:34,020
features anymore.

167
00:10:34,820 --> 00:10:40,140
And so I think that understanding that it's not just about making the developer's life easier

168
00:10:40,140 --> 00:10:50,560
has led to a maturity in PaaS that now allows us to focus on things like security and operational

169
00:10:50,560 --> 00:10:56,580
effectiveness and resilience, which when I first started studying this seven plus years

170
00:10:56,580 --> 00:10:58,380
ago, nobody was talking about it.

171
00:10:58,380 --> 00:11:04,360
And here's Cornelia explaining some of the differences between PaaS and what some people

172
00:11:04,360 --> 00:11:11,280
referred to as Kaas, C-A-A-S, or containers as a service, specifically Kaas as delivered

173
00:11:11,280 --> 00:11:12,060
via Kubernetes.

174
00:11:12,520 --> 00:11:15,760
Kubernetes is crazy cool technology.

175
00:11:16,480 --> 00:11:22,360
It's a set of primitives that you can just build so many awesome things with, but that's

176
00:11:22,360 --> 00:11:25,180
the key, is that you can build awesome things with it.

177
00:11:25,180 --> 00:11:34,340
The main thing that I think I would love your listeners to understand is that Kaas is essentially

178
00:11:34,360 --> 00:11:36,180
an infrastructure dial tone.

179
00:11:37,240 --> 00:11:45,200
So when you are dealing with Kubernetes, you are dealing with things like pods, and you

180
00:11:45,200 --> 00:11:53,300
are dealing with persistent volumes and persistent volume claims, and load balancers, they call

181
00:11:53,300 --> 00:11:57,020
them services, but a load balancer is a type of a service.

182
00:11:57,440 --> 00:12:02,020
So you're still largely dealing with infrastructure abstractions.

183
00:12:02,340 --> 00:12:05,860
Yes, it's an up-leveling from compute storage and network.

184
00:12:06,380 --> 00:12:07,980
It isn't just those broad things.

185
00:12:08,100 --> 00:12:12,160
It's not a machine in the same way that we've always thought of machines.

186
00:12:12,340 --> 00:12:13,660
It used to be a physical machine.

187
00:12:13,780 --> 00:12:17,740
Now it's a virtual machine, and it has every single thing that the physical machines had.

188
00:12:18,140 --> 00:12:22,800
We're starting to break those things up into an abstraction layer where we can compose them

189
00:12:22,800 --> 00:12:27,200
in interesting ways, but it's still fundamentally an infrastructure abstraction.

190
00:12:28,340 --> 00:12:35,960
So paths is all about bringing that abstraction up to a level that lets the infrastructure details

191
00:12:35,960 --> 00:12:42,820
fall by the wayside, that lets you apply controls to those, but then they aren't first-class

192
00:12:42,820 --> 00:12:44,840
concerns that's already built in.

193
00:12:44,840 --> 00:12:53,160
And here we have Guy Pujarni, co-founder of Sneak and previously CTO at Akamai, talking to us

194
00:12:53,160 --> 00:13:00,100
about why and how open source and other shifts in technology have changed the name of the game

195
00:13:00,100 --> 00:13:01,600
for securing applications.

196
00:13:02,360 --> 00:13:09,080
Open source is a component of DevOps, if you will, and a whole stack of changes that really

197
00:13:09,080 --> 00:13:12,480
transformed the way software is developed, developed faster.

198
00:13:12,860 --> 00:13:15,780
Software just sort of gets written and gets deployed.

199
00:13:15,940 --> 00:13:21,420
The path from writing a line of code to deploying it is much, much faster, and it is continuous.

200
00:13:21,920 --> 00:13:22,980
It doesn't stop.

201
00:13:23,140 --> 00:13:28,800
It's from CICD to a myriad of other technologies, including open source components and including

202
00:13:28,800 --> 00:13:30,640
containers, it just became continuous.

203
00:13:30,900 --> 00:13:36,480
And that really kind of rocks the boat for security because security's natural motion has

204
00:13:36,480 --> 00:13:38,000
been to work through gates, right?

205
00:13:38,040 --> 00:13:39,580
It's you stop here and you will audit.

206
00:13:40,180 --> 00:13:46,780
And so as software becomes fluid, right, becomes continuous, the opportunity to do those stops

207
00:13:46,780 --> 00:13:48,160
and to audit goes away.

208
00:13:48,160 --> 00:13:55,640
And that forces, that changes the world of security to need to embed itself more into the pipelines,

209
00:13:55,740 --> 00:13:58,900
into that continuous process, as that's really its opportunity.

210
00:13:59,580 --> 00:14:07,200
And here's Guy again with a very insightful comment on why open source is not more or less secure

211
00:14:07,200 --> 00:14:07,840
than anything else.

212
00:14:07,880 --> 00:14:13,240
It's just differently secure than some perhaps more traditional approaches.

213
00:14:13,540 --> 00:14:19,700
Definitely open source is not less secure nor more secure than closed source code.

214
00:14:20,420 --> 00:14:24,980
And it's not, you know, nor is, you know, a DevOps methodology, right, or a continuous pipeline

215
00:14:24,980 --> 00:14:28,300
more or less secure, you know, than a different approach.

216
00:14:28,440 --> 00:14:29,860
They just have different properties.

217
00:14:30,320 --> 00:14:33,420
Specifically, I do come back to people.

218
00:14:33,740 --> 00:14:36,420
So when you think about open source, for instance, it does two things.

219
00:14:36,480 --> 00:14:37,860
One is prevalence.

220
00:14:38,580 --> 00:14:42,800
So because open source is there, because you don't want to reinvent the wheel, then you go off,

221
00:14:42,840 --> 00:14:46,200
you have a piece of code that is very, very useful, and everybody embraces it.

222
00:14:46,200 --> 00:14:51,800
So it's not that that piece of code, OpenSSL or Bash or, you know, the Docker engine or whatever it is,

223
00:14:52,060 --> 00:14:54,820
is more or less secure.

224
00:14:55,040 --> 00:15:00,080
It's just that it's amazingly prevalent, you know, just far more so than any commercial software.

225
00:15:00,480 --> 00:15:07,780
So when a vulnerability does get found in one of those components, it has a whole world of victims available to it.

226
00:15:07,780 --> 00:15:16,400
So its implication on the entire internet ecosystem could be seismic, could be far more substantial than commercial software.

227
00:15:16,900 --> 00:15:22,240
So in that sense, open source is not more or less secure, but its security is more important.

228
00:15:22,500 --> 00:15:28,140
The likelihood of an attacker exploiting a vulnerability in an open source component is just higher.

229
00:15:28,140 --> 00:15:33,580
And you can kind of make the argument that a cloud application versus one that is just sort of a hidden in the data center,

230
00:15:33,680 --> 00:15:37,940
if it is more exposed to the world, it provides more value, but it also increases its attack surface.

231
00:15:38,420 --> 00:15:39,660
So that's one aspect.

232
00:15:40,080 --> 00:15:45,320
But the other and maybe very people-oriented aspect of open source is one of ownership, right?

233
00:15:45,380 --> 00:15:51,960
And it has to do with the fact that an organization that uses open source is getting a piece of value for free,

234
00:15:52,460 --> 00:15:57,680
but they're downloading it from the internet and their use of it is at their responsibility.

235
00:15:58,160 --> 00:16:01,020
So organizations need to build a new muscle, right?

236
00:16:01,060 --> 00:16:09,540
They need to understand how do they use this software that they did not write and take ownership of securing it,

237
00:16:09,620 --> 00:16:11,940
even though it's not their developers that wrote it.

238
00:16:11,940 --> 00:16:18,120
And that's, you know, I think that's a very substantial change to how companies think about managing their software.

239
00:16:19,480 --> 00:16:24,120
And finally, we have Peter Mattis, the co-founder and CTO of CockroachDB.

240
00:16:24,640 --> 00:16:33,440
He starts off with explaining why we're seeing so much new slash distributed slash next generation SQL today,

241
00:16:33,440 --> 00:16:36,480
as opposed to seeing it maybe a decade ago.

242
00:16:36,780 --> 00:16:38,820
I would look to not so much as valuable as possible.

243
00:16:38,920 --> 00:16:41,220
Why are these all coming out kind of near the same period of time?

244
00:16:41,580 --> 00:16:45,920
It's like, why didn't, you know, multiple people independently come up with the idea of the atomic bomb?

245
00:16:46,160 --> 00:16:48,680
You know, groups come up with, they kind of come with these breakthroughs.

246
00:16:48,880 --> 00:16:54,660
Well, there's a kind of technological change that occurred over the past 40 years since databases have been in existence.

247
00:16:54,880 --> 00:16:57,000
And that is, you know, computers have gotten faster.

248
00:16:57,100 --> 00:17:02,480
We all know about Moore's law, but networks have even outpaced the improvements in processors.

249
00:17:02,940 --> 00:17:10,940
And now it's, you know, I can read data from a remote machine, especially one that's nearby in a data center, faster than I can read it from disk.

250
00:17:11,300 --> 00:17:12,180
That's pretty incredible.

251
00:17:12,820 --> 00:17:15,060
A lot of people realize it outside the industry.

252
00:17:15,540 --> 00:17:16,800
Inside the industry, it's well known.

253
00:17:17,620 --> 00:17:25,400
And then the other big change is that we actually have a much better understanding of how to do, you know, distributed transactions and distributed consensus.

254
00:17:25,720 --> 00:17:31,520
All this stuff has come out in the past 20 years about Paxos and Raft, which are distributed consensus protocols.

255
00:17:31,740 --> 00:17:35,000
And then there's distributed transaction protocols to exist on top of that.

256
00:17:35,240 --> 00:17:41,200
So I think there's like a realization by a whole bunch of different people that you can put these things together and make a distributed SQL system.

257
00:17:41,680 --> 00:17:47,660
And what we're seeing is, you know, various different, you know, kind of ways to piece together these components into a working system.

258
00:17:47,820 --> 00:18:00,920
Here is Peter giving his thoughts on what he's excited about for the future of databases, primarily the benefits of databases and applications designed for handling geographically distributed workloads.

259
00:18:01,420 --> 00:18:12,780
Yeah, I mean, the thing I'm excited about is the, you know, this evolving landscape of applications that can work in a global manner and have geodistributed applications that can take advantage of a geodistributed database.

260
00:18:13,000 --> 00:18:18,100
And there's going to be enhancements to the kind of SQL abstractions to make this easier to do.

261
00:18:18,360 --> 00:18:20,280
And I'd say we're still kind of in the early days of this.

262
00:18:20,660 --> 00:18:24,480
CockroachDB provides a lot of mechanism for doing geodistributed applications.

263
00:18:24,980 --> 00:18:28,420
And yet those mechanisms are a little bit, you know, rough around the edges.

264
00:18:28,420 --> 00:18:36,180
So, I mean, the area I'm excited to see innovation in is improving those SQL abstractions, improving how, you know, that functionality works.

265
00:18:36,280 --> 00:18:39,180
So it's just crystal clear and easy for developers to use.

266
00:18:39,460 --> 00:18:44,760
And then also seeing this evolution of the, you know, kind of a global app tier coming to play.

267
00:18:45,220 --> 00:18:51,580
You can, it's so easy to get a VM running in a data center, but actually getting an application running is quite a bit harder.

268
00:18:51,740 --> 00:18:54,840
But then trying to get a geodistributed application running is even harder still.

269
00:18:55,060 --> 00:18:57,200
And all that stuff is going to be addressed over time.

270
00:18:57,320 --> 00:18:58,880
We're seeing progress in these areas.

271
00:18:59,400 --> 00:19:07,000
You know, before it was starting a VM, now it's like usually you get a Kubernetes cluster running, but getting a multi-region Kubernetes cluster is still hard.

272
00:19:07,540 --> 00:19:10,040
I think these things are all going to be addressed in the coming years.

273
00:19:10,380 --> 00:19:16,940
And we're going to get to this point where, you know, if I want to, you know, spin up a global application, I'll be able to do that in minutes and deploy it in minutes.

274
00:19:17,100 --> 00:19:21,300
You know, that's still, you know, kind of a far off pie in the sky, but I think we'll get there.

275
00:19:21,720 --> 00:19:22,300
And there you have it.

276
00:19:22,360 --> 00:19:27,700
I hope you enjoyed listening to some of these highlights as much as I enjoyed re-listening to them.

277
00:19:28,260 --> 00:19:35,520
And if you want more about digital transformation and cloud native architectures and the whole gamut of things discussed in this episode,

278
00:19:35,700 --> 00:19:43,960
you can obviously check us out at Pivotal.io, or you can check out Intersect, the home of this podcast, at Pivotal.io slash Intersect.

279
00:19:44,200 --> 00:19:48,800
I'm also running the site on Twitter at Intersect IT.