1
00:00:00,160 --> 00:00:05,380
Well, this week we have Rita back as a co-host. She had a great idea, as you'll see, to talk

2
00:00:05,380 --> 00:00:09,300
to Ben Hale, who's been working on the Tanzu application platform with many other people

3
00:00:09,300 --> 00:00:15,020
and has a long history in Spring. Now, what we wanted to talk about here is how the thinking,

4
00:00:15,300 --> 00:00:20,280
the influence, the way that Spring behaves, and kind of how it helps developers, how we're

5
00:00:20,280 --> 00:00:25,120
applying that in the Tanzu application platform to make using Kubernetes and doing cloud-native

6
00:00:25,120 --> 00:00:30,380
development better and easier, not only for developers, but also for the enterprise architects,

7
00:00:30,660 --> 00:00:35,820
the operations people in those large organizations, how it really applies a lot of those learnings

8
00:00:35,820 --> 00:00:41,220
to Spring to make Kubernetes the great enterprise platform it can be for people running applications.

9
00:00:41,840 --> 00:00:46,340
So we'll start in here with Ben introducing himself, giving a great history. He's got a

10
00:00:46,340 --> 00:00:51,880
great background for this job, and I hope you enjoy the show. And as always, if you want

11
00:00:51,880 --> 00:00:58,040
to subscribe, see archives, feed long and little videos, other podcasts, just go to tanzutalk.com

12
00:00:58,040 --> 00:01:03,760
and you can find all the podcasts and videos that we do. So let's listen in and meet our new friend

13
00:01:03,760 --> 00:01:11,980
here, Ben. So my name is Ben Hale. For about the first 15 years of my career, I was a core committer

14
00:01:11,980 --> 00:01:16,500
on the Spring Framework and various projects came along with that. Gave me a lot of background,

15
00:01:16,640 --> 00:01:21,440
a lot of really good experience with enterprise Java developers experience, especially.

16
00:01:21,880 --> 00:01:28,660
And about seven years ago, I also took on an additional job to lead the Java experience inside

17
00:01:28,660 --> 00:01:33,980
of Cloud Foundry to make sure that as we built the platform, Java developers and Spring developers

18
00:01:33,980 --> 00:01:39,900
specifically would love to go there. I often joke my first job was to make Cloud Foundry the best

19
00:01:39,900 --> 00:01:45,740
cloud to run Spring on. But after a couple of years, I changed that job title to make it the best place

20
00:01:45,740 --> 00:01:49,620
to run Spring, period. And I think we actually did a really, really good job towards that end.

21
00:01:49,620 --> 00:01:56,900
But for the last year, I've been a technical lead for the Tonsu application platform, which is our

22
00:01:56,900 --> 00:02:04,140
attempt to bring sort of Kubernetes to regular mainstream enterprise software developers. My

23
00:02:04,140 --> 00:02:09,400
purview is much larger than Spring. I care about all of the major programming languages at this point,

24
00:02:09,400 --> 00:02:16,900
but to take a lot of the lessons that we took from all of our deep experience with enterprise Java

25
00:02:16,900 --> 00:02:21,720
developers with Foundry customers and make sure that they can get those same really positive outcomes,

26
00:02:21,720 --> 00:02:23,540
but on Kubernetes instead.

27
00:02:24,180 --> 00:02:31,280
Yeah. So this is why I was excited to have Ben join Coté. During my discussions with Ben,

28
00:02:31,340 --> 00:02:37,380
when we were talking about Tonsu application platform and the influence that Spring has had

29
00:02:37,380 --> 00:02:43,120
on how we built this thing, he started telling me about this notion of an app-aware platform,

30
00:02:43,120 --> 00:02:48,960
and that really got my attention. I haven't heard that term. And so I want to start with,

31
00:02:48,960 --> 00:02:58,080
you know, I definitely want to get into what did we learn from Spring that is making up how we think

32
00:02:58,080 --> 00:03:03,280
about Tonsu app platform and actually just the future of application platforms in general. But before that,

33
00:03:03,280 --> 00:03:10,320
I wanted to get into what does app-aware platform mean? How would we define that? You know, is it,

34
00:03:10,320 --> 00:03:15,280
is it a very strict definition or is there room for interpretation there? So with that, you know,

35
00:03:15,280 --> 00:03:21,100
tell, tell us a little bit about what you mean by that Ben and where, where that came from, like how Spring kind of created that notion.

36
00:03:21,100 --> 00:03:26,460
Yeah, that's a, that's a really good question. So just to, to head things off at the top,

37
00:03:26,820 --> 00:03:31,720
uh, app-aware platform, I don't think it means anything particularly strict. Um, it's like saying the word microservice.

38
00:03:31,720 --> 00:03:37,420
It means what you need it to mean at any given time, but broadly, when we think about an application-aware platform,

39
00:03:37,420 --> 00:03:45,100
it's us saying that we want to take a lot of the lessons we turn, we learned from Spring and specifically the core idea of inversion of control.

40
00:03:45,100 --> 00:03:53,420
Right. And basically say it's, it's really critical if you want to have sort of portability and maintainability and observability and sustainability,

