A Week of Vertex Cloud – Towards the Best Developer Experience
I had plenty of time during this this spring thanks to Covid-19 to build a Vertex Cloud proof-of-concept. The goal was to find the best suitable Cloud Architecture and developer tools for our purposes. I’ve personally followed the Spring Framework evolving over the last 5 -10 years in my own hobbyist projects. With that in mind and the fact Vertex developers have built their Java expertise over the past 20 years, the obvious first choice was to test the Spring Framework the #1 Java Framework.
CTO, Vertex Systems Oy
Leader and Passionate Developer at Night
Monolithic vs Microservice Architecture
All of our past solutions are based on monolithic architecture. There’s been a lot of debate over the years about the pros and cons of microservices. Instead of going to all the details I decided to be open-minded and try in practise to built the POC based on Microservices Architecture. Of course having background knowledge about Docker containers and Kubernetes, thanks to my personal interest on new technologies, made it quite easy to give it a try. Based on the short experience I would say the the microservices are easier to maintain because the intention of the service is to do one thing only. But how to be productive?
Spring Boot and Visual Studio Code
To get started with your project Spring Initializr provides good starting point and with Spring Initializr Java Support it’s relatively easy to customize the project with configurations and manage Spring Boot dependencies.Visual Studio Code extension Spring Boot Dashboard makes it easy to debug the Spring Boot application, which is just on portion of the application development.
Docker and Kubernetes
I’ve used the Visual Studio Code almost three years now along with Docker desktop for Mac. It’s relatively easy to develop, deploy and run containerised application as one. But how to develop/debug a complex application with multiple microservices running on the Kubernetes cluster locally on your own device not talking about running on cloud provider environment. The first steps in April 2020 causing a headache and some dark clouds.
The first challenge was to to learn how to build Docker container using Buildkit providing faster development with incremental builds. That was quite straight-forward but only available on Linux and macOS. Thanks to Windows 10 version 2004 update we can us the Buildkit also on Windows. One step forward on this challenge.
Being able to build the Docker container and after pushed to Docker Hub the next step was to create the Kubernetes manifest files. After enabling Kubernetes on Docker desktop I was able to run the Docker containers inside Kubernetes cluster using kubectl command line tool like ‘kubectl apply -f some-kubernetes.manifest-file.yml’.
But to be productive workflow is so far something like:
Test using Spring Boot Dashboard
Build Docker image and Push to Docker Hub
Apply to Kubernetes using kubectl
Test application running on Kubernetes Cluster.
This is getting too complicated. And what if you have an application with multiple microservices? Let’s move forward …
Skaffold and Jib
Thanks to Google the are more tools to use. Skaffold is for fast, repeatable and simple local Kubernetes development and it’s really easy to get started. Run the ‘skaffold init‘ to prepare the skaffold for your project. To make life even easier you can build Java containers with Jib. Use the command ‘skaffold init –XXenableJibInit‘ instead. After you have installed the Skaffold just run use ‘scaffold dev‘ in you Visual Studio Code terminal build and deploy your app every time your code changes.
Getting closer, but more to come …
Cloud Code for Visual Studio Code
Last weekend I finally had some time to move forward and decided how to debug Kubernetes application with Cloud Code on my local environment Kubernetes running on Docker desktop.
Once having Cloud Code extension installed on my Visual Studio Code all I have to do is to choose the Debug on Kubernetes command using the Cloud Code status bar.
The program starts on Kubernetes cluster and stops on any defined breakpoint.
This is close perfection when developing / debugging on you local Kubernetes cluster.
The next challenge is to add more microservices to our application and do the same with services running on the cloud provider environment.