1
00:00:00,000 --> 00:00:01,020
Why don't you introduce yourself?

2
00:00:01,140 --> 00:00:02,880
Of course, I'm happy to do that.

3
00:00:03,640 --> 00:00:08,720
Purnima Padmanabhan, I am the general manager of the Tanzu division at Broadcom, and it

4
00:00:08,720 --> 00:00:10,020
is great to be here to chat with you.

5
00:00:10,100 --> 00:00:14,240
Yeah, today, I've been looking forward to this because, you know, I don't get the chance

6
00:00:14,240 --> 00:00:19,500
to talk with a lot of people who have kind of a parallel career that I've been through,

7
00:00:19,580 --> 00:00:21,580
let alone worked at BMC Software.

8
00:00:21,720 --> 00:00:23,800
So we should get to that at some point, those times.

9
00:00:24,800 --> 00:00:28,800
But I thought, like, you know, I wanted to talk about, like, what you've done over your

10
00:00:28,800 --> 00:00:34,660
career and kind of like the jobs that you've had and the groups that you've worked in, the

11
00:00:34,660 --> 00:00:39,080
products you've worked on, the people you've worked with, they've all been focused on, you

12
00:00:39,080 --> 00:00:43,600
know, we might call it like DevOps or platform engineering now, but there's this kind of

13
00:00:43,600 --> 00:00:48,140
continuous thread of, I mean, I don't want to put too many words in your mouth, but I feel

14
00:00:48,140 --> 00:00:52,900
like there's this continuous thread of we have infrastructure and we have developers that

15
00:00:52,900 --> 00:00:57,340
want to write applications and run on this infrastructure and we should make that better.

16
00:00:57,600 --> 00:01:02,220
And, like, I think over the past, I don't know, you tell me what you think it is, but

17
00:01:02,220 --> 00:01:09,460
20 or so years, there's been a couple different types of innovations and stages that we've gone

18
00:01:09,460 --> 00:01:09,720
through.

19
00:01:09,900 --> 00:01:14,000
And to kind of do it in reverse, how do you think we are now?

20
00:01:14,180 --> 00:01:17,040
Like, compared to, like, what you've seen in the past, how do you think we're doing?

21
00:01:17,460 --> 00:01:18,280
The stage of DevOps?

22
00:01:18,720 --> 00:01:19,260
Yeah, yeah.

23
00:01:19,360 --> 00:01:23,440
Like, this kind of, like, platform DevOps thing, like, is everything perfect for the

24
00:01:23,440 --> 00:01:24,400
application developers?

25
00:01:24,780 --> 00:01:25,340
Is it going out?

26
00:01:25,400 --> 00:01:27,100
Is it going well for the operations people?

27
00:01:27,320 --> 00:01:30,120
Like, what's the state when you go out and talk with people?

28
00:01:30,180 --> 00:01:34,220
Well, that's a good question on how platform engineering and DevOps has, is it solving the

29
00:01:34,220 --> 00:01:34,920
problem today?

30
00:01:35,100 --> 00:01:37,320
You know, is it, are we at the final stage?

31
00:01:37,500 --> 00:01:38,600
And I don't think so, right?

32
00:01:38,620 --> 00:01:43,380
It's never, it has gotten a lot better over the last 25 years, but it's not perfect yet.

33
00:01:43,380 --> 00:01:45,240
And there is still continuous room for improvement.

34
00:01:45,840 --> 00:01:49,860
And I think it is good to go back and ask a question.

35
00:01:50,060 --> 00:01:51,480
The terminologies change.

36
00:01:51,920 --> 00:01:54,480
Today, we talk about platform engineering and DevOps.

37
00:01:54,740 --> 00:01:57,180
But what is the goal that we have been striving for?

38
00:01:57,580 --> 00:02:02,540
And when you think about the goal, even when I started on early in my, in the software business,

39
00:02:02,540 --> 00:02:07,720
it has always been about, hey, you have written your applications, you have written your business

40
00:02:07,720 --> 00:02:08,140
logic.

41
00:02:09,020 --> 00:02:16,640
How do you speed the time, the amount of time it takes to take that code into production,

42
00:02:16,840 --> 00:02:17,960
that business logic, right?

43
00:02:18,260 --> 00:02:18,480
Right.

44
00:02:18,700 --> 00:02:21,000
And often there's like a lot of pitfalls.

45
00:02:21,480 --> 00:02:27,180
And when I think back about my career, right, early on, I was with a company called Loud Cloud,

46
00:02:27,600 --> 00:02:29,900
Mark Andreessen and Ben Horowitz had started it.

47
00:02:30,380 --> 00:02:32,740
And it was, I always say, cloud before cloud.

48
00:02:32,740 --> 00:02:38,540
But there, the whole thing was, hey, developers build their business logic, but often use things

49
00:02:38,540 --> 00:02:44,760
like standard middleware, infrastructure software, or infrastructure middleware, databases, web

50
00:02:44,760 --> 00:02:45,800
servers, app servers.

51
00:02:46,320 --> 00:02:50,360
And the thought for Loud Cloud was, can you give that on a tap, right?

52
00:02:50,420 --> 00:02:55,160
Very easily provision it and provide it so that the infrastructure automation pieces are there

53
00:02:55,160 --> 00:02:59,400
and the developers can build their software soon or faster.

