1
00:00:00,000 --> 00:00:04,080
Rita's back, as always, for an interview episode, and we have a guest here.

2
00:00:04,200 --> 00:00:05,440
Why don't you introduce yourself, guest?

3
00:00:05,880 --> 00:00:06,800
Hello, Michael and Rita.

4
00:00:07,000 --> 00:00:08,120
Thank you for the opportunity.

5
00:00:08,440 --> 00:00:09,200
I'm AJ Patel.

6
00:00:09,340 --> 00:00:14,000
I run the Modern Application Business Unit at VMware, and really excited to be here with you.

7
00:00:14,480 --> 00:00:15,840
I'm excited that you're here.

8
00:00:15,980 --> 00:00:21,560
I've been wanting to do this for a while because of your history, if you will.

9
00:00:21,740 --> 00:00:26,660
Coming at this with some of your background, specifically, you were right there, front and

10
00:00:26,660 --> 00:00:29,940
center, on the front lines during what I would call the app server war.

11
00:00:30,300 --> 00:00:33,820
WebLogic, WebSphere, JBoss, all those things.

12
00:00:34,020 --> 00:00:36,780
And so I was super excited to get to work with you again.

13
00:00:36,940 --> 00:00:40,020
Tell us a little bit about that, about your experience during that time.

14
00:00:40,200 --> 00:00:43,180
My own history, as you know, is early days at BEA.

15
00:00:43,240 --> 00:00:44,820
I wasn't really part of the app server team.

16
00:00:44,960 --> 00:00:46,720
I was part of the integration team.

17
00:00:46,900 --> 00:00:49,520
So I caught the EAI bandwagon, if you will.

18
00:00:50,060 --> 00:00:53,120
So I'm kind of dating myself, as you can see, from just the use of the terminology.

19
00:00:53,120 --> 00:00:56,380
And then very quickly, that EAI became a SOA metaphor.

20
00:00:56,700 --> 00:01:01,760
But if you look at the history, we went from monolithic applications to end-tier apps, to

21
00:01:01,760 --> 00:01:03,600
PaaS, platform as a service.

22
00:01:03,600 --> 00:01:05,600
And now we're hitting microservices, right?

23
00:01:05,660 --> 00:01:08,600
And the whole notion of public cloud and cloud native, as we call it.

24
00:01:08,820 --> 00:01:12,780
And consistently across those, I think of both the whole notion of middleware.

25
00:01:12,920 --> 00:01:14,820
And people hate when I use that word almost now, right?

26
00:01:14,840 --> 00:01:15,500
It's called a bad word.

27
00:01:15,580 --> 00:01:19,980
But if I look at what all of these application and data services are, they're nothing more

28
00:01:19,980 --> 00:01:24,060
than granular middleware services that were part of these larger platforms we built.

29
00:01:24,140 --> 00:01:28,780
So one trend I've seen is this general trend of breaking these large suites that software

30
00:01:28,780 --> 00:01:32,520
vendors love to sell, right, into the enterprise, because that's what we sold to enterprise, made

31
00:01:32,520 --> 00:01:36,960
it easier to package up these things and sell, to now more of these, you know, services that

32
00:01:36,960 --> 00:01:42,380
are easy to consume and are managed and are accessible to developers, right?

33
00:01:42,900 --> 00:01:44,860
But at the end, these are really about productivity.

34
00:01:45,100 --> 00:01:49,760
So the idea is, how do you give developers a set of things that they can quickly build applications

35
00:01:49,760 --> 00:01:52,860
and not have to worry about, whether it's transactions, whether it's security, whether

36
00:01:52,860 --> 00:01:55,720
it's messaging, whether a database persistently or et cetera.

37
00:01:55,800 --> 00:01:57,180
That notion has always existed.

38
00:01:57,440 --> 00:02:02,760
So I think middleware as a layer to give you portability, developer productivity, being

39
00:02:02,760 --> 00:02:06,540
able to scale, those benefits or those patterns haven't changed.

40
00:02:06,680 --> 00:02:10,700
The architectural patterns have gotten better, I would say more refined over the time.

41
00:02:11,100 --> 00:02:13,140
But there's a lot of learnings in my view.

42
00:02:13,480 --> 00:02:17,960
When I looked up an app server, and if I break up its parts and I see a microservices architecture

43
00:02:17,960 --> 00:02:19,340
today, the component still exists.

44
00:02:19,420 --> 00:02:22,580
You still have a messaging or event-driven architecture.

45
00:02:22,980 --> 00:02:26,660
You still have a transactional system that you need to build, usually backed by a database,

46
00:02:26,860 --> 00:02:27,020
right?

47
00:02:27,240 --> 00:02:29,220
You still have scale-up, scale-out architecture.

48
00:02:29,360 --> 00:02:34,000
So the learnings are, you need some kind of a productivity app platform.

49
00:02:34,460 --> 00:02:39,300
Whether it's an app server, whether it was a PaaS, or now moving to the world of Kubernetes,

50
00:02:39,300 --> 00:02:43,660
I think there's a gap here that we've got too fine-grained and there's a need to package

51
00:02:43,660 --> 00:02:45,200
up a more modular platform.

52
00:02:45,800 --> 00:02:48,040
And that's really the opportunity, as I see from my history.

53
00:02:48,580 --> 00:02:49,280
That is spot on.

54
00:02:49,920 --> 00:02:54,820
This occurred to me, I was a few years ago reading an analyst report.

55
00:02:54,960 --> 00:02:55,660
It was a taxonomy.

56
00:02:55,840 --> 00:02:57,160
It was a PaaS taxonomy.

57
00:02:57,360 --> 00:02:58,900
And there were like 19 PaaSs.

58
00:02:59,000 --> 00:03:04,860
It had everything from like mom PaaS, which was message-oriented middleware PaaS, to I PaaS,

59
00:03:04,960 --> 00:03:09,280
to DB PaaS, to A PaaS, to all these different PaaSs.

