Devops Monk

Running Spring Boot on Kubernetes is not just packaging the app in a container and deploying it. You need to configure health probes correctly, handle graceful shutdown so in-flight requests don’t get dropped, manage configuration without baking secrets into images, and make sure the JVM respects container memory limits. This guide covers the production-critical Kubernetes configuration for Spring Boot applications. Health Probes Kubernetes uses three probe types to manage pod lifecycle:

Testcontainers spins up real Docker containers for your tests — a real PostgreSQL database, a real Redis, a real Kafka broker. No more mocking JDBC connections or in-memory H2 databases that behave differently from production. Spring Boot 3.1 added @ServiceConnection, which removes the boilerplate of configuring connection URLs manually. This guide covers the right patterns for fast, reliable integration tests with Testcontainers. Why Testcontainers Over H2 Teams use H2 in-memory databases for testing because it’s fast.

Virtual Threads landed in Java 21 as a stable feature, and Spring Boot 3.2 added first-class support with a single property. The promise: write simple blocking code and get WebFlux-level throughput. The reality is mostly true — with some important exceptions. This article covers what Virtual Threads actually are, how to enable them in Spring Boot, real benchmark numbers, the three pitfalls that will silently destroy your performance, and a decision framework for when to use them (and when not to).

Every year, someone asks: “Should we use Spring Boot or Quarkus?” In 2026, both frameworks are mature, both run natively, and both work well on Kubernetes. The differences come down to developer experience, ecosystem size, and specific performance characteristics. This is an honest comparison with real numbers, not marketing claims. The Frameworks at a Glance Spring Boot 4 (November 2025): Built on Spring Framework 7. The de-facto standard for enterprise Java.

Microservices solve real problems: independent deployability, team autonomy, technology flexibility. They also create real problems: distributed transactions, network latency, operational complexity. Many teams split into microservices too early, before they understand their domain well enough to draw stable boundaries. Spring Modulith gives you module boundaries, enforced isolation, and event-driven decoupling inside a single deployable JAR. It’s the pragmatic middle ground. The Modular Monolith Problem It Solves A typical Spring Boot monolith looks like this after a year:

These are the questions that actually come up in Spring Boot interviews — at startups, scale-ups, and large enterprises. Each answer explains the concept clearly, with the level of depth an interviewer expects from a mid-level or senior developer. Questions are grouped by topic. For junior roles, focus on sections 1–3. For senior roles, everything here is fair game. Section 1: Core Fundamentals Q1. What is the difference between Spring and Spring Boot?

Most AI assistants are chatbots. You ask, they answer, the interaction ends. The interesting shift happening right now is treating AI as an autonomous worker — something that runs on a schedule, produces real artifacts, and delivers results without you being in the loop. This post walks through building that kind of assistant: a background agent that runs weekly, researches a set of topics relevant to your work, and delivers a structured briefing via Telegram or email.

Most stock screeners cost $30–$200 per month. Bloomberg Terminal costs $24,000 per year. I built something that does a meaningful fraction of what those tools do — analysing 220+ UK and US stocks every hour, scoring them across six dimensions, detecting bearish warning signals, running insider trading checks via SEC EDGAR, and presenting everything in a React PWA — at zero ongoing cost. The platform is live at share.devops-monk.com. The full source is at github.

Tools like ESLint, Semgrep, and Bandit catch what they are programmed to find: known patterns, common injection strings, deprecated API calls. They are fast, reliable, and deterministic. They are also blind to anything that requires understanding what your code is supposed to do. Claude Code operates differently. It reads code the way a human security researcher would — tracing data flows across files, understanding business logic, and reasoning about what could go wrong given the specific context of your application.

Most teams use Claude Code reactively — they type a prompt, Claude responds, they type another. That is fine, but it leaves significant value on the table. Claude Code has four automation layers that let you turn it from a reactive assistant into an active workflow participant: Layer What it does When to reach for it Hooks Shell or HTTP calls that fire on lifecycle events “This must happen every time, without exception” Custom Commands Reusable slash commands for repeatable prompts “I type the same prompt repeatedly” Skills Context-aware instructions Claude loads automatically “Claude should always do X when working on Y” Subagents Separate Claude instances for isolated, parallel work “This task is noisy and the main session only needs a summary” This post covers how to create each one and when to use them.