Buildpacks help ease the burden on developers by taking source code and turning it into fully functional applications.
To learn more about this technology, we interviewed Ram Iyengar, chief evangelist at the Cloud Foundry Foundation, about the most important topics. recent episode from our podcast, What the Dev?
Here is an edited and abbreviated version of that conversation:
How do buildpacks, and Paketo Buildpacks in particular, help developers deploy cloud-native applications?
I think build packs have been very important in getting many applications into production and containerized without having to deal with a lot of overhead that usually comes with the containerization process. What can I say that we haven’t already said in the webinar and in the article and things like that? Well, there is a community angle to this. Buildpacks is somewhat heading toward graduation within the CNCF, and we expect it to do so in the next six to 12 months. If there is any show of support you can do as a community, I really appreciate people giving it a star, opening important topics, trying out the project, seeing how they can consume it, and giving us feedback on what the project can be like. improved.
One thing I wanted to touch on a little bit is Korifi, which is their platform for building and deploying Kubernetes applications. Can you talk a little about Korifi and how it relates to build packages?
Absolutely, one of the main areas where we see a lot of build packs being consumed is when people get to work building platforms on Kubernetes. Now, any kind of talk you see about Kubernetes these days, whether it’s at KubeCon or one of the other events, is extremely complex, and it’s been said so many times over and over again, there are memes, opinion pieces, all that stuff. types of Internet subculture about how complex Kubernetes can be.
The consequence of this complexity is that some teams and companies have started to come up with a platform where they say they want to use Kubernetes. Well, install another substrate on top of Kubernetes and abstract away many of the internal parts of Kubernetes so that they don’t interact with your developers. That resonates perfectly with what Cloud Foundry’s messaging has been all these years. People want a first-class, self-service, multi-tenant experience across virtual machines, and today they want that same type of experience in Kubernetes for slightly different reasons, but the ultimate goal is for developers to be able to get there. speed at which they are most optimal. They need to be able to build and deploy quickly and still release applications to production while reducing many other areas of importance, for example, how do we scale this and how do we maintain load balancing on this? How do we set up networking and login?
All of these things should fall on one platform. So Korifi is what came out of the community to implement that kind of behavior, and buildpacks fit perfectly into this world. So by using build packs, and I think Korifi is like the number one consumer of build packs, they’ve actually created an experience to be able to deploy applications to Kubernetes, regardless of language and family, and take advantage of all those features of the build packages. .
I hear a lot of talk about the Cloud Foundry Foundation in general, that it’s a little old and that maybe Kubernetes is looking to displace what you guys are doing. So how would you respond to that? And what does the Cloud Foundry Foundation offer in the world of Kubernetes?
It’s a two-part or two-pronged answer I have. On the one hand, there is the technological side. On the other hand, there is a community and human angle to things. Engineers want new tools, new things, new infrastructure, and new types and ways of working. And so what’s happened in the broader tech community is that a good enough technology like Cloud Foundry suddenly found itself relegated to legacy technology and the old way of doing things and, in some cases, not modern enough. That’s the human angle. So when people started looking at Kubernetes, when the entire software development community found out about Kubernetes, what they did was they sort of picked up on this new trend and wanted to jump on the hype train, so to speak. And Kubernetes began to occupy a lot of mental space and now, as Gartner puts it, it is past that phase of high expectations. And now we’re getting into productivity and the entire community is yearning for a way to consume Kubernetes without the complexity. And they want a very convenient way to deploy applications to Kubernetes without worrying about networking, load balancing, auto scalars, and all those other peripheral things you have to attach to an application.
I think it’s not really about developers just wanting new things. I think they want better tools and more efficient ways to do their jobs, which gives them the freedom to do more innovation that they like and not get bogged down with all those infrastructure problems and things that they now know can be solved. of. So I think what you’re saying is very important in terms of positioning Cloud Foundry as something useful and useful for developers in terms of gaining efficiency and being able to work the way they want.
Well, yes, I agree in principle, which is why I say that Cloud Foundry and some others like Heroku, all perfected this experience of what a developer’s workflow should be like. Now, developers are happy to adopt new ways of working, but the problem is that when you’re on the path to gaining that kind of efficiency and speed, you often unintentionally build a lot of stubborn workflows around yourself. So all developers will have a very specific way in which they will create implementations and create these immutable artifacts, and build a fort from where they would like to be kings of the castle, lords of the manor, but it’s really attacking a lot of the mental image and any apprehension arising from deviating from that mental image. And at the moment, Kubernetes seems to offer one of the best ways to build, package, and deploy an application, since it can accomplish many different things.
Now, if you do a point-by-point comparison between what Cloud Foundry was capable of doing in, say, 2017 and what Kubernetes is capable of doing now, it will be almost the same. So in terms of feature parity, we’re at a point now, and this might be very controversial to say on a public podcast, but in terms of feature parity, Cloud Foundry has always offered the kind of features that are available in the community. of Kubernetes. right now.
Now, of course, Kubernetes imagines applications being built and deployed in a slightly different way, but in terms of putting everything into containers and shipping it to a container orchestrator and providing the kind of reliability that applications need, and allowing sidecars and services and multi-tenant.
I firmly believe that Cloud Foundry’s offering was pretty compelling even four or five years ago, whereas Kubernetes is still navigating some pretty choppy waters in terms of multi-tenancy and services and things like that. But hey, as a community, they are doing wonderful innovation. And yes, I agree with you when I say that engineers are always looking for the best way to achieve that efficiency.
