1
00:00:00,300 --> 00:00:06,900
Well, hey, everybody. This is another selection from my week daily Tanzu talks. You know,

2
00:00:06,920 --> 00:00:11,340
if you want to check them out, every day I come up with some topic to talk about. There's

3
00:00:11,340 --> 00:00:15,860
been a lot of interesting things, if I don't say so myself, about the process of doing

4
00:00:15,860 --> 00:00:21,800
meetings better. And also a bunch of advice if you're looking to learn more about Kubernetes

5
00:00:21,800 --> 00:00:27,220
and you're more of a traditional VI administrator or whatever. And I don't know, other stuff.

6
00:00:27,360 --> 00:00:33,400
But this is one where I kind of did a brain dump on platform operations, which I thought

7
00:00:33,400 --> 00:00:39,160
was worth including in here. So if you want to check out the actual video of this and all

8
00:00:39,160 --> 00:00:45,280
the other ones, if you go to Coté.io slash Tanzu talk, you can see an archive of all the videos

9
00:00:45,280 --> 00:00:51,520
and show notes. And in general, you can go to Tanzu.tv as well and see all the videos, the

10
00:00:51,520 --> 00:00:57,900
streams that we do. I generally broadcast every weekday around 11, 1130 a.m. Amsterdam

11
00:00:57,900 --> 00:01:01,880
time. So you should check those out as well. There's a whole lot of good stuff over there.

12
00:01:01,940 --> 00:01:03,620
And with that, enjoy the episode.

13
00:01:04,100 --> 00:01:09,520
And what I wanted to go over today is, you know, a bit of a brain dump about a topic called

14
00:01:09,520 --> 00:01:14,940
platform operations or as we fancy calling it platform as a product. I mean, this topic can

15
00:01:14,940 --> 00:01:21,720
also just be like, it more often comes up in how do I run my DevOps teams or how do I run

16
00:01:21,720 --> 00:01:26,680
Kubernetes stuff? It's like the people in charge of infrastructure and operations and stuff like

17
00:01:26,680 --> 00:01:33,180
that that are like running your infrastructure, maybe even running your platform as a service.

18
00:01:33,280 --> 00:01:40,440
Now, this idea has evolved a lot over time. You know, I just yesterday had a part two of a discussion

19
00:01:40,440 --> 00:01:45,960
with with Bosky and there's another one. And I think, you know, it traditionally in this majority

20
00:01:45,960 --> 00:01:51,260
of what still happens is you have people basically running your vSphere, your VMware estate, and you run

21
00:01:51,260 --> 00:01:55,240
all your stuff there. And as she was talking about, you know, they do a lot of capacity management,

22
00:01:55,240 --> 00:02:02,200
a lot of kind of setting up of VMs. And to a certain extent, it sounds like helping people out with

23
00:02:02,200 --> 00:02:07,140
those VMs. But developers, the people writing and running the custom software in large organizations

24
00:02:07,140 --> 00:02:15,220
are just sort of left up to do whatever, right? They can specify things differently. Now, I hadn't

25
00:02:15,220 --> 00:02:19,540
actually thought about this kind of introduction of why this topic comes up. So this is fun to kind

26
00:02:19,540 --> 00:02:27,200
of run through it. But I think the reason this new idea comes up of platform, you know, operations,

27
00:02:27,200 --> 00:02:32,080
and what does it mean to run this is the nature of what you do when you're operating,

28
00:02:32,080 --> 00:02:37,940
when you're running this infrastructure, this centralized platform for a large organization.

29
00:02:38,580 --> 00:02:45,140
It, you know, I don't really think it changes. I think there are new responsibilities that you

30
00:02:45,140 --> 00:02:53,960
have. And that new responsibility is basically thinking a lot more about what's running in

31
00:02:53,960 --> 00:02:59,380
your VMs and your containers and how they coordinate with each other. You're taking a much more active

32
00:02:59,380 --> 00:03:04,360
role in what we used to call the enterprise architecture and defining what the architecture

33
00:03:04,360 --> 00:03:10,840
of these applications are. And the reason that you do this, there's two main reasons that I can think

34
00:03:10,840 --> 00:03:16,320
of at the moment. The first one is that it's really inefficient to not centralize and standardize it.

35
00:03:16,320 --> 00:03:23,560
Now, you know, any centralized piece of IT or ideas eventually gets neglected so much that it doesn't

36
00:03:23,560 --> 00:03:29,220
evolve. And it becomes not only a huge piece of technical debt, but a huge calcified concrete

37
00:03:29,220 --> 00:03:34,820
thing that's weighing you down. And you saw this with enterprise service buses, with Java application

38
00:03:34,820 --> 00:03:41,540
servers. You can also see it with lamp stacks and old versions of, you know, open source stuff that you

39
00:03:41,540 --> 00:03:48,880
just never upgrade. And SOA stuff, all of these ways of centralizing and standardizing the way that

40
00:03:48,880 --> 00:03:55,940
applications are architected, designed, the way they're run. They were all great at the time. And

41
00:03:55,940 --> 00:04:03,600
I don't know, people just neglect them. And then they become crap. I don't know what else to tell you.

42
00:04:03,800 --> 00:04:09,540
That's the way it goes. So we're constantly coming in every five or 10 years and kind of renewing

43
00:04:09,540 --> 00:04:14,140
what those things are, because we've decided we don't want to pay attention to them anymore or evolve

44
00:04:14,140 --> 00:04:20,940
them. There's all sorts of reasons, whatever. So because we have something, you know, let's call it

45
00:04:20,940 --> 00:04:26,660
cloud native or Kubernetes, and then the platform as a service built on top of that, there's a whole new

46
00:04:26,660 --> 00:04:35,140
way of doing applications that let's just say, is good and desirable, right? Like, and so this means

47
00:04:35,140 --> 00:04:40,180
there's a new way that operations people need to think and, and run through things. So I want to go

48
00:04:40,180 --> 00:04:46,320
over just kind of like I was saying, a brain dump of everything I know, at the moment, I should say no,

49
00:04:46,660 --> 00:04:54,100
and can remember, or find in my notes, about platform operation stuff about what there's a new way of

50
00:04:54,100 --> 00:05:02,660
being assist admin, whatever you want to call it is. So let's switch over to looking at my notes.

51
00:05:02,840 --> 00:05:07,300
So you know, if you really want to see macro stuff, if you're you can see how this could be like a

52
00:05:07,300 --> 00:05:12,960
presentation, but you know, there's some great Gartner survey stuff that's basically like, this is a good

53
00:05:12,960 --> 00:05:19,460
idea. It people that we surveyed who are running things in a platform structured way, they see that

54
00:05:19,460 --> 00:05:24,980
things are going better. And I think as always, you know, paying attention to satisfaction, right? And

55
00:05:24,980 --> 00:05:29,160
I'm pretty sure what they mean by this, I'd have to go look it up as developers, not, you know, people

