Bringing back developer joy.

What a special year this has been. And no matter what happened to us in the last couple of weird months, time is relentless and runs through the roughest times. I hope, you and your loved ones are and will be safe and I hope that by keeping beloved traditions alive we all get a little bit of the normality back that we have missed dearly this year. Welcome to another edition of the Java Advent calendar. Again it is my pleasure to open the long awaited countdown to Christmas. While the kids in Germany get to open another little door filled with chocolate and little gifts every day, the amazing team organising your Java Advent Calendar made sure to bring the best and most interesting topics together in one place. Last year I had the pleasure to give you a little bit of an overview about the brand new Kubernetes native framework Quarkus. It was already in an impressive state with almost endless features and opportunities to function as a base for modern, distributed applications on the JVM. If you had a chance to follow my advise and use it in your own projects you can tell how much it has grown just this year and the community was pushing it forward constantly. Developers and customers keep asking me what framework to pick these days and I don’t really have a good answer. As an architect once said: “It depends”. There’s usually much more to a successful software project than just the APIs of the chosen framework. But it is an essential part. So, what are the other parts?

There are many visualisations of the various bits and pieces of a successful project. Depending on who’s presenting, if it’s aimed at developers or project managers. I personally like the one above very much. It focusses on the essential parts for developers. It all starts with source code for us.

Enterprise Java vs. Microservices vs. other languages
And maybe that is the reason that we focus on the framework question a lot in the first place. This is where it starts for us. And what really happened over time is that our toolbox grew and we got way more alternatives to choose from. Even if I like Quarkus personally, I am convinced that there are many solutions for your software project. I always strongly recommend to take a look at the team skills and past experiences. If you don’t know how to ride a horse, you should probably take some riding lessons and not start with something new when success is critical. The “right” choice also depends on the non functional requirements. Do we need microservices. Do we really independently scale individual services? Three-tier architectures don’t necessarily have to be a bad choice. A mix between individual approaches might also be a good choice. No matter which way you decide to go, you will have to make sure to respect the implied architecture styles and not build monsters like distributed monoliths.

Self-service provisioning and flexible environments
And after some due diligence you will land on something that your team can work with. I can only hope that you already work in a corporate environment that is embracing flexible ways of service provisioning or even offers self-services for developers. There’s nothing more hindering than having to wait for environments and scrambling for a minimalistic local environment. The need for this grows with the overall complexity of your architecture. While you can stick to what we did for a little more than a century and have a complete local development environment with an application server and a database this becomes increasingly more complicated to achieve if you add different data stores, message broker and event streaming platforms. What’s even more challenging is the configuration of some of these elements. While experienced and adventurous developers might be able to install all or at least some of these parts and get them working it is a completely different beast to run them at scale under load in production. There’s a lot of advantages of not having to worry about these parts.

Consistent Environments
On top of this, it’s rarely just the one development environment you need. You will need certain staging and testing environments plus others in various cloud regions. This is where we really need to start thinking about how we keep all these environments consistent and reliably change the scale and setup for the target platforms. What works well in smaller projects is to click-add services via online consoles and hope for intelligent defaults. At scale this is either going to cost you more than you want or it simply won’t work anymore. This is where Operators, Helm, Ansible or similar tools quickly show their power. Infrastructure becomes an important part of your software project and we need to find ways to communicate effectively with operations. This is where methodologies start to hit. Some call it DevOps or other even more fancy words. Fact is we, as developers, are taking over even more responsibility by adding the environments and their configuration to the mix. Maybe it is time to take a look at GitOps and tools like ArgoCD to help us handle this.

Automation
And honestly, when we start to think about infrastructure and environments the step back to a full fledged continuous delivery approach is the only thing that makes sense. We need to think about how our jar files become containers and how we version and label them. This is also the point where we start to think about blue-green deployments and rolling upgrades. We push containers to registries and work around rate limits and too small internet uplinks at home. How should we layer them to safe bandwith? We think about test strategies and ultimately if it really makes sense to build containers locally.

Continuous Integration / Continuous Delivery
Obviously it’s not. That is where CI comes in, right? Jenkins? Tekton? Something else? Who is building my containers? And where do they get pushed and what about upgrades? Manually? Fully automated. At this point it is really just juggling the specifics of platforms and pulling the bits and pieces together create a somewhat working pipeline. This usually also is the point in every project where the amount of YAML is constantly outgrowing the lines of business code for individual services quickly. Does it ever end?

Configuration Management
Not yet. Where do we place all the configuration? Ok, application properties might be easy (we know how to do that) and we can also work our ways around value files in Helm. And environment variables in containers we can also do. But there’s so much more that is dependent on environments and infrastructures. How and where do we configure and deploy queues are they part of the services or the environments? Where do we put ConfigMaps? Are CLI commands the right way to go? It does not end, does it?

App logs and Metrics
It will. Soon. I promise. But one last thing that is also way outside of the question of the underlaying framework in most of the cases. How do we ultimately collect, collate and view the combined metrics and logs of all our services, components and managed services? There’s prometheus and MicroProfile health and many others. But for us, it’s another part that we need to take a stab at and define it for our project.

And I will stop here. Reason for this exercise was mostly to reiterate the many smaller and bigger things that ultimately became part of our responsibilities as developers over the last couple of years. And we found solutions for all of them. Either coming from integrated container platforms like OpenShift or in a more DIY approach with other components.

What I intended to show is that a lot of our time as developers falls into areas that not necessarily have something to do with solving business problems with our code. And this became worse over time. Another good reminder how spoiled we have been, having been able to focus on simple and integrated application server platforms. Even the most complex scaling environment looks quite simple if I take a look at a full fledged cloud native application today. And this is the reason why I strongly believe that it is even more important to invest time into building a reliable and flexible process from day one to be able to efficiently create and maintain the software itself. We basically need to do two things:

• • Reduce non developer tasks to the absolute minimum!
  • Get back to fun coding!

While this is more easily said than done, reducing friction is the number one task for all of us going forward. Thinking about efficient local development settings. Using established APIs and relying on well known and production proven frameworks and functionalities. Thinking about ways easing configuration and provisioning, like ODO for example.

I’ve been short on recommendations or solutions in this post. But this wasn’t really the intention. I wanted to give you a little bit of an overview on how complex our world has become and encourage all of us to use this more silent times of the year to not only reflect on the madness it brought over all of us but also think a little bit about what it really needs to bring back a little more developer joy to our lives.
If you’re interested in the full story I have a little 15 minutes video for your to watch. With a little more explanation and obviously also some recommendations. And if you have even more time to spend take a look at the playlist of the Quarkus Day that happened recently. 15 to 20 minute videos each.

My favorites:

• Tightly packed and scalable. Quarkus on OpenShift.
• Quarkus meets Neo4J
• 3-tier vs. Microservices. How to get Spring Boot into the cloud.

Thank you for reading. For today all that is left is to wish you and your loved ones a peaceful time and a healthy start into the new year.