1
00:00:00,000 --> 00:00:04,420
Welcome to the Cloud Native in 15 Minutes podcast. If you haven't listened before,

2
00:00:04,780 --> 00:00:08,980
the goal of the podcast is to explain some strategic and sometimes complex

3
00:00:08,980 --> 00:00:15,560
enterprise IT subjects in about 15 minutes. This episode runs longer than that, so I'm going to

4
00:00:15,560 --> 00:00:22,040
keep the intro brief and just say I'm Derek Harrison Pivotal. My guest this week is Cornelia

5
00:00:22,040 --> 00:00:27,320
Davis, Vice President of Technology at Pivotal, and we talk all about platform as a service,

6
00:00:27,800 --> 00:00:34,880
containers as a service, even touch on functions as a service, aka serverless, and how and when it

7
00:00:34,880 --> 00:00:39,320
makes sense to adopt all of these things. I think it's a really informative episode and I hope you

8
00:00:39,320 --> 00:00:45,960
do too, so stick around and listen to Cornelia Davis educate you on platform as a service and

9
00:00:45,960 --> 00:00:54,740
containers as a service. Okay, Cornelia, so to get started, can you define at a high level what we're

10
00:00:54,740 --> 00:00:58,720
talking about when we're talking about PaaS? I always take like, I take it to mean like a cloud

11
00:00:58,720 --> 00:01:03,580
foundry level of platform as a service, right? Not some of the kind of subcategories that I've seen

12
00:01:03,580 --> 00:01:09,200
thrown around. Yeah, and even before we get to the subcategories, I think the place that I would start

13
00:01:09,200 --> 00:01:14,920
is that, you know, platforms have been around forever. We have the former platforms were things like

14
00:01:14,920 --> 00:01:22,160
WebLogic and WebSphere and JBoss and, you know, maybe even Tibco and things like that. But I think that

15
00:01:22,160 --> 00:01:28,620
where we moved to when we went to PaaS was, I think the as a service part is really important

16
00:01:28,620 --> 00:01:36,720
because platform as a service was all about enabling a certain class of people, we sometimes call them

17
00:01:36,720 --> 00:01:42,440
developers, to be able to get the things that they needed to be able to get those platform capabilities

18
00:01:42,440 --> 00:01:52,080
as a service. So it's all about autonomy. It's all about enabling those, that group of individuals to

19
00:01:52,080 --> 00:01:57,220
get what they need to be able to deliver value through software with minimal friction.

20
00:01:57,740 --> 00:02:02,320
Okay. I mean, and how would you, when you look at this, at this, at this space, right? You're right,

21
00:02:02,380 --> 00:02:07,880
because application platforms have definitely been around for a long time. And I think when Heroku and

22
00:02:07,880 --> 00:02:12,620
Google App Engine and some of the, and even Microsoft Azure, I think early on, right, they were kind of

23
00:02:12,620 --> 00:02:17,600
focused themselves around this idea of platform as a service early on. But how have you seen

24
00:02:17,600 --> 00:02:25,200
that space change, I guess? I mean, it's been around since God, probably a decade at this point,

25
00:02:25,240 --> 00:02:30,540
right? Yeah. Yeah, I think it has been. And, and you know, it's, it's really interesting. I'll share

26
00:02:30,540 --> 00:02:35,660
with you my personal perspective on that. So I started working with platform as a service,

27
00:02:36,220 --> 00:02:42,820
but gosh, more than seven years ago, I was at EMC working in the corporate CTO office on

28
00:02:42,820 --> 00:02:48,460
architecture and emerging tech. And while platform as a service, you know, from things like Heroku and

29
00:02:48,460 --> 00:02:54,740
stuff have been around for 10 years, really getting entrenchment in the enterprise, really getting

30
00:02:54,740 --> 00:03:01,720
broad adoption beyond the, maybe some startups who were a little bit ahead of the curve, didn't happen

31
00:03:01,720 --> 00:03:08,800
10 years ago, that really started happening later. And so when I first started working with this,

32
00:03:08,920 --> 00:03:13,380
what I found that was really interesting, because I didn't know what PaaS was, and I started Googling,