56
00:05:29,160 --> 00:05:34,020
like you and me who are operating with businesses. Although maybe it does go that far, that's, that'd be

57
00:05:34,020 --> 00:05:40,860
great. But essentially, they find success with doing things in this way. And one of the key things that

58
00:05:40,860 --> 00:05:49,800
Gartner and we as well, right, like, this is kind of my, my not quite a vendor pitch, sort of way of going

59
00:05:49,800 --> 00:05:56,780
over things, you know, people always want me not to give a vendor pitch. So, you know, I'll add before

60
00:05:56,780 --> 00:06:02,140
I get into this that I've kind of, uh, pulled a lot from a couple of Gartner reports and other things,

61
00:06:02,140 --> 00:06:10,200
but, uh, we in, in the pivotal labs world, which is a part of, uh, VMware Tanzu, uh, we find all the

62
00:06:10,200 --> 00:06:16,120
same stuff and we've been doing this kind of, uh, platform operation stuff for a long time, at least

63
00:06:16,120 --> 00:06:22,460
five years, if not more. And we have a great business to give you a little CTA, uh, in actually not only

64
00:06:22,460 --> 00:06:28,580
helping people become aware of and train and stand up their platforms, the VMware Tanzu stack of stuff,

65
00:06:28,640 --> 00:06:32,880
you know, what you would expect from a professional services organization, where you buy some big

66
00:06:32,880 --> 00:06:38,020
chunk of software and you pay some extra to have someone help you install it. But we actually pair

67
00:06:38,020 --> 00:06:43,920
up with people who are doing, doing, uh, platform operations to, uh, train them up on it, to kind of

68
00:06:43,920 --> 00:06:48,200
figure out the, um, we don't call it a run book, but kind of figure out the book of practices and

69
00:06:48,200 --> 00:06:52,760
things that they'll do and, uh, start to do some of the initial projects with developers.

70
00:06:53,600 --> 00:06:58,760
You should totally look into that. Uh, you can email me at Codem. I'm not sure who this Codem

71
00:06:58,760 --> 00:07:05,780
character is, but Codem, C-O-T-E-M at VMware.com or, you know, otherwise try to contact us and, uh,

72
00:07:05,780 --> 00:07:11,280
we can go over that in some more depth, but pretty much all of this matches, uh, all of the stuff.

73
00:07:11,280 --> 00:07:16,740
Well, all of it matches what we do. Otherwise, as someone who works at a vendor and never gives a

74
00:07:16,740 --> 00:07:24,360
vendor pitch, I would not be vendoring it to you. Um, so let's, uh, let's go over what generally

75
00:07:24,360 --> 00:07:32,820
occurs. So the idea of a, of a platform, uh, operations team is that you're centralizing this,

76
00:07:32,940 --> 00:07:37,400
this platform that you're running. Now, what do I mean by platform? It could be you're running

77
00:07:37,400 --> 00:07:42,020
Kubernetes and having multiple clusters that developers can package up and run their things

78
00:07:42,020 --> 00:07:47,820
on. It could be like you're using a platform as a service, like the VMware Tanzu, uh, application

79
00:07:47,820 --> 00:07:54,620
service, you know, cloud foundry. Uh, and so you're, you're, um, again, you're, you're giving

80
00:07:54,620 --> 00:08:00,520
all the development teams, this standard centralized way of doing things. It could be that you're,

81
00:08:00,660 --> 00:08:05,020
uh, you might even be building your own stuff, uh, whether it's on public clouds or your own

82
00:08:05,020 --> 00:08:11,460
infrastructure, but the goal remains the same in all of these cases. And that is to remove as much

83
00:08:11,460 --> 00:08:17,960
variability as possible, right? To standardize on how the infrastructure is, uh, sort of allocated out

84
00:08:17,960 --> 00:08:23,140
to people, how your development teams use that infrastructure, how they make that infrastructure

85
00:08:23,140 --> 00:08:29,400
ready to be in production. Um, how they standardize on the types of frameworks and services they use,

86
00:08:29,400 --> 00:08:34,880
all of this type of stuff where you're trying to centralize, uh, the it that you're using, uh, just

87
00:08:34,880 --> 00:08:40,120
as you would expect. Right. And I think, I think a major difference again, why things are different

88
00:08:40,120 --> 00:08:46,360
because in the traditional more VM led world, you really don't spend too much time kind of like

89
00:08:46,360 --> 00:08:52,660
as an infrastructure person, again, as an operations person, your responsibility kind of stops at the VM

90
00:08:52,660 --> 00:08:57,360
level, right? Like you're not really dictating a lot of how the applications are architected or built,

91
00:08:57,360 --> 00:09:03,260
right? You're not being involved in as we'll get into kind of like the build process or the middleware,

92
00:09:03,360 --> 00:09:10,960
the framework, right? You're not really a provider. You're not a, a vendor to developers of the stack

93
00:09:10,960 --> 00:09:15,700
that they need. You're more just kind of like arranging and giving them infrastructure and you

94
00:09:15,700 --> 00:09:21,880
don't really care, uh, what happens with it. And so it really comes from that, you know, these major

95
00:09:21,880 --> 00:09:28,320
differences that I think drive this need to have a platform team. So the, the, the, the key sort of

96
00:09:28,320 --> 00:09:33,680
consequence of that, if you think about it, one, you need to centralize as much as possible. This is

97
00:09:33,680 --> 00:09:40,000
sometimes a bad idea for developers, but like, again, the more variability you allow, the more ways you

98
00:09:40,000 --> 00:09:45,980
allow people to package up and run and architect their applications in Kubernetes or in, you know, a

99
00:09:45,980 --> 00:09:51,800
platform as a service, uh, like the Tanzu application service or whatever, the more stuff you're going to

100
00:09:51,800 --> 00:09:57,760
have to manage, the more you open things up for errors and doing things kind of wrong, the more

101
00:09:57,760 --> 00:10:03,720
knowledge you need to, to garden and persist and keep to keep your platform, all your stuff from

102
00:10:03,720 --> 00:10:10,320
atrophying, right? Like variability, not cool. Like that's, that's what causes a lot of problems.

103
00:10:10,740 --> 00:10:19,260
Um, so looking inward, right at the, at the, the platform team, first of all, uh, getting to the

104
00:10:19,260 --> 00:10:24,220
point where you have this strategy, like, I mean, this is what, uh, what Gartner recommends. And it's

105
00:10:24,220 --> 00:10:29,120
kind of what I've seen in our practices over the years is like when you have like three or four teams,

106
00:10:29,120 --> 00:10:34,120
that's when you really need to centralize a platform, right? In contrast, you can take the

107
00:10:34,120 --> 00:10:40,980
kind of full stack approach where each team, each software team is essentially building their own,

108
00:10:40,980 --> 00:10:47,200
um, layer between raw infrastructure, between compute network and storage, and they're running

