1
00:00:00,000 --> 00:00:05,980
Welcome back. This week, we have another interview as part of our Women of SpringOne Platform series.

2
00:00:06,560 --> 00:00:11,900
I sat down with Emily Casey, who's an engineer on the Cloud Native Buildpack contributor team,

3
00:00:12,140 --> 00:00:15,180
who is a returning SpringOne Platform speaker.

4
00:00:15,780 --> 00:00:19,600
In the process, I got to learn a lot more about Buildpacks and how they've evolved,

5
00:00:19,960 --> 00:00:25,120
and of course, what this means for the Cloud Native Buildpack and many other things that

6
00:00:25,120 --> 00:00:28,860
have changed and come to market in the last year.

7
00:00:29,500 --> 00:00:34,560
So, I recommend checking out her talk in the upcoming SpringOne Platform conference.

8
00:00:34,700 --> 00:00:39,440
If you're not already attending and you'd like $200 off, you can use the discount code

9
00:00:39,440 --> 00:00:48,940
S1P200 underscore D-Drewitz. That's D-D-R-E-W-I-T as in tango, Z as in zebra.

10
00:00:49,320 --> 00:00:51,080
With that, enjoy the show.

11
00:00:59,000 --> 00:01:07,500
So, I'm here today with Emily Casey, who is presenting again at SpringOne Platform this year.

12
00:01:07,560 --> 00:01:14,640
I know you presented last year as well. Is this your second, or how many years have you actually been going to SpringOne?

13
00:01:16,060 --> 00:01:23,460
I've gone to SpringOne. The previous two years. This will be my second year presenting at SpringOne.

14
00:01:24,020 --> 00:01:30,920
Okay. Yeah. So, having a kind of veteran attendee and presenters will be great.

15
00:01:31,060 --> 00:01:37,580
Our last couple questions will be around some advice and tips you can have for the attendees this year.

16
00:01:38,220 --> 00:01:45,860
All right. So, Emily, why don't you start us off by just, you know, what's your basic intro on who you are?

17
00:01:45,960 --> 00:01:54,460
Like, if you're at one of those big family weddings and you're meeting those, like, people that are sort of your cousin and they're wondering, like, oh, who is this person?

18
00:01:54,460 --> 00:01:56,080
Like, how would you introduce yourself?

19
00:01:57,460 --> 00:02:02,320
I would say I work as a software engineer at Pivotal Cloud R&D.

20
00:02:02,740 --> 00:02:14,940
I focus on a technology called BuildPacks, which turns a developer's source code into a container image that they can then run in a cloud platform like Kubernetes.

21
00:02:16,400 --> 00:02:23,160
If this was actually a family gathering, my cousins would not know what a container is or what Kubernetes is,

22
00:02:23,260 --> 00:02:28,420
and then we would continue to work backwards to some sort of shared understanding.

23
00:02:28,660 --> 00:02:31,580
But for this audience, I think that might do the trick.

24
00:02:32,240 --> 00:02:39,520
Yeah, we'll just assume that you're somehow, like, in a family of remotely software savvy folks.

25
00:02:39,840 --> 00:02:48,260
But, yeah, I hear you, you know, depending on how big this wedding is, like, you're going to have a few people in there who may have different associations with the word container.

26
00:02:50,220 --> 00:02:54,180
But, okay, so then let's just also kind of get to know you a little bit more.

27
00:02:54,300 --> 00:02:56,600
How did you get into tech in the first place?

28
00:02:57,940 --> 00:03:02,620
If I'm being honest, I sort of got into tech as an accident.

29
00:03:03,940 --> 00:03:09,300
So I studied physics for my undergraduate degree.

30
00:03:09,860 --> 00:03:13,760
For a while, I thought I would pursue a career in academic physics.

31
00:03:13,760 --> 00:03:22,480
But after a couple of years working in a lab, as much as I loved it, I didn't think that that career path was the right one for me in the long term.

32
00:03:22,880 --> 00:03:27,120
So I was sort of looking around for other options.

33
00:03:28,460 --> 00:03:31,240
One of the things I was considering was management consulting.

34
00:03:31,860 --> 00:03:36,780
I was planning to go to a career fair and talk to some consulting firms.

35
00:03:37,440 --> 00:03:45,620
And my mother had given me the wise advice to walk around to other booths and talk to companies I wasn't interested in first to practice my pitch.

36
00:03:46,060 --> 00:03:48,160
Ended up talking to a software consultancy.