41
00:03:53,420 --> 00:04:00,640
but the applications that run on a given platform are to the extent possible, completely unaware of the platform that they run on.

42
00:04:00,780 --> 00:04:04,700
They need to be handed all of the information. They need all the configuration they need.

43
00:04:04,760 --> 00:04:12,700
They need to be hooked into the proper logging systems, observability systems, but without requiring them to be aware that it's happening to them.

44
00:04:12,700 --> 00:04:19,180
So when we talk about an app-aware platform, it's effectively us saying, you should be able to bring anything to us,

45
00:04:19,180 --> 00:04:23,500
bring me a Python workload, bring me a Node.js workload, bring me a Spring workload.

46
00:04:23,500 --> 00:04:29,180
And if, and my platform should be able to say, hey, I know your Spring. I see that you're using actuators.

47
00:04:29,180 --> 00:04:32,620
Let me make sure that your liveness and readiness probes are configured properly.

48
00:04:32,620 --> 00:04:37,340
Let me make sure that, um, we've hooked you into whatever your observability solution is,

49
00:04:37,340 --> 00:04:42,060
that we're collecting your logs completely, that we're pulling from your centralized configuration system,

50
00:04:42,060 --> 00:04:46,700
and injecting that into the container on your behalf and on and on and on.

51
00:04:46,700 --> 00:04:49,340
We have, you know, a whole list of things that go along with that.

52
00:04:49,340 --> 00:04:52,780
And like it, that seems like, well, okay,

53
00:04:52,780 --> 00:04:57,900
you could have done many of those same things just by putting something into a Docker file or something like that.

54
00:04:57,900 --> 00:05:03,260
But what we observed way back in the day with Spring is like, if you tried to bake those things in,

55
00:05:03,260 --> 00:05:07,340
we saw it, especially like I'm going to really date myself, all the way back in EJVs.

56
00:05:07,340 --> 00:05:14,540
If your platform knew that you needed to hook up to JNDI or something like that to get some sort of database,

57
00:05:14,540 --> 00:05:19,180
rather than having the database injected into it, you ended up with these really brittle solutions.

58
00:05:19,180 --> 00:05:23,660
They would only run exactly where they were at force, you know, um,

59
00:05:23,660 --> 00:05:29,660
weird things where people were trying to run web sphere or something like that initially locally on their development machines.

60
00:05:29,660 --> 00:05:33,260
Um, eventually it, you know, got to the point where we were trying to, you know,

61
00:05:33,260 --> 00:05:39,500
sort of at development time run against Tomcat, but at production time, uh, run against, uh, web logic, things like that.

62
00:05:39,500 --> 00:05:47,020
And what we observed in the spring community is the best way to make that work better is allow you to focus on your business logic, right?

63
00:05:47,020 --> 00:05:52,060
Focus on your pojos doing the things and say, Hey, I just need any database, right?

64
00:05:52,060 --> 00:05:57,660
I need a data source injected that, that key thing, that idea that we invert control and say,

65
00:05:57,660 --> 00:06:02,060
you give us all of your functionality, we'll assemble it for you, give you all the pieces that you need,

66
00:06:02,060 --> 00:06:06,060
ended up with significantly better, you know, sort of outcome velocity,

67
00:06:06,060 --> 00:06:09,340
all the things that you actually care about as an enterprise developer.

68
00:06:09,500 --> 00:06:15,340
Yeah. You know, you know, you're making me think that like, uh, you know, I, I'm, I'm always like,

69
00:06:15,340 --> 00:06:20,460
not always, but when I am, so to speak, like thinking in my head, like, is, is, is something

70
00:06:20,460 --> 00:06:26,140
like Kubernetes really like for developers? And I mean, that's a, that's, that's a pose as a very

71
00:06:26,140 --> 00:06:31,820
binary question, but, um, you know, as, as you're kind of going through the history of spring stuff,

72
00:06:31,820 --> 00:06:35,340
right? Like, and I think about like the, the, you know, the great thing about something

73
00:06:35,340 --> 00:06:42,060
like a Kubernetes is it's, it is really like, uh, a great boiled down specification of like,

74
00:06:42,060 --> 00:06:46,940
this is the computer stuff you're going to need, right? Like, like if you're running software,

75
00:06:46,940 --> 00:06:52,140
there's really only ever like five or six computer things you need. Right. And like, however,

76
00:06:52,140 --> 00:06:57,100
if you were to go out on the internet, you would find like 5,000. Right. So let's just standardize

77
00:06:57,100 --> 00:07:01,420
on these things. And then you can, you can get the infrastructure you need, but kind of,

78
00:07:01,420 --> 00:07:06,460
you know, to, to the point of what you're saying, it doesn't necessarily, there's yet to be that layer

79
00:07:06,460 --> 00:07:13,420
of like, so if a developer goes there, a developer, like, you know, they kind of don't need computer

80
00:07:13,420 --> 00:07:18,140
stuff. They need databases and they need like, you know, all of these other things that are not,

81
00:07:18,140 --> 00:07:25,340
that are more, that are harder to like boil down into like however many atomic units there are in