33
00:03:13,480 --> 00:03:19,080
and I started reading things. And it was all about enabling the developer, which is kind of what I

34
00:03:19,080 --> 00:03:24,600
just said a moment ago. But I was super confused, because I was thinking, okay, there's all these

35
00:03:24,600 --> 00:03:30,800
predictions of this massive market for PaaS. And are they really just trying to make my life easier?

36
00:03:30,800 --> 00:03:35,320
Because I come from a development background. So I'm like, really? Is it just about making my life

37
00:03:35,320 --> 00:03:42,700
easier? And I think initially, that was where our thinking was. And I think that to a large extent,

38
00:03:43,440 --> 00:03:49,720
the offerings that came out was initially from this perspective of it's all about the developer.

39
00:03:50,640 --> 00:03:56,700
And the funny thing is that we still talk about the developer. We still use the term developer. And

40
00:03:56,700 --> 00:04:01,580
if you could see me, you could see that I'm actually putting air quotes around that. Because what I think

41
00:04:01,580 --> 00:04:08,040
we've learned, and so what has really changed is that our understanding of the potential value that

42
00:04:08,040 --> 00:04:14,100
something like a platform as a service can bring, goes so far beyond making Cornelia's life easier,

43
00:04:14,560 --> 00:04:19,840
making the developer's life easier, and takes you all the way to the entire life cycle of the

44
00:04:19,840 --> 00:04:25,760
application. So it's not just about development, but it's actually about deployment to production,

45
00:04:26,280 --> 00:04:33,400
operating in production, resilience in production. And even the developer workflow is considered a

46
00:04:33,400 --> 00:04:37,860
production activity, because as soon as that environment goes down, then you can't be shipping

47
00:04:37,860 --> 00:04:44,200
features anymore. And so I think that understanding that it's not just about making the developer's life

48
00:04:44,200 --> 00:04:54,760
easier has led to a maturity in PaaS that now allows us to focus on things like security and

49
00:04:54,760 --> 00:05:01,880
operational effectiveness and resilience, which when I first started studying this seven plus years ago,

50
00:05:01,880 --> 00:05:07,260
nobody was talking about it. It was all about making the developer's lives easier. So I think that that's

51
00:05:07,260 --> 00:05:08,280
one of the big differences.

52
00:05:08,720 --> 00:05:12,360
So what are some of the pros? I mean, you referenced some of the pros, obviously, but what are some of

53
00:05:12,360 --> 00:05:19,020
the pros and cons of PaaS relative to managing applications from the server on up? I assume a big

54
00:05:19,020 --> 00:05:25,680
perceived drawback is that a PaaS platform, they're perceived as too opinionated, right? But correct me if I'm wrong.

55
00:05:26,400 --> 00:05:31,200
Yeah, no, I definitely think that PaaS platforms, some people think that they're too opinionated,

56
00:05:31,200 --> 00:05:38,140
and others are actually delighted by that. I mean, I would say, honestly, a lot of Pivotal's most

57
00:05:38,140 --> 00:05:44,040
successful customers are delighted by that. But I mean, I think perhaps one of the best examples right

58
00:05:44,040 --> 00:05:50,320
now is Capital One, right? So the Capital One breach from a few weeks ago, what that was,

59
00:05:50,320 --> 00:05:58,000
was an IAM rule. So an identity and access management rule that was misconfigured. Now,

60
00:05:58,160 --> 00:06:04,420
I actually don't hold the person who configured that rule that way responsible for that. Because

61
00:06:04,420 --> 00:06:12,180
honestly, that's one of those things where IAM rules in an environment like AWS, where there are so

62
00:06:12,180 --> 00:06:19,220
many moving parts are extraordinarily complex to configure. And that's the risk, that's the tension

63
00:06:19,220 --> 00:06:26,200
that we've gotten into with PaaS, or with more, actually, maybe not so much with PaaS, but with,

64
00:06:26,200 --> 00:06:33,560
you know, developer empowerment, is this, we've gotten into this notion that, well, okay,

65
00:06:34,200 --> 00:06:38,500
we're going to enable the developer. And so the developer is going to be this full stack developer.