37
00:03:49,020 --> 00:03:55,000
And that is actually how I began even thinking about software as a career, sort of, as an accident.

38
00:03:55,640 --> 00:03:55,820
Wow.

39
00:03:56,000 --> 00:03:57,160
That's a great story.

40
00:03:58,440 --> 00:04:02,640
The whole, like, I was just giving my practice pitch where I thought I wasn't going to care about it.

41
00:04:03,860 --> 00:04:08,460
So what did you hear at this software consultancy that kind of got your attention?

42
00:04:09,980 --> 00:04:17,420
So I had learned a little bit of coding, like a little bit of C++, in order to analyze data and physics.

43
00:04:17,880 --> 00:04:23,780
But because I didn't have a CS degree, I didn't think that I was a candidate, sort of, for a software engineering job.

44
00:04:24,880 --> 00:04:30,860
But talking to these folks, they seemed open to the idea that someone without a traditional background could come in and learn.

45
00:04:31,680 --> 00:04:37,560
So they actually brought me into the office with a bunch of other, you know, folks that they met at this career fair.

46
00:04:37,560 --> 00:04:42,000
And they were going around asking everyone what position they were applying for.

47
00:04:42,680 --> 00:04:46,200
People either saying BA, QA, or dev.

48
00:04:47,060 --> 00:04:49,060
And I didn't know what any of those things were.

49
00:04:49,160 --> 00:04:51,040
I didn't know that dev was, like, short for developer.

50
00:04:52,140 --> 00:04:54,480
But I said dev because most people said dev.

51
00:04:54,620 --> 00:04:58,260
And I didn't want to admit that I didn't know what was going on in this conversation.

52
00:04:58,500 --> 00:05:01,200
And that's how I ended up applying for a software development job.

53
00:05:01,200 --> 00:05:09,360
So what have you kind of learned to love about it in the years that have passed since saying dev?

54
00:05:09,660 --> 00:05:17,700
Well, after I learned some more things very quickly in order to get through this long interview process.

55
00:05:18,520 --> 00:05:26,340
So I sort of taught myself Java for this interview process and, you know, did a lot of cramming so I could apply for this job.

56
00:05:27,840 --> 00:05:36,580
After I got the job offer, I actually took some computer science classes and very quickly realized that it was a very good fit for me, that I loved it.

57
00:05:37,080 --> 00:05:45,040
I saw myself, like, procrastinating a paper that was due the next day by doing CS homework that was due two weeks from then just because it was fun.

58
00:05:46,800 --> 00:05:53,120
So I think very quickly, once I started doing it, I realized that this is probably what I should have been doing all along.

59
00:05:53,120 --> 00:05:56,260
In some ways, I've always loved logic puzzles.

60
00:05:57,260 --> 00:06:09,960
And computer science gives you the opportunity to solve logic puzzles, but it also gives you an opportunity to be creative and collaborative and build things that real people will actually use.

61
00:06:10,140 --> 00:06:13,040
So it sort of, like, scratches a lot of different itches.

62
00:06:13,680 --> 00:06:13,940
Yeah.

63
00:06:16,340 --> 00:06:18,920
Okay, so now let's, like, fast forward a bit.

64
00:06:18,920 --> 00:06:32,700
And we're in the D.C. area in September of 2018, which happens to be where SpringOne Platform was last year.

65
00:06:33,260 --> 00:06:44,500
And you gave a talk with Steve Levine about build packs and kind of the start of the cloud native build pack discussion.

66
00:06:46,300 --> 00:07:06,940
What, a lot's happened on that front in the last 12 months, everything from buildpacks.io and the cloud native build packs joining CNCF and Pivotal's announced a bunch of offerings around it, etc.

67
00:07:06,940 --> 00:07:13,760
But what would you say is what you've really learned in the last year?

68
00:07:14,880 --> 00:07:18,020
And to what extent has that changed your thinking?

69
00:07:19,160 --> 00:07:24,420
I think the project has matured a lot since the last time we were at SpringOne.

70
00:07:25,940 --> 00:07:34,860
We have, we always imagined that there were a variety of use cases for this technology.

71
00:07:35,720 --> 00:07:47,920
So part of the goal of this project is to take staging, which was a tightly coupled piece of the cloud foundry experience,

72
00:07:48,340 --> 00:07:56,680
and extract it in a way that, by defining open standards, becomes something that other platforms can implement and use.