109
00:10:47,200 --> 00:10:51,880
applications, the way that things are packaged, managed the way that they're made ready to monitor

110
00:10:51,880 --> 00:10:56,500
and production. They're kind of determining what that framework is. And they're kind of one-offing a

111
00:10:56,500 --> 00:11:02,080
lot of that. And, you know, doing that for one or two teams is probably okay. But once you hit three

112
00:11:02,080 --> 00:11:05,760
or four teams, once you've got this momentum and you're going beyond that, you're going to have

113
00:11:05,760 --> 00:11:10,680
lots of problems. Again, you're going to introduce variability and, uh, that's always an issue,

114
00:11:10,680 --> 00:11:15,040
right? There's no way around that. So once you hit that three or four team thing, or if you want to

115
00:11:15,040 --> 00:11:21,960
be proactive and anticipate it, you really need to build a centralized platform team, right? So this team,

116
00:11:22,440 --> 00:11:28,160
what is it that they're going to own, right? So obviously they're going to own whatever that upper

117
00:11:28,160 --> 00:11:34,920
interface is, the development teams, right? And that might mean just Kubernetes, right? So you might

118
00:11:34,920 --> 00:11:39,940
be giving your developers just direct access to Kubernetes to deploy their applications, or it

119
00:11:39,940 --> 00:11:45,060
might mean a, uh, you know, again, uh, the platform, uh, the paths that you're using,

120
00:11:45,060 --> 00:11:52,880
but you're going to own running that specifying that, uh, and evolving that you're going to own it as a

121
00:11:52,880 --> 00:11:59,840
product. Hence that phrase we use, uh, platform as a product. And so that team, uh, needs to be the

122
00:11:59,840 --> 00:12:04,620
one in charge of that. Now, what this also implies, and if you'll remember, I think it was, um,

123
00:12:05,620 --> 00:12:11,900
I think it was Bosky yesterday. I was talking about this with, or maybe someone else, I forget. Um,

124
00:12:12,300 --> 00:12:18,300
but looking downward, that team also needs to own as much of the, the, the stack downward as possible,

125
00:12:18,300 --> 00:12:25,020
right? So essentially that means three areas, right? They compute your servers, uh, networking,

126
00:12:25,020 --> 00:12:33,200
uh, and storage. And anytime that they have to talk to someone else, another team that is managing,

127
00:12:33,200 --> 00:12:37,900
uh, those three, you know, one or three, one of those three things on their own, you're going to

128
00:12:37,900 --> 00:12:42,320
introduce immediately a constraint, a bottleneck, right? They're going to have a block. They're

129
00:12:42,320 --> 00:12:47,240
going to have to wait on that team anytime that they need to add capacity, that they need to change

130
00:12:47,240 --> 00:12:51,480
the way that networking works, you know, that they need to do anything. They're going to have to

131
00:12:51,480 --> 00:12:56,220
have a meeting with that team, prove that that those teams should do anything that this wacky new way of

132
00:12:56,220 --> 00:13:01,180
doing stuff should be allowed. Um, and it's just going to slow things down, right? And the point of

133
00:13:01,180 --> 00:13:07,460
all of this is to not slow things down. So initially this team is going to have to spend a lot of time

134
00:13:07,460 --> 00:13:15,620
with these external parties, or if you're lucky, you can collapse the management of those things into

135
00:13:15,620 --> 00:13:20,220
this, this team as well. And this team might be the amount of people that it is. I don't know.

136
00:13:20,220 --> 00:13:24,720
You'll have to figure that out. It could, it could be a handful of people. It could be a lot of people.

137
00:13:24,800 --> 00:13:29,680
There could be a lot of sub teams, but you know, the, the area of responsibility, you want to own as

138
00:13:29,680 --> 00:13:36,260
much of that stack, uh, as possible. Um, otherwise again, you're, you're going to introduce, uh, just

139
00:13:36,260 --> 00:13:42,480
friction into the system, which, which doesn't really make sense, right? Like if the point of what

140
00:13:42,480 --> 00:13:47,860
you're doing is to remove friction from the system, you don't want to introduce friction into the system

141
00:13:47,960 --> 00:13:56,160
or, uh, keep it there. So, um, let, let, now let me talk about the, the kind of mindset and the

142
00:13:56,160 --> 00:14:03,120
orientation, which I mentioned briefly, but kind of, uh, uh, specify that out a little bit more and

143
00:14:03,120 --> 00:14:10,240
kind of go over some, some ideas of what it means. So as I was saying, so the major shift, um,

144
00:14:10,500 --> 00:14:18,400
I think that I see these teams taking is again, you know, I mean, again, from my canon of spieling

145
00:14:18,400 --> 00:14:26,220
what we're doing here, the whole concern of digital transformation of Kubernetes of cloud native

146
00:14:26,220 --> 00:14:31,260
development for us is that we want to evolve the business rapidly. We want to add new features,

147
00:14:31,400 --> 00:14:36,720
experiment with things on a weekly basis, if not daily. This means we need to speed up our ability

148
00:14:36,720 --> 00:14:42,940
to get new features out the door, which means we need to, um, really think about the role of software

149
00:14:42,940 --> 00:14:48,580
development and product management of software, uh, in the organization and enable that as much as

150
00:14:48,580 --> 00:14:54,300
possible, uh, and enable as much as possible. And I mean, that's what we're constantly paying attention

151
00:14:54,300 --> 00:14:59,740
to. So from an infrastructure standpoint, from an operation standpoint, that means we automate as many

152
00:14:59,740 --> 00:15:05,160
things as possible. So we don't have to worry about tedious things, uh, that like, don't really have

153
00:15:05,160 --> 00:15:11,400
direct customer value that are just kind of like, I don't know, standard tedious junk. But it also means

154
00:15:11,400 --> 00:15:20,180
that as operations people, our customers become those developers. We, as the operations people are

155
00:15:20,180 --> 00:15:27,180
trying to help our customers, the developers do things as best as possible. Now that doesn't mean doing

156
00:15:27,180 --> 00:15:33,600
everything they want at all, it doesn't mean that, but what it means is analyzing what problems they

157
00:15:33,600 --> 00:15:38,320
have, what jobs to be done. If you want to use that terminology, they have what features are needed

158
00:15:38,320 --> 00:15:43,320
and providing that to them in the, in the platform and the infrastructure that you're doing. This means

159
00:15:43,320 --> 00:15:49,580
your product managing, uh, that, right? Like you're constantly studying, uh, what is it that developers

160
00:15:49,580 --> 00:15:54,880
need? Let's theorize a way that we could give that to them. Let's give, let's figure out kind of

161
00:15:54,880 --> 00:16:00,980
like a minimal viable product, a minimal viable way to gather experimentation and validate or invalidate

162
00:16:00,980 --> 00:16:06,820
those theories. And then keep going on this, this cycle of really product managing what you're giving