82
00:07:25,340 --> 00:07:31,420
Kubernetes. So that layer, that layer becomes, there's a different audience that you're serving

83
00:07:31,980 --> 00:07:37,500
more or less. Yeah, absolutely. Like, this is what we see is it's all about abstraction and

84
00:07:37,500 --> 00:07:43,260
progressive complexity. If I want to draw an analog to like where Kubernetes is today, like if you deal

85
00:07:43,260 --> 00:07:49,740
with kubectl and the straight API, broadly, you are dealing with the lowest possible level of a thing.

86
00:07:49,740 --> 00:07:54,780
It requires you to have understanding of all of the core types, all of the types that you might have

87
00:07:54,780 --> 00:07:59,180
installed, like all the CRDs and stuff like that. And to me, like there's a really strong parallel to

88
00:07:59,180 --> 00:08:04,140
using something like the bean factory inside of spring, or maybe the application context where

89
00:08:04,140 --> 00:08:09,020
you have the ability to be as detailed as you possibly ever want. But most of the time you

90
00:08:09,020 --> 00:08:13,420
actually don't want that, right? The flexibility is there if you need it, but you actually want to be

91
00:08:13,420 --> 00:08:18,780
working at a higher level because fundamentally like your job is to deliver this new feature for

92
00:08:18,780 --> 00:08:24,780
your insurance company or deliver this new way of, you know, doing car loan approvals for your car

93
00:08:24,780 --> 00:08:29,260
company or something like that. You want to work at these higher levels of abstraction. We introduced

94
00:08:29,260 --> 00:08:34,700
the application context, you know, being, sorry, Java based configuration, like we were moving up,

95
00:08:34,700 --> 00:08:38,620
right? Moving beyond what spring was. And then I think the big step change was the introduction of

96
00:08:38,620 --> 00:08:45,180
spring boot. And spring boot was customer saying, I really don't care even about spring anymore. Like, I want to

97
00:08:45,180 --> 00:08:49,900
move to this. I want to get convention over configuration. I want to focus even more on this

98
00:08:49,900 --> 00:08:55,020
stuff. That is my business logic. And so a lot of what the Tanzu application platform is, is us doing

99
00:08:55,020 --> 00:09:00,460
that same step up. We're building the platform on the platform. We want you to be able to say, here is

100
00:09:00,460 --> 00:09:05,820
my app, run it for me in the cloud. I don't care how that's the old CF, I do certainly, but it still

101
00:09:05,820 --> 00:09:11,340
applies here. We want developers to be able to do that. But we're also pretty clear that like, not

102
00:09:11,340 --> 00:09:16,300
everybody's going to be able to, to, to build an application that fits into that box, right?

103
00:09:16,300 --> 00:09:20,540
You can use all of the things that we're going to ship. So it's important that Kubernetes is still

104
00:09:20,540 --> 00:09:24,780
there. Like it's an incredible ecosystem. It's super flexible. There are thousands of different

105
00:09:24,780 --> 00:09:29,660
projects you or your enterprise might want to integrate with, but most of the time you shouldn't

106
00:09:29,660 --> 00:09:34,700
be smacked in the face with a wall of YAML. You should have something small that gets you into the system.

107
00:09:34,700 --> 00:09:40,860
And when it doesn't fit anymore, you should be able to drop into the full power of Kubernetes

108
00:09:40,860 --> 00:09:45,820
as a developer, as an operator, as an enterprise, it doesn't matter. You should have access to it,

109
00:09:45,820 --> 00:09:48,060
but not be required to deal with it every day.

110
00:09:49,260 --> 00:09:55,980
I said at the beginning that when we started building Tanzu application platform,

111
00:09:56,860 --> 00:10:02,220
it's, it's, it's heavily influenced by Spring, which I think is very, is great because this is a

112
00:10:02,860 --> 00:10:09,660
platform for developers and Spring knows developers, the Spring team. You guys really know how developers

113
00:10:09,660 --> 00:10:15,980
want to work. And so you took a lot of that in what we're building here. Can you kind of go over

114
00:10:15,980 --> 00:10:22,860
maybe like the top three or so principles that you took from Spring in, in building out this platform

115
00:10:22,860 --> 00:10:26,860
and how you think that's going to kind of, I guess, play out over the next few years and the future of

116
00:10:26,860 --> 00:10:30,940
platforms in general. And I'm asking you to be a little, you know, futuristic here.

117
00:10:32,940 --> 00:10:38,780
Yeah. So I think the biggest one is that inversion of control change, like number one, top of the

118
00:10:38,780 --> 00:10:44,700
list. We want to say that you shouldn't as a developer be responsible for imperatively defining

119
00:10:44,700 --> 00:10:49,820
exactly the way your Docker image is built with a Docker file. You shouldn't be responsible for

120
00:10:49,820 --> 00:10:55,340
imperatively saying every single piece of Kubernetes configuration that needs to happen to that image in

121
00:10:55,340 --> 00:10:59,260
order to get it running. Instead, we want to invert that and say something like,

122
00:10:59,260 --> 00:11:03,900
here is a Java, here is some Java source code. What does it mean to put it into an image, right?

