What it is
Spring is the default way to build a Java service: Spring Boot starts it, Spring MVC or WebFlux serves it, Spring Data talks to the database, Spring Security guards it, Spring Batch runs the jobs nobody watches, and its conventions mean the next developer can find their way around. What it saves is not typing; it is that it is the answer everybody already knows, which is worth more than it sounds.
What we do with it
- APIs and applications built as one thing. A current Boot release, records and Jakarta, a clear boundary between the web layer and the domain, and tests at the level each failure would be caught at.
- Upgrades, which is the work most clients actually arrive with. Spring 5 to 6 and Boot 2 to 3, the javax-to-jakarta move, Hibernate and dependency bumps - in steps that keep the test suite green and the service releasable.
- Persistence that behaves. Transaction boundaries that are deliberate, N+1 queries, lazy loading surprises, and schema changes through Flyway or Liquibase rather than by hand.
- Security review. A Spring Security configuration that is understood rather than copied from a tutorial, OAuth2 and OIDC done properly, and a dependency audit dealt with.
- Batch, scheduling and integration. The nightly job, the file import, and the retry that has to happen once and only once.
- Observability. Actuator, metrics and traces wired up, so that an incident is a question with an answer rather than a guess.
How it starts
Tell us what the service has to do, or send us the one that is misbehaving. For an upgrade we start with the test suite and a plan in steps; for a new service, with the boundaries between it and everything it talks to.