163
00:16:06,820 --> 00:16:11,160
them. Now, obviously there's going to be a whole lot of stuff that you don't have to product manage

164
00:16:11,160 --> 00:16:15,820
that you will just know that they need, uh, and you can start to set up. There will also be things

165
00:16:15,820 --> 00:16:23,320
taking kind of an SRE standpoint that you want developers, you will sort of negotiate with them,

166
00:16:23,360 --> 00:16:28,540
excuse me, that they, they will need to do right. Like even if a developer is not asking for it,

167
00:16:28,540 --> 00:16:35,100
when this application is running in production, you will need to be able to, uh, let me adjust my

168
00:16:35,100 --> 00:16:41,240
camera. You really got to be able to see the top of my head. I mean, don't you think, um, you know,

169
00:16:41,300 --> 00:16:46,600
it needs to be manageable. You need to be able to monitor it. You need to be able to restart it if

170
00:16:46,600 --> 00:16:51,340
needed, which is something nice that Kubernetes and a lot of higher level platforms like the Tanzu

171
00:16:51,340 --> 00:16:55,480
application service do for you. You need to be able to do rollbacks. There's all these things

172
00:16:55,480 --> 00:17:01,980
that you as an operations person probably intuitively know are going to be required that a developer may

173
00:17:01,980 --> 00:17:08,220
not exactly be thinking of, but you build up this list of features, right? And the important part is

174
00:17:08,220 --> 00:17:12,660
you're constantly going through and improving it by taking a real product management, look at it.

175
00:17:12,720 --> 00:17:19,380
Now let me scroll down to where is it? Uh, right. There's two like, like Gartner lists that I wanted

176
00:17:19,380 --> 00:17:26,060
to go, but you know, as help, and this is, uh, let me see which one there's two Gartner papers that

177
00:17:26,060 --> 00:17:30,800
are pretty good. Uh, as far as kind of going over a lot of this stuff and even giving you some stuff

178
00:17:30,800 --> 00:17:36,580
to start with. And this one is from the, uh, ah, the lengthier one, the, uh, they don't call

179
00:17:36,580 --> 00:17:41,560
himself Burton group anymore, but this is the part of Gartner that puts out like 50, 80 page PDFs that

180
00:17:41,560 --> 00:17:46,440
are a lot more prescriptive than the market analysis, but there's a good list of things to

181
00:17:46,440 --> 00:17:52,520
kind of kick off. Uh, what, uh, when you're putting kicking off and ongoing your platform team, like

182
00:17:52,520 --> 00:17:57,500
things you probably will want to pay attention to things that people, uh, that you'll put in that

183
00:17:57,500 --> 00:18:01,180
developers will need and that you'll need, right? Like, as I was saying, you know, you're going to need

184
00:18:01,180 --> 00:18:07,140
some monitoring, uh, you know, this is, this is an example of toil, right? So like, what are,

185
00:18:07,280 --> 00:18:12,540
what are different things that people do over and over again, uh, that you can automate for them?

186
00:18:12,700 --> 00:18:19,300
Let me, let me space this out a little bit. Yeah. Yeah. And, uh, I don't know, there's, there's all

187
00:18:19,300 --> 00:18:23,400
sorts of things here, right? Like, uh, something that's kind of missing from here that I would also

188
00:18:23,400 --> 00:18:31,840
think about in a, um, in a cloud native, right? Like in a Kubernetes, uh, or platform as a service

189
00:18:31,840 --> 00:18:37,060
kind of world is like, what service mesh are you going to provide for people? And by service mesh,

190
00:18:37,140 --> 00:18:43,560
what I mean is a standardized way of having all the different, not only the components of one piece

191
00:18:43,560 --> 00:18:48,220
of software, one app talk with each other, because all apps nowadays are basically distributed

192
00:18:48,220 --> 00:18:54,340
applications where you carve off sub components of the application to run on more, I'm simplifying it

193
00:18:54,340 --> 00:18:59,860
to run on different IP addressable things, different servers or in different containers. And you're

194
00:18:59,860 --> 00:19:05,100
really a developer doing the style of applications is really kind of orchestrating a bunch of these

195
00:19:05,100 --> 00:19:10,240
services together. And then there's also all the types of middleware, uh, that you want to provide,

196
00:19:10,320 --> 00:19:14,620
whether it's databases or message queues. And then of course, you know, you're going to have all

197
00:19:14,620 --> 00:19:20,660
your security and compliance and governance things. So orient yourself around that, right? Like, I mean,

198
00:19:20,660 --> 00:19:26,980
if you've never really spent time understanding what product management is, or, you know, if you don't

199
00:19:26,980 --> 00:19:32,820
know, if you've never encountered the phrase lean product management or the product pragmatic product

200
00:19:32,820 --> 00:19:37,820
manager, I mean, that's a, that's a really old one, but like get familiar with, uh, what the deal

201
00:19:37,820 --> 00:19:42,060
with product management is. And there's, there's actually a book I should reference here. That's a

202
00:19:42,060 --> 00:19:48,280
really good book. I read a couple of years ago that, that, uh, let me, let me put it to do thing here

203
00:19:48,280 --> 00:19:57,160
to, uh, insert that in. Cause it is, it's a good overview, but figure out product management. Cause

204
00:19:57,160 --> 00:20:03,200
this is, this is going to be a key to doing things better, right? You have to shift your mind from

205
00:20:03,200 --> 00:20:09,500
doing service delivery. We've been told we need to deliver this set of capabilities, this set of

206
00:20:09,500 --> 00:20:15,720
services, right? We needed to deliver VMs. We needed to deliver a load balancer, right? We

207
00:20:15,720 --> 00:20:22,560
have to deliver these things. And instead of just, you know, it evolves, but generally you deliver a

208
00:20:22,560 --> 00:20:29,060
service and you just incrementally evolve it as needed. You don't actually revisit it and constantly

209
00:20:29,060 --> 00:20:36,800
study. Do the developers needs for this service. Have they changed, right? Like, do we need to add

210
00:20:36,800 --> 00:20:41,400
new functionality, take away old functionality, right? Like think about what you're doing as

211
00:20:41,400 --> 00:20:46,660
constantly providing new features to developers instead of services, right? And how do you evolve

212
00:20:46,660 --> 00:20:51,760
and study what those features are? And that's a huge part of what's different from a product

213
00:20:51,760 --> 00:20:58,260
management mentality to a service delivery mentality. And to that end, right? Like another thing that's

214
00:20:58,260 --> 00:21:03,620
worth thinking about is that you're making a long-term commitment, right? So sometimes when

215
00:21:03,620 --> 00:21:09,500
people set up a chunk of infrastructure, they're thinking is that we'll have this initial, maybe

216
00:21:09,500 --> 00:21:14,980
even like an advanced POC proof of concept. And we're just kind of going to like set it in motion.

217
00:21:14,980 --> 00:21:21,260
And then we'll have some, as traditionally, you know, a lot of the jobs that some ops people do,

