1
00:00:00,000 --> 00:00:05,060
Welcome to the cloud native in 15 minutes, or in this case, closer to 30 minutes podcast.

2
00:00:05,440 --> 00:00:10,360
If you haven't listened before, the goal of this podcast is simple to explain some complex but

3
00:00:10,360 --> 00:00:14,820
increasingly important and even strategic technologies and about the time it takes for

4
00:00:14,820 --> 00:00:19,920
a coffee break. Normally I'd say a short commute, but a lot of us are teleworking from home at the

5
00:00:19,920 --> 00:00:24,400
moment or teleworking. So maybe a couple laps around the block, who knows? Anyhow, point being,

6
00:00:24,900 --> 00:00:29,700
it's about 30 minutes. Stick around. I'm Derek Harris from VMware. And also if you listened

7
00:00:29,700 --> 00:00:34,120
before, you know that I try not to talk about our own technologies too much. This was true when

8
00:00:34,120 --> 00:00:39,260
I was part of Pivotal and also true now that I'm part of Pivotal has been acquired by VMware. However,

9
00:00:39,780 --> 00:00:44,900
this episode, we are going to talk about some VMware technology. Specifically, we're going to talk

10
00:00:44,900 --> 00:00:50,280
about the big Tanzu launch we just did. It helps put the Pivotal acquisition in context, but it also

11
00:00:50,280 --> 00:00:54,220
helps explain how we got here. It's not all about Tanzu. It's about a lot of things, but it kind

12
00:00:54,220 --> 00:00:59,400
of builds this story, this narrative arc from where we were maybe a decade ago to how we ended

13
00:00:59,400 --> 00:01:04,200
up to where we are today when we're living in this world of Kubernetes and cloud native and Kafka and

14
00:01:04,200 --> 00:01:09,140
microservices and the list of things goes on. So joining me to talk about this all is James

15
00:01:09,140 --> 00:01:16,420
Waters. James is the CTO of VMware's MapBU. That is the modern applications platform business unit where

16
00:01:16,420 --> 00:01:24,460
the Tanzu technologies live. He joined VMware around 2009, helped launch Cloud Foundry. Cloud Foundry

17
00:01:24,460 --> 00:01:29,740
became an integral part of Pivotal. When that launched, James helped drive a lot of Pivotal's vision and now

18
00:01:29,740 --> 00:01:34,700
James is, along with a lot of other people, back at VMware. So he has some great perspective on the

19
00:01:34,700 --> 00:01:39,920
industry trends that kind of drove these various shifts. But yeah, like I mentioned, it's not all about

20
00:01:39,920 --> 00:01:45,480
Tanzu and the products that are part of that, which includes most of the Pivotal portfolio. It's really a talk

21
00:01:45,480 --> 00:01:51,660
about microservices and Netflix open source and Spring and Kubernetes and Kafka and just these other

22
00:01:51,660 --> 00:01:56,940
industry-wide movements that helped, you know, take us from this era of, you know, standard three-tier

23
00:01:56,940 --> 00:02:02,440
application into the area of virtualization and infrastructure of the service and then finally into this cloud

24
00:02:02,440 --> 00:02:07,660
native era that we're in. So I think it's a really good and useful way to get some context and kind of just how

25
00:02:07,660 --> 00:02:14,480
things evolved and why we are where we are. So stick around, listen to James. And when you're done, especially if you're

26
00:02:14,480 --> 00:02:17,940
listening to Apple Podcasts, rate this podcast. It's a huge help. Thank you.

27
00:02:19,560 --> 00:02:23,760
All right, James. So to start with, can you just give our listeners a quick background on yourself,

28
00:02:23,920 --> 00:02:26,420
maybe your evolution over the past 10 years?

29
00:02:26,420 --> 00:02:33,940
Yeah. So about 10 years ago, I took a job at, you know, it's shifted to a job at VMware focused on

30
00:02:33,940 --> 00:02:40,900
building a next generation cloud-first platform that could be developer-friendly. We called it Cloud

31
00:02:40,900 --> 00:02:47,700
Foundry at the time at VMware. And so I've been working on that project, which got spun out into a company

32
00:02:47,700 --> 00:02:55,400
called Pivotal for a while. And now a pretty exciting reincorporation of that back into a business unit

33
00:02:55,400 --> 00:03:00,920
at VMware that we call the Modern Application Platform Business Unit. That's the last 10 years for me.

34
00:03:00,920 --> 00:03:04,880
That was a real nutshell to 10 years there.

35
00:03:05,200 --> 00:03:11,080
I can go as deep as you like, but that's... We used to call it the Cloud Application Platform in 2010,

36
00:03:11,080 --> 00:03:13,820
and now it's the Modern Application Platform in 2020.

37
00:03:14,580 --> 00:03:16,620
Right. And the product line is Tanzu.