60
00:03:09,360 --> 00:03:10,920
So spot on with that.

61
00:03:11,080 --> 00:03:15,620
Still some of the same components, just broken up and renamed as a service.

62
00:03:16,100 --> 00:03:18,840
Yeah, the architecture pattern was loosely coupled, right?

63
00:03:19,360 --> 00:03:22,220
More and more developers own responsibility of the app.

64
00:03:22,260 --> 00:03:26,800
I think what Docker and the whole container and now Kubernetes deliver is, it's really made

65
00:03:26,800 --> 00:03:29,540
it easy to package up and make the deployment easier, right?

66
00:03:29,840 --> 00:03:32,020
So now developers can take everything they need.

67
00:03:32,480 --> 00:03:37,760
And so the granularity of a component or an application has really shrunk.

68
00:03:37,760 --> 00:03:42,100
In the world of SOA, the business contract and the services contract are much more coarse-grained.

69
00:03:42,620 --> 00:03:44,920
In microservices, you have much more smaller components.

70
00:03:45,180 --> 00:03:48,700
Like I remember the promise of EJBs 20 years ago, right?

71
00:03:48,940 --> 00:03:54,420
The idea was creating, you know, at BA, I think in 2000, our company bought 20 components.

72
00:03:54,540 --> 00:03:56,660
They were e-commerce components.

73
00:03:56,820 --> 00:04:00,080
And the whole idea of modularity was that you could take these building blocks and quickly

74
00:04:00,080 --> 00:04:01,820
build an application, but these were the components.

75
00:04:02,220 --> 00:04:04,980
You change the word component to microservices, you know, it's quick.

76
00:04:04,980 --> 00:04:08,560
And I know it's not the same, but you can start to see the principles haven't changed.

77
00:04:08,660 --> 00:04:10,740
The problems do change with the microservice world.

78
00:04:10,860 --> 00:04:16,020
So things like DevOps as a delivery, as a practice for how we deliver software becomes

79
00:04:16,020 --> 00:04:18,760
even more urgent, more critical as you break this down.

80
00:04:18,840 --> 00:04:22,260
But it's an improvement of a lot of good practices and a lot of learnings we carry forward.

81
00:04:22,360 --> 00:04:23,980
Every generation has taught us something new.

82
00:04:24,000 --> 00:04:26,880
And I think the past productivity has been just unbelievable.

83
00:04:27,200 --> 00:04:29,900
Something that I wasn't directly involved in, I competed with it.

84
00:04:29,900 --> 00:04:34,880
And so now being part of that Spring PaaS platform owner, if you will.

85
00:04:34,980 --> 00:04:36,200
It's, it's pretty exciting.

86
00:04:36,480 --> 00:04:37,160
It's pretty exciting.

87
00:04:37,340 --> 00:04:42,060
Tell me if what you're reminding me of is wrong, but when you're going over EJB, the promise

88
00:04:42,060 --> 00:04:50,960
of enterprise Java beans and SOA stuff is I'd forgotten that a lot of that effort was modularizing

89
00:04:50,960 --> 00:04:53,700
business process and workflows, right?

90
00:04:53,700 --> 00:05:00,060
Like that, like this EJB is for paying for something or this EJB is for like approving

91
00:05:00,060 --> 00:05:03,240
a job title change, right?

92
00:05:03,240 --> 00:05:05,860
There was a tremendous amount of, what did they call it?

93
00:05:05,920 --> 00:05:10,820
Like industry working groups that were trying to codify what this service looks like and

94
00:05:10,820 --> 00:05:17,020
therefore have the reusable component, not just be like a technical thing.

95
00:05:17,120 --> 00:05:19,020
Like here's how you, I don't know.

96
00:05:19,100 --> 00:05:19,720
Business service.

97
00:05:19,940 --> 00:05:20,180
Yeah.

98
00:05:20,180 --> 00:05:27,160
And I hadn't really thought about that, but we don't really like do that yet in, in like

99
00:05:27,160 --> 00:05:28,640
our microservices days.

100
00:05:28,640 --> 00:05:30,360
You're actually seeing some of that now.

101
00:05:30,500 --> 00:05:31,660
If you, I'll pick on something else.

102
00:05:31,680 --> 00:05:36,920
If you look at a company in Twilio and some of the communication services that you now have

103
00:05:36,920 --> 00:05:37,540
just used.

104
00:05:37,720 --> 00:05:39,540
So you have a little bit of mix of both, right?

105
00:05:40,040 --> 00:05:42,820
You have higher level services that you're not procured.

106
00:05:42,940 --> 00:05:43,580
You don't even buy.

107
00:05:43,580 --> 00:05:49,300
So we call it PaaS or application services or public cloud services that the abstractions

108
00:05:49,300 --> 00:05:51,260
are getting more well-defined.

109
00:05:51,380 --> 00:05:55,920
We went from complex schemas and XML and web services, right?

110
00:05:55,960 --> 00:06:00,700
Something much more simpler with Rust, JSON, et cetera, the protocol.

111
00:06:00,900 --> 00:06:04,540
We're also starting to see that business services you can actually just consume.

112
00:06:04,940 --> 00:06:08,160
The entire company like Twilio has formed around communication APIs.

113
00:06:08,160 --> 00:06:09,660
And also I don't have to worry about those, right?

114
00:06:09,700 --> 00:06:11,520
So there's a mix of that's happening.

115
00:06:12,040 --> 00:06:15,440
The big trend here is you're buying it as a service versus setting up that component

116
00:06:15,440 --> 00:06:17,000
and building it yourself and operating it.

117
00:06:17,040 --> 00:06:20,320
So one big trend is you're consuming it as a service is one trend.

118
00:06:21,000 --> 00:06:24,220
The second trend you'll see here is my own application.

119
00:06:24,360 --> 00:06:25,760
I'm breaking it down to smaller pieces.