218
00:21:21,440 --> 00:21:27,020
that was a lot of that some, but a lot of operations work is basically just keeping things up and

219
00:21:27,020 --> 00:21:33,240
running, right? Meeting the SLA that it has uptime and availability rather than like, let's call it an

220
00:21:33,240 --> 00:21:40,000
SLU, service level of usefulness, right? And so what this means is that you don't want to just build

221
00:21:40,000 --> 00:21:44,420
this infrastructure and keep it up and running. You're going to be spending a time, especially

222
00:21:44,420 --> 00:21:49,500
initially, I would say the first three months, maybe even six months getting it wrong a lot,

223
00:21:49,560 --> 00:21:55,160
right? Like a constant theme with me, getting good at messing up. And what you want to do,

224
00:21:55,260 --> 00:21:59,520
what you're doing here is this is the essence of product management is you're coming up with a

225
00:21:59,520 --> 00:22:04,540
theory of how to solve a developer's problem. You know, you can think of observability as that,

226
00:22:04,620 --> 00:22:09,880
right? Like the problem we might have is that things are always going wrong in production and it

227
00:22:09,880 --> 00:22:15,020
takes us a long time to recover from that. And it takes us even longer to figure out like,

228
00:22:15,020 --> 00:22:19,820
what's going wrong so that we can fix it. So you have an observability problem, at least in that second

229
00:22:19,820 --> 00:22:26,400
case. So you might come up with several ways, not only technologies to instrument and make observable

230
00:22:26,400 --> 00:22:35,480
that you might bundle in there, but also, and this is another key shift is you as a platform team are

231
00:22:35,480 --> 00:22:41,280
going to have to come up with practices and mindsets, even culture that people follow, right? So if an

232
00:22:41,280 --> 00:22:47,440
issue that you have is that developers are constantly putting stuff into production and something goes

233
00:22:47,440 --> 00:22:53,160
wrong and you can't diagnose it and fix it, it takes a long time, then there's some kind of process problem

234
00:22:53,160 --> 00:23:00,340
the developers have. Like they're not writing their code to be observable or diagnosable, knowable,

235
00:23:00,440 --> 00:23:05,900
if you will. I'm disclaiming too much. I just don't want to get the observable observability monks all

236
00:23:05,900 --> 00:23:10,820
up in a tizzy because I'm not being precise enough in my definition. Essentially there's problems in

237
00:23:10,820 --> 00:23:15,500
production and the developers aren't really helping the situation out, right? So you're going to have to

238
00:23:15,500 --> 00:23:19,940
think about what kind of process, what kind of mindset shift can I as the platform team help my

239
00:23:19,940 --> 00:23:24,300
developers go through and tools that I provide them. And this is a, you know, that'll happen in

240
00:23:24,300 --> 00:23:29,000
the first, the initial kind of a couple of quarters, but then ongoing, you can see that there's all

241
00:23:29,000 --> 00:23:33,120
sorts of topics that come up that you'll need to figure out, not only that they exist and how to

242
00:23:33,120 --> 00:23:38,840
solve them, but to constantly be addressing them. And, you know, there's a couple of initial things

243
00:23:38,840 --> 00:23:43,960
here, right? Like chargebacks is going to come up. I think some time ago, I had a little episode

244
00:23:43,960 --> 00:23:48,200
about chargeback stuff, but you're going to figure out how to need to figure out how to do chargebacks

245
00:23:48,200 --> 00:23:52,540
and kind of how to cycle through different ways of doing it. You're going to have to figure out

246
00:23:52,540 --> 00:23:58,160
how to, again, do all your monitoring stuff. And then also just generally, right? Like in your

247
00:23:58,160 --> 00:24:03,100
organization, you're going to have to evolve who has responsibilities for what in your DevOps world,

248
00:24:03,180 --> 00:24:08,200
right? Like how much operational response in production responsibility developers have versus

249
00:24:08,200 --> 00:24:13,560
you, the platform team? How do you divide that up? Like there's a lot of this constant discovery that

250
00:24:13,560 --> 00:24:18,780
you're going to go through. So you really are making this long-term commitment to doing something.

251
00:24:19,700 --> 00:24:26,360
You know, you're more, this is all soft, the way of putting it, but you're more providing this idea

252
00:24:26,360 --> 00:24:33,560
of what a platform is, not just the, the actual infrastructure, the code, the running stuff that

253
00:24:33,560 --> 00:24:43,120
you're providing. Now, a couple of more things. One, if you think about this idea that what we

254
00:24:43,120 --> 00:24:52,320
operations, infrastructure, sysadmin, whatever admin people are doing now is we are making the lives

255
00:24:52,320 --> 00:24:58,900
of our development teams better, right? Like we are, we are the, the servants, if you will, of them.

256
00:24:59,680 --> 00:25:04,220
Some of the things, you know, you also have other stakeholders and that will largely be

257
00:25:04,220 --> 00:25:11,860
your like compliance and security people, right? But this brings in two other areas that traditionally,

258
00:25:11,860 --> 00:25:17,760
I don't think most infrastructure ops people think too much about. One of them is for developers,

259
00:25:17,760 --> 00:25:24,340
again, to remove variability, but also to make it better, to make the overall quality of running their

260
00:25:24,340 --> 00:25:30,540
software and all of the production concerns that you have. It's highly likely that you will want to

261
00:25:30,540 --> 00:25:37,880
control as much of the build process as possible, right? So, um, you know, I'm always a little leery of,

262
00:25:37,880 --> 00:25:44,600
uh, kind of centralizing a build, but that's just my own personal history with like the build person

263
00:25:44,600 --> 00:25:51,600
who was always a bottleneck long, long ago when I was a developer. But nowadays, I think it behooves

264
00:25:51,600 --> 00:25:59,940
the platform team behoove, uh, and also developer teams to try to standardize on a way of automating

265
00:25:59,940 --> 00:26:05,720
their builds, right? Their continuous integration tool and how the tooling that they use in the policy

266
00:26:05,720 --> 00:26:12,960
to move from checked in verified code to packaging it all up and making sure that it gets into production,

267
00:26:12,960 --> 00:26:19,240
right? So generally what I see is this is a function that the platform team really is in charge of. And

268
00:26:19,240 --> 00:26:24,920
you can think about all the other tools that are involved in doing software and how the platform

269
00:26:24,920 --> 00:26:30,120
team is probably best suited to be in charge of that as well. Now, the other side that comes with

270
00:26:30,120 --> 00:26:35,860
this is it's probably a good idea for you, the platform team to kind of be the focal point for

271
00:26:35,860 --> 00:26:40,720
dealing with compliance and security and things like that, right? Because if you control the build

272
00:26:40,720 --> 00:26:46,680
pipelines, uh, and you control the runtime environment, right? Your Kubernetes stuff or your platform as a

273
00:26:46,680 --> 00:26:54,360
service, you have, you're, you're the people who have the ability to automate and improve the quality