66
00:06:38,900 --> 00:06:44,820
And they're going to know everything that they need to know to properly secure, to properly

67
00:06:44,820 --> 00:06:51,540
deploy this in such a way that it's resilient to regional outages, and et cetera, et cetera, et

68
00:06:51,540 --> 00:06:56,320
cetera. And while I do believe that the developer has to take on responsibility, for example,

69
00:06:56,840 --> 00:07:03,100
some responsibility, for example, they do need to know how to build their application architecture so

70
00:07:03,100 --> 00:07:08,880
that it can be deployed across regions and operate across regions so that if a region goes down,

71
00:07:08,900 --> 00:07:15,280
things are still up and running. So that set of cloud native patterns, they need to understand.

72
00:07:16,020 --> 00:07:22,220
But if we, for example, if they're doing that deployment on IaaS, or in an environment where

73
00:07:22,220 --> 00:07:30,820
they are given the responsibility to configure complex IAM rules, it's really our fault in making

74
00:07:30,820 --> 00:07:36,680
that assumption that that can be done in a reasonable way. And so what I like to say is that we have to

75
00:07:36,680 --> 00:07:44,840
partition the set of activities that need to happen to run, to develop and run an application into,

76
00:07:44,840 --> 00:07:51,740
in production. We need to partition that in such a way that the experts that know about security and

77
00:07:51,740 --> 00:07:57,740
compliance and, you know, HIPAA doesn't go away because we've, you know, enabled developers,

78
00:07:57,800 --> 00:08:05,140
but we need to partition that platform in that space so that the X, that we, we give kind of a surface area

79
00:08:05,140 --> 00:08:09,860
to the experts in these various fields. It's not that I'm suggesting that developers don't care about

80
00:08:09,860 --> 00:08:16,060
security. They care. But do we want them, do we require that they be experts? Well, that's just asking

81
00:08:16,060 --> 00:08:17,040
for a world to hurt.

82
00:08:17,040 --> 00:08:22,200
I take what you're saying to be that security, at least in the IAM part of it, right, can be something

83
00:08:22,200 --> 00:08:26,900
that's enabled at the platform level and not, not at the, at the developer level, the application level.

84
00:08:27,200 --> 00:08:33,220
Yeah, that's right. And those opinions are in fact, exactly what not only makes developers' lives

85
00:08:33,220 --> 00:08:39,740
easier, or in some cases they think harder, but it is actually what makes the overall, remember I said,

86
00:08:39,740 --> 00:08:46,320
it's not all about the developer. It is about the entire business. It's about making sure that we can

87
00:08:46,320 --> 00:08:52,360
operate these things securely and effectively and all of that stuff. And so those opinions aren't there

88
00:08:52,360 --> 00:08:58,140
to constrain the developer. They're actually there to, for example, enhance our security posture.

89
00:08:58,720 --> 00:09:00,260
And that's hugely valuable.

90
00:09:01,260 --> 00:09:04,580
Okay. And I mean, this might get into some of that, but I mean, how, so, so how do you think,

91
00:09:04,580 --> 00:09:10,900
when you think of PaaS, you know, in, in relation to some of the other things like, uh, IAS infrastructure

92
00:09:10,900 --> 00:09:15,020
as a service, IAS, I guess, or containers as a service or microservices, there's other things where

93
00:09:15,020 --> 00:09:20,500
it tends to get, uh, kind of grouped together. I mean, how do you, how do you think about, I guess,

94
00:09:20,500 --> 00:09:23,060
that relationship between, between these various things?

95
00:09:23,600 --> 00:09:30,040
Yeah. Well, I mean, of the things that you listed, so microservices, for example, I think that

96
00:09:30,040 --> 00:09:39,040
microservices and PaaS really do go hand in hand. Um, it, could you have a platform as a service that

97
00:09:39,040 --> 00:09:45,840
isn't optimized for microservices? Yeah, maybe. And maybe it's just, I don't think it's coincidence,

98
00:09:45,840 --> 00:09:53,300
but I think actually the emergence of microservices required that we have a new set of platforms to be

99
00:09:53,300 --> 00:09:59,520
able to enable those things to be deployed and effectively managed. Um, and then I think the