73
00:07:57,240 --> 00:08:02,720
And a build pack can run, a build pack that adheres to the standards can run in a variety of situations.

74
00:08:03,940 --> 00:08:09,380
And, you know, the OCI images that we're generating as an artifact now, rather than a droplet,

75
00:08:09,680 --> 00:08:16,180
it can be deployed into, can fit flexibly into many different deployment scenarios.

76
00:08:16,180 --> 00:08:22,240
So, you know, whether you're running it in Docker, or you're deploying it to Kubernetes, or you are deploying it to PaaS eventually.

77
00:08:24,540 --> 00:08:29,300
So we sort of had a vision for why this would be a good idea.

78
00:08:29,780 --> 00:08:34,560
I think over the last year, that vision has become a lot more of a reality.

79
00:08:34,560 --> 00:08:41,640
We're seeing other customers start to, other companies, not necessarily customers,

80
00:08:41,760 --> 00:08:44,840
because this is an open source project, the part that I'm talking about now,

81
00:08:44,920 --> 00:08:48,480
start to adopt our technology and use it in their platforms.

82
00:08:49,420 --> 00:08:59,320
And it's getting that, like, hard use by, like, real-world users who have a variety of different goals

83
00:08:59,320 --> 00:09:02,060
has really forced the tooling to mature.

84
00:09:03,680 --> 00:09:07,820
What are, you know, what's an example of something that, you know,

85
00:09:07,860 --> 00:09:14,420
as folks are really kicking the tires on it, have exposed that the team has had to go back

86
00:09:14,420 --> 00:09:15,620
and work on?

87
00:09:21,320 --> 00:09:31,360
I think one example was we recently sort of retooled the idea of what the build plan looks like

88
00:09:31,360 --> 00:09:34,560
inside the Buildpack API.

89
00:09:35,860 --> 00:09:42,000
So we have, I don't know how familiar you are with, like, the different phases of the Buildpack API,

90
00:09:42,520 --> 00:09:47,840
but, like, one of the phases that runs during a build is detection.

91
00:09:48,200 --> 00:09:52,680
And during detection, a group of Buildpacks work together to figure out which ones are going to run

92
00:09:52,680 --> 00:09:53,980
to actually build the application.

93
00:09:54,380 --> 00:10:02,440
And we have a concept of a build plan where Buildpacks could, you know, provide information to that build plan

94
00:10:02,440 --> 00:10:06,820
that would help other Buildpacks figure out if they wanted to run and how they wanted to run.

95
00:10:08,100 --> 00:10:14,200
And we realized that that format was, like, very open-ended when we first designed the API.

96
00:10:14,300 --> 00:10:15,100
It was like a whiteboard.

97
00:10:15,760 --> 00:10:20,180
And what happened is that groups of Buildpacks that were sort of designed to work together,

98
00:10:20,380 --> 00:10:27,560
sort of developing their own sort of domain-specific language for doing a negotiation

99
00:10:27,560 --> 00:10:30,320
about whether to run together using the build plan.

100
00:10:31,320 --> 00:10:36,140
And we recently changed that to create something a little bit stricter

101
00:10:36,140 --> 00:10:39,900
where every Buildpack should say what it provides and what it requires.

102
00:10:41,240 --> 00:10:46,280
And by creating more structure around that part of detection,

103
00:10:46,600 --> 00:10:49,620
now Buildpacks are more likely to be interoperable with each other.

104
00:10:51,200 --> 00:10:56,400
So you can use a Cloud Foundry Buildpack with a Heroku Buildpack

105
00:10:56,400 --> 00:11:00,880
because the structure provided by the build plan makes it easier to define

106
00:11:00,880 --> 00:11:06,420
a contract that will allow them to communicate rather than each set of Buildpacks

107
00:11:06,420 --> 00:11:10,300
sort of deciding what that contract means between themselves.

108
00:11:11,320 --> 00:11:13,180
That seems really useful.

109
00:11:13,760 --> 00:11:21,560
And maybe we should go back a little bit for folks to walk through what those phases are.

110
00:11:21,660 --> 00:11:25,160
For example, you mentioned this is all what's going on in the detection phase.

111
00:11:25,640 --> 00:11:30,640
But if I recall, there's four phases in the sort of what the Buildpacks are doing.

112
00:11:30,880 --> 00:11:35,480
Can you give us a quick sort of high-level intro?