38
00:03:16,920 --> 00:03:17,480
That's right.

39
00:03:17,540 --> 00:03:24,160
So when you joined VMware about a decade ago, coming from Sun Microsystems, right? What was it

40
00:03:24,160 --> 00:03:27,700
that... I mean, VMware was known, you know, as a virtualization, right? And the hypervisor

41
00:03:27,700 --> 00:03:32,500
company primarily at the time, infrastructure as a service was just kind of wrapping up around that

42
00:03:32,500 --> 00:03:38,080
timeframe, maybe a few years into that movement. What was it that inspired VMware to say,

43
00:03:38,160 --> 00:03:39,560
we want to build something like Cloud Foundry?

44
00:03:40,120 --> 00:03:43,860
Yeah. I mean, a little bit on my history just before that, in my context, you know,

45
00:03:43,860 --> 00:03:50,440
just what was going on in the world was Google had always quietly been building this scaled

46
00:03:50,440 --> 00:03:54,720
infrastructure, very bespoke, but they were sort of the only ones in the world that were

47
00:03:54,720 --> 00:04:01,040
doing it. But around, you know, 2007 to 2009 at Sun, I started, I took on the task of trying

48
00:04:01,040 --> 00:04:04,300
to work with these like web scale companies like Facebook and like, what could we build

49
00:04:04,300 --> 00:04:10,180
for them? But it was interesting that the feedback that came back was basically stripping features

50
00:04:10,180 --> 00:04:13,380
out of servers was all they wanted. Like they wanted less and less and less. They just

51
00:04:13,380 --> 00:04:20,320
wanted, you know, network attached CPU and disk. And so at one point you realize that there's

52
00:04:20,320 --> 00:04:25,700
going to be a revolution in infrastructure software that's coming, because the value is no longer

53
00:04:25,700 --> 00:04:30,180
being added at that atomic server level at all anymore, including kind of in the operating system,

54
00:04:30,180 --> 00:04:34,420
both the operating system and the server were very difficult place to start adding value for those

55
00:04:34,420 --> 00:04:40,020
kinds of companies. So I really was on the lookout for like, who are the players in infrastructure software

56
00:04:40,020 --> 00:04:46,280
that could harmonize these distributed systems in this, you know, a business tool, something that a large

57
00:04:46,280 --> 00:04:50,400
company could use. And VMware was on the top of my list. And I happened to meet some people there.

58
00:04:50,960 --> 00:05:19,960
So that was really a good fortune in a sense, because that fit with my passion. And then within VMware, they had hired a couple of ex-Google engineers to go work on building almost exactly that kind of next generation system that we'd been trying to fulfill hardware and operating systems into. And I think the insight that VMware had at the time was based on that transition that was happening in the market is it wasn't just Google anymore who was starting to build these very at-scale systems. There was this next tier of users.

59
00:05:19,960 --> 00:05:43,400
Facebook on down that were starting to go that way. And so you could imagine 10 years from then, that would be a more ordinary business tool that the average enterprise might need to use to differentiate themselves. So I think VMware was reading the tea leaves and saw that shift coming in the same way I was experiencing it at sun at the tail end of my stay there. Does that make sense?

60
00:05:43,400 --> 00:05:44,400
Oh, yeah, for sure.

61
00:05:44,400 --> 00:05:53,220
Oh, yeah, for sure. For sure. And it's funny to think, looking back that right to selling to Facebook, because they ultimately ended up just building their own open source hardware.

62
00:05:53,600 --> 00:06:07,660
It was a completely impossible system of this task that I did for eight months, trying to add value to those companies. And it taught me the hard lesson that the value was all going to be in the distributed system software very soon for the market.

63
00:06:08,400 --> 00:06:11,900
Yeah, for sure. So VMware announced Cloud Foundry, I believe in 2011.

64
00:06:12,680 --> 00:06:17,580
Yeah, correct. Seems like a lifetime ago, but here it is still providing a lot of value.

65
00:06:17,960 --> 00:06:18,080
Yeah.

66
00:06:18,160 --> 00:06:24,880
What do you think it was around Cloud Foundry that helped to build that value? And then platform as a service or paths overall that really kind of resonated.

67
00:06:25,160 --> 00:06:28,660
But also, I think it had maybe limited traction as well. So what was kind of that?

68
00:06:29,340 --> 00:06:46,080
Well, it was an R&D project and kind of an experiment, to be clear. It was an exploration. And so it started in very late 09 and I joined it in 10. And I think there were two things that it did that were still indicative of the future that it got right.

69
00:06:46,080 --> 00:06:57,060
It was originally just a hosted service. But if you go even back to the launch day in 2011, it did two things. One is it really had a super highway for the developer to get code to production.