54
00:03:00,040 --> 00:03:07,320
Then that was a very important step and eventually led to the public cloud boom that we have seen

55
00:03:07,320 --> 00:03:10,020
and making infra, you know, much easier.

56
00:03:10,660 --> 00:03:13,340
And then I moved to BMC and that is why both of us were there.

57
00:03:13,880 --> 00:03:14,400
That's great.

58
00:03:14,800 --> 00:03:16,360
Probably even at the same time.

59
00:03:16,900 --> 00:03:22,760
And a lot of it at BMC was about process automation, where infrastructure automation is a piece,

60
00:03:23,240 --> 00:03:27,140
but often there are many, many teams that work together.

61
00:03:27,320 --> 00:03:35,160
There is database teams, networking teams, compute teams, infrastructure, monitoring teams, right?

62
00:03:35,480 --> 00:03:37,080
Application teams, services team.

63
00:03:37,540 --> 00:03:40,920
And there was always a confusion between all of these, right?

64
00:03:41,200 --> 00:03:44,160
Anything went wrong, anybody could have made the change.

65
00:03:44,160 --> 00:03:50,360
Things would go wrong and then you'd take hours and hours and hours in war rooms trying to find out problems.

66
00:03:50,880 --> 00:03:55,240
And what BMC focused on was process automation and ITIL, you know,

67
00:03:55,440 --> 00:04:01,760
now we think ticket is a bad word, but ITIL really transformed a lot of the processes there

68
00:04:01,760 --> 00:04:07,680
and made things simpler, made the connectivity, the idea of a common view of the environment with CMDB,

69
00:04:08,120 --> 00:04:11,340
the idea that you could have consistent configuration and change management.

70
00:04:11,840 --> 00:04:15,660
That automation was a really big, you know, and we still see that, right?

71
00:04:15,720 --> 00:04:20,740
Today, now the evolution of what we did at BMC, you see with ServiceNow and other companies, right?

72
00:04:20,780 --> 00:04:24,140
So now you've automated the process piece, you've automated the infrastructure piece.

73
00:04:24,680 --> 00:04:30,300
And as I kind of think about my next steps in care careers, a few startups, and then I was at VMware.

74
00:04:30,820 --> 00:04:34,900
And VMware is where, you know, we have had this interesting relationship with that platform.

75
00:04:35,460 --> 00:04:36,320
Pivotal, right?

76
00:04:36,440 --> 00:04:39,340
Pivotal said, okay, even those are disparate pieces.

77
00:04:39,340 --> 00:04:41,760
And can you make that even simpler for the developer?

78
00:04:42,500 --> 00:04:45,940
And Pivotal was, of course, started with VMware, spun out.

79
00:04:46,060 --> 00:04:48,380
And then again, we bought it, Pivotal back again.

80
00:04:48,680 --> 00:04:53,980
But the concept was, why should the developer even think about these processes and tickets separately?

81
00:04:54,120 --> 00:04:56,860
Why should they think about automation of infrastructure separately?

82
00:04:57,300 --> 00:05:00,620
Can they just build their code and define their intent?

83
00:05:01,440 --> 00:05:07,220
And the platform takes care of everything else and makes it much faster for developers.

84
00:05:07,740 --> 00:05:09,820
And so that was kind of the next evolution.

85
00:05:10,080 --> 00:05:14,500
To some extent, Pivotal pioneered the notion of platform engineering.

86
00:05:14,940 --> 00:05:25,300
And from there onwards, we are here today, where the Pivotal assets and a lot of the organic Kubernetes assets that we have within the organization have come together as the Tanzu division.

87
00:05:25,760 --> 00:05:36,600
But again, the singular goal of Tanzu division is to reduce that time it takes from code to having a running application and project production that can be maintained, that is resilient, that is safe.

88
00:05:37,920 --> 00:05:39,360
And we have done a lot.

89
00:05:39,500 --> 00:05:42,100
We can talk more, but the work is not done.

90
00:05:42,640 --> 00:05:51,520
Yeah, you know, I mean, there's a lot of little interesting, let's say, side journeys and cul-de-sacs and what you were just saying to kind of explore there.

91
00:05:51,620 --> 00:06:01,160
And I think, you know, one of them, I think I was a little more familiar with the, I mean, tell me if I'm wrong, but I think there was kind of like two states of loud cloud.

92
00:06:01,380 --> 00:06:04,680
There was like the first go at it and then kind of automation, if I remember.

93
00:06:04,680 --> 00:06:14,540
And I think, I guess you're like the first one, what, I mean, you would know, was kind of like, I think we would call it a managed service provider, maybe something like that back then.

94
00:06:14,880 --> 00:06:22,100
And it's interesting that one of the notions was there's all this like middleware that developers use.

95
00:06:22,400 --> 00:06:24,960
Why don't we take care of that for developers?

96
00:06:25,260 --> 00:06:25,580
Right.

97
00:06:25,620 --> 00:06:34,200
Like kind of standardize that because that's a very similar, I'm always trying to pull out like two different paths through all of this that you were just going over.

98
00:06:34,200 --> 00:06:40,040
And one of them is standardize what developers use, a platform, right?

99
00:06:40,100 --> 00:06:48,000
Just, just like here we have like, you know, at Tanzu platform, we've got like Spring as a standard framework and data services as a thing that's all taken care of.

