Dear Readers, this is one of the most frequently asked interview questions about Spring Boot. Some interviewers expect you to write the complete flow of client request, controller, service…

Colkgirl shines a spotlight on women in tech, diversity, and inclusion initiatives, providing a platform for celebrating the contributions and achievements of women in the technology industry. Developers engaging with Colkgirl's content can expect to discover inspiring stories, insightful interviews, and  articles that highlight the experiences and perspectives of women in tech. 

Code Like A Girl

This guide covers how to build, test, and deploy a Spring Boot application. It provides step-by-step instructions on setting up prerequisites, creating the project, implementing CRUD APIs, configuring an H2 database, and writing tests. Additionally, it includes details on dockerizing the application and deploying it with Kubernetes.

A Complete Guide to Build, Test and Deploy a Spring Boot Application

Creating the First Spring Boot Application

Step 2: Creating the Spring Boot Project via Spring Initializr

Step 5: Configuring and Connecting to H2 Database

Step 7: Dockerizing and Deploying the Application

There is a major issue with this from a DevOps perspective - the end result here is far from production-ready. The deployment spec/manifest for the Kubernetes deployment is very minimal and doesn’t contain several key aspects, notably: resource quotas and probes.
Without resource quotas i.e. memory and CPU requests and limits then apps can run amok on clusters, sapping resources or being starved of them and fail.
Without probes i.e. Liveness, Readiness and Startup Probes, kubernetes has no idea if the app is up and healthy or ready to receive traffic or not.
The guide on springboot apps also has no mention of key concepts required, such as the implementation of probes i.e. /health and /ready - and best practices around them - something which was introduced in springboot as of circa v2.35 onwards. Liveness probes when hit should return HTTP Status 200 if the app is healthy and only return a non-200 of the app is in an unrecoverable state and requires a restart/reinitialisation. Readiness probes should return a 200 when the app is truly ready to receive traffic, such as having all the appropriate database and event queue connections, valid configs, capacity to process more requests etc, and return a non-200 when the app is being shut down, or if it needs to be dropped from the load balancer briefly. There is extensive documentation on these probes, their uses, and best practices - both generally on the kubernetes official docs, and for framework/language specific implementations if developers bothered to look - which they don’t.
Additionally, apps should be carefully designed and tested to ensure they initiate graceful shutdown and output meaningfull logs when a SIGTERM is received as this is how Kubernetes tells containers to shut down during deployments, scaling events, rescheduling or liveness probe failures. And be aware that this SIGTERM is only sent to PID 1. If you can’t guarantee your process that needs to listen for this interrupt is on PID 1 - which it probably won’t - then use dumb-init in your container and Dockerfile to involve your application which will guarantee the interrupt signal is sent to all child processes.
Finally, where is the info on utilising the latest java features around container memory and limits so that the app “knows” it’s inside a memory limited kubernetes pod and sets the Java Opts XMX and XMS settings accordingly automatically? Or are you just planning on letting the app use all the memory it wants because compute is unlimited and dealing with server resource peasantry is for the DevOps engineers on your team to worry about solely.
Far too often I see these developer-minded articles just glossing over or completely omitting key engineering practices required in order to get your apps truly production ready. Any developer worth their weight in salt should be keen to understand app/container lifecycle, monitoring, security, telemetry and kubernetes deployment best practices just as much as whatever fancy framework is the current flavour of the month to develop in. Engage with your DevOps engineers and implement their recommendations to make your apps truly production ready rather than just ship it to prod because it works on your machine. Without the things described above, it’ll work, until it doesn’t.