Kubernetes embodies modern infrastructure. It’s riding a wave of nearly universal adoption using containers as the vehicle for deployment as an effective abstraction above raw infrastructure. The cloud-native movement is obviously ”all-in” on this open source orchestration platform.
The problem for organizations is that Kubernetes wasn’t designed with a “developer-first” mindset. It was designed to power infrastructure. Organizations adopting Kubernetes are experiencing a feeling that harkens back to the time when virtual machine-based clouds started gaining popularity. Yes, infrastructure is now more consumable through APIs. Yes, the organization is getting more agility out of its infrastructure. However, somebody has to put the app in a container, understand how all the various parts of it are wired up, figure out monitoring, and contend with the slew of integrations and code required to stand up a platform that will run applications at scale.
Cloud Foundry can help. Its developer-first goals have been evolved and refined over the years, as users helped the community remain focused on developer productivity and helping users get better at software delivery.
Kubernetes Places Some Undue Burdens on Developers
Kubernetes rose right behind Docker, building up an ecosystem and field of knowledge in the developer community about how to build and run container images to power capabilities and services. But Kubernetes’ purpose to be the bigger version of the infrastructure environment failed to lift the fog between app development and backend systems management.
The future of application development cannot be shackled to the Kubernetes API. Developers deserve better.
— Gabe Monroy (@gabrtv) February 5, 2021
This brings us back to the problem.
Building apps or services on containers and running them in Kubernetes requires people to not only gain expertise in the Kubernetes platform, Docker, and container technologies, but also the multitude of other associated functions those containers need to perform while wrapped around any infrastructure environment.
Should application developers, rather than infrastructure platform developers — the people who are really inspired to build the pipeline tooling — be worried about how they’re going to deploy and run software? Developers that want to write an app, a website or a service should be focused on supporting a business case — not figuring out the infrastructure.
The combination of Docker and Kubernetes has made things easier for developers, but are they able to focus on the software that they need to write? I don’t think so, and I know there are many people who agree. We aren’t the only part of the cloud-native community thinking about these issues now.
A wave of open source projects, commercial products and cloud services are being built on top of Kubernetes now, trying to take that next step to get closer to the application developers’ needs. Some of these efforts take root by living with the developer in their integrated development environment, ensuring the developer is focused on implementing business features, not the code that manages network configurations.
Buildpacks Revival Reorients Developer Focus
As an alternative approach to this issue, we’ve seen a resurgence of interest in buildpacks with broad support and adoption from public cloud providers, developer communities and platforms. The concept of buildpacks, originally created by Heroku in 2011, is to let the platform handle the tenancies and other network integrations so developers are able to quickly go from writing code to running applications.
Compliance is the biggest reason for enterprises to adopt @Paketo_io buildpacks. Not having to write a Dockerfile is cool, being able to guarantee all my containers are free of vulnerable dependencies is solid gold
— Ollie Hughes (@olliehughes82) February 8, 2021
Buildpacks act as the bridge into a platform, providing support for every language and framework combination — all the wiring — so programmers can be focused on writing code. Better yet, what if it also manages how networking is going to be plumbed across the environment, application monitoring and fleetwide patching?
The entire technology industry is trying to figure out a better way for app developers to work with Kubernetes. It turns out there is a project that has been doing this almost twice as long as Kubernetes, which is now based on and integrated with Kubernetes called Cloud Foundry.
There’s only one open source project that’s been around since 2009, that uses buildpacks, and works really well on Kubernetes. Give Cloud Foundry a shot. Many companies and developers rely on it. You just might already, and probably should, too.
For those interested in experiencing Cloud Foundry on Kubernetes, our developer advocate Ram Iyengar wrote a great getting started guide over on The New Stack.