100
00:06:48,060 --> 00:06:51,940
And I think, I think that comes up over and over again.

101
00:06:52,280 --> 00:07:01,760
Like we're still always trying to just get developers to be happy about using some, some services we've packaged up for them instead of having to do it on their own.

102
00:07:01,760 --> 00:07:03,480
Yeah. Standardized Lego blocks.

103
00:07:03,960 --> 00:07:11,840
And, and look that, that part of loud cloud business, which is basically like a managed service and like a cloud service, really.

104
00:07:12,120 --> 00:07:17,100
So just like you get, and, and the notion of, it was in fact called utility computing, the notion.

105
00:07:17,180 --> 00:07:17,800
Oh, that's right.

106
00:07:18,160 --> 00:07:18,380
Yeah.

107
00:07:18,760 --> 00:07:20,540
VM on a tap, right.

108
00:07:20,720 --> 00:07:29,040
Is what later we started getting with AWS is essentially the same thing with loud cloud, which is, hey, I'll provision the infrastructure.

109
00:07:29,040 --> 00:07:30,380
I'll provision the virtual machine.

110
00:07:30,500 --> 00:07:38,040
I will provision the, the, the stack, basic stack, like operating system and maybe a web server or app server.

111
00:07:38,260 --> 00:07:41,280
So that is the notion like RDS.

112
00:07:41,520 --> 00:07:43,740
That is the precursor to RDS for a database.

113
00:07:43,780 --> 00:07:44,240
Right, right.

114
00:07:44,720 --> 00:07:51,620
But the managed service part of it ran into one problem, which is at that time, people still were not comfortable with shared infrastructure.

115
00:07:52,040 --> 00:07:56,680
So people, we would have customers who would come and walk in and say, hey, can you, can I see my physical server?

116
00:07:57,100 --> 00:07:58,040
Can you show me a demo?

117
00:07:58,480 --> 00:08:07,460
Can you show me, walk me through the Equinix or wherever we were sitting, our, kept our infrastructure and pinpoint the exact server that my software is running?

118
00:08:07,600 --> 00:08:07,800
Yeah.

119
00:08:07,800 --> 00:08:09,420
So that was still there.

120
00:08:09,840 --> 00:08:16,540
And so the evolution, maybe it was a cloud before cloud or maybe a little early in its times for the cloud.

121
00:08:16,960 --> 00:08:25,800
And so the evolution of it was then to say, okay, instead of giving you a service, like a cloud service, how about we give you the software?

122
00:08:25,940 --> 00:08:28,700
And that's what became Opsware, cloud cloud, Opsware.

123
00:08:29,200 --> 00:08:30,620
And it is an infrastructure automation.

124
00:08:30,780 --> 00:08:37,780
So the same automation software that was used to build the cloud, let me give that to you so that you can build your services.

125
00:08:37,780 --> 00:08:47,600
You can automate the provisioning of infrastructure, of servers, boot up of that, secure the, put the secure OS and put your secure packages and then give it over to the developer.

126
00:08:48,060 --> 00:08:50,140
But again, the net goal was same.

127
00:08:50,540 --> 00:08:56,360
Either you do it yourself or we do it for you, a set of consistent building blocks for the developers.

128
00:08:56,780 --> 00:09:01,280
And whether it doesn't have to be the person, developer doesn't just mean the person who's writing code.

129
00:09:01,340 --> 00:09:03,620
It could also be the application team, right?

130
00:09:03,680 --> 00:09:06,640
There are multiple roles within that that is setting up that much.

131
00:09:06,640 --> 00:09:16,120
So do you think there's, especially, well, kind of informed or kind of colored by the various jobs you've had throughout your career,

132
00:09:17,040 --> 00:09:24,980
do you think there's a pattern of someone wants to basically have a hosted thing and then someone wants to see the server?

133
00:09:25,220 --> 00:09:30,800
And then eventually you package up the software to give to them in basically a private cloud form, right?

134
00:09:30,840 --> 00:09:38,280
Like I ask this because like you see this in a lot of the, even, even if you, you know, like the automation vendors, like Puppet and Chef,

135
00:09:38,280 --> 00:09:41,580
like they kind of start started off as like public cloud things.

136
00:09:42,000 --> 00:09:46,580
And then eventually they all get, they all find out that customers actually want to run stuff on their own.

137
00:09:46,660 --> 00:09:48,560
Just like you were saying, I don't know.

138
00:09:49,060 --> 00:09:55,120
That seems like a near universal pattern that, that universal pattern.

139
00:09:55,320 --> 00:09:59,240
But I think the shift is that there is enough.

140
00:09:59,640 --> 00:10:03,900
There are enough people who wanted, who are willing to accept the hosted form factor.

141
00:10:03,900 --> 00:10:07,740
There is enough maturity, enough consistency APIs and SLAs.

142
00:10:08,220 --> 00:10:20,260
So what I see is if you look at the patterns, I see both continuing to coexist, which is, can you make things as turnkey as possible for me?

143
00:10:20,880 --> 00:10:27,020
And then package up everything, host everything and give it so that all I have to do is a little, little bit.

144
00:10:27,080 --> 00:10:31,160
But even there, again, you still have to do work to make that ready for your application.

145
00:10:31,860 --> 00:10:45,980
Or the second one is give me the software that allows me to offer that as a central team, IT team or a platform team, all those services as a utility for my developers, right?