70
00:06:57,060 --> 00:07:07,300
So it had the CF push experience, where you just gave it an app artifact and it did everything that you needed to get that running on end number of servers for you.

71
00:07:07,360 --> 00:07:12,480
So the developer both had an easier task in terms of the number of steps they need to go through to deploy any app.

72
00:07:13,480 --> 00:07:24,560
But then the second magic thing it had, it had, and it really was very unique in the market around this for a long time, is it had a declarative container engine underneath that.

73
00:07:25,300 --> 00:07:32,100
And we had a magic command CF scale. And the demo used to be, you know, CF push app running and then CF scale times 1000.

74
00:07:32,640 --> 00:07:38,100
And suddenly you had 1000 instances of your app running. And that was about 30 or 40 seconds.

75
00:07:38,100 --> 00:07:43,440
And in 2011, 2012, no one had ever seen declarative container automation like that.

76
00:07:44,040 --> 00:07:47,800
And so those were the two superpowers that it had back in the day.

77
00:07:47,900 --> 00:07:54,900
But I think we were just curious, like, okay, so these are, these are new powers, but how do we make a market for that?

78
00:07:54,980 --> 00:08:04,000
How do we, you know, go to market with that? That was all very wide open, but you can see the potential of what's now become the developer experience on containers, as well as declarative automation.

79
00:08:04,200 --> 00:08:06,140
They were there early on.

80
00:08:07,180 --> 00:08:15,760
Yeah, what was it? Because I mean, because Cloud Foundry was out for a few years, and then definitely building up like a user base, and then containers and Docker kind of hit the scene.

81
00:08:16,700 --> 00:08:24,200
And I mean, they kind of changed stuff as well, right? I mean, you talk through like, like, like what happened? I mean, they, for some reason, they captured the zeitgeist.

82
00:08:24,260 --> 00:08:30,740
And like you said, this declarative model becomes a much more widely accepted and understood thing.

83
00:08:31,400 --> 00:08:39,380
Yeah, I think there's two ways of thinking about markets. The first is like how you build an end to end business tool, and that might look more like a solution.

84
00:08:39,980 --> 00:08:48,320
And so Cloud Foundry from the start was always a solution that did a wide variety of things and use vertical integration to deliver a business outcome.

85
00:08:48,960 --> 00:08:58,480
And then the trend that it was tracking to, though, this at scale declarative automation was just too big for it to be limited to a single solution.

86
00:08:58,480 --> 00:09:18,140
And so you saw that manifest in a whole variety of things, from Docker to Mazus, ultimately Kubernetes, which were tools that applied that not at a solution level, like an end to end solution, but more at the, here's a technology you could build an ecosystem around to build platforms like Cloud Foundry.

87
00:09:18,400 --> 00:09:24,580
So I think, you know, it was just a difference of design. Cloud Foundry was really designed to be an enterprise solution.

88
00:09:24,900 --> 00:09:32,720
And remarkably, the open source community really came along and rebuilt almost every component that we had had to build by hand in Cloud Foundry.

89
00:09:33,020 --> 00:09:36,740
We had to build a router by ourselves. That's now been built in Envoy.

90
00:09:37,040 --> 00:09:39,540
We had to build container management ourselves. That's now Kubernetes.

91
00:09:40,440 --> 00:09:44,560
We had to explore how you patch the system live and manage the operating system.

92
00:09:44,600 --> 00:09:45,740
And there's all kinds of trends.

93
00:09:46,200 --> 00:09:54,300
Like if you look at Bottle Rocket that just came out from AWS just this last couple of weeks, it makes it easier to patch, you know, running declarative systems.

94
00:09:54,700 --> 00:10:01,940
So what's happened is pretty interesting, which is that what was a vertically integrated solution originally and delivered a lot of great outcomes.

95
00:10:02,300 --> 00:10:06,180
There's now a community at every layer of that system that has been born.

96
00:10:06,400 --> 00:10:08,920
So it's just fun to look at it from both of those lenses.

97
00:10:09,700 --> 00:10:18,520
Yeah, it's funny. So, I mean, one way of looking at that, I think that you alluded to is like open source just, open source changed a lot in the meantime.

98
00:10:19,200 --> 00:10:22,220
And so like it was a vertically integrated thing came out of VMware, right?

99
00:10:22,260 --> 00:10:26,560
The community, but then these communities around all these things started to build and grow.

100
00:10:26,760 --> 00:10:31,940
And just the way that open source projects were developed, it seems like it changed as part of that.

101
00:10:32,000 --> 00:10:38,560
So like you said, you have Envoy and you have, you know, you have Kubernetes and you have all the other stuff that's built around that.

102
00:10:38,560 --> 00:10:43,920
Yeah. Layer by layer, almost every layer of the system developed an open source community around it.

103
00:10:43,980 --> 00:10:47,340
I think what's been fun has been continuing to integrate those into the solution.