274
00:26:54,360 --> 00:27:00,520
of compliance and security because you can automate and bake in and enforce a lot of those things

275
00:27:00,520 --> 00:27:06,360
rather. And this is an example of how variability is a problem rather than across your 10, 50,

276
00:27:06,360 --> 00:27:13,240
2,000 product teams relying on them to talk to the compliance and security people and relying on them

277
00:27:13,240 --> 00:27:18,200
to do the right thing and also relying on them to report it back and to constantly be doing that,

278
00:27:18,200 --> 00:27:22,920
right? Instead, you can suck a lot of that down into the build pipelines that you have in the

279
00:27:22,920 --> 00:27:28,040
platforms, not as far as enforcement, but also just standardizing on how it's done.

280
00:27:28,040 --> 00:27:33,960
So those, again, this is the part of the product management mentality is like, how do we always

281
00:27:33,960 --> 00:27:38,120
make our developer lives easier? How do we always make the quality of the software that they're

282
00:27:38,120 --> 00:27:42,440
running easier? Not just the infrastructure that traditionally we are in charge of, right?

283
00:27:42,440 --> 00:27:49,160
Pay attention to the whole picture there. So finally, after that, um, kind of in the ongoing

284
00:27:49,160 --> 00:27:54,760
way of running stuff, right? Like what, what you get to very quickly is, all right, how do we scale that

285
00:27:54,760 --> 00:28:00,520
up? I mean, this is how you scale thing. Anything new up in an organization is kind of the only concern

286
00:28:00,520 --> 00:28:06,200
for the next, depending on what position you're in two to five years in our industry, right? Like you'll need

287
00:28:06,200 --> 00:28:11,000
to settle on how to do something in the small, right? Like how to start doing a couple, a handful of new

288
00:28:11,000 --> 00:28:15,480
projects this way. But then for large organizations, the next thing is going to be like, how do we

289
00:28:15,480 --> 00:28:20,520
sustainably scale this out to thousands of different teams, thousands of different whatever, right?

290
00:28:21,320 --> 00:28:27,000
And I think as always, right, when you're putting together your strategy, the important thing is to

291
00:28:27,000 --> 00:28:32,600
start small and slower than you think, right? Start with a handful, you know, like two to five projects,

292
00:28:33,560 --> 00:28:40,360
get, get not only like, uh, I don't know what you would call them really eager and overly skilled, full

293
00:28:40,360 --> 00:28:46,440
stacky kind of people and developers to work on that. But you also will need to get people who are

294
00:28:47,000 --> 00:28:54,680
normals, right? Who are just sort of your regular people, uh, and use them as this kind of the

295
00:28:54,680 --> 00:28:59,480
customers initially to start specifying what this platform should look like and all those things I was

296
00:28:59,480 --> 00:29:04,600
just going over. Right. And what that means is you're going to be learning along the way. So you don't

297
00:29:04,600 --> 00:29:09,080
want to do everything at once. And so you need to start small and probably over the first year,

298
00:29:09,080 --> 00:29:13,320
you're not going to get extremely far unless, unless you're lucky.

299
00:29:14,040 --> 00:29:18,520
Here's a tip about feeling lucky. Everyone thinks that they're going to be lucky. They think that

300
00:29:18,520 --> 00:29:24,680
they're going to be the ones who, uh, who, uh, who are lucky. Now, the opposite of that is, is this

301
00:29:24,680 --> 00:29:30,200
quippy thing to point out that 50% of the people are better than average and 50% of the people are

302
00:29:30,200 --> 00:29:35,800
worse than average. I think it might actually 49.5% if I were to think about it, but whatever.

303
00:29:36,360 --> 00:29:42,200
Um, but you know, try to be more conservative in what you're doing here and, uh, plan things

304
00:29:42,200 --> 00:29:47,320
accordingly. Now, uh, equally what that means, not equally, but another thing that comes up a lot

305
00:29:47,320 --> 00:29:51,800
that people skip over is that you're going to need to be spending a lot of time initially,

306
00:29:51,800 --> 00:29:56,840
probably the first six months, if not the first 12 months doing a lot of consulting with the developer

307
00:29:56,840 --> 00:30:02,440
teams, uh, basically really sitting with them and doing a lot of hands on like, here's how you package

308
00:30:02,440 --> 00:30:08,760
things up. Here's what it means to run stuff in a cloud native architecture. Um, here's how you can

309
00:30:08,760 --> 00:30:14,280
make things observable. You might even need to have some capability of, of actual development,

310
00:30:14,280 --> 00:30:20,360
right? Uh, here's how you just use the tools to request resources and, uh, set up your own clusters

311
00:30:20,360 --> 00:30:25,720
and your own things like that. So I've found that pretty much all organizations that they need to,

312
00:30:25,720 --> 00:30:31,800
uh, they do a lot of this consulting. Um, and also, uh, you're going to need to spend a lot of resources,

313
00:30:31,800 --> 00:30:37,320
um, not only on that, that hands-on consulting, but what I think of as internal training and marketing

314
00:30:37,320 --> 00:30:42,840
where you're going around and advocating, or as we used to say, evangelizing, uh,

315
00:30:42,840 --> 00:30:46,840
the use, what this platform is and people using it. And as I've mentioned several times,

316
00:30:47,720 --> 00:30:52,280
it's almost a year ago now, but like, um, there's, there's some good examples from, uh, BT,

317
00:30:52,840 --> 00:30:58,360
formerly British telco, um, where they have this project canvas is the name of their whole platform

318
00:30:58,360 --> 00:31:02,680
initiative. And they spend a tremendous amount of time. They have at least one person fully dedicated

319
00:31:02,680 --> 00:31:08,760
to just going out and internally marketing, raising awareness. Um, I don't know what else

320
00:31:08,760 --> 00:31:15,080
to say than about evangelizing, but evangelizing the platform. Um, uh, and you know, it's, it's great,

321
00:31:15,080 --> 00:31:19,560
actually, uh, people get very interested and it helps, helps, uh, those development teams you're

322
00:31:19,560 --> 00:31:24,120
trying to reach rate, you know, know about your platform and kind of figure out how they can start

323
00:31:24,120 --> 00:31:30,040
being in it. Now, bigger there is that probably your platform team is going to need to start, um,

324
00:31:30,040 --> 00:31:34,920
running internal conferences about every three months, and you're going to need to find help

325
00:31:34,920 --> 00:31:39,720
eventually other people outside of the platform team. But you want to get those developers who are

326
00:31:39,720 --> 00:31:44,920
running, uh, applications on there to start speaking at those and, and again, start helping

327
00:31:44,920 --> 00:31:49,800
train, raise awareness and train people. And you're going to need as platform people to do those sessions

328
00:31:49,800 --> 00:31:55,320
as well. And hopefully you can record these and put them online on your intranet or whatever,