123
00:11:03,900 --> 00:11:07,820
Allow something like the cloud native build packs project to take a look at it and say, hey,

124
00:11:07,820 --> 00:11:12,380
I recognize that you're a Python app or I recognize that you're Node.js app, or I recognize that you're

125
00:11:12,380 --> 00:11:17,340
a Spring app. Not only am I going to make sure that you get a really good safe image, right? Like,

126
00:11:17,340 --> 00:11:23,260
don't run as root, make sure the minimum possible operating system behind it, but also to say, hey, I notice you're

127
00:11:23,260 --> 00:11:27,180
probably going to need to bind to some data services. Let me make sure all the stuff in

128
00:11:27,180 --> 00:11:33,820
there so that you can bind to data services. Let me make sure that if we see a new version of the

129
00:11:33,820 --> 00:11:37,740
JVM come out, we can do a quick rebuild without needing to rebuild your entire application, make

130
00:11:37,740 --> 00:11:43,180
sure that you can get that. But then it goes beyond that. We can also say, hey, if I know certain things

131
00:11:43,180 --> 00:11:49,180
about your application, I can configure even the resources for Kubernetes. I can set up liveness

132
00:11:49,180 --> 00:11:53,740
and readiness codes. I can read your software bill of materials and build pack, put on your thing,

133
00:11:53,740 --> 00:11:58,460
make sure that we're configuring other things like your observability to hook in the right place,

134
00:11:58,460 --> 00:12:02,860
make sure we're injecting the proper side cards, if that's what it is, or setting some sort of

135
00:12:02,860 --> 00:12:10,940
configuration to hide the management URLs off of your HTTP endpoints. And it goes on and on. So the

136
00:12:10,940 --> 00:12:15,820
developer is really focusing on this and the platform is reacting to what it's being presented with.

137
00:12:15,820 --> 00:12:21,900
That's number one. Okay. Number two, I think, is the idea of dependency injection, which you might

138
00:12:21,900 --> 00:12:28,540
think is what inversion of control is, but it's not really. It's us saying, as a developer, I want to say,

139
00:12:28,540 --> 00:12:32,940
you know, sort of in spring terms, it would say, I need to be injected with a bean of this particular

140
00:12:32,940 --> 00:12:37,580
kind. But what we actually want developers when they get to the platform to say is, I actually need

141
00:12:37,580 --> 00:12:42,620
a data service of a particular kind. So for example, we'll say, hey, I need a Postgres. You can point to

142
00:12:42,620 --> 00:12:49,340
a specific Postgres, but we learned, right? Trying to do dependency injection by name is really brittle.

143
00:12:49,340 --> 00:12:55,020
Probably what you want to do is describe a characteristic. I need a Postgres database, or I need a RabbitMQQ.

144
00:12:55,020 --> 00:12:59,580
Maybe say some stuff like I need it to, you know, handle 1000 transactions per second or something

145
00:12:59,580 --> 00:13:05,100
like that, or have, you know, 10,000 IOPS. Be able to describe the characteristics and the platform is

146
00:13:05,100 --> 00:13:10,300
responsible for saying, okay, given all of the service instances, all the databases that I have that are

147
00:13:10,300 --> 00:13:15,420
on this particular cluster here, what might you want? How can I inject that into your thing? Or

148
00:13:15,420 --> 00:13:20,780
centralized configuration feels the same way. Hey, my application needs to go back to a Git repository,

149
00:13:20,780 --> 00:13:24,940
back to Vault or something like that. I need it to be injected. But for me, it's

150
00:13:25,020 --> 00:13:31,900
just configuration. The platform needs to get that onto the, injected into my container for me on my

151
00:13:31,900 --> 00:13:40,460
behalf. Number three, that's a good question. As I look sort of off into the future, I think that we're

152
00:13:40,460 --> 00:13:49,260
going to see a lot more of what it means to move supply chains into the platform itself, where we're

153
00:13:49,260 --> 00:13:53,900
sort of used to this idea that you've got something like Jenkins that is responsible for sitting off of

154
00:13:53,900 --> 00:13:58,620
the cluster and orchestrating a bunch of different things with the source code scanning, or you need

155
00:13:58,620 --> 00:14:03,340
to do image scanning, or you need to, you know, run through some sort of audit or something like

156
00:14:03,340 --> 00:14:08,700
that. All that runs off. And at the very end, in my previous career, the last step would be CF push

157
00:14:08,700 --> 00:14:13,100
this thing onto the platform. Instead, what we want to do is, I think what we're going to see is

158
00:14:13,100 --> 00:14:18,540
all of those things moving on to Kubernetes itself. For what it's, for my money, certainly,

159
00:14:18,540 --> 00:14:24,620
I think Kubernetes is the best reconciliation engine that's ever been invented, right? That's really the

160
00:14:24,620 --> 00:14:29,100
key, you know, one of the key drivers here is rather than having an imperative thing that says,

161
00:14:29,100 --> 00:14:33,900
do step one, do step two, do step three, do step four, and then finally get onto the platform.

162
00:14:33,900 --> 00:14:38,140
We have a platform that basically looks at the thing ahead of it and says, hey, if some change