120
00:06:26,640 --> 00:06:29,280
Domain-driven design is really becoming really critical.

121
00:06:29,600 --> 00:06:34,000
So I'm starting to self-contain everything around a capability or function, but a much more

122
00:06:34,000 --> 00:06:34,640
granular level.

123
00:06:35,420 --> 00:06:41,900
And then the application developer's job is to build an app or solution or workflow by composing

124
00:06:41,900 --> 00:06:42,740
these pieces together.

125
00:06:42,900 --> 00:06:46,780
Some things are bits of code I wrote, self-contained as a service.

126
00:06:46,960 --> 00:06:48,980
Some things that I'm procuring or acquiring.

127
00:06:49,420 --> 00:06:52,620
Some things are libraries I'm taking from open source to build these things as well.

128
00:06:53,420 --> 00:06:56,560
And so this world of a new app is a composite app.

129
00:06:57,060 --> 00:07:03,900
That's a combination of images, code you build, services you're wiring in at runtime, not even

130
00:07:03,900 --> 00:07:05,100
at build time.

131
00:07:05,220 --> 00:07:06,700
And so how do you start to manage this?

132
00:07:06,740 --> 00:07:08,200
That's the new fun world we're living in.

133
00:07:08,300 --> 00:07:08,920
Yeah, yeah.

134
00:07:08,920 --> 00:07:09,820
To manage control and flexibility.

135
00:07:10,140 --> 00:07:17,120
I like that explanation where those business modules have shifted to SaaS things, essentially.

136
00:07:17,460 --> 00:07:21,780
Like it gets to Rita's point of all the different types of cloud things.

137
00:07:21,860 --> 00:07:23,140
I remember those reports.

138
00:07:23,300 --> 00:07:23,900
There's lots of them.

139
00:07:24,060 --> 00:07:27,960
And I think a lot of those categories were trying to, a lot of those analyst reports were

140
00:07:27,960 --> 00:07:29,580
trying to categorize exactly that.

141
00:07:29,660 --> 00:07:34,900
The types of business services versus just lower level technical things.

142
00:07:35,180 --> 00:07:37,500
How do we render a UI or whatever?

143
00:07:37,580 --> 00:07:39,160
Those kinds of services are great, right?

144
00:07:39,200 --> 00:07:45,920
Like it takes care of a huge amount of operational problems that you would have in the pre-SaaS

145
00:07:45,920 --> 00:07:48,040
days, which is wonderful.

146
00:07:48,300 --> 00:07:49,080
And global scale.

147
00:07:49,200 --> 00:07:49,900
So I build an app.

148
00:07:50,100 --> 00:07:51,500
I need to deploy it in another region.

149
00:07:52,060 --> 00:07:56,460
How do I deal with all the local constraints or leveraging the infrastructure?

150
00:07:57,300 --> 00:07:58,940
And this is like communication is a big problem.

151
00:07:59,020 --> 00:07:59,600
It's like SMS.

152
00:07:59,760 --> 00:08:02,700
I was talking to another company that's doing something similar in this space.

153
00:08:02,700 --> 00:08:05,720
And they're like, we provide SMS as a service.

154
00:08:05,920 --> 00:08:07,680
So developers don't have to worry about it.

155
00:08:07,700 --> 00:08:11,300
And we provide a very simple programming model by which you can consume this service.

156
00:08:11,500 --> 00:08:16,260
But we make sure the messages are delivered to each of these 20 countries in Africa.

157
00:08:16,720 --> 00:08:18,580
And they've set up the infrastructure to do that.

158
00:08:18,680 --> 00:08:24,340
So this is where the world is coming together between cloud and a traditional self-contained

159
00:08:24,340 --> 00:08:25,920
application server, right?

160
00:08:26,040 --> 00:08:27,380
The deployment model was much more.

161
00:08:28,040 --> 00:08:30,320
App server was a box you put applications into.

162
00:08:30,800 --> 00:08:34,980
The internet and the cloud is, quote, unquote, the platform on which you're deploying these

163
00:08:34,980 --> 00:08:35,700
services to.

164
00:08:35,840 --> 00:08:38,560
So all of a sudden, the problem statement has changed, right?

165
00:08:38,580 --> 00:08:44,500
It's no longer a foundation of a PaaS or a container of an app server or a Java instance,

166
00:08:44,560 --> 00:08:46,620
or if you will, that you want to set up on a JVM somewhere.

167
00:08:46,780 --> 00:08:49,160
It's now a collection of these things running at scale.

168
00:08:49,160 --> 00:08:51,160
And you're wiring them up to talk to each other.

169
00:08:51,580 --> 00:08:54,540
You're making me think when we think about cloud services for developers, right?

170
00:08:54,540 --> 00:08:55,300
We've talked about this.

171
00:08:55,400 --> 00:08:55,980
There's hundreds.

172
00:08:56,460 --> 00:09:00,580
Yet the onus is still on the developer decision together to build the thing they're trying

173
00:09:00,580 --> 00:09:01,120
to build.

174
00:09:01,400 --> 00:09:06,380
What we propose is, as you said, put it all together so they have it all in one place and

175
00:09:06,380 --> 00:09:07,320
not have to worry about that.

176
00:09:07,420 --> 00:09:08,620
Reducing even more toils.

177
00:09:08,860 --> 00:09:09,640
That's what I'm thinking about.

178
00:09:09,680 --> 00:09:10,700
The evolution of that.

179
00:09:10,700 --> 00:09:16,760
The other thing that strikes me is we talked about Conway's Law in a previous discussion

180
00:09:16,760 --> 00:09:23,320
and how this evolution from SOA to microservices and just thinking about it as granularity, but

181
00:09:23,320 --> 00:09:26,180
also how it impacts your operating model.

182
00:09:26,380 --> 00:09:32,280
You can't talk about microservices without talking about DevOps, without talking about domain-driven