104
00:10:48,380 --> 00:11:00,640
And then ultimately there was a super integration at the company level where the creators of Kubernetes who were at VMware are now on the same team as the platform that was this kind of more of a solution approach.

105
00:11:01,360 --> 00:11:09,500
And we've named it Tanzu and the whole idea is to give you both the ability to use it as a solution and to end as well as to use it in a modular way.

106
00:11:10,140 --> 00:11:12,960
So to me, it's like now we're playing for all the marbles.

107
00:11:12,960 --> 00:11:19,880
We're playing for the outcomes and for, you know, the independent atomic and modular value add each step of the way.

108
00:11:20,540 --> 00:11:27,960
So I think that's why Tanzu is such an exciting bet is because it has the best teams from both of those approaches working together to synthesize that.

109
00:11:28,380 --> 00:11:29,260
Nobody else has that.

110
00:11:30,200 --> 00:11:30,560
Yeah.

111
00:11:30,640 --> 00:11:38,780
Before we get into Tanzu a little more deeply, like I do want to ask what happens with, so there's the, I guess from the platform side, it's very simple.

112
00:11:38,820 --> 00:11:40,840
So, okay, we want developers to have a much easier experience.

113
00:11:40,920 --> 00:11:44,540
We want to make scale and managing these, these systems more declarative.

114
00:11:44,780 --> 00:11:49,180
So, so that makes a lot of sense, but there's also the application side of things, right?

115
00:11:49,180 --> 00:11:55,140
Not just the, maybe the platform or the operation side, like what shifted, I think microservices are part of that, right?

116
00:11:55,140 --> 00:11:58,180
Like what shifted on the application side to make this more appealing?

117
00:11:59,120 --> 00:12:02,180
Yeah, I think there was an early period.

118
00:12:03,420 --> 00:12:14,640
I remember being in the room when we were working on Cloud Founder early on and everyone is like, look, we could have a much better developer experience and we can be so much more efficient operating this.

119
00:12:14,800 --> 00:12:23,460
If we could only find a way of standardizing more of how each application works and communicates with each other over a network.

120
00:12:23,800 --> 00:12:27,480
We were essentially articulating microservices as a trend.

121
00:12:27,740 --> 00:12:29,800
I hadn't really been named that yet.

122
00:12:30,860 --> 00:12:44,480
And so I had an acquaintance with Adrian Cockroft and we used to go watch all of his talks when Netflix was the first really at scale adopter of Amazon and went Amazon native.

123
00:12:45,140 --> 00:12:57,820
And Adrian's group at the time, building on what you might call now rudimentary IaaS, they really had to invent this whole scaffolding for microservices and to make that pattern work on top of IaaS.

124
00:12:58,500 --> 00:13:04,440
And so, you know, they built tools for service discovery because there was no longer multicast on Amazon at the time.

125
00:13:05,100 --> 00:13:10,980
They built circuit breakers because any part of the infrastructure was expected to be unreliable at one given time.

126
00:13:11,420 --> 00:13:17,240
They did a whole series of innovations around these patterns that also allowed them to scale their engineering teams.

127
00:13:17,240 --> 00:13:26,160
And I think that's when the lights went on for me because not only was this a new trend in application patterns, it was a new trend in organizational patterns.

128
00:13:26,860 --> 00:13:32,280
And a lot of enterprise companies were going to, I thought, adopt that pattern because they were already operating at scale.

129
00:13:32,340 --> 00:13:37,560
And like, how do you get more engineering horsepower into your customer features hands faster and faster?

130
00:13:37,620 --> 00:13:38,580
And that became microservices.

131
00:13:38,580 --> 00:13:51,400
So I really look at microservices patterns as the most important trend that happened over the last 10 years in terms of driving real demand to buy systems like this that are both developer friendly and declarative.

132
00:13:51,600 --> 00:13:58,920
And if you look at a company like Monzo that's out there today, they've hyper-standardized in terms of the framework that they use.

133
00:13:58,920 --> 00:14:06,360
So everything that they do is a Go microservice that uses Kafka in a very structured way and Cassandra.

134
00:14:06,580 --> 00:14:07,300
And that's the toolkit.

135
00:14:07,520 --> 00:14:09,140
And then every service really looks alike.

136
00:14:09,320 --> 00:14:12,960
And it's more about differentiating at that higher level above that.

137
00:14:13,020 --> 00:14:20,440
So I think that's one of the fascinating trends in terms of allowing you to really harvest the power of distributed infrastructure is that level of standardization.

138
00:14:21,500 --> 00:14:29,300
And come to think of it, it does seem like when cloud and some of the stuff first started happening, it was still application architectures weren't changing.

139
00:14:29,300 --> 00:14:35,040
I remember when there used to be those big Amazon outages, everything would go down and Netflix would stay up.