163
00:14:38,140 --> 00:14:43,660
has happened, do a thing. So instead of having pipelines, we now have graphs, we can now enter

164
00:14:43,660 --> 00:14:48,300
and exit and, you know, in the middle of it rather than the beginning of the end. And more importantly,

165
00:14:48,300 --> 00:14:54,380
you all, you have a single cohesive place where all of it, including the final runtime, even if it's on

166
00:14:54,380 --> 00:14:58,220
another cluster, you know, we sort of think multi cluster is still part of the same platform.

167
00:14:58,220 --> 00:15:03,900
It's all in one location, being reconciled with high availability, you know, all the things that

168
00:15:03,900 --> 00:15:09,100
you want out of that kind of thing. I'm going to have so many questions now. Here are the two that

169
00:15:09,100 --> 00:15:16,780
I have. One, I wanted to get into how to describe characteristics. If there is, this will demonstrate

170
00:15:16,780 --> 00:15:21,820
my lack of developer skills here, developer experience, but what does that mean? Are there ways,

171
00:15:21,820 --> 00:15:26,380
like best practices that we think about, like how you should describe those characteristics? But the other

172
00:15:26,380 --> 00:15:33,340
one is when you're talking about, um, Kate's, uh, as the, you know, best reconciliation engine and just

173
00:15:33,340 --> 00:15:37,580
the notion of a supply chains into the platform. And then that makes me think about, maybe this is a

174
00:15:37,580 --> 00:15:43,100
whole other topic for another discussion is the supply chain choreography. Um, and that's something

175
00:15:43,100 --> 00:15:47,100
I've talked about with some of our other colleagues, right. And how that's different than, than, uh,

176
00:15:47,100 --> 00:15:52,060
orchestration. Uh, and what does that mean? Um, I don't know if that's what you're getting into

177
00:15:52,060 --> 00:15:55,500
a little bit here when you're talking here, but that's kind of what sparked, uh, got into my head a

178
00:15:55,500 --> 00:15:58,860
little bit. So I don't know which one of these you want to tackle, which one we have time for, which

179
00:15:58,860 --> 00:16:05,420
one's going to be, to be continued. Let's, let's, let's start next week. Yeah. Prompt me, prompt me

180
00:16:05,420 --> 00:16:10,460
the first question again. Okay. So, um, you talked about how, you know, we're, we're asking folks

181
00:16:10,460 --> 00:16:14,620
rather than to be, to say, I want this specific thing to just describe the characteristics of the

182
00:16:14,620 --> 00:16:20,380
thing that you want. Are there best practices of how, uh, folks need to go about that? And, um, why is that, uh,

183
00:16:21,340 --> 00:16:23,740
better? Like, does it lead to less brittle, brittleness, as you mentioned?

184
00:16:23,740 --> 00:16:29,500
Yeah. So, uh, inside of tons of application platform, we actually split two very distinct

185
00:16:29,500 --> 00:16:35,900
roles, which are often occupied by the same person, but have two very different, um, uh, characteristics.

186
00:16:35,900 --> 00:16:40,380
One is an application developer. An application developer typically speaks in a high level language,

187
00:16:40,380 --> 00:16:45,900
like Java or node, uh, knows exactly what goes on inside of it, understand some characteristics like,

188
00:16:45,900 --> 00:16:50,860
Hey, I need a dependency or, Hey, this is a web application or, Hey, I'm using spring or, uh,

189
00:16:51,740 --> 00:16:57,660
this requires, you know, two CPUs and a gig of RAM to actually run properly. And we want them to focus

190
00:16:57,660 --> 00:17:02,780
really on that, the things that only an application developer can know. And then we split out the other

191
00:17:02,780 --> 00:17:07,500
side of it, what we call the application operator and the application operator is responsible for that

192
00:17:07,500 --> 00:17:12,700
definition of what exactly those, you know, to do with those characteristics. So we'll talk a little bit

193
00:17:12,700 --> 00:17:16,700
about supply chain in a second, but suffice to say, it's a thing that says, Hey, if you're a web app,

194
00:17:16,700 --> 00:17:21,420
I want you to perform this set of actions, right? Like I want you to go through and I would, you know,

195
00:17:21,420 --> 00:17:26,780
eventually I need to sync it out as a K native, uh, service, right? Something that scales to zero or,

196
00:17:26,780 --> 00:17:31,260
you know, automatically scales to a very high number buying databases into it, things like that.

197
00:17:31,260 --> 00:17:35,900
But another characteristic might be, this is a job, right? This is part of a batch. And so I want to

198
00:17:35,900 --> 00:17:41,580
do things a little bit differently, or maybe, you know, uh, at sometimes, you know, when I first get started,

199
00:17:41,580 --> 00:17:46,940
it's simply give me a source and give me a URL at the end of it, but maybe as my enterprise is bigger,

200
00:17:46,940 --> 00:17:51,020
I started injecting things like image scanning and software scanning. I put a guard out at the end

201
00:17:51,020 --> 00:17:56,220
to make sure that nothing with a C, uh, a known CVE is actually deployed into production, things like