100
00:09:59,520 --> 00:10:08,040
emergence of these platforms has also kind of, uh, accelerated or ramped the emergence of microservices.

101
00:10:08,040 --> 00:10:13,180
So it's a bit of a chicken and egg thing. Um, I think that they, they're very synergistic and I

102
00:10:13,180 --> 00:10:21,420
think that therefore they have, um, kind of evolved at the same time. Um, the IAS thing is, is interesting

103
00:10:21,420 --> 00:10:29,200
because, um, I have been in the EMC VMware pivotal family for gosh, almost 20 years now in some way,

104
00:10:29,200 --> 00:10:35,320
shape or form. Um, and, um, I always like to talk about the fact that it was VMware that really was

105
00:10:35,320 --> 00:10:41,800
at the forefront of virtualization technology, but it was Amazon that changed the game when they added

106
00:10:41,800 --> 00:10:49,640
the, as a service. So VMware was not a, you know, IAS company, they were a virtualization company.

107
00:10:49,720 --> 00:10:56,180
And then Amazon is actually what made us all realize that, holy smokes, I can actually get

108
00:10:56,180 --> 00:11:03,260
infrastructure as a service. So to some extent, clearly this, as a serve a service model that

109
00:11:03,260 --> 00:11:09,980
kind of started in the IAS space. And I mean, it, one could argue, I I've, I've studied a little bit

110
00:11:09,980 --> 00:11:15,460
of the history and I think that Google's foray into the, as a service actually came with app engine.

111
00:11:15,460 --> 00:11:23,040
Right. So they didn't start with IAS. They started with app engine. So, um, but I think that Amazon was

112
00:11:23,040 --> 00:11:30,540
arguably the most successful and they started with infrastructure. Um, so I mean, they're very

113
00:11:30,540 --> 00:11:35,800
different because IAS is compute storage and network. It is an infrastructure abstraction.

114
00:11:36,340 --> 00:11:41,220
And so when it comes time to secure something while you're securing against machine boundaries,

115
00:11:41,220 --> 00:11:46,640
not against applications and those types of things. But I do think that the, as a service part

116
00:11:46,640 --> 00:11:54,300
really helped inform that. Um, okay. Do you think, why do you think, I mean, I think actually

117
00:11:54,300 --> 00:11:59,780
Microsoft Azure initially started as a, as a platform as a service thing too, at least the original

118
00:11:59,780 --> 00:12:04,740
vision was. I mean, why do you think it's, it seems natural. It seems like a natural thing for

119
00:12:04,740 --> 00:12:08,960
developers to want. And yet they had, they both had to go back to IAS. Do you have a sense of why?

120
00:12:10,080 --> 00:12:15,240
Yeah. I mean, I, I actually think that they were maybe just too far ahead of the game. Um,

121
00:12:15,240 --> 00:12:22,700
I think that, that, that remember when we talked just a moment ago about microservices and PaaS

122
00:12:22,700 --> 00:12:32,100
platform. Um, I think that, uh, initially there wasn't enough of an understanding of what are the new

123
00:12:32,100 --> 00:12:40,720
architectural patterns for things that are going to run in an as a service environment. Now at,

124
00:12:40,960 --> 00:12:46,180
when I say run in an as a service environment, what do I mean by that? Well, I'm actually kind

125
00:12:46,180 --> 00:12:53,220
of talking about these new as a service cloud-based environments where, um, where things are always,

126
00:12:53,400 --> 00:12:59,260
they're in constant flux. I've been in the industry long enough. I worked for Documentum for a while.

127
00:13:00,060 --> 00:13:07,180
Documentum was a piece of software that was built expecting the infrastructure that it ran on to

128
00:13:07,180 --> 00:13:14,960
remain stable. And if the Oracle database that you depended on for Documentum to run

129
00:13:14,960 --> 00:13:22,200
went belly up for any reason or needed to be upgraded for any reason, or, you know, needed to be

130
00:13:22,200 --> 00:13:29,160
migrated from one data center to another, well, that was a major event. There is no way that the software

131
00:13:29,160 --> 00:13:34,360
running on top of that database could survive could stay running during that transition.

