Dramatically speed your development workflow and feedback loop with Devspace

✏️ Written by Lee Van Steerthem, Cloud & DevOps Architect at Devoteam G Cloud

Kubecon has always been a great way to learn how certain tooling would be able to help with common problems we find with working with Kubernetes. In the last years, we saw an increase of focus on the Developer Experience (finally). At the end of the day, it’s important that the end-user (which is the Developer who creates applications) is being put in the spotlight to make their lives easier. I went to the Devspace talk, “Using Devspace to usher in an era of peace for our developers“, because I wanted to know how this would help. Devspace is a free open-source solution from the company Loft, who you might know from Vcluster.

The talk was mainly about how developers can get a faster feedback loop without the complete “local” onboarding setup they should do. But rather use remote Kubernetes clusters to reflect more the reality of how their application would run in production. The key here is fast development and iteration. To compare this to other tools you can think about Docker compose for Kubernetes but then remote. It took a lot of the simple elements of docker-compose which is key for developers. So what problems does it solve and how?

Devspace solves these 5 problems you might have

Shared environments chaos: As you might know if you share a “dev” cluster, and you did not have a system to isolate per developer then you will be constantly talking to each other to NOT wipe the environment. In Devspace, you get your own environment totally isolated. This of course brings in a higher running cost, however with some governance and lifecycle rules you can remove environments when they are no longer needed.

Local installation hell: When people get onboarded they are required to install X amount of programs and tools to get going. This is fine if every laptop is the same OS and everybody works on the same Language version & Libraries. But we all know that his utopia does not really exist, it’s not uncommon that certain things don’t work (or require some undocumented steps). And does somebody remember the phrase, It works on my machine? This is where a remote environment comes into play. You install fewer tools, and focus on development on the laptop but running in a “production-like environment”. This means you can also use all the available observability tooling without needing to install anything. 

Testing locally: Testing is always hard because it needs to be in a controlled environment, yet it also needs to be representative. It’s done too many times that the focus is on writing good tests, yet they fail if they run in a CI environment. But what if we run Devspace in the pipeline also? Then we eliminate the other environment that is different and we can see during the run what is happening with that environment. While the system might be remote, it’s still more accessible than having a “CI Slave” running the system in the dark and you have to rely on the logs (that are most of the time not streamed). 

Waiting for the artefact to be built by the CI system: Continuous Integration systems are awesome, however, if we are waiting hours for a new commit in our Pull request to be able to be deployed onto a system then we should find a better way. In many cases your IDE already has a “hot reload” functionality, now what if we can have the same but remote? With the devspace dev command, you are sharing your files (mounting)  to the Kubernetes cluster. Making it possible to quickly change something and devspace will take care of the rest.

Stakeholders like QA, PM, and Leadership are unable to see early developments: In an Agile organization, you want to iterate fast based on feedback. Yet typically stakeholders need to wait until it’s deployed in a stable environment, this means the code is ready but we waiting hours, days before someone (outside of yourself) is capable of validating and providing feedback. This is even more valid with remote work because, in an office environment, you could quickly ask someone to come over. With Devspace, you get a shareable link the moment the environment is up. It’s even so powerful that you can compare both the old and new version.

Conclusion

There are many benefits to using devspace and you can extend it to so many environments (dev, test, acc). Not only do you get a faster feedback loop, but you also get a simple interaction with the deployment that is not as abstract as some other tools. Ultimately, it gets deployed on Kubernetes and you can quickly test out what would happen if you change certain parameters. I love it, it’s a win for the developers and a win for the people who manage the platform because they can focus on other things.