183
00:09:32,280 --> 00:09:34,740
design, without talking about agile practices.

184
00:09:34,740 --> 00:09:40,680
So that's probably been an interesting evolution for you to watch and see, especially having left

185
00:09:40,700 --> 00:09:44,340
the middleware world and gone to infrastructure software and now back.

186
00:09:44,440 --> 00:09:49,300
I used to talk about my buddy Yafim and Massimo from almost a decade ago when I used to work

187
00:09:49,300 --> 00:09:49,700
in the middleware.

188
00:09:49,720 --> 00:09:51,700
I call them Mr. and Mr. Middleware.

189
00:09:53,380 --> 00:09:57,680
And we used to talk about this concept and we didn't know what to call it even then.

190
00:09:57,760 --> 00:10:02,700
And we said there is this layer above infrastructure, but it's more flexible than an opinion it

191
00:10:02,700 --> 00:10:03,060
has.

192
00:10:03,060 --> 00:10:06,420
And then it also competed with the products that now I am responsible.

193
00:10:06,660 --> 00:10:08,460
And we call it this IaaS plus layer.

194
00:10:09,020 --> 00:10:14,340
It was this flexible modular PaaS that gave you a lot more productivity above infrastructure,

195
00:10:14,340 --> 00:10:18,640
but was not as constraining, if you will, and supported all application deployment stuff.

196
00:10:19,240 --> 00:10:25,740
And what's happened is with containers, with Kubernetes, you effectively now have a toolkit

197
00:10:25,740 --> 00:10:29,940
that allows you to package up application, give that control back in the hand of the developer.

198
00:10:30,040 --> 00:10:34,840
There's this constant battle of how much control you give the developers or the platform teams.

199
00:10:35,040 --> 00:10:40,760
It has been an ongoing battle between the architects who own enterprise architecture teams, right?

200
00:10:41,060 --> 00:10:42,940
Who need to set up the guardrails, if you will.

201
00:10:43,440 --> 00:10:45,260
The developers need more self-service flexibility.

202
00:10:45,660 --> 00:10:48,440
We've been in this constant tug of war of where the line is.

203
00:10:48,880 --> 00:10:52,260
And I think the beauty of Kubernetes and some of the work is we can start to now,

204
00:10:52,360 --> 00:10:56,740
we layered this both as an infrastructure IaaS, but also the platform on which to deliver capability.

205
00:10:56,740 --> 00:11:04,740
And so we are all on this race to take what TaaS has successfully done for the largest enterprises,

206
00:11:04,740 --> 00:11:13,000
but make it much more ubiquitous and much more pervasive to leverage the breadth and the ubiquity of cloud.

207
00:11:13,720 --> 00:11:16,080
And so that's really where the next innovation is going to happen.

208
00:11:16,240 --> 00:11:20,020
And so I'm pretty excited about the practices are evolving.

209
00:11:20,200 --> 00:11:22,100
The platform is becoming more richer.

210
00:11:22,680 --> 00:11:31,520
It's becoming more open and more standards-driven, allows us to start to really layer on and take all the experience and capability we build with TaaS

211
00:11:31,520 --> 00:11:34,740
and the productivity that is unbelievable productivity that I've seen, right?

212
00:11:34,840 --> 00:11:36,420
And what TaaS continues to deliver.

213
00:11:37,020 --> 00:11:42,880
But extending that to a Kubernetes world or leveraging the Kubernetes more natively, that is really a huge opportunity for us.

214
00:11:43,120 --> 00:11:47,220
I want to go back a little bit too to talk about the evolution of microservices, right, from SOA.

215
00:11:47,360 --> 00:11:54,960
When microservices was first coming on the scene, if you will, there was a lot of talk about how microservices is, you know, people were, it's just SOA done.

216
00:11:55,040 --> 00:11:56,220
But there's more to it than that.

217
00:11:56,280 --> 00:12:04,880
I think the key difference was SOA also was one of those architect enterprise, what Michael, you were saying, at a business services level.

218
00:12:04,960 --> 00:12:15,980
The intent was really much more to say, how do I take my, either my legacy application, wrap them up, or start to build these kind of building blocks that led to this whole BPM or workflow.

219
00:12:16,500 --> 00:12:21,920
I also had a technology called Beeple, business process execution language, if you remember, how you wire these things up.

220
00:12:21,960 --> 00:12:24,280
So it was much more at a higher level, if you will.

221
00:12:24,480 --> 00:12:33,480
And as you said, it was more on process automation and driving those new applications or taking legacy ERP applications and providing that customization layer on top.

222
00:12:33,600 --> 00:12:35,620
That was where bulk of the SOA efforts.

223
00:12:35,720 --> 00:12:43,240
It was also the next generation integration using well-defined services contracts versus doing it in a more one-off adapter manner, et cetera.

224
00:12:43,360 --> 00:12:46,360
So those are the kinds of problem or EAI evolution.

225
00:12:46,860 --> 00:12:53,320
That's where it ended up more in the business process automation space, more in terms of, you know, wrapping up capability, right?

226
00:12:53,320 --> 00:12:57,140
It didn't really become the way you build your new next generation application.

227
00:12:57,600 --> 00:13:01,200
It was how you connect to something that you wanted to integrate with, right?

228
00:13:01,960 --> 00:13:08,380
On the other hand, what I saw with Beeple Paths, and by the way, what a surprise when I took this business over, how Spring had evolved.

229
00:13:08,620 --> 00:13:16,140
Spring often would utilize this amazing thing that drove the injection model into reality, but it was considered a heavy framework, right?

230
00:13:16,580 --> 00:13:21,900
And now I look at Spring Boot, Spring Cloud, and some of the work we're doing around Spring Cloud Gateway or Dataflow.

231
00:13:22,320 --> 00:13:24,480
It's really putting the power in the hands of the developer.

232
00:13:24,760 --> 00:13:25,660
It's becoming more lighter.