140
00:14:35,440 --> 00:14:39,600
And I think that had something to do with how it was building its applications.

141
00:14:40,560 --> 00:14:43,820
And circuit breakers were very inspiring to our clients.

142
00:14:43,960 --> 00:14:53,720
Like I know many banks that adopted Netflix OSS and Spring Cloud because they really were tired of the failure patterns being monolith fell over everything down.

143
00:14:54,220 --> 00:14:56,040
Every enterprise cared about SLA.

144
00:14:56,200 --> 00:15:02,040
So circuit breakers were one of those patterns that really got people excited about adopting this next generation of design.

145
00:15:02,960 --> 00:15:03,440
Yeah.

146
00:15:03,620 --> 00:15:06,340
It seemed like there were a lot of things where the pieces were there.

147
00:15:06,340 --> 00:15:12,240
Kafka is one of them too, where Kafka kind of started off as a, it was kind of in that big data sphere of things.

148
00:15:12,300 --> 00:15:22,540
It was always talked to as, talked about in the same breath as Hadoop and maybe when you're a NoSQL system and all this, but it's really evolved into like a critical piece of building modern applications.

149
00:15:22,540 --> 00:15:29,320
And it just took, I think it took everything else coming along with it to get us to this state, but that seemed like it was a vision all along.

150
00:15:29,740 --> 00:15:42,940
Yeah, I'd say Kafka has been one of those magical connective technologies between the world of data engineering and big data, as it was kind of called at its peak, Hadoop and modern applications.

151
00:15:43,840 --> 00:15:52,540
When, you know, you look at 2013, it was sort of the all in a Hadoop era as well before the microservices trend kicked off.

152
00:15:53,200 --> 00:16:03,380
But, you know, as I went and used some of those technologies, it wasn't easy for an application developer to go turn that into an application or to connect that to an application.

153
00:16:04,380 --> 00:16:19,440
MapReduce was this very batch based system, the way it thought about things and applications tend to want to respond more on a per event base or more real time to make it engaging for users and to orchestrate across a lot of services.

154
00:16:19,840 --> 00:16:37,760
And so when you started to see Kafka being this linking technology across things like Spark, as well as into microservices and application patterns, you start to go like, oh, wow, I can start to really think of at least starting off with a lot of my data in something like Kafka.

155
00:16:37,900 --> 00:16:41,820
And then I could query it in different ways, or I could use those events to enrich applications.

156
00:16:41,820 --> 00:16:50,200
And for the first time, you really saw what used to be, like, I've literally been in banks data centers where they walk me to the right, and that's the application clusters.

157
00:16:50,460 --> 00:16:53,100
And they walk me far to the left, and I'm like, that's our big data cluster.

158
00:16:54,160 --> 00:16:57,060
And, you know, I didn't realize how extreme it was.

159
00:16:57,100 --> 00:17:00,820
Like, they're completely different teams, completely different hardware, different, like, they're completely organized.

160
00:17:01,580 --> 00:17:02,920
I mean, Conway's the water, the extreme.

161
00:17:03,640 --> 00:17:08,860
But now you have the central Kafka integration point where every team can feed off that.

162
00:17:08,860 --> 00:17:18,600
And that's a big change in terms of how we think about enterprise architecture, because at the end of the day, enterprises are about integrating thousands of applications together.

163
00:17:18,720 --> 00:17:19,880
They're not about building one app.

164
00:17:21,260 --> 00:17:25,540
So we were talking about microservices and kind of events and these new architectural patterns.

165
00:17:25,640 --> 00:17:30,640
And one of the things, in a recent episode of the podcast, we had on Spencer Gibb talking about Spring and Spring Cloud.

166
00:17:30,900 --> 00:17:31,140
Yeah.

167
00:17:32,020 --> 00:17:36,780
And again, I mean, you know, that's, you know, from the VMware and Pivotal perspective, that was a very big deal.

168
00:17:36,840 --> 00:17:48,360
But also just for, I think, for the industry as a whole, the idea of being able to take some of these complex things and simplify them and make it so that average developer development teams could take advantage of them was a pretty big shift as well.

169
00:17:48,360 --> 00:18:04,000
Well, it was, and a little history there is maybe interesting, or at least fun for me, which is Alexis Richardson, who's now on the Kubernetes technical operating committee, and was the founder of RabbitMQ and now the founder of WeWorks, was at Pivotal at the time.

170
00:18:04,600 --> 00:18:19,980
And he was really the first person at Pivotal or one of the first people at Pivotal before myself to look at Netflix OSS as a huge opportunity for us because at the time it had been released to open source, but it was relatively idiosyncratic to Netflix itself.

171
00:18:20,120 --> 00:18:24,420
So, like, you weren't using, if you weren't inside Netflix, it wasn't easy to pick it up and use it.