146
00:10:45,980 --> 00:10:49,040
I think both models will continue to coexist.

147
00:10:49,040 --> 00:10:55,820
And both, those models are actually, I think, independent, a little bit independent of private cloud or public cloud.

148
00:10:55,920 --> 00:10:58,220
See, one is where do you host your software?

149
00:10:58,440 --> 00:11:01,200
Where do you host your environment itself, right?

150
00:11:01,520 --> 00:11:04,200
Is it a hosted environment or is it a private environment?

151
00:11:04,800 --> 00:11:10,980
But the second thing is, hey, where is the management software that you use to build out those environments?

152
00:11:10,980 --> 00:11:16,520
And that could be either offered as a software that you manage yourself or as a SaaS.

153
00:11:16,760 --> 00:11:17,420
Right, right, right.

154
00:11:17,440 --> 00:11:19,320
So there are multiple vectors there.

155
00:11:19,480 --> 00:11:33,540
Yeah, there's an interesting distinction there is, and especially drawing from what you're saying is, are we talking about, like, I want to be able to go touch my server or I want to be able to control and manage the stack, right?

156
00:11:33,540 --> 00:11:42,720
Like, you know, I don't really care where the platform is running, probably, but I want control over what the platform does versus kind of like a take it or leave it kind of situation.

157
00:11:43,000 --> 00:11:43,120
Correct.

158
00:11:43,380 --> 00:11:48,860
And so you, that's why I keep saying now we have enough viable choices that there's a spectrum.

159
00:11:49,320 --> 00:11:49,680
Right.

160
00:11:49,680 --> 00:11:59,180
And you pick and choose based on the needs, whether it is resiliency needs, security needs, data privacy needs, control needs.

161
00:11:59,280 --> 00:12:01,980
You pick where in the spectrum you want to be.

162
00:12:02,580 --> 00:12:09,080
But again, all these are just permutation combinations of the stack below.

163
00:12:09,700 --> 00:12:11,520
The goal still stays the same.

164
00:12:12,320 --> 00:12:16,460
So then, you know, I was saying there's kind of, there's kind of two threads to pick out.

165
00:12:16,520 --> 00:12:26,960
One of them is, is, is that, that kind of, let's call it like the way of business runs, like it's applications, the developers, like, you know, the, the software that you're writing.

166
00:12:26,960 --> 00:12:38,220
And it kind of, as, as a, whatever we used to call it at BMC, like IT business alignment, we had all sorts of fantastic charts about how, how IT was actually running the business.

167
00:12:38,220 --> 00:12:51,860
And there, there's, there's another path that comes up a lot in, in your, your career, which it's kind of like more internal facing IT, like automating the infrastructure, doing that service management service delivery.

168
00:12:52,120 --> 00:12:57,120
That's, that's a phrase I haven't used in a long time, you know, kind of all, all the ITIL stuff.

169
00:12:57,200 --> 00:13:04,120
What do you think, like, why do we not talk about like ITIL and IT service management as, as much as we used to?

170
00:13:04,120 --> 00:13:07,960
Cause that used to be, I feel like the thing, right?

171
00:13:07,960 --> 00:13:11,560
Like everything rotated around, like, let's map out what your service is.

172
00:13:11,780 --> 00:13:13,240
Let's have the tickets around it.

173
00:13:13,240 --> 00:13:18,540
Like you're saying service delivery and a CMDB, but I don't know, that doesn't seem to come up.

174
00:13:18,620 --> 00:13:21,860
Maybe those people are just doing their job and they don't do conference talks about it.

175
00:13:21,860 --> 00:13:23,560
I think it is the latter.

176
00:13:23,980 --> 00:13:26,320
What happens is you don't talk about Linux now.

177
00:13:26,880 --> 00:13:27,360
Right, right.

178
00:13:27,360 --> 00:13:28,680
You don't talk about operating systems.

179
00:13:28,980 --> 00:13:33,900
You don't talk about us, batching operating systems, even though that's a fundamental problem and everybody's still doing it.

180
00:13:34,120 --> 00:13:40,620
And similarly, there are basic change management processes that you don't talk about.

181
00:13:41,080 --> 00:13:42,860
But that said, they have to exist.

182
00:13:43,160 --> 00:13:45,640
You cannot automate something that does not exist.

183
00:13:46,460 --> 00:13:46,940
Right.

184
00:13:47,500 --> 00:13:47,860
Right.

185
00:13:47,920 --> 00:13:52,600
You have to have a process that you can do manually two times in a row, then you can automate it.

186
00:13:52,960 --> 00:13:58,980
And that is kind of what, so a lot of those underlying discipline that was built over the ages, right?

187
00:13:58,980 --> 00:14:06,380
Many, the last few decades has allowed us to actually do automation at a much higher level of fidelity.

188
00:14:07,340 --> 00:14:17,640
So a lot of times I see customers, they still have the idle process of ticketing process, but instead of a human generating a ticket and closing a ticket and updating a ticket, now systems do it.

189
00:14:17,920 --> 00:14:40,840
As we have done more process automation at the DevOps level and at the platform level, these things just automatically get opened and closed so that the tracking is there, the logging is there, the discipline around, you know, the troubleshooting and monitoring and logging, that all is still a very much, very much a very critical discipline.

