Developer productivity seems to be front and center again these days. While projects like Backstage draw a lot of interest and we also see a lot of traction happening around productivity tools I personally believe that it is time to revisit the bigger picture and take a look at what developers are going through in this new distributed world and how things could be easier.
What we know best – The Inner Loop
When we talk about developer productivity it is important to take a look at the whole picture. As developers we usually only seem to care about the so called “inner loop” development. This can be summarised as everything that happens on your development machine. From coding in your favourite development environment to unit- and container testing, debugging and code management. Our industry became pretty mature in the last decade in getting developers productive and setting up environments. We can check in workspace settings and even roll out complete project definitions simply with tools like Maven or projects like devfiles.
In the age of containers and Kubernetes some other things are starting to become important though. The ability to create small services (both in physical size and logically) and the ability to handle the various forms of containers including local service testing. There’s plenty of alternatives for so called microservices frameworks and they all have their strengths and weaknesses. Nobody should be surprised to see me cheering for Quarkus here. I have talked about it and it’s great features at plenty of occasions already. If you haven’t had a chance to check it out, there are simple getting-started guides available and the Microsoft team just recently published a hands-on-lab on Azure where you get to play with Quarkus and some others.
The outer-loop challenges
The challenge with modern application development stacks barely lies on the inner-loop side. Problems start when we think about the execution environment. It feels like hundred years back where developers were not only responsible for the applications but also the runtime environments and we had plenty of fancy ways to package and distribute everything on top of the OS to the ops teams. While long nights and heated discussions might lead to cozy memories for some, with the advent of DevOps and interdisciplinary teams we now find ourselves in the midst of being responsible not only for development, packaging and configuration but also the test, integration and production environments. What sounds like an organisational challenge mostly became much bigger in recent years. 
Looking at the above application stack example we quickly see the variety of topics that now fall into the responsibilities of development teams. And the above picture is just what I said: An example. Not even distantly capturing all the details and specifics we might see in our individual projects. Meeting the challenge of navigating complexity we do see different approaches in development teams.
Just lately I listened to an old friend of mine who works in a platform team that does nothing else than caring for developer productivity and curating a stack. What might work for mature and established companies isn’t necessarily where you’re at right now. Maybe you are starting out on your cloud adventures and just began looking at managed services. In situations like that you would need a curated and ready to roll platform that offers a great flexibility and tooling while still fitting into more or less traditional development processes. There’s some options out there and you might guess, what my answer would be if you’d ask me. But let’s dig deeper into the tooling for a minute. Because I think that besides the platform the accessibility and usability of developers day-to-day tooling is the most critical path besides a platform that broadly enables team velocity.
Only Code in Production is Valuable Code
The following little six minute video gives you an opinionated view onto a subset of tools that I believe get you a head-start into container-based development.
The individual tools you see in this recording have been used in Natale’s and my O’Reilly book, too. And you can play around with the code and even download the book for free. The application itself is build with Quarkus, that I mentioned above already. What is new is that Podman-Desktop is used to build the containers locally. It is somewhat similar to Docker-Desktop but uses Podman-Engine underneath and gives you an easy on-ramp to Kubernetes deployments.
The local services is deployed to the OpenShift Developer Sandbox. A free playground where you can get to know OpenShift and learn about it’s features. Don’t miss out on the demo of Dev Spaces for easy browser based development! From here it gets really interesting. The services configuration usually is something that is kept with your code and configured in GitOps tools for automated environment management. Instead of hand-crafting the configuration you can also use the GitOps Primer Operator from the Konveyor project. This is an operator can be deployed with a Kubernetes environment to export objects out of the cluster and store them within a Git repository. And this was done in the above demo. From the sandbox directly into ArgoCD via a git repository. This approach might look unusual and for sure isn’t suited for ongoing development but what I wanted to share is that it takes a lot more than just a simple platform to successfully navigate today’s complex tech stacks. You’ll also need to find transitioning paths for existing projects and find a level approach for your teams to broaden their knowledge without slowing them down.
What does all of this have to do with Java
A good question. Glad you asked. I believe that Java will continue to play an important role in enterprises around the globe and it’s footprint will continue to expand into containers and Kubernetes. After all it is essential for developers to be able to use the programming languages and frameworks of choice to be productive. With GraalVM we have an alternative at hand for burst load driven applications. Monitoring across different JVMs with tools like Cryostat and it’s Operator also becomes more manageable. But more importantly the friction for developers to go from local service and application development to full scale deployment on Kubernetes is being addressed not only by processes but tools. To make the best out of new challenges we need to continue to invest into developer tools that remove complexity and don’t add more.
Author: Markus Eisele
Markus Eisele leads developer tools marketing at Red Hat. He has been working with Java EE servers from different vendors for more than 14 years, and gives presentations on his favourite topics at leading international Java conferences. He is a Java Champion, former Java EE Expert Group member, and founder of JavaLand. He is excited to educate developers about how microservices architectures can integrate and complement existing platforms.
He is also the author of “Modern Java EE Design Patterns” and “Developing Reactive Microservices” by O’Reilly. You can follow more frequent updates on Twitter @myfear or Mastodon @myfear@mastodon.online
steinhauer.software