202
00:17:56,220 --> 00:18:01,900
that. And so like that split, I think is really important to us to be able to say developers

203
00:18:01,900 --> 00:18:06,140
describe, describe a characteristic. A lot of, a lot of the time we're actually looking at implicit

204
00:18:06,140 --> 00:18:10,940
characteristics. If you've included spring jars, right? Like we can detect that kind of thing.

205
00:18:10,940 --> 00:18:14,700
If you've included spring actuators, we can include that kind of thing. If you include certain,

206
00:18:14,700 --> 00:18:19,020
you know, Python frameworks, we'll do something based on that. But all of these are characteristics

207
00:18:19,020 --> 00:18:24,540
that get, um, interpreted by the platform and defined by platform operators or application operators.

208
00:18:24,540 --> 00:18:32,060
The, the, the key thing I think here is that we want to do what we kind of did in CF where we said,

209
00:18:32,060 --> 00:18:37,180
hey, platform operators can gain leverage on applications. We can take what used to, you know,

210
00:18:37,180 --> 00:18:41,980
require a thousand operators to run a thousand apps, and we're going to bring it down. So four operators

211
00:18:41,980 --> 00:18:45,900
can, you know, sort of run a platform that a thousand apps run on. We want to do that same

212
00:18:45,900 --> 00:18:50,460
thing for applications. We know that in enterprises, especially, but it trickles down to much smaller

213
00:18:50,460 --> 00:18:56,620
companies as well. Consistency is a real multiplier for people. We want to be able to say, Hey, uh,

214
00:18:57,500 --> 00:19:02,140
all of my spring apps probably need this set of things. So if I determine a characteristic,

215
00:19:02,140 --> 00:19:07,100
this is a spring app, do this thing. My Python apps need, you know, probably should all look roughly

216
00:19:07,100 --> 00:19:11,740
like this, apply this kind of thing and allows application operators, which in most companies these

217
00:19:11,740 --> 00:19:18,620
days are like SRE teams to define what makes it right to run applications in their experience and

218
00:19:18,620 --> 00:19:24,060
then gain leverage. Smaller number of SREs, higher number of developers over at the other side.

219
00:19:24,060 --> 00:19:29,980
You know, when, when, when I talk with people about like why it's good to have a, uh, uh, a platform

220
00:19:29,980 --> 00:19:35,020
in, in your, in your large organization, like I, I, maybe I should start using the word consistency,

221
00:19:35,020 --> 00:19:42,620
but I, I say it in the, uh, uh, the bad way, which is that like variability is bad, right? Like you,

222
00:19:42,620 --> 00:19:47,820
you want to, you know, you, you want the minimal amount of variability, especially when it comes to

223
00:19:47,820 --> 00:19:53,820
things like, you know, stuff that's below your actual application. Right. And the more variability

224
00:19:53,820 --> 00:19:58,940
you have in like whatever services you're using, how you can even how you configure and deploy applications,

225
00:19:58,940 --> 00:20:03,820
the infrastructure it runs on, on and on and on, like the more problems you're going to have

226
00:20:04,700 --> 00:20:11,180
in the medium and long term. And so it seems like, you know, listen, listening to you go over like a

227
00:20:11,180 --> 00:20:17,500
lot of this, you know, to, to kind of go between two levels here. Right. So again, like at the Kubernetes

228
00:20:17,500 --> 00:20:24,300
level, uh, I'll use your word for it. There's a lot of consistency, right? Like there's, there's a very

229
00:20:24,300 --> 00:20:30,620
limited amount of ways to do things. Right. And it's very thought out how it fits together. And this is

230
00:20:30,620 --> 00:20:38,060
what the infrastructure looks like. And, um, we have never, uh, suffered from over consistency in the

231
00:20:38,060 --> 00:20:47,420
application development layer. Stop. You're too consistent. Yeah. No, no, no one's ever starved from

232
00:20:47,420 --> 00:20:53,100
that, so to speak. Uh, but it, it is, you know, in the same way that like, I think one of the,

233
00:20:54,140 --> 00:20:59,100
the things that we've learned from like the, you know, container and Kubernetes world is that if you,

234
00:20:59,100 --> 00:21:05,740
to use my phrasing for it, if you limit variability, you get a lot of benefits, right? Like it's actually

235
00:21:05,740 --> 00:21:11,420
okay. If there's only like one way to specify network routing, like, you don't, you don't really

236
00:21:11,420 --> 00:21:16,220
need a whole bunch of different ways if you have one that's well-designed. And so similarly, like,

237
00:21:16,220 --> 00:21:20,620
like, you know, what you're going over is this is let's move that notion up to the developer.

238
00:21:20,620 --> 00:21:25,180
I don't know if anyone says middleware anymore, but the middleware layer and say like,

239
00:21:25,740 --> 00:21:31,500
so maybe like you need a database, right? Like, or you need an event system and describe the

240
00:21:31,500 --> 00:21:36,840
characteristics instead of getting obsessed with the exact thing that you need and then having to

241
00:21:36,840 --> 00:21:42,380
configure it. Right. Like, yeah. I mean, it gives you a lot of problems comes in. Yeah. And it gives you a lot