329
00:31:55,960 --> 00:32:01,240
and start to use them as the material to bring other people, uh, up to speed. So I think I've already

330
00:32:01,240 --> 00:32:06,920
gone over the, uh, the product management part, uh, quite a bit, but finally from the beginning,

331
00:32:06,920 --> 00:32:14,840
start thinking about how you are going to prove yourself, report metrics to whoever it is,

332
00:32:14,840 --> 00:32:20,920
is controlling your fate, controlling your budget, uh, controlling your ability to do things, your,

333
00:32:20,920 --> 00:32:29,120
your, um, your priorities, the bosses, whoever your boss is, right. Um, and start putting that,

334
00:32:29,120 --> 00:32:34,240
that together and reporting on it regularly. Now, obviously what you want to show with metrics

335
00:32:34,240 --> 00:32:40,800
is improvement, right? The other thing you want to show with metrics, um, despite what,

336
00:32:40,960 --> 00:32:45,280
you know, if it's good or not, you want to show ROI, return on investment. Now, a more sophisticated

337
00:32:45,280 --> 00:32:51,200
way of thinking about financial metrics is you're showing that you are getting value for your spend.

338
00:32:51,200 --> 00:32:58,000
Now, Americans are particularly bad at thinking about getting what you pay for because it's part of our

339
00:32:58,000 --> 00:33:04,720
culture, uh, to really try to get the cheapest deal possible. Like we don't really think about

340
00:33:04,720 --> 00:33:11,520
there is, there is a point, I forget what they call it, of marginal returns. There is a point of

341
00:33:11,520 --> 00:33:16,880
spending where you're not getting that much more for what you're spending. Um, but until you reach that

342
00:33:16,880 --> 00:33:22,320
point, the more you spend the better quality and the more that you get, uh, which is something us

343
00:33:22,320 --> 00:33:27,520
Americans don't understand. We always think that if we're clever, we can horse trade and we can spend

344
00:33:27,520 --> 00:33:33,360
a lot less money than someone else and get the same quality, if not more. Right. So, you know,

345
00:33:33,360 --> 00:33:38,880
this, this mentality percolates a lot, especially in, in us thinking, but it does in other firms.

346
00:33:38,880 --> 00:33:45,840
Um, but you still have to report on ROI. Uh, and you know, the way, the way that this TD Ameritrade

347
00:33:45,840 --> 00:33:54,160
is great on do it that they figured out how to do that is they won the model or the framing. They

348
00:33:54,160 --> 00:34:00,160
won the definition of what that meant. And what the definition of that meant was that we will achieve

349
00:34:00,160 --> 00:34:06,320
value. We will achieve return on investment as we move applications to the platform. So the,

350
00:34:06,320 --> 00:34:11,120
the, the one metric that they started tracking was how many applications that we moved to the

351
00:34:11,120 --> 00:34:15,440
platform. So the, the less applications they have moved, that means they need to investigate and

352
00:34:15,440 --> 00:34:18,960
figure out why the more that they had moved, the more success they would have. So that's a good

353
00:34:18,960 --> 00:34:25,520
metric to report. Right now, again, to this idea of constantly evolving, uh, what you're doing,

354
00:34:26,080 --> 00:34:30,320
they shifted that after a while, they shifted that to, well, we will actually achieve value,

355
00:34:31,200 --> 00:34:36,000
even more value return on investment when we move these applications to production.

356
00:34:36,000 --> 00:34:39,920
Right? So that's the new metric. They started tracking after some time, but that's just an

357
00:34:39,920 --> 00:34:45,680
example of how to track ROI, right? You're spending time and money. And usually the way you figure time

358
00:34:45,680 --> 00:34:50,640
is just staffing, right? Um, you can get really sophisticated with opportunity costs and things

359
00:34:50,640 --> 00:34:55,360
like that, which is totally cool. If you can get an agreement on that, but start thinking about

360
00:34:55,360 --> 00:35:01,520
return on investment based on staffing time, uh, and, um, things like that as they basically did now,

361
00:35:02,080 --> 00:35:07,920
and, and just moving things, uh, to the platform. So then the other thing, uh, that you will have to

362
00:35:07,920 --> 00:35:15,360
start thinking about tracking is you can call this time to market, but somehow start, start to think about

363
00:35:15,360 --> 00:35:21,840
how you will model out and win agreement on how you report on, we are, the business is moving faster,

364
00:35:21,840 --> 00:35:26,800
right? Which could be the business can innovate new ideas. So the actual business can change how

365
00:35:26,800 --> 00:35:32,000
it operates, which basically means adding new features. Um, even if they're not changing how

366
00:35:32,000 --> 00:35:37,520
they operate, we are able to deliver more frequently. So even if we're just kind of making incremental

367
00:35:37,520 --> 00:35:42,800
improvements, uh, we're improving how the business currently functions instead of changing how it

368
00:35:42,800 --> 00:35:48,240
functions, but we can do that more rapidly. Right? And this is kind of just tracking feature delivery,

369
00:35:48,240 --> 00:35:54,800
right? Like we are making it faster for developers to deliver features. Now, you know, you can also

370
00:35:54,800 --> 00:36:01,120
track in, you should also track like how fast you can do. Um, people like to be all cool and say CVE,

371
00:36:01,120 --> 00:36:06,000
but you know that you can do security patches and you can address needs that you have. Um, and that's

372
00:36:06,000 --> 00:36:11,920
a great thing to track as well, you know, off in, uh, here in to be a little vendor pitchy,

373
00:36:11,920 --> 00:36:17,040
we have this five S's message that methodology. That's, uh, as you can imagine, five things that

374
00:36:17,040 --> 00:36:21,520
start with S and there's a good framework that we have there. If you want to use that as a baseline

375
00:36:21,520 --> 00:36:27,440
for, I think there's like five, you know, it's like speed, stability, security. I forget what they

376
00:36:27,440 --> 00:36:33,440
all are. I don't have my charts with me, but there's basically five or eight or 10 submetrics in there.

377
00:36:33,440 --> 00:36:38,160
And you can kind of a pick and chooses makes sense for you as a kind of a baseline of metrics to do.

378
00:36:38,160 --> 00:36:41,920
And, you know, if you start doing that from day one, if you have a baseline, it allows you to

379
00:36:41,920 --> 00:36:48,560
really track improvement and start reporting on, um, on, on that success, that success on how things

380
00:36:48,560 --> 00:36:54,080
are going. But, you know, so that's my, my kind of brain dump on everything that I know about, uh,

381
00:36:54,080 --> 00:36:59,440
platform operations and, uh, and delivery. And just to go over this last list and I'll put this

382
00:36:59,440 --> 00:37:05,680
stuff in the show notes, why not? But you know, this list is kind of funny, but it is a good list

383
00:37:05,680 --> 00:37:10,720
from, from the, uh, from the Gartner people from this other report of like the type of people, uh,