190
00:14:41,560 --> 00:15:02,720
The remediation approaches have changed as you have gone on a platform approach, but also as you have swapped out the underlying virtual machines, which are persistent and long running to more of these ephemeral containers, what has happened is you don't, for many basic remediation steps, you don't need a human in the loop.

191
00:15:02,760 --> 00:15:09,920
You just throw out, throw the thing out and you reinstantiate it or you reboot it and the automated platform can do it, right?

192
00:15:09,960 --> 00:15:14,380
As you know, one of the things that Pivotal pioneered is this idea of repave.

193
00:15:15,160 --> 00:15:20,720
Now, in an idle world, the repave would have required, repave, what does repave mean?

194
00:15:20,840 --> 00:15:33,160
Essentially, you're taking your entire infrastructure that is running the app and with no downtime to the app, no downtime to the app, you're continuously fixing and repaving the underlying infrastructure.

195
00:15:33,560 --> 00:15:38,040
That would have required a lot of tickets, manual work, a lot of process coordination.

196
00:15:38,640 --> 00:15:40,800
But if you think about it, it is still there.

197
00:15:40,980 --> 00:15:43,620
There's a very strict sequence of repave.

198
00:15:43,620 --> 00:15:59,440
But the advances in technology with containerization allows us to do repave by just throwing away some instances or moving them to easily to some other location, fixing the host, updating it, upgrading it, and then bringing it back into configuration.

199
00:16:00,060 --> 00:16:07,660
Now, all those, instead of being individual steps, are consistent steps that have been done in the past that can now be automated as part of platform.

200
00:16:08,120 --> 00:16:12,660
So all you do is issue a single command called repave the infrastructure for me, and it happens.

201
00:16:12,940 --> 00:16:19,500
So that is really the power – platform engineering doesn't live in isolation.

202
00:16:19,720 --> 00:16:24,900
It's built on top of these subsequent layers of automation and consistency that we have built.

203
00:16:24,900 --> 00:16:37,980
Like you were saying, to repave your infrastructure in the olden times would require a lot of, like, you know, runbook thinking and kind of –

204
00:16:37,980 --> 00:16:38,400
Runbooks.

205
00:16:38,560 --> 00:16:40,320
Yeah, tickets and approval meetings.

206
00:16:40,320 --> 00:16:44,700
And it's almost – you know, there's maybe two causes of that.

207
00:16:44,760 --> 00:16:47,500
One of them is just didn't exist.

208
00:16:47,580 --> 00:16:50,580
Whether you're using VMs or, like, containers, right?

209
00:16:50,640 --> 00:16:53,380
Like, it's just so much faster to do what you were describing.

210
00:16:53,940 --> 00:17:01,480
But there's also – the other side of that feels like a certain amount of trust that it will work, right?

211
00:17:01,480 --> 00:17:08,640
I feel like a lot of the times there is a governance in sort of, like, some service delivery or an application.

212
00:17:09,180 --> 00:17:13,460
It's because some people don't trust the computers enough to do it on their own.

213
00:17:13,660 --> 00:17:15,200
Like, they want to have a checkpoint in there.

214
00:17:15,440 --> 00:17:21,420
And, yeah, I mean, like you're saying, I think over the years people have just come to trust that it will work.

215
00:17:22,040 --> 00:17:26,060
And the way it happens is that it's thanks to some of this process automation, right?

216
00:17:26,260 --> 00:17:26,520
Yeah.

217
00:17:26,700 --> 00:17:38,200
Again, as I say, if you have seen a runbook work 10 times in a row and consistently in a row and consistently deliver results, now you say, hey, I can maybe call that runbook automatically.

218
00:17:38,600 --> 00:17:41,520
Well, maybe I can now automate it as part of my subsystem.

219
00:17:42,060 --> 00:17:50,860
So these don't just happen overnight, but the fact that you can do something consistently multiple times in a row gives the trust to automate it.

220
00:17:51,440 --> 00:17:54,540
And that is where what platform has benefited from.

221
00:17:54,860 --> 00:18:02,720
And that's what we are trying to leverage as part of the platform engineering process, which is, hey, can we automate things that you know are consistent?

222
00:18:03,200 --> 00:18:05,060
To some extent, boring and easy.

223
00:18:05,360 --> 00:18:07,620
It doesn't mean governance goes away, right?

224
00:18:07,940 --> 00:18:20,220
It means that instead of doing the, when you do repave, if there were 20 steps and each of them was a separate ticket with its own approvals, now there might be just one approval at the top saying, hey, do you know what is the time window?

225
00:18:20,320 --> 00:18:22,300
Do you know it's a low risk time?

226
00:18:22,500 --> 00:18:24,140
And have you got the right approvals?

227
00:18:24,220 --> 00:18:25,600
And then you issue the repayment, right?

228
00:18:25,660 --> 00:18:30,180
That would be an example of an approval that might be still needed for that repave action.

229
00:18:30,420 --> 00:18:32,300
And that would still go through the ticketing system.

230
00:18:32,880 --> 00:18:37,520
But you're not trying to orchestrate every little piece of the runbook.

231
00:18:37,780 --> 00:18:42,600
Through a ticketing system because you now have enough, we have enough comfort in the automation.

232
00:18:42,800 --> 00:18:45,780
We understand the, each of the layers have been automated enough.