132
00:13:35,800 --> 00:13:41,180
And so that's the way we've been building as developers. That's the way we've been architecting

133
00:13:41,180 --> 00:13:46,040
our software, building our software. And so if you'll permit me, I'll just mention that I recently

134
00:13:46,040 --> 00:13:52,460
published a book with Manning called Cloud Native Patterns. And the subtitle actually, I like even better

135
00:13:52,460 --> 00:14:00,620
than the title, which is designing change tolerant software. And so back to your question of, well,

136
00:14:00,620 --> 00:14:08,400
Azure and Google started with these app engine metaphors. To a large extent, those had an expectation.

137
00:14:08,400 --> 00:14:16,280
It had some of these opinions we've been talking about built into it. And I just don't think that there

138
00:14:16,280 --> 00:14:23,660
were very many apps that were ready for that. And even today, I still find lots of interest for an

139
00:14:23,660 --> 00:14:28,680
understanding of what actually, what are those cloud native patterns? That's why I wrote a book on it.

140
00:14:29,740 --> 00:14:33,480
I think you're onto something too. I used to ask that question a lot. Like when cloud came around,

141
00:14:33,560 --> 00:14:37,520
it was, when are we going to start building new types of applications to take advantage of this?

142
00:14:37,520 --> 00:14:42,840
Because for a long time, it seemed like same application running on Amazon and somehow we

143
00:14:42,840 --> 00:14:47,760
expected things to be different. And so I think we're catching up finally. One thing we haven't

144
00:14:47,760 --> 00:14:51,800
talked about yet is containers and probably more specifically container orchestration. So I want

145
00:14:51,800 --> 00:14:56,740
to get to that because I think that that captured over the past few years, some of the paths,

146
00:14:56,880 --> 00:15:01,820
mindshare, and maybe there's been a conflation of the two, right? Like there can be only one or the

147
00:15:01,820 --> 00:15:05,480
other. Can you talk a little bit about that relationship between containers and container

148
00:15:05,480 --> 00:15:09,540
orchestration and platform as a service? Absolutely. So I, that's where I've been spending

149
00:15:09,540 --> 00:15:16,360
most of my time for the last two plus years is in the Kubernetes space. Having had kind of a long

150
00:15:16,360 --> 00:15:24,460
background with, with our, you know, PCF and our paths and cloud foundry platform. So this is an area

151
00:15:24,460 --> 00:15:29,260
that I'm very, very passionate about. So you are absolutely right that containers and container

152
00:15:29,260 --> 00:15:34,760
orchestration has captured the mindshare. Now I'll tell you, it's interesting. We need to

153
00:15:34,760 --> 00:15:41,500
kind of separate those two because I was working on paths a number of years ago, you know, four or five

154
00:15:41,500 --> 00:15:47,980
years ago when Docker and containers became really big. And there was this wave where everybody thought

155
00:15:47,980 --> 00:15:53,900
that the days of paths were over because we now had Docker and we now had containers. And I'll tell

156
00:15:53,900 --> 00:16:01,220
you that that petered out pretty quickly. We did have, I would say maybe six months where we had,

157
00:16:01,580 --> 00:16:06,800
you know, that was kind of quote unquote competitive, if you, if you will. But because it was just

158
00:16:06,800 --> 00:16:12,580
containers, it very quickly became apparent that you needed more than just containers. You needed a

159
00:16:12,580 --> 00:16:20,840
whole bunch of stuff around the containers. And in fact, that's what a paths is. So certainly the

160
00:16:20,840 --> 00:16:28,820
cloud foundry paths has been container based all along. It predates Docker, but it's been container based.

161
00:16:28,820 --> 00:16:34,520
So I actually believe that containers are a prerequisite for being able to build a modern

162
00:16:34,520 --> 00:16:42,920
paths like we've been talking about here. So that, that, that came and went and people kind of got the

163
00:16:42,920 --> 00:16:49,140
difference. So, but one of those things that you need around that is container orchestration. And now

164
00:16:49,140 --> 00:16:54,740
with the advent of Kubernetes being so popular, and there's a good reason for it being popular.

165
00:16:54,740 --> 00:17:02,280
Kubernetes is crazy cool technology. It is, it's a set of primitives that you can just build so many