113
00:11:35,740 --> 00:11:42,240
What are those phases just so people can orient what this particular problem, where it fits in?

114
00:11:43,100 --> 00:11:43,840
Sure, sure.

115
00:11:44,360 --> 00:11:49,220
When I talk about phases, I'm talking about the phases of the Cloud Native Buildpack lifecycle,

116
00:11:49,420 --> 00:11:53,720
which is the primary component that my team helps to build.

117
00:11:54,420 --> 00:11:57,340
And the lifecycle defines two contracts.

118
00:11:57,960 --> 00:12:02,820
One of those contracts is a contract with the Buildpacks that it invokes,

119
00:12:02,920 --> 00:12:05,900
and the other is a contract with a platform that runs the lifecycle.

120
00:12:06,960 --> 00:12:10,340
So the lifecycle is broken up into phases.

121
00:12:10,780 --> 00:12:12,600
The main phases are detect.

122
00:12:13,200 --> 00:12:20,800
And when the detect phase runs, the lifecycle is figuring out which Buildpacks will execute the build.

123
00:12:21,620 --> 00:12:23,640
The next phase is analyze.

124
00:12:24,460 --> 00:12:29,800
And during analyze, the lifecycle will look at the previous version of the image that it built,

125
00:12:29,860 --> 00:12:36,200
if there was one, and pull down metadata about layers in the built image.

126
00:12:36,840 --> 00:12:42,120
And this is important because it will allow the Buildpacks at build time,

127
00:12:42,120 --> 00:12:46,300
if they don't need to recreate a specific layer, for example,

128
00:12:46,300 --> 00:12:52,180
because the previous image already has the exact dependency it needs to avoid doing rework.

129
00:12:53,940 --> 00:13:01,880
So during build, all of the Buildpacks will write layers, adding dependencies to the final image.

130
00:13:02,700 --> 00:13:08,940
They may make changes to the application layer itself as well and provide other types of configuration.

131
00:13:10,000 --> 00:13:16,520
Finally, there's the export step, where the lifecycle takes all the information that the Buildpacks generated

132
00:13:16,520 --> 00:13:20,880
and turns that into an image as efficiently as possible.

133
00:13:21,400 --> 00:13:27,040
So getting back to, like, our layer reuse example that we brought up from Analyze,

134
00:13:27,040 --> 00:13:32,880
if a Buildpack runs and sees in the metadata that it doesn't need to rebuild a layer,

135
00:13:33,300 --> 00:13:38,800
the exporter will know it can just tell the registry to reuse a layer from the previous image.

136
00:13:39,460 --> 00:13:46,960
So we get a lot of efficiencies by breaking up the image we're generating into structured layers

137
00:13:46,960 --> 00:13:49,180
with, like, well-known contents.

138
00:13:49,780 --> 00:13:56,540
So we can build only exactly as much as we need to on each build to be as fast as possible.

139
00:13:56,540 --> 00:13:57,700
Okay. Yeah.

140
00:13:58,060 --> 00:14:00,680
So those are the phases that you go from, like, a group of Buildpacks to an image.

141
00:14:01,400 --> 00:14:03,940
There are two more phases that are around, like, local caching,

142
00:14:04,580 --> 00:14:06,940
called the restorer and the cacher, but those are optional.

143
00:14:07,160 --> 00:14:17,160
And what they do is allow you to cache certain types of layers that you will want to use during build

144
00:14:17,160 --> 00:14:20,420
close to where you do the build.

145
00:14:20,420 --> 00:14:23,460
So you can, without having to re-download from the registry,

146
00:14:24,320 --> 00:14:27,460
sort of get at that information as quickly as possible.

147
00:14:28,040 --> 00:14:35,180
Okay. So those can be used for sort of further tuning the performance dial on the whole process.

148
00:14:35,780 --> 00:14:36,040
Yeah.

149
00:14:36,420 --> 00:14:42,920
Okay. Okay. So that is really helpful and kind of lays out, you know, this whole life cycle.

150
00:14:43,680 --> 00:14:50,060
And so now, as we, you know, the example you gave in Detect, just to dive in,

151
00:14:50,260 --> 00:14:57,320
because I find this interesting, you know, it detects, you mentioned finding which build packs are needed.

152
00:14:57,320 --> 00:15:06,040
And then also this particular kind of work that you've been, one of the examples that you gave

153
00:15:06,040 --> 00:15:12,200
was around how you got a lot more prescriptive and specific about,