233
00:18:46,440 --> 00:18:46,460
Right.

234
00:18:46,540 --> 00:18:48,360
And proven itself to be consistent, right?

235
00:18:48,400 --> 00:18:51,720
Like that's, if you have inconsistency, there's no way you can trust it.

236
00:18:51,720 --> 00:18:55,780
It has to behave the way you assume it would.

237
00:18:55,860 --> 00:18:59,100
You cannot automate something that you can't do manually two times in a row.

238
00:18:59,660 --> 00:19:00,280
Right, right.

239
00:19:00,700 --> 00:19:00,880
Yeah.

240
00:19:00,880 --> 00:19:01,740
It's a good rule of thumb.

241
00:19:02,060 --> 00:19:02,280
All right.

242
00:19:02,360 --> 00:19:06,880
So, so after the, let's call it the ITEL era, the BMC era, where, where do you go?

243
00:19:07,020 --> 00:19:07,720
Where do you go after that?

244
00:19:07,780 --> 00:19:09,980
This is like 2011 or so, or 2008?

245
00:19:10,180 --> 00:19:12,140
Like what, what year do you go to the next?

246
00:19:12,480 --> 00:19:13,360
2008, 2008.

247
00:19:13,640 --> 00:19:23,140
And, you know, sometimes it's one of those things where you say, okay, you know, you, you think of yourself as a startup person or a big company person.

248
00:19:23,140 --> 00:19:27,820
And I always thought of myself as a startup person, but I have been in big companies now for a long time.

249
00:19:28,660 --> 00:19:42,580
And so after BMC, went to a company called Mocha 5 and pioneering started by a professor from Stanford, Monica Lam, and Vinod Khosla's company.

250
00:19:42,660 --> 00:19:45,060
So very interesting, a desktop virtualization.

251
00:19:45,260 --> 00:19:54,280
And the idea was how can you give customers a desktop practically on a USB key that you just carry anywhere.

252
00:19:54,560 --> 00:19:54,840
Yeah.

253
00:19:54,960 --> 00:19:56,800
Put it into the system and be up and running.

254
00:19:57,260 --> 00:20:02,080
And so it was both offline yet available all the time, always synced when it was up and running.

255
00:20:02,820 --> 00:20:18,640
And so VDI was already in play, but still, if you think about it, you know, I think when you think about innovation, right, just like the first phase of loud cloud, the idea that I can have a shared server and still be secure was mind bending.

256
00:20:18,980 --> 00:20:19,100
Right.

257
00:20:19,500 --> 00:20:20,980
But now it doesn't matter, right?

258
00:20:21,060 --> 00:20:23,440
Everybody, fast forward, now it's very, everybody's comfortable.

259
00:20:23,860 --> 00:20:31,040
When we were doing Mocha 5, VDI was there already, but the connectivity was not as good always.

260
00:20:31,420 --> 00:20:41,240
So people, the need for a desktop that you could have with you with all the data that you could carry around was very valuable and without necessarily having a device.

261
00:20:41,900 --> 00:20:52,160
And so, but now if you think about it, fast forward again, with 4G, 5G, et cetera, the connectivity and disconnected mode of operations is less critical, I would say.

262
00:20:52,260 --> 00:20:52,440
Yeah.

263
00:20:52,440 --> 00:20:53,880
Most people understand, right?

264
00:20:53,940 --> 00:20:56,980
Especially with phones and apps, all of them require connectivity all the time.

265
00:20:57,060 --> 00:20:58,620
So you're a lot, lot more comfortable.

266
00:20:59,480 --> 00:21:03,320
And so that was the premise of Mocha 5, I mean, really a fabulous time.

267
00:21:03,900 --> 00:21:10,460
And after Mocha 5, did a cloud security startup and then a container security startup.

268
00:21:11,340 --> 00:21:18,800
And so different, so when you think about, it's not just about automation of infrastructure, but just various aspects.

269
00:21:19,100 --> 00:21:31,080
How does the automation power the user experience, how does it power the employee experience, how does it power the partner and customer experience, how do you make sure that all that experiences are then secure?

270
00:21:32,020 --> 00:21:40,460
So those were, and container, especially Kubernetes had started to build up in popularity and so did a container security startup.

271
00:21:40,620 --> 00:21:46,520
And then I joined VMware, primarily doing cloud management or automation.

272
00:21:46,520 --> 00:21:58,880
While we've gone through many phases of that cloud management journey at VMware from 2016, I would say onwards, synthesizing it down to, it's not about just delivering a VM.

273
00:21:59,200 --> 00:22:02,700
It's not about doing individual network storage and compute virtualization.

274
00:22:03,300 --> 00:22:20,060
But early on itself, the role of cloud management, which was we realized and later branded ARIA, was how can you bring all those pieces together so that you can give a set of services, public cloud-like services that were complete and comprehensive?

275
00:22:20,060 --> 00:22:26,220
And how can you ship a set of management software or provide that management software as a SaaS so that customers can do it themselves?

276
00:22:26,800 --> 00:22:28,040
That was the big part, right?

277
00:22:28,280 --> 00:22:46,300
Which is, hey, you're not beholden to just the set of services that you may have from a private or public cloud, but can you curate your own set of services on-prem or on your captive infrastructure, whether it's on-prem or not, that have a similar type of experience, easy for the developers to consume?