166
00:17:02,280 --> 00:17:08,380
awesome things with, but that's the key is that you can build awesome things with it. People like

167
00:17:08,380 --> 00:17:15,240
Kelsey Hightower and Joe Beda, two very, very influential people and knowledgeable people in the

168
00:17:15,240 --> 00:17:19,940
Kubernetes community, both talk about Kubernetes being a platform for building platforms,

169
00:17:20,660 --> 00:17:30,860
not a platform itself, not an application platform like paths. And so CAS is really interesting. And

170
00:17:30,860 --> 00:17:35,780
there are some use cases where you might want to use CAS. And I'm guessing that we'll probably go there

171
00:17:35,780 --> 00:17:42,580
and talk a little bit about those. But the main thing that I think I would love your listeners to

172
00:17:42,580 --> 00:17:53,500
understand is that CAS is essentially an infrastructure dial tone. So when you are dealing with Kubernetes,

173
00:17:54,140 --> 00:18:03,380
you are dealing with things like pods and you are dealing with persistent volumes and persistent volume

174
00:18:03,380 --> 00:18:11,120
claims and load balancers. They call them services, but a load balancer is a type of a service.

175
00:18:11,120 --> 00:18:18,980
So you're still largely dealing with infrastructure abstractions. Yes, it's an up leveling from compute

176
00:18:18,980 --> 00:18:24,880
storage and network. It isn't just those broad things. It's not a machine in the same way that

177
00:18:24,880 --> 00:18:29,500
we've always thought of machines. It used to be a physical machine. Now it's a virtual machine and it has

178
00:18:29,500 --> 00:18:34,680
every single thing that the physical machines had. We're starting to break those things up into an

179
00:18:34,680 --> 00:18:40,100
abstraction layer where we can compose them in interesting ways, but it's still fundamentally an

180
00:18:40,100 --> 00:18:48,640
infrastructure abstraction. So PaaS is all about bringing that abstraction up to a level that lets

181
00:18:48,640 --> 00:18:55,760
the infrastructure details fall by the wayside, that lets you apply controls to those, but then

182
00:18:55,760 --> 00:18:58,900
they aren't first-class concerns that's already built in.

183
00:18:58,960 --> 00:19:04,480
And Pivotal offers both a PaaS, which we call PAS, not P-A-A-S, right?

184
00:19:04,960 --> 00:19:10,720
And a Kubernetes-based product. I mean, so why is it that, like, yeah, I'm curious, as you mentioned,

185
00:19:10,820 --> 00:19:16,380
like, why would someone opt for one over, given that choice, if it must be a choice, and maybe it

186
00:19:16,380 --> 00:19:21,400
doesn't need to be a choice, why would someone opt for containers over a PaaS offering?

187
00:19:21,960 --> 00:19:30,500
Yeah. Yeah. And I think that it comes back to, there are definitely cases where you aren't going to want to

188
00:19:30,500 --> 00:19:36,580
run something on the PaaS. And I think it takes us back to this conversation that has, kind of theme

189
00:19:36,580 --> 00:19:41,660
that's been running through our conversation, which is around cloud-native apps, or microservices,

190
00:19:41,800 --> 00:19:47,940
we sometimes call them, and about these patterns for applications that are designed to allow for

191
00:19:47,940 --> 00:19:53,460
the infrastructure to be moving, to shifting around. So I always say that cloud-native apps are highly

192
00:19:53,460 --> 00:19:58,240
distributed and constantly changing. The environment's changing, the apps themselves are changing.

193
00:19:59,160 --> 00:20:04,840
And so there are a certain set of patterns. And platform as a service is, to a large extent,

194
00:20:05,020 --> 00:20:11,380
playing a big role in intentionally trying to up-level us into this next wave of application

195
00:20:11,380 --> 00:20:19,260
architectures. But there are a lot of workloads out there that don't fall into that category,

196
00:20:19,460 --> 00:20:28,360
that are existing workloads, that maybe are not as resilient to changes at the infrastructure level,

197
00:20:28,520 --> 00:20:37,360
maybe require a little bit less opinionation than a PaaS typically has, yet they can benefit from