154
00:15:12,200 --> 00:15:21,360
hey, this is, this is what is needed so that different build packs could be in rumble.

155
00:15:21,440 --> 00:15:25,180
So this kind of raises this thing that I think might not be really obvious to folks,

156
00:15:25,180 --> 00:15:32,100
which is that multiple build packs are in play for a given application.

157
00:15:33,040 --> 00:15:39,840
So I think, you know, when first learning about cloud foundry, I remember learning about build packs,

158
00:15:39,960 --> 00:15:41,800
but it was like, oh yeah, you need it for this language.

159
00:15:41,800 --> 00:15:44,040
And it's like, well, obviously there's only one language.

160
00:15:44,040 --> 00:15:47,420
So per application, so that's the build pack.

161
00:15:47,720 --> 00:15:52,940
But now I've learned there's like, oh no, there's all these other things that can be built as build packs

162
00:15:52,940 --> 00:15:57,520
that are just really part of what needs to go into this application, what needs to be built.

163
00:15:58,400 --> 00:16:04,680
So this kind of raises that build pack interoperability and I mean, in some ways,

164
00:16:04,760 --> 00:16:11,080
build pack management question, which is what the, this particular challenge was, was getting at.

165
00:16:11,540 --> 00:16:21,100
I'm just kind of curious, like what, as this particular model for how software gets built,

166
00:16:23,820 --> 00:16:32,820
as that grows, are you seeing the, the complexity in terms of the number of build packs that people have to use?

167
00:16:33,180 --> 00:16:39,700
Is that increasing as a factor of, this is just as the technology gets adopted,

168
00:16:39,840 --> 00:16:46,120
you're going to start to see more of this or what, or is this something that's always been kind of well known?

169
00:16:47,840 --> 00:16:49,440
That's a really good point you bring up.

170
00:16:49,600 --> 00:16:56,700
I feel like, so with the previous version of build packs, let's say you had a Java application,

171
00:16:57,060 --> 00:16:59,020
you might run the Java build pack.

172
00:16:59,760 --> 00:17:04,180
Using the new cloud native build packs model, the Java build pack has become,

173
00:17:04,600 --> 00:17:06,880
I think at this point, 40 or more.

174
00:17:07,220 --> 00:17:11,580
Someone would have to ask Ben Hale, individual modular Java build packs.

175
00:17:11,940 --> 00:17:19,340
And this is part of the design of the model because it's so modular.

176
00:17:19,660 --> 00:17:24,560
It allows people to customize small parts of the build in a really convenient way.

177
00:17:25,100 --> 00:17:31,180
So let's say you wanted, you know, everything that came standard in a Java build,

178
00:17:31,180 --> 00:17:42,380
but you wanted to replace open JDK, you know, with a Oracle JDK to have a license for something like that.

179
00:17:43,300 --> 00:17:49,060
You can replace just that one modular build pack with a different modular build pack

180
00:17:49,060 --> 00:17:57,600
without having to like fork the entire monolithic Java build pack that used to exist

181
00:17:57,600 --> 00:17:58,900
and then maintain that fork.

182
00:17:59,760 --> 00:18:00,240
Okay.

183
00:18:00,680 --> 00:18:06,820
So it makes it really easy for people to plug in and replace specific components that they want to tune

184
00:18:06,820 --> 00:18:16,000
or add in small build packs that, you know, they want to add an agent that's specific to their organization

185
00:18:16,000 --> 00:18:18,320
and they have a build pack for it, stuff like that.

186
00:18:19,240 --> 00:18:23,820
And then, obviously, when your one build pack becomes 40 build packs,

187
00:18:24,360 --> 00:18:28,420
you don't want people to have to think about 40 build packs

188
00:18:28,420 --> 00:18:34,560
because that is not particularly, you know, increases the cognitive overhead.

189
00:18:34,560 --> 00:18:41,000
So another part of what we've been doing over the last year is thinking about build pack distribution

190
00:18:41,000 --> 00:18:47,020
and how we can create a build pack that really is an ordered list of other build packs

191
00:18:47,020 --> 00:18:52,860
and allow people to think at whatever layer of detail they need to.

192
00:18:52,860 --> 00:18:55,520
So it's sort of like progressive complexity.

193
00:18:55,740 --> 00:19:02,080
If all you want to do is run Java based on the existing opinions, you just have to think Java build pack.

194
00:19:02,160 --> 00:19:14,380
But if you need a different level of detail to, you know, as a super user achieve a more complicated goal,

