From Java Development to Kubernetes Deployment: Complete End-to-End Journey of a Spring Boot Microservices Application
When developers start learning Spring Boot microservices, they often learn technologies like Docker, Kubernetes, Redis, RabbitMQ, API Gateway, Config Server, Kafka, and CI/CD separately. However, one important question…
When developers start learning Spring Boot microservices, they often learn technologies like Docker, Kubernetes, Redis, RabbitMQ, API Gateway, Config Server, Kafka, and CI/CD separately.
However, one important question usually remains unanswered:
“Where does everything actually run in a real enterprise application?”
For example:
- Where does the Spring Boot application run?
- Where does the API Gateway sit?
- Where are Docker images stored?
- Does the database run inside Kubernetes?
- Where do Redis and RabbitMQ live?
- How does the application move from a developer’s laptop to production?
In this article, we’ll walk through the complete lifecycle of a Java microservices application exactly as it happens in modern enterprise companies like Amazon, Microsoft, Oracle, Walmart, banks, and healthcare organizations.
High-Level Journey
The complete flow looks like this:
Developer Laptop
│
▼
Git Repository
│
▼
CI/CD Pipeline
│
▼
Docker Registry
│
▼
Kubernetes Cluster
│
▼
Users
Now let’s understand every stage in detail.
Stage 1 — Development
Everything begins on a developer’s laptop.
Suppose you’re developing an e-commerce application with the following services:
- Accounts Service
- Payment Service
- Order Service
- Inventory Service
- Notification Service
- API Gateway
Each service is an independent Spring Boot project.
Example:
payment-service/
src/
pom.xml
Dockerfile
application.yml
During development, the service usually runs locally using:
mvn spring-boot:run
or directly from IntelliJ IDEA.
For example:
http://localhost:8083
At this stage, the application is simply running as a Java process on your computer.
Stage 2 — Local Infrastructure
A microservice rarely works alone.
It needs several supporting components.
Database
Your application connects to a separate database.
Spring Boot
│
▼
MySQL / PostgreSQL
Notice that the database is not inside the Spring Boot application.
It is an entirely separate application.
During local development, developers usually run the database using Docker.
Redis
Redis is another independent application.
Spring Boot
│
▼
Redis
It is commonly used for:
- Caching
- Session management
- Rate limiting
RabbitMQ or Kafka
For asynchronous communication, microservices communicate through a message broker.
Payment Service
│
▼
RabbitMQ / Kafka
│
▼
Notification Service
Again, this is another independent application running separately.
Config Server
Instead of placing configuration inside every microservice, organizations often centralize configuration.
Git Repository
│
▼
Config Server
│
▼
All Microservices
Whenever configuration changes, every service can refresh its configuration without manually updating files everywhere.
Stage 3 — API Gateway
Imagine your application contains ten microservices.
Without an API Gateway, the frontend would need to know the address of every service.
Frontend
│
├── Accounts
├── Payment
├── Orders
├── Inventory
└── Notification
This quickly becomes difficult to manage.
Instead, we introduce an API Gateway.
Frontend
│
▼
API Gateway
│
┌────┼────┐
▼ ▼ ▼
Accounts Payment Orders
Now every client communicates with only one endpoint.
The gateway is responsible for:
- Routing requests
- Authentication
- Authorization
- Logging
- Rate limiting
- Request filtering
Stage 4 — Service Discovery
In traditional Spring Cloud architecture, services frequently changed IP addresses.
A Discovery Server kept track of them.
Gateway
│
▼
Discovery Server
│
▼
Payment Service
Whenever a service restarted, it registered itself again.
The gateway always knew where the service was running.
Stage 5 — Dockerizing the Application
After development is complete, every microservice is packaged as a Docker image.
For example:
payment-service:1.0.0
Each image contains:
- Java Runtime
- Spring Boot application
- Dependencies
- Configuration
- Everything required to run the service
One Docker image represents one microservice.
Stage 6 — Source Code Management
Once development is complete, the developer pushes code.
git add .
git commit
git push
The source code is stored in GitHub or another Git repository.
Stage 7 — CI/CD Pipeline
As soon as the code is pushed, the CI/CD pipeline starts automatically.
Typical pipeline:
Checkout Code
│
Compile
│
Unit Tests
│
Integration Tests
│
Build JAR
│
Build Docker Image
│
Push Docker Image
Tools commonly used:
- GitHub Actions
- Jenkins
- GitLab CI
- Azure DevOps
Stage 8 — Docker Registry
The Docker image is not deployed directly.
Instead, it is stored inside a Docker Registry.
Examples include:
- Docker Hub
- Amazon ECR
- Azure Container Registry
- Google Artifact Registry
- Harbor
Think of a Docker Registry as GitHub for Docker images.
Docker Registry
payment:1.0.0
payment:1.1.0
payment:2.0.0
Whenever Kubernetes needs an application, it pulls the image from the registry.
Stage 9 — Kubernetes Cluster
This is where applications actually run in production.
A Kubernetes cluster consists of multiple servers.
Control Plane
│
----------------------------
Worker Node 1
Worker Node 2
Worker Node 3
Applications do not run directly on servers.
Instead, Kubernetes creates Pods.
Pod
│
Container
│
Spring Boot Application
Each Pod usually contains one Docker container.
Stage 10 — Deploying the Application
Deployment is defined using a Kubernetes Deployment.
Example:
Payment Deployment
Image:
payment-service:1.0.0
Replicas:
3
Kubernetes automatically creates:
Payment Pod 1
Payment Pod 2
Payment Pod 3
If one Pod crashes, Kubernetes immediately creates another one.
Stage 11 — Kubernetes Service
Pods constantly change.
Their IP addresses are not permanent.
Instead of connecting directly to Pods, Kubernetes provides a Service.
Payment Service
│
┌────┴────┐
▼ ▼
Pod 1 Pod 2
The Service provides:
- Stable DNS
- Stable IP
- Internal load balancing
Other microservices communicate only with the Service.
Stage 12 — Spring Cloud Gateway in Kubernetes
One common misconception is that the API Gateway is something special.
It is not.
Spring Cloud Gateway is simply another Spring Boot application.
It follows exactly the same deployment process.
Spring Boot Gateway
│
Docker Image
│
Docker Registry
│
Kubernetes Deployment
│
Gateway Pods
│
Gateway Service
Suppose we deploy three replicas.
Gateway Pod 1
Gateway Pod 2
Gateway Pod 3
The Gateway Service distributes incoming requests among all Gateway Pods.
If one Gateway Pod crashes, Kubernetes automatically starts another one.
Stage 13 — Request Flow in Production
Now let’s see what happens when a user sends a request.
User
│
Internet
│
Cloud Load Balancer
│
Kubernetes Ingress
│
Gateway Service
│
Gateway Pod
│
Payment Service
│
Payment Pod
│
Redis
│
Database
│
Response
│
Gateway
│
User
Every request follows this path.
Stage 14 — Where Does the Database Run?
One of the most common questions is:
“Does MySQL run inside Kubernetes?”
In most enterprise applications:
No.
Databases are usually managed separately.
Examples:
- Amazon RDS
- Azure SQL Database
- Cloud SQL
- Dedicated database servers
Applications connect to the database over the network.
Stage 15 — Where Does Redis Run?
Redis also usually runs outside application Pods.
Organizations either use:
- Managed Redis services
- Redis Cluster
- Dedicated Redis servers
Every microservice connects to Redis whenever caching is required.
Stage 16 — Where Does RabbitMQ or Kafka Run?
Message brokers also run independently.
Payment Service
│
RabbitMQ
│
Notification Service
Large organizations generally deploy RabbitMQ or Kafka as clusters to ensure high availability.
Stage 17 — Monitoring
Production systems require monitoring.
Common metrics include:
- CPU
- Memory
- Response Time
- Request Count
- Error Rate
A common monitoring stack is:
Pods
│
Prometheus
│
Grafana
Developers and SRE teams use Grafana dashboards to observe system health.
Stage 18 — Centralized Logging
Instead of checking logs on every server individually, logs are collected centrally.
Typical logging pipeline:
Application
│
Fluent Bit
│
Elasticsearch
│
Kibana
This allows developers to search logs across every microservice from one interface.
Stage 19 — Secrets Management
Sensitive information such as:
- Database passwords
- API Keys
- JWT Secrets
should never be stored inside the source code.
Instead, organizations use:
- Kubernetes Secrets
- AWS Secrets Manager
- Azure Key Vault
- HashiCorp Vault
Applications securely read these secrets during startup.
Stage 20 — Auto Scaling
Suppose traffic suddenly increases.
Instead of manually starting more servers, Kubernetes automatically scales the application.
Before
Payment Pods
2
↓
After Scaling
Payment Pods
10
Traffic is distributed automatically.
Complete Production Architecture
Users
│
▼
Internet
│
▼
Cloud Load Balancer
│
▼
Kubernetes Ingress
│
▼
Spring Cloud Gateway
│
┌───────────────────┼───────────────────┐
▼ ▼ ▼
Accounts Service Payment Service Order Service
│ │ │
▼ ▼ ▼
Redis RabbitMQ/Kafka Inventory
│
▼
MySQL / PostgreSQL
-----------------------------------------------
CI/CD Pipeline
Developer
│
Git Repository
│
GitHub Actions / Jenkins
│
Build Docker Image
│
Docker Registry
│
Kubernetes Deployment
│
Running Pods
Final Thoughts
Modern enterprise applications are built from many independent components working together.
Each technology has a specific responsibility:
- Spring Boot builds business services.
- API Gateway becomes the single entry point for clients.
- Docker packages applications into portable images.
- Docker Registry stores those images.
- Kubernetes runs and manages containers in production.
- Kubernetes Services provide stable networking and load balancing.
- Redis handles caching.
- RabbitMQ/Kafka enables asynchronous communication.
- Databases persist business data.
- CI/CD automates building and deployment.
- Prometheus and Grafana monitor system health.
- Centralized logging simplifies debugging.
- Secrets management protects sensitive information.
One important thing to remember is that Spring Cloud Gateway is not a special infrastructure component. It is simply another Spring Boot microservice. It is packaged as a Docker image, stored in a Docker Registry, deployed into Kubernetes Pods, exposed through a Kubernetes Service, and scaled just like every other microservice in your system.
Once you understand where each component lives and how they interact, the entire microservices ecosystem becomes much easier to visualize and reason about. This end-to-end mental model is exactly how modern Java applications are developed, deployed, and operated in production.