198
00:20:37,360 --> 00:20:44,080
containerization. I mean, for example, one of the benefits of containerization is that you,

199
00:20:45,360 --> 00:20:51,560
what we in the DevOps community call shift left. So a lot of the things that you typically would have

200
00:20:51,560 --> 00:20:58,820
done and configured at the time of deployment, you can actually make those decisions and start to put

201
00:20:58,820 --> 00:21:07,340
some of those things and go through some of those processes of verifying that even things like

202
00:21:07,340 --> 00:21:12,920
compliance can be met while you're building the container. And then you sign the container

203
00:21:12,920 --> 00:21:19,500
and you to ensure that it's never changed. And so you have this abstraction that allows you to say,

204
00:21:19,660 --> 00:21:24,840
okay, I did some checks when I signed this container and nothing can change since then.

205
00:21:25,160 --> 00:21:31,060
That's one of the benefits of containerization that applies whether you've got a cloud native app or

206
00:21:31,060 --> 00:21:38,040
not. So containerization and then orchestrated containers around that can actually benefit

207
00:21:38,040 --> 00:21:44,740
existing applications that are not necessarily cloud native. And so there's a category of workloads.

208
00:21:45,740 --> 00:21:50,080
But the interesting thing is, is it's not, I always like to point out as well that

209
00:21:50,080 --> 00:21:56,120
it's not only workload. It's not only the application architecture that determines where,

210
00:21:56,500 --> 00:21:59,560
whether you want to run on Kubernetes or you want to run on something like

211
00:21:59,560 --> 00:22:07,800
Cloud Foundry or some kind of a PaaS. It also depends on things like your skill set or whether you already

212
00:22:07,800 --> 00:22:16,100
have containers. So there are organizations out there where they have tooled up processes for creating

213
00:22:16,100 --> 00:22:24,120
trusted containers. And so if they have cracked that nut, which by the way is not a trivial nut to crack,

214
00:22:24,120 --> 00:22:32,060
that's a big part of what PaaS offers is it actually helps you create, it provides a trusted container

215
00:22:32,060 --> 00:22:37,040
pipeline with which you can actually go through this process of creating these trusted containers

216
00:22:37,040 --> 00:22:45,100
built into the platform. But if you've already tooled that up, why not continue to use, leverage that

217
00:22:45,100 --> 00:22:50,140
investment that might've been a two-year investment in an organization. So they're already creating

218
00:22:50,140 --> 00:22:56,520
containers. And so they want to continue operating that and they need a place for orchestrated Docker

219
00:22:56,520 --> 00:23:04,240
containers. So if you've already got investment there, or we're also seeing independent software vendors

220
00:23:04,240 --> 00:23:10,580
are taking advantage of some of those advantages that I just talked about. They're saying, hey, gosh, you know,

221
00:23:10,640 --> 00:23:17,480
it used to be really hard for me to deploy, for my customers to deploy my offering because there were so

222
00:23:17,480 --> 00:23:22,740
many configurations that needed to happen once they got the compute storage and network that they needed.

223
00:23:23,280 --> 00:23:30,600
Well, we can start to apply some of those configurations in a set of containers that work

224
00:23:30,600 --> 00:23:36,900
together cohesively as a whole. We're going to start using containers as a distribution mechanism

225
00:23:36,900 --> 00:23:44,100
for our software. And so there's another use case for maybe running on something like a container as a

226
00:23:44,100 --> 00:23:49,200
service as opposed to a PaaS. And then finally, Cornelia, I wanted to ask, like, you know, and we

227
00:23:49,200 --> 00:23:53,520
could probably lump even something like functions or serverless into this discussion, right? But if I'm

228
00:23:53,520 --> 00:23:59,060
an IT exec and I'm looking at this collection of abstractions from infrastructure to application to

229
00:23:59,060 --> 00:24:05,340
whatever, and then, you know, that may or may not, you know, merge and converge as the years go on,

230
00:24:05,400 --> 00:24:10,320
like, where does it make sense to jump in today? Like, what's my guideline for? Okay. Well, like,

231
00:24:10,360 --> 00:24:14,920
even where do I, I hear about Kubernetes all the time, but maybe, maybe, maybe I, maybe I need to