233
00:13:25,840 --> 00:13:27,060
It's becoming more productive.

234
00:13:27,340 --> 00:13:37,120
And so what was exciting was the PaaS revolution was really about simplifying the life of the developer who wanted to get some basic web application or transactional application out.

235
00:13:37,860 --> 00:13:40,000
And so I saw these two parallel evolution.

236
00:13:40,140 --> 00:13:45,820
One was more in the integration evolution, if you will, with Sova, and the application development evolution with PaaS.

237
00:13:46,160 --> 00:13:46,380
Yeah.

238
00:13:46,460 --> 00:13:52,660
And we're now having an interesting gesture which says, okay, what have we learned in the world of public cloud and microservices?

239
00:13:53,180 --> 00:14:00,520
How do we now bring the same productivity, the simplicity, the security, the management value into this world, right?

240
00:14:00,560 --> 00:14:01,980
Because now I've got a whole bunch of toolkit.

241
00:14:02,140 --> 00:14:03,340
I've got 400 piece parts.

242
00:14:03,460 --> 00:14:06,100
I've got tremendous power at my hands.

243
00:14:06,240 --> 00:14:10,280
But I have to be an amazing expert to pull it together and build one at scale.

244
00:14:10,280 --> 00:14:10,860
That's interesting.

245
00:14:11,380 --> 00:14:15,280
The, first of all, I haven't thought about Beeple in a long time.

246
00:14:15,400 --> 00:14:24,660
I keep trying to remember the name of this book, but there was a book that I read way back then that was like, we all read these books, these breathless books about how awesome the future is going to be because of computers.

247
00:14:24,920 --> 00:14:30,340
And I remember I read one that was about Beeple, like business processing stuff.

248
00:14:30,340 --> 00:14:38,020
And it was just going to revolutionize everything for us, which it was, yeah, that was, it was one of those books that I remember reading all the way to the end.

249
00:14:38,020 --> 00:14:43,580
And then I realized I have no idea what that actually means I should do now, other than anticipate an awesome future.

250
00:14:43,920 --> 00:14:52,060
I think it's interesting to look at the branching of, let's just call it SOA from, I think, what microservices ended up being.

251
00:14:52,220 --> 00:15:01,900
And to your point, a lot of SOA ended up being about the XML standards, the WS star, or as people eventually started calling it WS death star.

252
00:15:02,460 --> 00:15:07,300
And that, as you were saying, is all about integration and not just, what's the other I want?

253
00:15:07,300 --> 00:15:08,620
Being able to talk with each other.

254
00:15:09,640 --> 00:15:10,620
Interoperability was a big thing.

255
00:15:11,180 --> 00:15:12,200
There you go, exactly.

256
00:15:12,380 --> 00:15:15,420
And then I think that was right at the tail end when I was still a developer.

257
00:15:15,420 --> 00:15:20,420
And I feel like what the developers were frustrated about is it had very little to do with coding.

258
00:15:20,980 --> 00:15:24,480
Like those concerns are more about standards and controls.

259
00:15:24,840 --> 00:15:40,020
And it almost seems like I'm reaching for a connection here, but it almost seems like that frustration led to more of microservices thinking, which was, it still is largely about the actual coding and defining the APIs, not so much about the business process.

260
00:15:40,220 --> 00:15:44,000
And then, but eventually those two parts, they eventually need to come back together.

261
00:15:44,000 --> 00:15:45,960
So if you see the evolution, right?

262
00:15:46,320 --> 00:15:51,900
A lot of the code, you know, process SOA companies have become low-code automation companies.

263
00:15:52,340 --> 00:15:57,660
What's happening is, you know, there are layers of productivity and layers of granularity, if you want to think about it that way.

264
00:15:57,660 --> 00:16:10,260
As an application developer, or if I were now an application architect, responsible for building my next generation e-commerce, my banking app, my prescription platform, et cetera, et cetera.

265
00:16:10,600 --> 00:16:17,460
What I want to do is I still want to have all the principles of, you know, modularity, loose coupling, well-defined services contracts.

266
00:16:17,720 --> 00:16:27,300
But more and more APIs are becoming critical, not just between how I publish and make myself exposable to the world, but how my two different teams or 20 different teams that have broken this down.

267
00:16:27,660 --> 00:16:30,000
Exposed a set of contractor services.

268
00:16:30,960 --> 00:16:38,860
And so you're starting to see in the world of microservices, notion of East-West API contracts between two development teams.

269
00:16:39,180 --> 00:16:48,300
My own application is a combination of using somebody else's services and being able to discover what other APIs and services exist in my company's portfolio that I reuse.

270
00:16:49,200 --> 00:16:51,380
And so those problems of reuse still exist.

271
00:16:51,900 --> 00:16:53,800
Service discovery still exists.

272
00:16:54,240 --> 00:16:56,580
Being able to late-bind still exists, right?

273
00:16:57,020 --> 00:17:02,000
Being able to deploy and manage and iterate at a component level so I don't have to change the entire system.

274
00:17:02,080 --> 00:17:03,380
Can I not just change my part?

275
00:17:04,320 --> 00:17:08,680
These ideas of A-B testing where I want to try something new and see if it doesn't work, roll it back.

276
00:17:08,760 --> 00:17:10,580
All the things public clouds do at scale.

277
00:17:10,960 --> 00:17:15,760
And the DevOps practice we all aspire for, and I say this because not every enterprise has really mastered this yet.

278
00:17:16,320 --> 00:17:17,580
That is really the opportunity.

279
00:17:17,740 --> 00:17:19,960
Everybody wants to be able to push out code every day.

280
00:17:20,700 --> 00:17:25,280
Repave the environment if needed every day so there is no malware sitting up there.

281
00:17:25,740 --> 00:17:28,840
Be able to change just their piece without breaking the whole thing.

282
00:17:29,560 --> 00:17:31,140
Test this thing called a system.