195
00:19:14,440 --> 00:19:17,720
you can then break down to the next level and swap out the individual components.

196
00:19:18,720 --> 00:19:19,160
Okay.

197
00:19:20,360 --> 00:19:20,840
Okay.

198
00:19:20,840 --> 00:19:32,680
This makes a lot more sense with just everything having been sort of going to this more decoupled, modular approach.

199
00:19:32,980 --> 00:19:44,480
How then thinking about how to keep things interoperable as all these potential changes are happening makes a lot more sense.

200
00:19:44,480 --> 00:19:52,120
So that's hugely interesting and I can see how anyone who's trying to get up to speed on what's happened in the last year

201
00:19:52,120 --> 00:19:59,980
is definitely going to want to come to your talk, which brings me to let's talk a little bit about what you're getting into this year

202
00:19:59,980 --> 00:20:04,420
focusing on build packs and Kubernetes.

203
00:20:06,640 --> 00:20:08,420
Yes, that's a good segue.

204
00:20:08,920 --> 00:20:15,980
So I think from this talk is going to be particularly developer centric, I believe this year.

205
00:20:16,520 --> 00:20:23,480
So hopefully a lot of the complexity we were just talking about will be somewhat transparent to the end users.

206
00:20:23,880 --> 00:20:30,120
So folks who write an app and they want to turn their app into an image and they want to run it in Kubernetes.

207
00:20:30,760 --> 00:20:38,660
They don't want to have to think about all the nuances of the build pack API, maybe operators at their organization.

208
00:20:38,800 --> 00:20:42,440
Do you want to make some customizations and then care about that level of detail?

209
00:20:42,720 --> 00:20:45,680
But this talk is going to be mostly focused on the developer experience.

210
00:20:46,320 --> 00:20:53,640
So we're going to be demoing how to use the pack CLI to generate an image, deploy that image to Kubernetes.

211
00:20:54,580 --> 00:21:00,660
How you can very easily then use the pack CLI to rebase that image.

212
00:21:01,240 --> 00:21:09,360
Say in the instance that there was a vulnerability in one of your operating system packages and then update your deployment.

213
00:21:10,420 --> 00:21:19,120
And then we're going to be demoing KPAC, which is a new platform that was recently open sourced by Pivotal

214
00:21:19,120 --> 00:21:31,360
that runs the cloud native build packs life cycle for you in Kubernetes and provides a more Kate's native experience.

215
00:21:31,620 --> 00:21:33,960
So it employs a declarative model.

216
00:21:34,260 --> 00:21:38,360
We'll show how you can define sort of the configuration for your image.

217
00:21:38,360 --> 00:21:50,380
And then as your platform gets build pack updates or base image updates, KPAC will just create new images for you and keep a tag in the registry up to date.

218
00:21:50,660 --> 00:21:56,280
What's the one thing that you hope folks take away from your talk this year?

219
00:21:58,800 --> 00:22:05,100
I think it would be that Docker is not the same thing as Docker files.

220
00:22:06,120 --> 00:22:16,440
So a lot of people love Docker and a lot of people love Kubernetes because of the myriad benefits of containerization.

221
00:22:17,140 --> 00:22:19,220
Well, I can run something locally.

222
00:22:19,480 --> 00:22:20,800
I can port it to the cloud.

223
00:22:20,900 --> 00:22:22,280
It looks exactly the same.

224
00:22:24,040 --> 00:22:25,500
All of these great benefits.

225
00:22:26,300 --> 00:22:31,620
But I think a lot of people assume that in order to generate a container image within they can run Kubernetes,

226
00:22:31,760 --> 00:22:33,620
they have to use a Docker file to build it.

227
00:22:33,920 --> 00:22:45,580
We want to present an alternative model that has different benefits that I think are more appealing for particular types of users and use cases.

228
00:22:46,360 --> 00:22:58,600
So sort of break the assumption in people's minds that to get an image, you have to start with a Docker file and present a competing model.

229
00:22:58,600 --> 00:23:01,160
This is your second year speaking at Springland Platform.

230
00:23:02,900 --> 00:23:08,520
What was your favorite thing about last year that you're looking forward to again this year?

231
00:23:09,420 --> 00:23:15,900
Obviously, the talks are going to be different years gone by, but what did you sort of just generally like about the show that you're like,

232
00:23:15,960 --> 00:23:19,900
oh, yeah, I'm looking forward to sort of that aspect again?

