Cloud-native application development with devfiles

Background

In the previous post, I briefly introduced the concept of a development container. In my opinion, the most significant problem solved by these is the this-does-not-work-on-my-machine issue. Development containers ensure that members of a team are all developing in the same software environment, with an identical software stack.

Lets move a step ahead. Today, if you are developing a back-end application, it is very likely that you are targeting a cloud-native deployment, using Kubernetes perhaps. Working on the Kubernetes deployment after the application has been through multiple cycles of development and testing sounds very waterfall-ish. And it indeed is, because deployment to Kubernetes can lead to unforeseen issues, wasting time during deployment. It makes sense to develop for cloud-native right from the beginning.

This approach has motivated the creation of cloud-native development tools that let you run your development and test cycles - the inner loop of application development - on a local Kubernetes instance. In some way or the other, these tools encapsulate the complexity of Kubernetes, offering an easy-to-use interface to the developer, easily integrated into the development workflow.

Enter devfiles.

Devfiles

Devfiles are configuration files that let you describe the building and running of an application in a cloud-native container, using YAML. They may include configuration to:

1. build your project

2. run it in a local container

3. run it in a local cloud-native container

Devfiles for popular language/framework stacks are provided through a public community registry. They could be customized for specific application requirements. For every unique framework/language stack, a new devfile needs to be authored.

While a devfile describes the configuration to build and run a cloud-native application, we need tools that can talk to Kubernetes (or Redhat Openshift, Podman) and run the described automation.

Enter Redhat odo.

Odo

Odo works with the the local Kubernetes (or Openshift) instance. It is run in the project’s root directory. The odo init and odo dev commands attempt to auto-detect the language/framework used by the project, and download the appropriate devfile from the public registry. Subsequently, the odo tool uses this description to build and run the application.

One of the features of odo that impressed me is related to watching of the project directory and re-building and re-deploying on the smallest changes to a file in it. This is elucidated in the demo videos below.

Demo

I tried the quick-start guides for SpringBoot/Java and .NET. The docs don’t really cover well the installation of odo alongside k8s, but the issues I faced were quite trivial. I have this screen-cast of setting up odo and k8s on an Ubuntu 25.10 instance:

For all of the demos, the downloaded devfiles did not work out-of-the-box on Ubuntu 25.10. A difference in the uid/gid between the host and the container caused a failure to copy project files to the container. I added the following YAML to the container definition to fix this:

  # On my host id -u and gid -u both return 1000.
  attributes:
    pod-overrides:
      spec:
        securityContext:
          runAsUser: 1000
          fsGroup: 1000
    container-overrides:
      securityContext:
        runAsUser: 1000

For the Spring Boot / Java stack, I tried the Pet Clinic example and a simpler hello-world sample. For Pet Clinic, I had to increase the memoryLimit from 768Mi to 3Gi. The hello-world sample is simpler and the screen-cast below covers it:

And here’s a screen-cast depicting the .NET example:

Conclusion

It is unfortunate that odo is being deprecated. However, I think it is important to understand the distinction between odo and devfiles (right now, I cannot say that they are not tightly coupled in certain aspects). While a devfile is a descriptor, tools like odo are the drivers that execute the descriptor. Devfiles are a great way of abstracting the k8s complexity for application developers. They seem to offer a solid tooling foundation to improve the cloud-native developer experience.