283
00:17:31,140 --> 00:17:32,260
I'll give you a simple example.

284
00:17:32,340 --> 00:17:39,260
My old observer is we used to have a massive environment in front of the largest banks running at Oracle because I had to figure out how to debug it.

285
00:17:39,360 --> 00:17:41,000
And the only way we could do it was we could do that scale.

286
00:17:41,160 --> 00:17:42,980
How do you do this now in a modern cloud world?

287
00:17:43,040 --> 00:17:46,380
You don't own the infrastructure, but you're using all these services.

288
00:17:46,600 --> 00:17:50,200
So the new problems are starting to emerge around day two operation.

289
00:17:50,200 --> 00:17:56,340
And things like observability as a category have emerged because you can't reproduce that problem.

290
00:17:56,480 --> 00:18:02,920
You've got to diagnose what happened in the environment itself, and hence you need a lot of observability to know what happened.

291
00:18:03,440 --> 00:18:06,440
Because you can't go and become the reproducibles in the lab.

292
00:18:06,560 --> 00:18:09,060
Let's get a reproducible done so we can then figure out how to debug it.

293
00:18:09,320 --> 00:18:10,060
There's no reproducible.

294
00:18:10,200 --> 00:18:17,300
You've got to go get the data from the live environment and make the change in the live environment and deploy it without bringing the system down.

295
00:18:17,300 --> 00:18:24,300
So the scale problems, the management problems, the operations problem become even much larger than just the developer productive thing.

296
00:18:24,720 --> 00:18:26,180
We tend to get indexed on.

297
00:18:26,660 --> 00:18:29,480
So these new systems have to be designed for resilience.

298
00:18:29,960 --> 00:18:30,440
How do you do that?

299
00:18:30,580 --> 00:18:36,380
That's a good segue into the next thing that I thought would be interesting to extract from you, so to speak.

300
00:18:36,700 --> 00:18:40,880
I think like a lot of us, one of the fun things you get to do, usually it's fun.

301
00:18:41,160 --> 00:18:41,960
Sometimes it's not.

302
00:18:41,960 --> 00:18:48,080
But one of the fun things you get to do is talk to a lot of the executives and teams at various enterprises and organizations.

303
00:18:48,080 --> 00:18:54,940
And I think having that bird's eye view of what everyone does, it allows you to collect a lot of what you were just talking about.

304
00:18:55,100 --> 00:19:04,120
And in talking with all these organizations, like what are the common, to put it in a negative way, what are the problems people have now, right?

305
00:19:04,180 --> 00:19:10,080
To put it in a more neutral way, what are the management concerns that people have, whether they're new or old?

306
00:19:10,160 --> 00:19:12,440
What are the problems they need to solve?

307
00:19:12,440 --> 00:19:23,700
So a couple of things, and I'll pick, I've been fortunate enough to be now an executive sponsor to several large banks, just happen to be all financial services, but this problem applies more broadly.

308
00:19:23,900 --> 00:19:25,860
So I'm using this just as an example, right?

309
00:19:26,400 --> 00:19:40,380
And you're starting to see some kind of either a CTO office or platform office trying to figure out what are the common building blocks that each line of business, CIO and teams need, so that we can pull that back and make it a common platform.

310
00:19:40,380 --> 00:19:43,460
In some ways, the principles of SOA were exactly that, right?

311
00:19:43,840 --> 00:19:45,760
Build a common thing once, make them available.

312
00:19:45,980 --> 00:19:51,560
So from a principles perspective, it follows the same desire to have a set of core components.

313
00:19:52,280 --> 00:19:58,780
This notion of pipelines that reflect the CICD DevOps operating model is another thing we're seeing.

314
00:19:58,900 --> 00:20:06,300
Can we create these three or four common pipelines by which they reflect the different application patterns and the deployment patterns we need to support?

315
00:20:06,300 --> 00:20:17,880
So there's this, on one side, it's about the generalization of providing ready-to-use infrastructure or platforms and decoupling that from the developer who doesn't have to worry about setting up all of this stuff.

316
00:20:17,940 --> 00:20:19,640
He just is a user of these pipelines.

317
00:20:19,820 --> 00:20:25,500
The second thing we're seeing is having a more curated set of what we call accelerators of some forms.

318
00:20:25,620 --> 00:20:27,680
And we've seen this from our experience with Spring.

319
00:20:28,280 --> 00:20:39,420
The Spring starters demonstrate a tremendous opportunity to take a whole bunch of curated capability, whether it's images, whether it's blueprints, application patterns, and make it available.

320
00:20:39,420 --> 00:20:48,700
So when a developer starts on a particular type of application type, they have a recommended set of patterns to start with so that they can start to build this new composite application.

321
00:20:48,700 --> 00:20:59,580
So one side is really about reducing complexity, removing the concerns from the developer for all the infrastructure concerns, if you will, and making them highly productive.

322
00:21:00,380 --> 00:21:09,940
Second one is around this whole DevOps practice, making it mainstream, really creating the art of setting up a centralized or set of pipelines that developers can use.

323
00:21:10,140 --> 00:21:16,180
And the third piece is really this application patterns and the curated set of images that they can expose to the developers for productivity.

324
00:21:16,700 --> 00:21:22,100
And the fourth for them is really, how do I wire in security into this right from the get-go, right?

325
00:21:22,540 --> 00:21:24,720
Because if it's too late, by the time it's gone.

326
00:21:24,800 --> 00:21:30,520
So this notion of the secure software supply chain is starting to get a lot more discussion at this topic and top of mind.

327
00:21:30,600 --> 00:21:31,780
So those are the kinds of problems.

328
00:21:31,960 --> 00:21:40,020
So there are developer productivity, deployment concerns, general security concerns, and then day two operations management concerns.

329
00:21:40,580 --> 00:21:44,620
And under management, I'll put observability, put the cost, being able to predict costs and manage it.