233
00:23:21,120 --> 00:23:22,920
I mean, the talks are obviously great.

234
00:23:23,360 --> 00:23:33,020
I always enjoy catching up on the cutting edge of fields that maybe I haven't been paying attention to since the last year I went to SpringOne.

235
00:23:33,440 --> 00:23:39,460
But I would have to say my favorite part of SpringOne is the opportunity to talk face-to-face with folks that are using our product

236
00:23:39,460 --> 00:23:48,320
and, like, get their feedback in a way that I think sometimes allows for a longer, more interesting discussion that might happen in a GitHub issue.

237
00:23:48,840 --> 00:23:54,340
You can really start to empathize with people a bit more and understand how and why they use your product

238
00:23:54,340 --> 00:23:59,220
rather than just hearing about the one specific thing that they would like tweaked.

239
00:24:01,300 --> 00:24:02,560
That's what I'm really looking forward to.

240
00:24:03,380 --> 00:24:03,640
Okay.

241
00:24:04,560 --> 00:24:13,400
And so, obviously, folks who have been playing around with or using in any capacity should go to your session,

242
00:24:13,480 --> 00:24:15,880
and then they can find you and ask questions.

243
00:24:15,980 --> 00:24:22,580
And then, hopefully, that can lead to those broader conversations that give you that sort of well-rounded feedback.

244
00:24:23,720 --> 00:24:24,880
Yes, please come find me.

245
00:24:25,020 --> 00:24:31,920
We're very friendly, and we want to hear about your use cases, even if you're only just curious about Cloud Native Build Packs.

246
00:24:32,380 --> 00:24:32,700
Okay.

247
00:24:33,060 --> 00:24:33,540
All right.

248
00:24:33,660 --> 00:24:40,920
So, what would you say to someone who is still on the fence about whether or not to come to SpringOne platform

249
00:24:40,920 --> 00:24:51,920
and why you think that they should attend, including, like, you know, it's, hey, if you're trying to answer these types of questions

250
00:24:51,920 --> 00:24:55,840
or you're working in this type of role, like, here's why.

251
00:24:57,840 --> 00:25:06,380
I think we, in the tech industry, know that tech moves fast, and there are a lot of important questions right now,

252
00:25:06,480 --> 00:25:10,400
especially in the Kubernetes track that will be happening at SpringOne,

253
00:25:10,500 --> 00:25:14,720
about how people can take this technology that we're all very excited about,

254
00:25:14,920 --> 00:25:23,660
but use it in a mature organization in a way that meets security requirements, meets performance requirements.

255
00:25:23,660 --> 00:25:26,720
So, I think there's going to be some really interesting conversations happening there.

256
00:25:28,060 --> 00:25:32,620
I feel like SpringOne, in general, is a good place to get an overview of current best practices,

257
00:25:32,900 --> 00:25:38,980
but also to get a preview of what technologies might shake up the landscape in the future.

258
00:25:39,440 --> 00:25:39,720
Mm-hmm.

259
00:25:40,340 --> 00:25:40,700
Okay.

260
00:25:41,160 --> 00:25:49,120
Yeah, there's, like, kind of a Kubernetes for grown-ups sort of theme going on.

261
00:25:50,520 --> 00:25:52,620
That's a theme that's interesting to me.

262
00:25:53,280 --> 00:25:57,480
There are, obviously, many other themes that will be explored to SpringOne besides that.

263
00:25:58,240 --> 00:25:58,680
Okay.

264
00:25:59,060 --> 00:25:59,720
Well, great.

265
00:26:00,320 --> 00:26:08,060
Any last parting thoughts for our listeners, where they can find you or follow what you've been working on?

266
00:26:10,020 --> 00:26:13,300
Feel free to check out our project at buildpacks.io.

267
00:26:14,080 --> 00:26:18,420
We're very available on GitHub and on Slack.

268
00:26:19,720 --> 00:26:20,080
Okay.

269
00:26:20,220 --> 00:26:20,900
Feel free to reach out.

270
00:26:21,920 --> 00:26:22,320
Awesome.

271
00:26:22,560 --> 00:26:22,700
All right.

272
00:26:22,720 --> 00:26:23,340
Well, thanks, Emily.

273
00:26:23,500 --> 00:26:25,680
Look forward to seeing you in Austin, Texas.

274
00:26:26,520 --> 00:26:27,440
Thank you very much.