172
00:18:25,500 --> 00:18:37,200
And Alexis articulated the opportunity for the Spring framework to wrap a lot of that and to bring the same ease of integration that Spring is so famous for across lots of projects right in the Netflix OSS.

173
00:18:37,580 --> 00:18:46,100
And so we started packaging something that's now called Spring Cloud, which was a more developer-friendly way of consuming Netflix OSS, and it really took off.

174
00:18:47,140 --> 00:18:59,420
You know, it took off so well that now Netflix has adopted Spring Cloud as its internal boilerplate, and they were presenting at the last couple Spring Ones about their internal adoption of Spring Cloud.

175
00:18:59,420 --> 00:19:17,660
So it's like this magical Mobius strip of developer experience where we wrapped Netflix OSS to make it easier for people to use, and they ultimately ended up, you know, doubling down on Spring Boot, not just to get access to their own Netflix OSS components, but really the whole ecosystem across data and other open source technologies.

176
00:19:17,860 --> 00:19:24,480
So that's a really fun part of this history, and, you know, credit to Alexis for being one of the first people at Pivotal to notice that.

177
00:19:25,280 --> 00:19:31,280
Yeah, it's funny. I remember back when I was a reporter, when I was asked, well, who's going to commercialize this Netflix OSS?

178
00:19:31,360 --> 00:19:31,720
That's right.

179
00:19:31,820 --> 00:19:37,140
And the answer was, and you're waiting for the cloud providers who weren't going to do it, it turns out, at least not on scale, but it was Spring, right?

180
00:19:37,180 --> 00:19:40,920
I mean, and then there's open source network effects kick in, and everyone wins in the end.

181
00:19:41,180 --> 00:19:41,380
Yeah.

182
00:19:42,340 --> 00:19:51,300
So let me ask him again, so I want to, as we start to wrap up, like I want to get back into Tanzu and help explain to listeners kind of what, you know, what's new in the world of Tanzu.

183
00:19:51,300 --> 00:19:56,100
And one of the big parts, like we referenced earlier, is Kubernetes. That's kind of a core piece of this.

184
00:19:56,180 --> 00:20:10,180
So as we look at everything that happened on the application side and the infrastructure side, like what was it about Kubernetes, do you think, that made it catch on as kind of the de facto or default layer, container, kind of infrastructure layer for these modern applications?

185
00:20:10,180 --> 00:20:30,600
Yeah, I think Kubernetes was really well designed and purpose-built to build, Kubernetes and Envoy, I would say, were purpose-built and designed to be not solutions, not end-to-end solutions, but rather components that would fit really well into platforms, into other solutions.

186
00:20:30,600 --> 00:20:42,820
And I think they really had both the zeitgeist of, you know, Google brand, they had an incredible movement around everyone using Docker on their laptops, so suddenly there was a cartridge to put into the machine.

187
00:20:42,820 --> 00:21:00,220
And they also, I think Joe and Craig and that team did a tremendous job of finding a Goldilocks abstraction where it really was applicable immediately to infrastructure folks as well as to developers, but without trying to be an end-to-end vertically integrated solution.

188
00:21:00,220 --> 00:21:02,020
So it really was built for an ecosystem.

189
00:21:02,020 --> 00:21:12,220
I think you can also look at the work that was done around Envoy, where there's great talks about how Envoy was intentionally designed to be pluggable and to only do so much.

190
00:21:12,220 --> 00:21:22,020
And I think components that are designed in that way have the best potential to become viral and industry standards across their horizontal.

191
00:21:22,240 --> 00:21:26,020
So I think they did a really great job of executing on that space.

192
00:21:26,820 --> 00:21:35,240
And then it's up to platforms, you know, like we've been building for years to incorporate those ecosystems and to leverage the network effects that they bring.

193
00:21:35,320 --> 00:21:37,500
And that's the exciting stuff that we're doing to this day.

194
00:21:38,660 --> 00:21:48,740
So how, with Tanzu and with kind of the new, let's call it the new VMware Pivotal integration, like, how does all this stuff come together now, right?

195
00:21:48,740 --> 00:21:58,040
I mean, so we have a lot of the stuff we've been talking about at Pivotal with Cloud Foundry and some of that, but also like there's whole new products like Tanzu Mission Control and Project Pacific and all those things.

196
00:21:58,120 --> 00:22:04,000
So what's kind of the, how did this all merge together, I guess, and form this new business unit?

197
00:22:04,800 --> 00:22:23,520
Yeah, I mean, let's just talk about Pacific for a second, because, you know, as an ex-VMware person, regardless of my Tanzu hat or if I work there or not, I think Pacific's a really, really fascinating moment in time, because it really starts to directly incorporate those distributed system APIs right into vSphere.