330
00:21:44,620 --> 00:21:53,460
I think those set of being able to patch and upgrade, right, at scale, like those are the kinds of problems I hear when I talk to customers or challenges that they're trying to deal with in your work.

331
00:21:53,460 --> 00:22:02,360
Yeah, one of the first things you were talking about is, we don't really use this phrase very much anymore, but there was a big debate a couple of years ago about like full stack developers.

332
00:22:02,360 --> 00:22:12,520
The idea that your application developers would be in charge of everything down to the infrastructure, which was the reality of early cloud stuff.

333
00:22:13,080 --> 00:22:14,660
I met one of those ones.

334
00:22:14,860 --> 00:22:16,360
I was like, oh, you're a full stack developer.

335
00:22:16,480 --> 00:22:17,280
And he was like, what?

336
00:22:17,900 --> 00:22:26,580
And similar to what you're saying, as I've talked to organizations over the years, I think one of the major things they struggle with is like, that doesn't actually work, right?

337
00:22:26,580 --> 00:22:34,660
It's almost like the question they have is, so how much stuff do I actually want the developers to do aside from the application?

338
00:22:34,880 --> 00:22:36,140
That's been the holy grail, right?

339
00:22:36,220 --> 00:22:36,980
We've always debated.

340
00:22:37,380 --> 00:22:48,180
We want application developers to work on the business logic, the customer experience, et cetera, and give them a palette that they can quickly draw these beautiful pictures or these beautiful applications.

341
00:22:48,520 --> 00:22:52,780
On the other hand, the problem with PaaS typically has been, it's been a hard line.

342
00:22:53,280 --> 00:23:00,220
So if you were not able to fit within the jacket, which is where the challenge of low-code, no-code has been, it's great for my own, I'm sure my bias here.

343
00:23:00,680 --> 00:23:08,820
It works great for very specialized problems because then you can say for that set of problems, I can provide you a phenomenal developer experience and I can give you very high productivity.

344
00:23:09,360 --> 00:23:15,100
As you go further right, you get a lot more flexibility, but now you have to be responsible for wiring the things up.

345
00:23:15,120 --> 00:23:18,160
And that line is a fuzzy line, right?

346
00:23:18,800 --> 00:23:26,600
And most customers that I speak to are trying to get the largest number of developers highly productive, having to worry the least about infrastructure.

347
00:23:27,200 --> 00:23:36,440
And maybe there's 5% or 10% that need to be the sophisticated developers, I'll say, that need to break glass and dive into infrastructure and be those full-stack developers for a set of concerns.

348
00:23:36,840 --> 00:23:47,140
And when they do that, they should hopefully create components or services that others can use next time around as part of these accelerators so that not everybody has to go solve for that over and over again.

349
00:23:47,140 --> 00:23:49,220
So I think this is going to be an evolution, Michael.

350
00:23:49,340 --> 00:23:50,440
We've been at this for 20 years.

351
00:23:50,940 --> 00:23:53,680
So when I look back, it's the same set of problems.

352
00:23:54,200 --> 00:23:56,660
We just have a richer palette and sometimes more complex palette.

353
00:23:57,080 --> 00:23:57,160
Yeah.

354
00:23:57,240 --> 00:24:00,800
So we got middleware, Beeple, business logic.

355
00:24:01,200 --> 00:24:09,340
I think that these are good phrases and words we can put in the Rosetta Stone for new developers to explain what...

356
00:24:09,340 --> 00:24:10,660
Accelerators and starters.

357
00:24:10,860 --> 00:24:11,000
Sure.

358
00:24:11,140 --> 00:24:11,300
Yeah.

359
00:24:12,180 --> 00:24:17,200
Frameworks being more lighter weight, but more in the control so they don't pull in the rest of the world.

360
00:24:17,680 --> 00:24:19,320
We love this idea of injection.

361
00:24:20,080 --> 00:24:24,880
We like the idea of being more declarative or intent-driven versus imperative.

362
00:24:25,060 --> 00:24:27,040
So some of those are the new principles.

363
00:24:27,520 --> 00:24:34,980
We still like the domain-driven design where we can start to create a well-defined contract, fully encapsulated set of capability.

364
00:24:35,880 --> 00:24:44,180
The fact you can now package your own database as part of that, so you can have your own persistence layer as part of that fully integrated versus having to depend on all things.

365
00:24:44,360 --> 00:24:47,860
So those well-defined contracts, I think, are really very critical.

366
00:24:48,140 --> 00:24:53,300
And then have a platform team that gives you a place you can deploy this at scale.

367
00:24:53,760 --> 00:24:56,320
And it's part of the pipelines and the platform.

368
00:24:56,520 --> 00:24:58,060
You can start to define your policies.

369
00:24:58,400 --> 00:24:59,820
And I'm introducing a new concept.

370
00:24:59,920 --> 00:25:10,780
I get a new terminology of policies, which says, my policies dictate where this thing gets deployed, who talks to who, who has access to the data that it's speaking to.

371
00:25:10,900 --> 00:25:25,320
And more and more, you're going to start to see this become described, both application intent, controls as policies, being brought together through an automated platform that defines where an application runs and what controls we need to put in place.

372
00:25:25,320 --> 00:25:28,060
And it has to be done at scale without human intervention.

373
00:25:28,760 --> 00:25:34,820
And so it's driven by data, things like observability that allow us to then react and act on things like this.

374
00:25:34,940 --> 00:25:36,480
So that's the future we're talking about.

375
00:25:36,980 --> 00:25:39,900
Hopefully, I'm not recreating the book that you read and say, OK, I don't know what to do about it.

376
00:25:40,280 --> 00:25:47,040
I have to say, one of my favorite things that you said is layers of interoperability and layers of productivity, right?

377
00:25:47,080 --> 00:25:53,060
Because to Coté's point, those things sometimes seem antithetical, especially when you bring in standards and stuff.