232
00:24:14,920 --> 00:24:18,320
jump in there. Maybe we need to jump in a PaaS, like maybe it's functions, right? Like how do I make

233
00:24:18,320 --> 00:24:25,340
that decision? Yeah. Yeah. So I, I think actually at the highest level, the answer to that is super

234
00:24:25,340 --> 00:24:33,920
simple. Where are your biggest pain points? So this is all about value creation. And I think that's one of

235
00:24:33,920 --> 00:24:40,860
the biggest challenges in an industry, and especially right now where there is this crazy cool technology

236
00:24:40,860 --> 00:24:47,460
that everybody's in love with, like I said, with good reason, is to jump into it, you know, based on

237
00:24:47,460 --> 00:24:54,620
FOMO, fear of missing out. And that right there is not the best way to go into a new technology space.

238
00:24:54,860 --> 00:25:01,880
It's look at the problems that you're, that you need to solve to generate value for your business.

239
00:25:02,440 --> 00:25:08,760
If you are, let's take functions as a service. Functions as a service, I consider that just a

240
00:25:08,760 --> 00:25:16,820
flavor of PaaS, if you will. It is, and, and what's, what's unique about FaaS over the PaaSs that have

241
00:25:16,820 --> 00:25:22,760
been around for the last several years are really, I see it as two things, the economic model. So it's

242
00:25:22,760 --> 00:25:29,740
this, like, you only pay for things as the compute is happening. So only as the function is executing.

243
00:25:29,740 --> 00:25:34,360
So there's an economic model, but let's put the economic model to the side. The other thing is

244
00:25:34,360 --> 00:25:43,560
events. It is at the core, kind of the, the, the spinal cord of FaaS are events. So if you are a

245
00:25:43,560 --> 00:25:50,860
company that has, that is generating value for your consumers based on things that are naturally

246
00:25:50,860 --> 00:25:59,800
represented as events and the event stream is the primary entity and you need to do things against

247
00:25:59,800 --> 00:26:06,560
those events, then perhaps FaaS is exactly the right place for you to start. If you are taking

248
00:26:06,560 --> 00:26:14,480
legacy client server desktop applications and building a set of web, you know, web apps for that,

249
00:26:14,680 --> 00:26:22,840
then my recommendation would be your best thing is PaaS. If you want to, you know, take legacy workloads

250
00:26:22,840 --> 00:26:28,840
and just get them running, you're having struggling with infrastructure and you just want to get them

251
00:26:28,840 --> 00:26:36,340
running in a container environment because you can do things like, um, at least put image scanning against

252
00:26:36,340 --> 00:26:43,140
container images for some level of security, then perhaps CAS is the place to start. So it's really

253
00:26:43,140 --> 00:26:48,100
to do that evaluation of where do you need, I ultimately think you're going to need all of

254
00:26:48,100 --> 00:26:54,580
those things because every enterprise has all three of those problems that I described, but where do you

255
00:26:54,580 --> 00:26:59,620
start? Look at where you're going to get the biggest bang for your buck in terms of value creation.

256
00:26:59,620 --> 00:27:03,300
All right. And that seems like a great place to end. Thank you so much, Cornelia.

257
00:27:05,420 --> 00:27:09,860
Okay. And there you have it. I hope you learned something. I certainly did. We're going to keep this

258
00:27:09,860 --> 00:27:14,380
brief because everyone's from Pivotal. So if you want to learn more about Pivotal and

259
00:27:14,380 --> 00:27:18,900
what we're doing in the platform as a service and container orchestration space with Kubernetes

260
00:27:18,900 --> 00:27:25,180
and functions, et cetera, check us out at pivotal.io. And if you like this podcast and you want to read

261
00:27:25,180 --> 00:27:32,060
blog posts and highlights of the podcast and, and other type of, you know, vendor neutral yet, uh,

262
00:27:32,060 --> 00:27:37,980
hopefully informative, uh, content regarding your digital transformation efforts and cloud computing

263
00:27:37,980 --> 00:27:45,580
and the like, you can visit pivotal.io slash intersect. Thank you very much.