198
00:22:24,100 --> 00:22:49,960
And, you know, back to like, when I joined VMware, that was sort of my hope, I wouldn't call it a vision, but like the hope that this company I was joining would both do the very traditional IT workflows of, you know, basically offering a virtual server at a time, as well as starting to get into some of those distributed system declarative programming models that you could see even back, you know, in early days at places like Facebook.

199
00:22:50,580 --> 00:23:04,740
And so Pacific now is a really amazing moment in time for VMware, because they formally launched a product with vSphere 7 that is the best of both of those worlds, that can do both of those things.

200
00:23:05,320 --> 00:23:18,220
And I think it starts to rationalize the Kubernetes market in an important way, where when it came out, it was sort of one CIO that I was talking to said, all the time, there's like a platform team for every component that comes out.

201
00:23:18,220 --> 00:23:24,920
But now I think we can say, like, you don't have to go buy and integrate Kubernetes, that just comes into the infrastructure that you have.

202
00:23:25,620 --> 00:23:27,460
And in the case of vSphere, I think that's pretty exciting.

203
00:23:28,160 --> 00:23:40,280
And so to me, just as a, you know, long traveled person in this journey, it's great to see the very core of vSphere clients starting to shift to that declarative model, and to the Kubernetes APIs right in vSphere.

204
00:23:40,400 --> 00:23:41,360
So I think that's super exciting.

205
00:23:41,360 --> 00:23:48,260
And then that allows us to change our own waterline of where we have to do value-add engineering.

206
00:23:48,940 --> 00:23:53,740
So things like Tanzu Mission Control start to say, like, let's assume that you have lots of Kubernetes everywhere.

207
00:23:54,220 --> 00:24:04,300
How could you apply policy, user management, backup recovery, you know, all these other operational lifecycle controls to a multitude of Kubernetes clusters?

208
00:24:04,300 --> 00:24:15,260
And in fact, Kubernetes is so ubiquitous now that you might have an Amazon-managed Kubernetes cluster and a VMware-managed, and then you might have a Tanzu Kubernetes cluster on another cloud.

209
00:24:15,340 --> 00:24:18,380
And all of those could be all within one product.

210
00:24:18,540 --> 00:24:28,120
So I think you're starting to see IT adopt what was in 2009, these very emerging, very nascent-only Facebook-carried kind of patterns.

211
00:24:28,400 --> 00:24:30,720
But that's very mainstream IT now, and it's pretty exciting.

212
00:24:32,160 --> 00:24:40,280
And it seems like a big part of this is the idea that it's never one thing replaces the next thing.

213
00:24:40,560 --> 00:24:46,140
So it's never that you're going to go from managing VMs to all of a sudden VMs don't matter to you anymore.

214
00:24:46,240 --> 00:24:54,900
Like, I think that's part of the vSphere 7 stuff is, like, there's a spectrum and everything, but it's never like that left side of the spectrum kind of never goes away.

215
00:24:54,900 --> 00:25:02,920
Oh, man, I'll tell you, beware of the hype cycle, because what does get replaced is the hype cycle.

216
00:25:03,040 --> 00:25:05,320
So you will come in and out of a hype cycle for sure.

217
00:25:06,000 --> 00:25:18,300
But if you look at the companies that said, oh, we're going to be the company that's the next X, it often not is not the case, because that company has tons of resources designing the next X or the original X.

218
00:25:18,300 --> 00:25:27,740
It has so many resources to keep producing that design and has scale and has what technology philosophers would call dominant design.

219
00:25:29,100 --> 00:25:34,960
So the companies that kind of rode the hype cycle and said, oh, we're going to replace this, this, and this, like, that's not where the trend has been.

220
00:25:35,040 --> 00:25:40,880
I think it's been the companies that say, we're going to capture this next generation of behaviors and patterns.

221
00:25:41,100 --> 00:25:44,780
I mean, integrate those into what you already have, that tends to be the sweet spot.

222
00:25:45,380 --> 00:26:03,680
And I think, you know, not to just talk about VMware, I think Amazon's done a relatively interesting work of growing from just EC2 to now offering these higher level container abstractions, to offering Kafka as a service, to really leaning into both their legacy, which is really just an infrastructure service provider, but also providing the next generation.

223
00:26:03,680 --> 00:26:06,980
And I think with Tanzu, that's VMware is doing the same thing.

224
00:26:06,980 --> 00:26:14,980
It's offering this full spectrum where you can go from basic infrastructure or the whole way up to microservices scaffolding in one seamless approach.

225
00:26:15,980 --> 00:26:21,720
And just kind of in closing here, if you were giving advice, I know you spent a lot of time talking to customers who are trying to get on this journey.

226
00:26:21,880 --> 00:26:29,200
What does the outline look like from getting from, we want to do, as we've heard about these things, we want to modernize to actually doing it.