378
00:25:53,300 --> 00:25:56,680
Are we, is that, are we making this, are we fixing this for the future?

379
00:25:56,920 --> 00:25:57,700
I'm very bullish.

380
00:25:58,100 --> 00:26:01,680
I'm a simple, I'm no longer a technologist as much as I sound one like here.

381
00:26:01,980 --> 00:26:03,440
I'm more of a business guy now.

382
00:26:03,440 --> 00:26:14,860
And so when I think about the world for me, like Spring and the productivity that Spring and frameworks like Spring offer, Kubernetes is both a platform and a platform of platform, if you will.

383
00:26:15,820 --> 00:26:21,880
Standards by which we could package up content, ways we can then have well-defined services that we can engage with.

384
00:26:22,480 --> 00:26:28,040
New operating models like serverless, like this isn't, when I look at all that, this is nothing more than a new middleware.

385
00:26:28,240 --> 00:26:33,800
It's a platform that runs on any IaaS infrastructure, whether it's VMware or public cloud.

386
00:26:34,480 --> 00:26:37,880
And so hinting at where we're going as stands, right?

387
00:26:37,880 --> 00:27:02,540
We see an opportunity here to build the kind of next generation application platform, a modern multi-cloud application platform that takes a ubiquity of Kubernetes and containers, brings in the productivity of frameworks and patterns, and brings the DevOps automation of CICD into this kind of holistic platform with strong distributed connectivity, application runtime.

388
00:27:02,540 --> 00:27:08,220
This is a distributed application runtime, so application connectivity, things like service mesh become even more critical.

389
00:27:08,540 --> 00:27:13,540
So those concerns are, again, more, when I look at an app server, it took on some concerns, so I didn't have to worry about it.

390
00:27:14,020 --> 00:27:17,460
I think the service mesh does something similar around security and app connectivity.

391
00:27:17,600 --> 00:27:18,820
I don't have to worry about those things.

392
00:27:18,900 --> 00:27:20,180
I can just turn them on or off.

393
00:27:20,300 --> 00:27:24,400
And then you start to add API management and API collaborations on top.

394
00:27:24,660 --> 00:27:26,920
Now you see the shape of a new platform emerging, right?

395
00:27:27,200 --> 00:27:37,880
And I think that platform is what customers need to get all the benefits they're looking for developers while driving the level of kind of guardrails and controls they need to operate at scale across any cloud.

396
00:27:38,560 --> 00:27:44,260
So, and cloud is not just a big data center cloud or backend clouds, but more the edge clouds as well.

397
00:27:44,260 --> 00:27:50,940
So, to me, cloud is ubiquitous of any location where I can spin up a compute runtime and manage it at scale.

398
00:27:51,340 --> 00:27:55,260
And so the world is going to be this internet is the new cloud platform, and we've said that for many years, right?

399
00:27:55,260 --> 00:27:56,280
Internet is a new platform.

400
00:27:56,900 --> 00:27:59,640
How do you not put a layer or application across that?

401
00:28:00,200 --> 00:28:03,160
And what is the infrastructure middleware to unlock that value, right?

402
00:28:03,680 --> 00:28:06,760
And I think that's a pretty exciting, bold opportunity.

403
00:28:07,080 --> 00:28:11,160
So, bringing a lot of the infrastructure and bringing a lot of the middleware of expertise to bear.

404
00:28:11,440 --> 00:28:11,820
Yeah, I know.

405
00:28:12,020 --> 00:28:16,320
I remember having those conversations as well many years ago.

406
00:28:16,600 --> 00:28:16,820
Awesome.

407
00:28:17,460 --> 00:28:29,480
Yeah, and like you were saying, like we said, when you see everything in effect and that productivity goes up and everyone leads a better, I don't know, to make it grandiose, leads a better life because they have less stuff to worry about.

408
00:28:29,780 --> 00:28:31,360
Like, it's very rewarding.

409
00:28:31,620 --> 00:28:31,960
Well, great.

410
00:28:31,960 --> 00:28:33,580
It was good having you on.

411
00:28:33,680 --> 00:28:35,660
For this discussion, we'll have to have you back on.

412
00:28:35,900 --> 00:28:36,200
Yeah.

413
00:28:36,340 --> 00:28:38,960
And yeah, do you have anything you want to point people to?

414
00:28:39,180 --> 00:28:40,900
You like promoting your Twitter handle?

415
00:28:41,260 --> 00:28:42,120
You have a web blog?

416
00:28:42,440 --> 00:28:43,240
Anything like that?

417
00:28:43,240 --> 00:28:52,080
Watch out for our big cloud event, end of March, as well as if you haven't looked at Tanzu Advanced, it is the start of this journey of building this new platform.

418
00:28:52,180 --> 00:28:58,160
As well as if you're an existing Tanzu application service customer, rest assured, we're going to continue to invest heavily there.

419
00:28:58,460 --> 00:29:04,000
And a lot of the work you're leveraging and driving in the industry is the expertise we're trying to capture and bring to the masses.

420
00:29:04,180 --> 00:29:09,060
Thank you again for the opportunity and I'm looking forward to working with you again, Michael, and being on the pod again next time.

421
00:29:09,700 --> 00:29:09,980
Yeah.

422
00:29:10,160 --> 00:29:10,460
All right.

423
00:29:10,480 --> 00:29:10,720
Great.

424
00:29:10,800 --> 00:29:16,200
As always, if you listeners want to get the archives, you can go to tanzutalk.com, check them all out.

425
00:29:16,240 --> 00:29:17,560
And we'll see everyone next time.

426
00:29:17,780 --> 00:29:18,260
Bye-bye.

427
00:29:18,560 --> 00:29:19,220
Thanks again, Michael.

428
00:29:19,240 --> 00:29:19,580
Thanks.

429
00:29:19,700 --> 00:29:20,120
Thanks, Rita.

430
00:29:20,120 --> 00:29:20,160
Thanks, Rita.