384
00:37:10,720 --> 00:37:14,240
that you want for your platform operations team, right? The type of people that you,

385
00:37:16,000 --> 00:37:20,480
the skills that they have that you need to start thinking about that's kind of in contrast to

386
00:37:20,480 --> 00:37:25,600
traditional infrastructure people. Now, as always, I would suggest that like, these are the roles,

387
00:37:25,600 --> 00:37:31,040
these are the types of people that you always want, right? Um, which is fine, but like, it is,

388
00:37:31,040 --> 00:37:36,000
it is a good list to kind of start with. And, you know, the other thing I was, I was making a, a

389
00:37:36,000 --> 00:37:41,040
snarky tweet about this this morning, but you know, you're going to have a skills gap. It's really

390
00:37:41,040 --> 00:37:48,880
hard to find all of these, uh, all of these kind of like, uh, angelic, uh, perfect, uh, profile of

391
00:37:48,880 --> 00:37:55,600
people. So, you know, figure out, don't figure out how you're going to, uh, hire some perfect person

392
00:37:55,600 --> 00:38:00,320
who has all of this stuff, figure out how you're going to train up the existing people that you have,

393
00:38:00,320 --> 00:38:06,160
you know, how you might find, uh, some people that even, even though they're probably not going to have

394
00:38:06,160 --> 00:38:12,720
all these skills carefully, how you train people up to this, right? And like I said, we here in Tanzu

395
00:38:12,720 --> 00:38:18,960
land in our pivotal labs practice. We have a, uh, uh, an old, very old in a good way. We have a very

396
00:38:18,960 --> 00:38:25,680
mature proven practice of helping organizations do this. We help build up, uh, this competency, um,

397
00:38:25,680 --> 00:38:30,400
more so than just a PS capability of getting things up and running, but we can help you build up that

398
00:38:30,400 --> 00:38:35,920
capability. Um, and it's not staff augmentation. We're helping train people by pairing with them and,

399
00:38:35,920 --> 00:38:40,560
uh, setting that up for you. But I mean, look, you're going to need to do that. Like,

400
00:38:40,560 --> 00:38:46,080
you're going to need to spend some time training and learning how to do this stuff. Uh, cause really,

401
00:38:46,080 --> 00:38:50,320
no one knows how to do it. And if they really do know how to do it, they're, they're getting paid a

402
00:38:50,320 --> 00:38:55,520
lot of money. Uh, and, and, uh, you know, you can always use money to hire people away, but you're

403
00:38:55,520 --> 00:39:02,400
talking about, um, uh, basically going in and doing some, uh, do they say poaching, poaching from other

404
00:39:02,400 --> 00:39:08,240
organizations where people are, uh, well compensated. And that's a low volume thing to find people who

405
00:39:08,240 --> 00:39:13,000
already know how to do this stuff. So instead be more realistic and focus on how you bring your

406
00:39:13,000 --> 00:39:20,160
existing people up to speed, uh, for, for what they can do. So, uh, that's what I got for you today.

407
00:39:20,160 --> 00:39:26,080
I think it was, uh, instructive, helpful for me to go over that kind of work. Um, and you know,

408
00:39:26,080 --> 00:39:33,280
as always, Hey, are you interested in figuring out more about all of this? Let me bring up, uh,

409
00:39:33,280 --> 00:39:39,920
some references, uh, that you might be interested in. Now I've mentioned several times, uh, that

410
00:39:41,440 --> 00:39:47,280
we have, uh, if you want to, we can help you out with, uh, doing a lot of these practices. So if you

411
00:39:47,280 --> 00:39:53,040
go to Coté.pizza, here's what you can do. You can set up, you can go here and you can select software

412
00:39:53,040 --> 00:39:58,160
development office hours, and you can just submit this and we can figure out like not only how to sort

413
00:39:58,160 --> 00:40:02,400
out your application priorities and things like that, but we can help you start figuring out how

414
00:40:02,400 --> 00:40:06,720
you might put together your, uh, your platform operations team, uh, and your strategy there.

415
00:40:07,520 --> 00:40:14,240
Also, like I said, you can try to directly contact me. Email is pretty good at Codem, C O T E M

416
00:40:14,240 --> 00:40:19,920
at VMware.com. You can send me a DM in Twitter if you're into that kind of thing. And, uh, you know,

417
00:40:19,920 --> 00:40:24,480
I don't really do this work. I just talk about it. So, uh, you would have, I can hook you up with

418
00:40:24,480 --> 00:40:29,440
someone else. Now, also, if you are someone who's interested in figuring out, uh, Kubernetes

419
00:40:30,080 --> 00:40:34,640
speaking out, is there any embarrassing stuff there? I always wonder that. Nope. Looks pretty good.

420
00:40:35,200 --> 00:40:41,040
Uh, if you, you know, speaking of training up people that you have and, uh, getting better, uh,

421
00:40:41,680 --> 00:40:46,800
with, with yourself and your, your team, you can go to kube.academy and there's a tremendous amount

422
00:40:47,280 --> 00:40:51,040
of, uh, free training and certification. I mean, I almost feel like I haven't gone through all the

423
00:40:51,040 --> 00:40:56,080
training. Oh, look, there's Cora. I should see what she does. But I feel like if you were to go

424
00:40:56,080 --> 00:41:02,800
through all of these courses, you would have a pretty solid, uh, standing of what, of not only

425
00:41:02,800 --> 00:41:08,320
what Kubernetes is, but how you use it and put it into place. And, uh, eventually, hopefully we also

426
00:41:08,320 --> 00:41:12,960
have some training on more platform oriented things, uh, for tons of application services,

427
00:41:12,960 --> 00:41:16,720
all sorts of training out there for, for that as well. Speaking of,

428
00:41:17,280 --> 00:41:23,760
if you're interested in developer, uh, knowledge, you know, resources, this is kind of, even though

429
00:41:23,760 --> 00:41:29,360
we call it the, uh, the developer center, it's actually kind of becoming, uh, as they say, the

430
00:41:29,360 --> 00:41:34,240
hub or, or the center of attention for all of the kind of technical material that we have. I just

431
00:41:34,240 --> 00:41:41,120
finally submitted a piece on what, uh, you know, digital transformation is beyond the BS way that it's

432
00:41:41,120 --> 00:41:46,400
used. Um, but you can go check that out. We've got all sorts of topics over at tonsu.vmware.com

433
00:41:46,400 --> 00:41:51,520
slash developer. Now, all of that is available. If you want to see the, the, the show notes,

434
00:41:51,520 --> 00:41:59,200
the archives, past episodes, uh, for what we have here, if you just go to Coté.io slash tonsu talk,

435
00:41:59,600 --> 00:42:06,800
it's all there. You can see yesterday's past episode, uh, you know, all the CTA, CTA stuff that I went over,

436
00:42:06,800 --> 00:42:11,200
it's all there. So with that, we'll see everyone tomorrow. Bye-bye.