227
00:26:29,260 --> 00:26:31,300
Do you put the, do you put the applications first?

228
00:26:31,380 --> 00:26:33,040
Do you put the, do you buy the technology first?

229
00:26:33,120 --> 00:26:40,060
What does this pattern look like as you're, as we're talking about these shifts in application architectures and, and, and infrastructure technology and all this?

230
00:26:40,200 --> 00:26:41,800
What's with chicken and the egg in this situation?

231
00:26:42,220 --> 00:26:42,480
Yeah.

232
00:26:42,660 --> 00:26:44,020
And I've talked to you about this.

233
00:26:44,020 --> 00:26:51,920
So pardon me, repeating myself to you, but others haven't maybe heard it is when we, there's different ways of coming at this change.

234
00:26:52,280 --> 00:26:57,000
One is I have, you know, some new capabilities I want to build.

235
00:26:57,000 --> 00:27:03,140
I have relative greenfield or I have a strong appetite to do a real business level refactoring of my apps.

236
00:27:03,540 --> 00:27:18,560
And that's where things like, you know, spring boot and spring cloud and, you know, Kafka and this general move to a microservices architecture, or, you know, kind of what you might call the next generation of distributed architectures is really important to get right.

237
00:27:18,560 --> 00:27:20,780
And make sure that you have some standards there.

238
00:27:22,180 --> 00:27:27,700
And the story I tell folks is that you can look at the history of Uber in the Valley.

239
00:27:27,920 --> 00:27:32,040
And they said, build a microservice, however you want to, and run it on the platform.

240
00:27:32,040 --> 00:27:41,680
And they rightfully were trying to scale really fast and they made that decision, but I've seen some public Uber talks where they said, Hey, maybe having fewer, more standardized approaches might've helped us there.

241
00:27:41,680 --> 00:27:52,380
And then Netflix, who I continue to be a huge fan of, they've continued to be standardized on largely Java microservices and increasingly spring and a really driven great outcome.

242
00:27:52,380 --> 00:27:58,060
So I think the application first really matters and getting that application pattern is right.

243
00:27:58,280 --> 00:28:02,960
But maybe the interesting thing is, well, what do you do with all the apps that you just want to evolve?

244
00:28:03,860 --> 00:28:06,000
You're not ready for a full refactor on.

245
00:28:06,080 --> 00:28:11,560
And I've been asking companies, you know, how many apps that you have are one factor at least?

246
00:28:12,100 --> 00:28:13,100
And they kind of laugh.

247
00:28:13,180 --> 00:28:14,340
We're like, well, what's the one factor?

248
00:28:14,500 --> 00:28:17,980
Because sometimes enterprises are like, Hey, we're not ready to make everything 12 factors.

249
00:28:18,080 --> 00:28:20,720
So I try to reduce it down to just a simple question.

250
00:28:21,260 --> 00:28:25,400
And the one factor is like, Hey, can you even restart this application predictably?

251
00:28:25,880 --> 00:28:32,020
Because shifting to declarative automation and scheduling, you might want to be able to restart that app.

252
00:28:32,020 --> 00:28:43,200
And so I think there is this application first movement of either at least be able to do some basic automation of even your monolithic applications or a full refactor of them.

253
00:28:43,460 --> 00:28:46,960
But I think everyone recognizes that the app is the scarce thing right now.

254
00:28:47,120 --> 00:28:49,440
Like we've made Kubernetes more and more ubiquitous.

255
00:28:49,660 --> 00:28:50,660
It's in Project Pacific.

256
00:28:50,860 --> 00:28:51,860
It's in public clouds.

257
00:28:52,200 --> 00:28:56,160
I think the question now is how quickly all the application portfolios adapt to that.

258
00:28:57,600 --> 00:28:59,140
Listen, James, we are out of time.

259
00:28:59,560 --> 00:29:00,160
So thanks a lot.

260
00:29:00,880 --> 00:29:01,660
Thanks for the chat.

261
00:29:01,800 --> 00:29:02,620
Always good to connect.

262
00:29:04,120 --> 00:29:04,920
There you have it.

263
00:29:05,000 --> 00:29:05,820
I hope you learned something.

264
00:29:06,400 --> 00:29:07,400
We're going to keep this brief.

265
00:29:07,400 --> 00:29:18,360
For more information on VMware Tansu and all the products that encompass the newly launched Tansu brand, you can visit tansu.vmware.com.

266
00:29:19,200 --> 00:29:42,500
And for more information, or I should say more information, like the stuff you heard in this podcast, if you want to keep up with all things, you know, quote unquote digital transformation and cloud native, including some insightful posts from experts in the field, some guides and explainers and blogs and other podcasts and whatnot, you can visit the home of this podcast, Intersect, at tansu.vmware.com.

267
00:29:42,500 --> 00:29:43,540
slash intersect.