242
00:21:42,380 --> 00:21:48,380
of flexibility as well. When you have an app aware platform, it means that you can make different

243
00:21:48,380 --> 00:21:53,020
decisions at the appropriate time. So for example, we often think about development as a continuum

244
00:21:53,020 --> 00:21:59,020
between personal at one end, production at the other end, some staging and QA somewhere in the middle,

245
00:21:59,020 --> 00:22:04,140
and like, and like applications go through from one end of that continuum to the other during their

246
00:22:04,140 --> 00:22:10,780
lifetime. But it means like, if I asked for, Hey, I need a, my SQL database, right? Like I need the one that has all of

247
00:22:10,780 --> 00:22:15,820
our user accounts in it. When I deploy this in my personal environment, um, call it mini cube on my,

248
00:22:15,820 --> 00:22:21,500
my laptop or something like that. Fulfilling that requirement, maybe, Hey, I just deploy a quick

249
00:22:21,500 --> 00:22:25,340
helm chart with ephemeral storage behind the scenes and who cares, right? It's just dead tomorrow,

250
00:22:25,340 --> 00:22:28,940
but you know what I'm doing personal development. So it doesn't matter when I go to something like

251
00:22:28,940 --> 00:22:34,700
staging or QA, maybe I do actually provision a database. It's a little bit more controlled,

252
00:22:34,700 --> 00:22:39,740
probably. Um, but it's not like, you know, any, like it, it probably has some cross controls around it

253
00:22:39,740 --> 00:22:44,380
says, Hey, my team is only allowed to do four of these, right? You know, it's only allowed to ask for

254
00:22:44,380 --> 00:22:49,740
four of these because otherwise my Azure bill goes absolutely insane. Finally, um, when you get to

255
00:22:49,740 --> 00:22:55,660
production, that exact same requirement, I need a MySQL might be just the platform vending a set of,

256
00:22:55,660 --> 00:23:01,740
you know, credentials that point to the bare metal DBA care and fed production database that has been

257
00:23:01,740 --> 00:23:07,020
around in your company for 10 years, right? Like you can do really great things without the application

258
00:23:07,020 --> 00:23:10,860
developer really knowing about it and programming against it, because what they're doing is they're

259
00:23:10,860 --> 00:23:15,500
describing characteristics and in different situations, those characteristics can be fulfilled

260
00:23:15,500 --> 00:23:20,780
by something else. Yeah. Yeah. Yeah. Yeah. No, it's, it's that same notion that you get that again,

261
00:23:20,780 --> 00:23:25,820
down at the infrastructure layer of like how to use developer language, how this is implemented,

262
00:23:25,820 --> 00:23:32,380
the infrastructure can vary because you've basically specified what you need. And so we can,

263
00:23:32,380 --> 00:23:37,180
we can, we can switch things around depending on production or development and, and, or even just

264
00:23:37,180 --> 00:23:42,860
simple as simple as, as, uh, handling more load, right? Like just the way that we do load balancing

265
00:23:42,860 --> 00:23:47,980
can change between these different things because you've told us what you need instead of specifying

266
00:23:47,980 --> 00:23:52,460
how to achieve what your needs are. Yeah. And like one final point I want to make is like,

267
00:23:52,460 --> 00:23:58,860
while I think there's demonstrable value to this kind of consistency, the balance you really have to

268
00:23:58,860 --> 00:24:05,580
strike is making sure you don't hide it completely, right? Like there will always be the thing that

269
00:24:05,580 --> 00:24:11,420
needs to be the exception. And if you build a system that is so locked down, but that exception can't be

270
00:24:11,420 --> 00:24:16,220
made, you really end up in a bad situation. So like one of the things that I think about every day on,

271
00:24:16,220 --> 00:24:21,580
on the times of application platform is how do I give developers sort of like their day-to-day

272
00:24:21,580 --> 00:24:28,060
experience as, as productive as possible, as simple as possible, as, uh, um, as consistent as

273
00:24:28,060 --> 00:24:33,580
possible while still maintaining the ability for them to make a different decision, to make a small

274
00:24:33,580 --> 00:24:37,820
exception without having to throw out the entire platform. Hey, you don't want to use build packs

275
00:24:37,820 --> 00:24:41,820
because build packs aren't right for this app. I need a Docker file. What would it take for me to make

276
00:24:41,820 --> 00:24:47,180
all of the rest of the platform work, except we, you, you, you can use Conoco to like do on cluster

277
00:24:47,180 --> 00:24:51,660
builds with a Docker file and then deploy that. How do I, how do you do that? And like, that's,

278
00:24:51,660 --> 00:24:56,140
I think, uh, one of the big value propositions that we're really going after with tons of application

279
00:24:56,140 --> 00:25:00,620
platform. Well, I think we're, uh, about ready to wrap up. So I don't know how deeply we can get

280
00:25:00,620 --> 00:25:05,340
into this again. I think maybe this will be a stay tuned for next week, but you mentioned supply chains

281
00:25:05,900 --> 00:25:10,300
and, uh, which again, sparked this like, Ooh, Ooh, choreography versus orchestration. I don't know