278
00:22:46,300 --> 00:22:47,160
Yeah, that makes sense.

279
00:22:47,480 --> 00:22:49,340
So I have two last questions.

280
00:22:49,600 --> 00:23:08,380
And one of them is, now that we've kind of gone over various places you've worked, I wonder if, like, what are some ways of, like, working and managing a startup that you find helpful to apply in a larger organization, like we're in now and at VMware?

281
00:23:08,580 --> 00:23:10,840
Like, what are things that you bring over?

282
00:23:10,960 --> 00:23:14,740
And, you know, if you also want to make it interesting, what are things you don't bring over?

283
00:23:14,740 --> 00:23:17,020
That's a wonderful question.

284
00:23:17,160 --> 00:23:20,260
So there's some aspects of startup that you should absolutely keep.

285
00:23:21,160 --> 00:23:26,400
And it is relentless focus on product market fit.

286
00:23:26,840 --> 00:23:35,680
Just because you have a mature product that customers are paying a lot of money for doesn't mean you can rest on your laurels.

287
00:23:36,100 --> 00:23:36,240
Right.

288
00:23:36,460 --> 00:23:55,700
You have to see how are the needs for that particular service that you're offering customer software or service evolving and how the ecosystem is evolving and constantly test and make sure that you're driving that innovation that is needed to help them with the goal.

289
00:23:56,200 --> 00:23:59,100
It doesn't mean you're changing your goal every time.

290
00:23:59,160 --> 00:23:59,380
Right.

291
00:23:59,720 --> 00:24:01,760
The goals actually stay pretty consistent.

292
00:24:02,260 --> 00:24:04,300
Like in our case, my goal is singular goal.

293
00:24:04,620 --> 00:24:06,920
I need to accelerate quote production.

294
00:24:07,380 --> 00:24:08,540
It's a very simple goal.

295
00:24:08,720 --> 00:24:12,900
If it used to take three months, today it has to take three days and then three hours and three minutes.

296
00:24:13,120 --> 00:24:13,920
That is the goal.

297
00:24:15,440 --> 00:24:29,140
But what new technologies are getting introduced, new approaches are getting introduced, new services are getting introduced, how do those change the landscape and how can you continuously keep not only up to date with it, but take advantage of that.

298
00:24:29,400 --> 00:24:29,880
Leapfrog.

299
00:24:30,540 --> 00:25:00,520
And that curiosity is something that is always inherent in a startup. So definitely you have to keep that curiosity going. The other thing is, generally you tend to in a startup have less red tape in the sense the different silos, whether it is marketing and sales and product and engineering and, you know, support tend to not talk as much or even if they talk, they tend to talk as much.

300
00:25:00,540 --> 00:25:25,160
They tend to be a lot more siloed and fiefdoms that are established in a larger company. In a startup, that's not the case. You really, all of you just are so focused on survival and getting the first land and making it happen that you work together. Actually, there is nothing that prevents you from doing the same thing in a larger company. That's what I've realized, especially, I think, and with Hawk's approach.

301
00:25:25,340 --> 00:25:47,440
The Broadcom Hawk creates these divisions almost like a mini company. And so you have all the functions fully aligned within a division. And those functions better roll together in concert towards a singular goal. And when you do that, really the movement is much faster, it's a lot more efficient, and you actually get better results.

302
00:25:47,440 --> 00:25:53,820
So that is one thing that I would translate, might seem counterintuitive, but I would definitely translate from a startup to a large company.

303
00:25:54,380 --> 00:26:07,180
Yeah, I like the, you know, if I were to, I don't know how I would file it in my head, the startup aspect you were saying is, in a startup, you're trying to get product market fit, like figure out the product.

304
00:26:07,180 --> 00:26:14,720
And like you're saying, you know, you got to land a deal and, you know, it's, it's constantly getting to that initial, like getting to that initial phase.

305
00:26:15,340 --> 00:26:22,500
Whereas in, in contrast, it's not like you don't do that at a large organization, but you more shift into continuous product market fit.

306
00:26:22,660 --> 00:26:30,700
We are always going back and revisiting, like, do we still have product market fit and like, has this changed around and, and yeah, I mean, I agree with you.

307
00:26:30,700 --> 00:26:39,300
It's like, I always think unhelpful bureaucracy is a choice that, that organizations make, like, they're not always aware that they're making it.

308
00:26:39,300 --> 00:26:51,120
And you just kind of like flow into that river of bureaucracy, but eventually you can just decide, we don't want to have all this red tape and, you know, do something about it, which, which is nice.

309
00:26:51,120 --> 00:26:59,660
Well, so the last question I was going to ask, so we spent, you know, we kind of started off talking about like, um, where's DevOps and platform engineering, how we progressed with that.

310
00:26:59,660 --> 00:27:07,440
And do you think we'll get to the point where we don't really have much separation between development and operations anymore?

311
00:27:07,440 --> 00:27:21,100
Like, because a lot of what we've been talking about is it's almost like if there's operations at the, at the bottom of the stack and developers are at the top or the business, you know, running at the top, a lot of what we talked about is kind of like bringing them ever closer and closer together.

312
00:27:21,120 --> 00:27:33,940
And kind of having them help each other, but it seems like there's still plenty of operations roles and plenty of development roles instead of it just being kind of fully automated and only application developers running around.

