Joe Kutner is a Software Architect here at Salesforce working on the Heroku Platform. In this episode, I’m sitting down and talking with Joe about Cloud Native Buildpacks and they are powering cloud based deployments and trends like microservices. We talk about their origins at Heroku, and how Kubernetes, Docker, and all sorts of other really cool technology allow developers to convert their apps into images that can be easily served to users. With all of his experience at Heroku, Joe has incredible insights to share with all of us on how Cloud Native Buildpacks have evolved from their beginnings. Tune in to receive great value and learn a lot.

Show Highlights:

  • How Joe got started at Heroku and what the Heroku platform actually is.
  • The impetus of Buildpacks and what they were like in the early days.
  • A basic level walk-through from detection to compilation on the Heroku server.
  • API competition and how Cloud Native Buildpacks are resolving it.
  • Capabilities in the new API that weren’t supported in the old one.
  • What Docker and Kubernetes are and how they work with Buildpacks and each other.
  • How this technology helps enable microservices.
  • The prerequisites to moving your applications to a Cloud Native Buildpack.

Links:

Special Update!

Cloud Native Buildpacks have been promoted to incubation.  Read more here: https://www.cncf.io/blog/2020/11/18/toc-approves-cloud-native-buildpacks-from-sandbox-to-incubation/

Special shout out in this episode to James Ward (https://twitter.com/_jamesward)

Episode Transcript

Joe Kutner:

… because it’s so valuable to the developer who really just wants to solve problems for their business.

Josh Birk:

That is Joe Kutner a software architect here at Salesforce. I’m Josh Birk, your host for the Salesforce Developer Podcast. And here on the podcast, you’ll hear stories and insights from developers, for developers. Today, we sit down and talk with Joe about Cloud Native Buildpacks, Heroku, Kubernetes, Docker, and all sorts of really cool technology. But before we get started, I just, once again, want to thank everybody and give a shout out to all of my listeners. Because last week, as we were recording this, we passed 100,000 downloads. So again, my huge thanks and very grateful for everybody listening and here’s to another 100,000 coming your way. Now let’s sit down and talk with Joe and we start as usual with his early years.

Joe Kutner:

Yeah. I’ve always enjoyed computing and building things with software, but I definitely have always had a tilt towards building things that people can use, that are accessible, that are sort of at a layer above some of the deeper nitty gritty stuff. And I think that probably ties into what we’ll talk about today.

Josh Birk:

Gotcha. What was your early experience with computers?

Joe Kutner:

Oh, building games like everybody else.

Josh Birk:

Oh, nice, nice. What games?

Joe Kutner:

Oh, just text-based stuff. Which interestingly enough is what my son still is doing today. Question and answer type of role-playing things and little Asgard on a screen.

Josh Birk:

Nice. The good old [inaudible 00:01:47] days.

Joe Kutner:

Yeah.

Josh Birk:

Okay. And you come to Salesforce by way of Heroku. How did you get started over at Heroku?

Joe Kutner:

Yeah, so I joined Heroku after it had been acquired by Salesforce, but only shortly after. So at the time it was still sort of functioning as its own independent business. And over the years, we started, when I joined a Heroku very much focused on developer experience, we still are. But in the more recent years, we’re trying to bring those principles and values that led to the Heroku developer experience to the Salesforce platform.

Josh Birk:

Gotcha. And just a high-level set in case we’re talking to Salesforce developers who aren’t familiar with the Heroku platform, what’s the elevator pitch for the Heroku platform?

Joe Kutner:

Yeah. So the Heroku platform is a place to run your apps in the cloud. And when I say apps in that context, I’m talking about programs that are written with frameworks like Spring Boot and Java or Ruby on Rails, things that require custom code and usually handle HDP requests, those kinds of apps. But when you’re running them on Heroku, you’re working at a higher level of abstraction than something like AWS or Google Cloud. Those providers are offering infrastructure as a service, or you have to manage your virtual machines and your virtual infrastructure. Whereas on Heroku, you’re focused on processes and really your application.

Josh Birk:

Got it. And in the early days Heroku was very Ruby-focused and then other languages and frameworks came on board. And then eventually there was this concept of buildpacks. What was the impetus of buildpacks of what were they like in those early days?

Joe Kutner:

The impetus was to support more languages. Because you’re right, Heroku started in the Ruby ecosystem in the early 2010s Ruby was really gaining momentum. And so just supporting Ruby was enough to run a business on, but very quickly we learned that we had to support languages like Java, JavaScript, Python, and we needed an extension point in the platform. Something that would allow the platform to have some kind of modular component that could extend its capabilities. And buildpacks were that thing, they allowed us to add support for other languages and other tools without having to reconstruct the platform itself.

Josh Birk:

And I kind of remember those days as, I was interfacing with kind of the standard buildpacks. Correct me if I’m wrong, there were some really weird buildpacks back in those days [crosstalk 00:04:26].

Joe Kutner:

There still are.

Josh Birk:

What’s the weirdest buildpack that you can think of right now.

Joe Kutner:

Oh, it’s my favorite. It’s the Minecraft Buildpack, that allows you to run a Minecraft server on Heroku. I use it with my son.

Josh Birk:

Nice.

Joe Kutner:

He uses it with his friends. It seems totally trivial and meaningless. Well, maybe not to some people, but it’s actually an interesting buildpack in that it solve some really difficult problems because you have to use a secure tunnel to connect to the server. You can’t just connect to it over HTTP. So it actually has been a great example of the power that buildpacks bring and allow you to use them still in a very simple way.

Josh Birk:

And I kind of remember my early days working with Heroku, that it really clicked with me once I had that… And I think that’s what you were just talking about. Like I’m a node guy, I’m a JavaScript guy and I can really just focus on my app and telling Heroku what my app needs to run. And then just watching that deployment, just sort of magically unfold. At kind of a basic level, can you walk me through some of that magic, like from detection to copulation of up on the server?

Joe Kutner:

Yeah, absolutely. So if you’re deploying an application or your source code to Heroku, the first step is transporting that code to the platform. And then the platform will detect what kind of app it is and it uses buildpacks to do that. So the buildpack will inspect your code to look for particular files that indicate what kind of project it is. For example, a package.json would say, this is a node app or a Gemfile would indicate that it’s a Ruby app.

Joe Kutner:

So in most cases, it can just automatically figure out what kind of app it is. And then from there, it uses the appropriate tools for that language ecosystem. So for the JavaScript ecosystem, it’s going to run npm to download your dependencies for Java and other compiled languages. And it’ll compile your source code. And it goes through this whole process sort of intelligently or in a way that’s app-aware of preparing your source code for production. And in the end results is an image that contains everything your application needs to run on the Heroku platform in the cloud and to launch processes from.

Josh Birk:

And what are some big benefits from a development cycle that you get from that kind of process?

Joe Kutner:

The biggest benefit is that you don’t have to worry about it. In most cases, that’s probably 80% of cases, it just works. And in fact, I love talking about buildpacks, but I would say most of Heroku’s users don’t really understand what a buildpack is, even though they use one every day.

Josh Birk:

Yeah. It occurs to me the first time that I actually felt the need to set my node server up in localhost mode to do local testing because simply lifting and shifting it up to Heroku was one command line away. And this was pretty brand new, innovative stuff when it came out, nobody else was really doing it. And it feels like it kind of started this fundamental shift to the way especially cloud computing was getting built and deployed and scaled. Do you think that’s an accurate statement?

Joe Kutner:

Yeah, absolutely. What Heroku introduced was like you said, a sort of a single command, you git push if you’re using git, that was the old days. Now we have a couple of mechanisms where you can automatically sync from GitHub and things like that. But in any case, it’s in the best case, a single step.

Joe Kutner:

And the platform handles provisioning all of the server instances and the compute resources that are necessary to run your app, including databases and things like that. And this was a huge departure, especially when Heroku was first introduced from AWS or other cloud providers, which gave you this sort of smorgasbord of resources that you could provision, but didn’t really enforce any kind of opinions about how you should architect them other than maybe like a white paper or something like that.

Joe Kutner:

And I think that sort of opinionated approach to the underlying infrastructure is something that other platforms are still trying to emulate today because it’s so valuable to the developer who really just wants to solve problems for their business, those developers working on the Ruby on Rails or the Spring Boot app that we talked about, when they’re toiling away on upgrading the operating system and their virtual machine, they’re really not adding value to their business. They’re just doing chores. And our goal at Heroku is to take a lot of that off your plate.

Josh Birk:

Gotcha. With that kind of momentum in shift though, it seems like a lot of other people were starting to come to the party. We start getting competing APIs, other projects who can do things like converting apps to images. Can you talk a little bit about that competition and then how something like Cloud Native Buildpacks are resolving that balkanization.

Joe Kutner:

Right. So buildpacks in articular were borrowed, or the design for buildpacks was used by other platforms, but in the early days, I don’t think we were really ready for that. So there were Heroku buildpacks, and then there were Cloud Foundry buildpacks, and there were some that were used on other platforms too, but there were different things and they didn’t really work together well.

Joe Kutner:

So what we’ve been trying to do with the Cloud Native Buildpacks project, which is sort of the next version of buildpacks is to unify that ecosystem. And that brings value to the platforms that support buildpacks and that once you support buildpacks, you can use all the buildpacks that are out there and available, including the Minecraft buildpack. But it also means that our customers can create buildpacks, people who work in open source ecosystems for different languages can create buildpacks and have them used on lots of different platforms.

Josh Birk:

Just out of curiosity, or maybe it already is. But I’m curious as to kind of porting effort to take the Minecraft buildpack and convert it to the Cloud Native format?

Joe Kutner:

That one was not too bad. So we do provide a shim where we can take old buildpacks using the old buildpack API, and run them on the new infrastructure with the new API. You just have to give up some of the capabilities that are available. So the Minecraft one is one that has an implementation in both APIs. I think for someone who is familiar with the old API and was trying to move to the new API, there’s some important things you have to learn, but the sort of fundamentals of what constitutes a buildpack are still largely the same. There’s a couple entry points, essentially scripts or executables that get run by the platform, the inputs and outputs of those have changed. But the concept is still largely the same.

Josh Birk:

Got it. Tell me a little bit about, because obviously opensource, portability, these are all good things that developers love. Talk to me a little bit about some of those new capabilities though, in the new API that maybe weren’t supported in the original one?

Joe Kutner:

Yeah. One of the biggest… Well, I guess there’s two ways to look at this, internal to buildpacks. Like how does this make the buildpack experience better? And in that respect, the layers that are available in the image format that we use allow you to transfer your images more quickly without duplication. So basically the old buildpacks created a sort of proprietary format image, it was just a one compressed file or files. And then in this new format, we’re following a specification called the OCI Image Format, which is essentially just the format that Docker images use. So this is a standard ecosystem format, and it breaks down that single compressed file into lots of compressed files, but then it calculates a hash for each of those files, which are called layers. And then if two runs of a buildpack produce the same layer, it can deduplicate those.

Joe Kutner:

So for example, my operating system, that’s a part of my image will be composed of many layers, probably a dozen or so. And another app that’s running on the same operating system will have those same 12 layers. So when I deploy or release that image, whether it’s to the Heroku platform or somewhere else, if someone else has already deployed those layers, then I don’t have to transfer them. And so I can transfer an entire image, including an operating system in just a fraction of a second, in some cases.

Josh Birk:

Nice. And I would assume there’s also some benefits there, like you were talking about keeping developers out from the grunt work of updating the OS and patching the OS, so I would assume that also makes it easier. On one framework, I can have an OS patch and not have to worry about the 15 to a hundred apps that are relying on it.

Joe Kutner:

Yeah. And that’s really what separates buildpacks from the rest of this Docker and container ecosystem is that buildpacks can sort of go in strategically and updates, specific layers without effecting the other layers in the image. So buildpacks can update the layer that contains your Java runtime without having to rebuild your application. They can update the layers that contain your operating system and some of those lower level packages without having to make any modifications to your app, or even really running any of your build process at all.

Josh Birk:

Gotcha. So taking a step back for the unfamiliar, what exactly is Docker and how is it working with buildpacks?

Joe Kutner:

Yeah. So Docker is what’s called container technology. So if you’re familiar with virtual machines, which are essentially like operating systems that run inside of operating systems, Dockers like a very lightweight version of that, where if you’re not running an entire operating system inside of your operating system, you’re leveraging your base operating system for some of the primitive capabilities like scheduling processes, but you have a container which is an isolated environment in which you can run those processes. And so you get these sort of illusion of having your own virtual machine, but in a much lighter weight capacity.

Joe Kutner:

And so that technology has been around for a long time, actually Heroku was built on a container technology called LXC, Linux containers back 10 years ago. But Docker came around, I think in 2015 or so, I think sounds about right. And it brought that kind of technology to the broader developer ecosystem made it accessible. So people can do it on Mac and on Windows as well as on Linux. And it allows you to create these sort of isolated environments that can directly reproduce the environment that you’re running in the cloud.

Josh Birk:

Gotcha. Yeah, no, I was going to say that’s a really interesting, what do you think was kind of the magic there behind Docker that really made it so accessible for developers?

Joe Kutner:

I think very much in the same way that Heroku simplified some of the cloud infrastructure, Docker simplified the container infrastructure. And I draw that parallel because if you look at the commands that you would run with Docker, they are the exact same commands that you would run for Heroku.

Josh Birk:

Got it.

Joe Kutner:

So docker push like Heroku’s git push, Heroku master, docker run like heroku run. It’s not a coincidence that those things are very similar, that was intentional. I think that the difference for Docker was that they weren’t trying to build a cloud platform. They were just focused on that container technology.

Josh Birk:

Got it, got it. And we might be retreading here a little bit, but then Docker also kind of restructured those layers, right? Like originally containers were kind of based like a tree, like git, and then this allowed for this evolution for the layers to be swapped out, not necessarily in terms of branches. Am I saying that right?

Joe Kutner:

Yeah. So Docker introduced this layer concept too. So before that, there really wasn’t a structure. So that’s what I was saying with the sort of old proprietary image format was just a single compressed file and it would be sort of launched inside of the container. But yeah, Docker introduced, in addition to those sort of developer experience features of making containers accessible, it also introduced this image format that allowed it to deduplicate layers and do things more efficiently.

Josh Birk:

Okay. And then taking it one higher for people not familiar with Kubernetes. Can you describe that and how it plays with buildpacks and things like Docker?

Joe Kutner:

Right. So if I back up, so what I was saying about Docker, not building a platform, when Docker became popular, the next thing everybody wanted was a platform for Docker.

Josh Birk:

Got it.

Joe Kutner:

And that’s the space that Kubernetes fills. It allows you to orchestrate your containers and build a platform out of them. So without Kubernetes, you have Docker on your local workstation, and that’s great. It can help your development environment, but you still need a way to put those containers into production, make sure when they crash, restart them when you need to restart them, launch new ones for administrative tasks, all that kind of boring infrastructure stuff. And Kubernetes provides a very powerful environment for not just running the containers, but operating them and wiring them together and doing all those important infrastructure level tasks.

Josh Birk:

Got it. Okay. So I’m going to pitch an analogy to you. If we take a crate, a buildpack is kind of like a really highly efficient way to organize the contents of that crate, so they could be easily used by anyone. Docker is like the container around that crate itself. And Kubernetes is kind of like the cargo ship that can hold those crates and move them around. How close am I?

Joe Kutner:

I think that could work. I think the one thing I would change is that the buildpack does sort of encapsulate a bunch of concerns. The buildpack doesn’t really stick with you, right? The buildpack is a tool that you run so that you can get a container, but then when you’re done with it, you kind of move on from it. Like the buildpacks are not required at runtime. They may insert a few artifacts into your image that help you run it. But the buildpack itself, it’s kind of like a drive-by shooting in a good way, I guess.

Joe Kutner:

That crate analogy, the way I guess I would change it is that you sort of open up the crate, drop some things off and then the crate goes away. And then the next time you change your code and need to create a new container, you can use that create, that buildpack again.

Josh Birk:

Got it. So kind of like magic crates? Sure.

Joe Kutner:

Yeah.

Josh Birk:

Okay. So one of the reasons I wanted to put some of those concepts of together was to give people kind of an introduction to some of the technology that’s been behind a kind of another huge trend that we’ve seen for years. And we’re seeing it with Salesforce functions and things like that. How is this technology helping enable like microservices? Why is microservices, I feel like almost dependent on those kind of technology?

Joe Kutner:

Yes. I would say that it’s what containers allow you to do is treat your services to the components that make up your software systems as commodities, you can dispose of them, you can replicate them, you can stand up lots of them, you can run them in very lightweight environments, all of those things. Yeah, I think they are essential to the microservice architecture because when you start to embrace microservices, you very much increase the sort of components that are running in your system and all the interactions that they have. And so these new concepts allow you to deal with those concerns more efficiently.

Josh Birk:

Gotcha. Because it definitely feels like for maybe some of us old school Klan server guys where it’s like, it’s just a model of application strengths, but the world we’re kind of walking to, it’s more ephemeral and more agile, I guess.

Joe Kutner:

Yeah, I think so. Although I definitely, some of these principles I think have value to the more monolithic app as well. And that transition happened, or maybe it’s still happening, but around the same time as the interest in microservices. And a lot of this was driven by Heroku, and Heroku created this methodology called the Twelve-Factor App and it defines 12 factors or principles that lead to more scalable, more maintainable applications.

Joe Kutner:

And those principles really are in my opinion, the foundation for microservices, because they speak to the disposability and all those other things I was just talking about. But they’re also used by people working on more monolithic applications, because even though they may only have a single app or monolith, they still need to be able to scale it and replicate it and create test environments where they can test stuff and whatever.

Josh Birk:

So that’s interesting. And I know we can’t go down a rabbit hole with this because I know I’ve put theater sessions together on the Twelve-Factor App. We don’t have another 20 minutes, but maybe give us a little more of a medium dive into that. Like what are some of those principles and how are they relatable to a development cycle?

Joe Kutner:

Yeah. So they cover a lot of different areas, including how you do development, how you do operations, how you do deployment. But I think there’s a few that are particularly related to our conversation. One is making your applications disposable, which again, relates to this idea of containers and being able to sort of discard, restart whatever.

Joe Kutner:

Another is a Twelve-Factor App has as close as possible to dev/prod parity. So your development environment is close to identical with your production environment. And again, this is something that containers and buildpacks make possible. Whereas prior to Twelve-Factor App, you might have special tooling that you run locally, but you don’t run in production. And then that can make debugging production issues, very complicated and things like that.

Josh Birk:

Gotcha. So let’s talk brass tacks. If people want to start to move their applications into a Cloud Native Buildpack, what are the tools, what are the prerequisites that they need in order to start getting that work done?

Joe Kutner:

As part of the open source project, there’s a CLI called the pack CLI, P-A-C-K, and it runs on Windows, Linux, and Mac. And once you install the CLI, you can run the pack build command on any application. It’ll ask you what set of buildpacks you want to use. And I recommend the Heroku buildpacks, but once you have those, they will recognize a node app or a Java app or a Python app. There’s about seven main different types of apps that are buildpacks support by default.

Josh Birk:

Gotcha.

Joe Kutner:

So that pack build command, the end result is a Docker image. And then from there, it’s just a matter of running it.

Josh Birk:

And going back to our Minecraft example, because I can see where… Well, actually let me follow up just on that. So if I have a fairly vanilla straightforward node application, are we just talking about basically a few lines of a command line operation and I’m done?

Joe Kutner:

You as the developer?

Josh Birk:

Mm-hmm (affirmative).

Joe Kutner:

Yeah. It’s just that pack build command.

Josh Birk:

Got it. Got it.

Joe Kutner:

If the build itself runs inside of a container and then all of those other steps like NPM, Install or whatever it may be are executed as essentially sub-processes inside of that.

Josh Birk:

Got it. But then to bring it back to the Minecraft example, how do you identify some of those edge cases you were talking about, like having to have a secure tunnel and then how do you resolve some of that kind of stuff?

Joe Kutner:

Yeah. So the Minecraft buildpack is funny because you don’t have a Minecraft app. Just sort of installs Minecraft for you. One of the things that I’d love to enhance it… You can drop configuration files in there. Like there’s, I think an admin-json and a white list. So you put some of your source code is essentially just those configuration files. Then in the future, I’d like for it to support, I think they’re called extensions or plugins or something like that.

Josh Birk:

Whatever the modern version of Minecraft mods are?

Joe Kutner:

Right. But in the case of Minecraft, it just knows that it’s going to need that secure tunnel and the buildpacks install like ngrok and some other tools that’ll handle that for you.

Josh Birk:

Gotcha.

Joe Kutner:

Yeah. But there are other buildpacks like the more standard like Java or Python that can detect what kinds of things your application will need, like in the case of Python, it’ll detect if you need SQLite and then install that into your image too.

Josh Birk:

Got it. And where can people go to learn more about this.

Joe Kutner:

buildpacks.io is where we have our documentation and some other important links to videos and content you can learn from. There’s also a link to our Slack, which I believe is slack.buildpacks.com or buildpacks.slack.com. One of the two, the link is on the buildpacks.io webpage. We have a pretty healthy community there, that’s eager to answer your questions and help you work through any issues you might encounter.

Josh Birk:

And that’s our show. Now, before we go, I did ask Joe about his favorite non-technical hobby and it turns out he really likes staring into the sky.

Joe Kutner:

Oh, astronomy. Well, I guess that’s actually kind of technical because I do astrophotography, but I very much prefer the nontechnical astronomy, just visual observing.

Josh Birk:

Nice. Nice. What kind of gear do you need for, what was that again?

Joe Kutner:

Astrophotography?

Josh Birk:

Yeah.

Joe Kutner:

Expensive gear. You need cameras.

Josh Birk:

I was going to say, is it just like a super expensive camera or is it like a very specific kind of camera?

Joe Kutner:

You can do astrophotography with a fairly inexpensive DSLR. However, it is incredibly addictive and you will inevitably spend thousands of dollars on a more expensive camera. I love recommending to people, very inexpensive setup. When I say inexpensive I mean like maybe under a $1000.

Josh Birk:

Got it.

Joe Kutner:

But it’s very easy to get carried away with.

Josh Birk:

This is why I never got my first tattoo. I want to thank Joe for the great conversation and the information. And of course I want to thank you once again for listening. Now, if you want to learn more about this podcast, head on over to developer.salesforce.com/podcast, where you can hear old episodes, see the show notes and have links to your favorite podcast service. And a special note we have now started putting the episodes of the podcast up on YouTube. If that just happens to be a place you hangout. I’ll talk to you next week.

 Get notified of new episodes with the new Salesforce Developers Slack app.