282
00:25:10,300 --> 00:25:14,620
if there's anything you want to say about that today, then we can get into it and deeper discussion

283
00:25:14,620 --> 00:25:21,260
later. But, um, yeah, that, that, that struck me. So. Yeah. To tease it just a little bit. We

284
00:25:21,260 --> 00:25:26,940
internally use the phrase choreography in almost all cases, instead of orchestration. And the semantic

285
00:25:26,940 --> 00:25:31,180
difference we observed between that is an orchestrator is like saying, do this thing,

286
00:25:31,180 --> 00:25:35,500
do this thing, do this thing, do this thing. And what, the way we think about it, especially since

287
00:25:35,500 --> 00:25:41,980
we're built on a declarative reconciliation is it's more of notice a piece of information has changed

288
00:25:41,980 --> 00:25:47,100
and move that information to someone who cares about it. Right. Don't do any actual work. Don't

289
00:25:47,100 --> 00:25:52,220
force a thing to happen. And so like sort of a concrete example of this is we might notice that,

290
00:25:52,220 --> 00:25:55,900
you know, a piece of source code, the version of source code, the latest commit has changed.

291
00:25:55,900 --> 00:26:00,060
All we're going to do is shuffle that information over to the front end of, of the

292
00:26:00,060 --> 00:26:05,100
cloud made to build packs, KPAC project. If KPAC wants to do a build, they're free to do it,

293
00:26:05,100 --> 00:26:10,460
but they don't have to. And the platform doesn't have any strong opinions on this. Each individual

294
00:26:10,460 --> 00:26:17,500
project gets to do what it thinks is right to do. And we notice and help people understand and help

295
00:26:17,500 --> 00:26:22,940
the data flow around between them. Yeah. You have a platform for building your own opinions.

296
00:26:22,940 --> 00:26:30,380
Absolutely. Uh, we know that customers absolutely love opinions. Uh, and we want to make a nice

297
00:26:30,380 --> 00:26:34,700
getting out, uh, getting started out of the box kind of experience with a set of default opinions,

298
00:26:34,700 --> 00:26:39,420
but you should be able to change those opinions as your company evolves that you become more

299
00:26:39,420 --> 00:26:43,660
sophisticated in your usage and you really understand what makes your company tick.

300
00:26:43,660 --> 00:26:47,180
That sounds good. Well, great. Well, well, thanks for being on. I, I think, I think, uh, as always,

301
00:26:47,180 --> 00:26:52,300
Rita had a good instinct for a topic that would be fun to talk about. So, so if, if, uh, uh,

302
00:26:52,300 --> 00:26:56,860
if people are interested in like, whether, whether it's these ideas or just you yourself,

303
00:26:56,860 --> 00:27:01,020
do you, do you have, do you have like a, you got a weblog, a live journal, anything you would point

304
00:27:01,020 --> 00:27:06,700
people towards? Where do you put your morning musings? Probably my Twitter account, although it

305
00:27:06,700 --> 00:27:12,380
has a lot to do with cycling rather than, uh, software or anything else. Yeah. Uh, but yeah.

306
00:27:12,380 --> 00:27:17,180
Yeah. There's actually some really great content also on the Tanzu Dev Center actually. And

307
00:27:17,180 --> 00:27:21,660
especially on this last one that we started talking about choreography and orchestration. And, um,

308
00:27:22,380 --> 00:27:26,540
we're going to be, uh, talking a little bit more about inversion of control and things like that on

309
00:27:26,540 --> 00:27:34,220
the various Tanzu blogs and such. So go there. Yeah. Yeah, it's true. It's, it's well fleshed out.

310
00:27:34,220 --> 00:27:40,220
Well, great. Well, thanks for being on Ben. One more, one more plug for, uh, Ben and Valentina's,

311
00:27:40,220 --> 00:27:45,740
uh, SpringOne keynote also talks, uh, about this and specifically in the context of Tanzu

312
00:27:45,740 --> 00:27:49,900
application platform. So that's it. You can find those on YouTube or spring.io.

313
00:27:50,860 --> 00:27:55,420
Sounds good. Well, as always, as always, this has been Tanzu Talk. If you want to get the archives,

314
00:27:55,420 --> 00:28:00,700
you can go to TanzuTalk.com, uh, find them there and we'll put in links to the, uh, the things we

315
00:28:00,700 --> 00:28:05,420
just mentioned there. And otherwise that you can check out that keynote or learn about cycling and

316
00:28:05,420 --> 00:28:10,780
Ben's life. I, I don't, I, you know, even though I live here in the Netherlands, I don't really know

317
00:28:10,780 --> 00:28:15,740
what cycling culture is like. It's much different if it's just your daily commuting vehicle than if it's

318
00:28:15,740 --> 00:28:21,340
something you actually, uh, think about, uh, much more squeaky sounding over here than it is in the

319
00:28:21,340 --> 00:28:27,580
States. Anyhow, you can, uh, go to TanzuTalk.com and check that out. And with that, we'll see

320
00:28:27,580 --> 00:28:29,180
see everyone next time. Bye-bye.