313
00:27:33,940 --> 00:27:38,500
I don't think that that is, that that is going to happen because it's not a feasible approach.

314
00:27:39,380 --> 00:27:49,120
When you think about a customer's environment, one of these large healthcare firms, financial services firms, doesn't matter, retail, and they are building their own environment.

315
00:27:50,120 --> 00:27:57,380
There will always be the role of operations and the role of platform engineering doesn't go away.

316
00:27:57,500 --> 00:28:05,360
And that is fundamentally different from the role of the team that is writing business logic to do, let us say, grocery transactions.

317
00:28:06,100 --> 00:28:16,260
And so the goal of infra and platform is to remove as much of the complexity and present simple primitives to the developers.

318
00:28:16,700 --> 00:28:16,800
Right.

319
00:28:17,140 --> 00:28:18,760
But that role doesn't change.

320
00:28:18,840 --> 00:28:19,620
Somebody has to do it.

321
00:28:19,660 --> 00:28:21,640
If developers themselves have to do it, that doesn't help.

322
00:28:22,040 --> 00:28:23,900
So there are only two scenarios then, you know.

323
00:28:24,280 --> 00:28:35,800
One is you could go to a cloud-like offering where everything is set up for you and those primitives are all you offer and you buy them by the SIP or something like that.

324
00:28:36,220 --> 00:28:36,500
Right.

325
00:28:36,500 --> 00:28:46,440
As a developer, as an application team in an organization, which means, of course, you have no control of the infrastructure, no control of the policies, no control, but you're just getting those primitives.

326
00:28:46,740 --> 00:28:48,080
And that is a valid model.

327
00:28:48,680 --> 00:28:53,920
And you will see the hyperscalers are, you know, offering those models.

328
00:28:54,460 --> 00:29:00,960
Other model is you do the same thing in-house with your own infrastructure or with the public cloud infrastructure and curate that experience.

329
00:29:00,960 --> 00:29:06,260
But ultimately, somebody has to curate that experience so that the developers can have that speed.

330
00:29:06,780 --> 00:29:10,120
So it's not that operations goes away or developers do everything.

331
00:29:10,220 --> 00:29:11,220
That's the wrong thing.

332
00:29:11,580 --> 00:29:15,080
This idea, oh, I'm giving DevOps and I'm giving developers YAML code.

333
00:29:15,540 --> 00:29:17,040
Developers don't want to write YAML code.

334
00:29:17,300 --> 00:29:21,640
The whole goal of what we are doing is developers should just write business code.

335
00:29:22,400 --> 00:29:26,220
And everything else should be taken care of by operations and platform teams.

336
00:29:26,740 --> 00:29:26,820
Right.

337
00:29:27,060 --> 00:29:31,060
And someone has to do that to build the platforms and maintain them and run them.

338
00:29:31,860 --> 00:29:36,820
So the infra operations, you know, and platform operations.

339
00:29:37,560 --> 00:29:46,880
So the IT organizations, as you see, are evolving from, you know, OK, now they have private cloud teams and more and more so platform teams.

340
00:29:47,040 --> 00:29:55,940
And this is critical because these teams are the ones who offer the set of services with the right set of SLAs and visibility to these application teams.

341
00:29:56,620 --> 00:30:02,960
And ultimately, the goal is so that the application teams add at a drop of a hat based on market needs.

342
00:30:02,960 --> 00:30:08,200
They can quickly make the changes to their software as soon as possible and get it out as soon as possible.

343
00:30:08,720 --> 00:30:10,380
Reliably, safely, consistently.

344
00:30:11,680 --> 00:30:11,780
Yeah.

345
00:30:12,020 --> 00:30:12,280
Yeah.

346
00:30:12,400 --> 00:30:13,040
Well, that sounds good.

347
00:30:13,040 --> 00:30:14,900
I mean, that's what we're always shooting for.

348
00:30:15,040 --> 00:30:15,840
I think that's good stuff.

349
00:30:15,840 --> 00:30:18,260
Well, I appreciate getting the chance to talk with you.

350
00:30:18,380 --> 00:30:24,140
It's fun going down memory lane a little bit and use the word runbook again after all these years.

351
00:30:25,220 --> 00:30:26,100
That was good stuff.

352
00:30:26,160 --> 00:30:26,340
All right.

353
00:30:26,380 --> 00:30:28,000
Well, well, well, thanks for being on.

354
00:30:28,040 --> 00:30:33,420
And I think I mean, I think the obvious thing is if, you know, we do a lot of great work over here at Tonsu.

355
00:30:33,480 --> 00:30:38,260
We've got the Tonsu platform, which is easy enough to find if you go to tonsu.vmware.com.

356
00:30:38,560 --> 00:30:41,000
And we're around here and there doing things.

357
00:30:41,140 --> 00:30:43,560
But all sorts of platform talk to be had as well.

358
00:30:43,560 --> 00:30:50,300
And we'll have to we'll have to have you back to have kind of more discussion about actually Tonsu platform and the technology.

359
00:30:50,380 --> 00:30:51,080
That would be wonderful.

360
00:30:51,460 --> 00:30:51,580
Yeah.

361
00:30:51,880 --> 00:30:52,160
All right.

362
00:30:52,180 --> 00:30:52,700
Well, thanks again.

363
00:30:52,900 --> 00:30:53,360
That was great.