اجرا: کانتینر/Kubernetes/Service Mesh و سرورهای legacy جاواRuntime: Containers/Kubernetes/Service Mesh & Legacy Java App Servers

So far we've talked about what code you write; now comes the hard part: your code has to run somewhere. That same Spring Boot service that comes up on your laptop with mvn spring-boot:run must, in production, stay alive next to a hundred other services, on machines you'll never see, through a thousand restarts and rollouts, on a network that can drop at any moment. This chapter is about that layer: the runtime.

And here's a truth many courses hide: the real world has two halves. One half is "modern" — containers, Kubernetes, service mesh, the 12-factor mindset. The other half is "legacy" — WebLogic, WebSphere, JBoss/WildFly that have run banks, insurers, and telecoms for twenty years and will run them tomorrow too. A real senior knows both halves, because the real senior job is often exactly this: bridging the two worlds.

0. Two runtime worlds, one engineer

The fundamental difference: in the app-server model, the platform is inside the application (the server provides everything and your code is its guest). In the cloud-native model, the application is a plain process and the platform is outside it (Kubernetes builds a fence around your process). This inversion of responsibility is the whole story.

1. The 12-Factor App: constitution of a cloud-native service

Before any tool, you need a mindset. The Twelve-Factor App manifesto (written by Heroku engineers) has twelve principles that, a decade later, are still a great litmus test for "is this service container-ready?" The most important for us:

• Config in the environment, not in code. DB password, another service's address, a feature flag — none should live inside the jar. They come from environment variables or mounted files. Why? Because one single artifact should run in dev, staging, and prod without a rebuild.
• Stateless processes. Nothing important should live in the process's local memory or local disk, because that process can be killed at any moment. State goes to the database, Redis, or object storage.
• Port binding. The service serves HTTP itself (Spring Boot with embedded Tomcat binds a port) — no need to deploy inside an external app server.
• Disposability. Start fast, shut down fast and cleanly (graceful shutdown). This is exactly what Kubernetes leans on during a rollout.
• Logs as event streams. Write logs to stdout, not to a file. Collecting and rotating logs is the platform's job.

2. Containerizing Spring Boot

2.1 What a container is (from scratch)

An image is a read-only bundle of filesystem + a run command. A container is a running instance of that image — a process on a Linux host, walled off by namespaces (isolating what it sees) and cgroups (limiting its resources) so it thinks it's the only machine. A container is not a VM; it shares the host kernel, which is why it's light and fast.

2.2 The classic mistake: don't COPY the fat jar directly

Everyone's first Dockerfile looks like this:

FROM eclipse-temurin:21-jre
COPY target/app.jar /app.jar
ENTRYPOINT ["java", "-jar", "/app.jar"]

It works, but it's inefficient. Spring Boot builds a fat jar (uber jar) where everything — your code + tens of MB of dependencies — is in one file. With every small code change, that entire layer is rebuilt, pushed, and pulled, even if the dependencies didn't change one bit. On a team doing dozens of deploys a day, that's wasted bandwidth and slow CI.

2.3 The right way #1: layered jars

Spring Boot can slice the jar into "layers" ordered by rate of change: dependencies (rarely change) in one layer, snapshots in another, and your own code (changes often) in the last. The layertools tooling extracts these, and in a multi-stage Dockerfile each layer becomes a separate COPY — so Docker can cache the rarely-changing layers:

# ---- Stage 1: extract layers ----
FROM eclipse-temurin:21-jre AS builder
WORKDIR /app
COPY target/*.jar app.jar
RUN java -Djarmode=tools -jar app.jar extract --layers --destination extracted

# ---- Stage 2: final image ----
FROM eclipse-temurin:21-jre
WORKDIR /app
# layers from least- to most-changing; order matters for caching
COPY --from=builder /app/extracted/dependencies/ ./
COPY --from=builder /app/extracted/spring-boot-loader/ ./
COPY --from=builder /app/extracted/snapshot-dependencies/ ./
COPY --from=builder /app/extracted/application/ ./
ENTRYPOINT ["java", "-jar", "app.jar"]

2.4 The right way #2: buildpacks (no Dockerfile)

If you'd rather not maintain a Dockerfile at all, Spring Boot has built-in support for Cloud Native Buildpacks (the Paketo implementation). One command, no Dockerfile:

# Maven
./mvnw spring-boot:build-image -Dspring-boot.build-image.imageName=myorg/order-service:1.4.0

# Gradle
./gradlew bootBuildImage --imageName=myorg/order-service:1.4.0

The buildpack picks a suitable JDK, understands the layered jar, produces an optimized OCI-standard image, and even generates an SBOM (software bill of materials). You set the Java version through a buildpack environment variable:

./gradlew bootBuildImage \
  --imageName=myorg/order-service:1.4.0 \
  --builder=paketobuildpacks/builder-jammy-base
# JVM version via env: BP_JVM_VERSION=21

2.5 The big trap: the JVM inside a container

JAVA_TOOL_OPTIONS="-XX:MaxRAMPercentage=75.0 -XX:InitialRAMPercentage=50.0"

The CPU point matters too: the JVM sizes GC threads, the ForkJoin pool, etc. from availableProcessors(). If you set the container CPU limit to, say, 500m (half a core), modern JDKs round this correctly, but at boundary settings you should still test. Don't go below a full core unless the service really is low-traffic.

3. Kubernetes basics for a service

Kubernetes (k8s) is a distributed operating system for containers. You tell it the desired state ("I want 4 healthy instances of this image running at all times") and it, through an endless reconciliation loop, keeps reality converging toward that state. If a pod dies, it creates a new one; that's self-healing.

3.1 The fundamental objects

• Pod: the smallest deployable unit; one or more containers sharing network and storage. Usually one main container (your service) + maybe a sidecar.
• Deployment: manages a set of identical, stateless pods — replica count, update strategy, and rollback.
• Service: a stable name and virtual IP for reaching those pods (whose IPs constantly change). Internal load-balancing across healthy pods.
• Ingress (or Gateway API): the entry gate from the outside world; HTTP routing by host/path to internal Services + TLS handling.

Topology of a typical service on k8s (Persian: from user to database; English: from user to database):

flowchart LR
  User([User]) --> Ingress[Ingress / Gateway]
  Ingress --> Svc[Service: order-svc]
  Svc --> P1[Pod 1]
  Svc --> P2[Pod 2]
  Svc --> P3[Pod 3]
  P1 --> DB[(PostgreSQL)]
  P2 --> DB
  P3 --> DB
  P1 -. reads .-> CM[ConfigMap]
  P1 -. reads .-> SEC[Secret]

3.2 A real Deployment

apiVersion: apps/v1
kind: Deployment
metadata:
  name: order-service
spec:
  replicas: 3
  selector:
    matchLabels: { app: order-service }
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 0     # never drop capacity during rollout
      maxSurge: 1           # bring up one extra temporarily
  template:
    metadata:
      labels: { app: order-service }
    spec:
      containers:
        - name: app
          image: myorg/order-service:1.4.0
          ports:
            - containerPort: 8080
          resources:
            requests: { cpu: "500m", memory: "512Mi" }
            limits:   { memory: "768Mi" }   # no CPU limit (explained below)
          envFrom:
            - configMapRef: { name: order-config }
            - secretRef:    { name: order-secrets }

3.3 Probes: the brain of self-healing, and where Actuator shines

Kubernetes has three probe types, and their difference is a classic interview question:

Spring Boot Actuator is built exactly for this, with separate liveness and readiness endpoints:

# application.yml
management:
  endpoint:
    health:
      probes:
        enabled: true       # enables /actuator/health/liveness and /readiness
  health:
    livenessstate:
      enabled: true
    readinessstate:
      enabled: true

# in the Deployment
          startupProbe:
            httpGet: { path: /actuator/health/readiness, port: 8080 }
            failureThreshold: 30
            periodSeconds: 5      # up to 150s to start
          readinessProbe:
            httpGet: { path: /actuator/health/readiness, port: 8080 }
            periodSeconds: 5
          livenessProbe:
            httpGet: { path: /actuator/health/liveness, port: 8080 }
            periodSeconds: 10

3.4 ConfigMap and Secret

Per 12-factor, config comes from the environment. In k8s that's a ConfigMap (non-sensitive settings) and a Secret (credentials).

apiVersion: v1
kind: ConfigMap
metadata: { name: order-config }
data:
  SPRING_PROFILES_ACTIVE: "prod"
  SPRING_DATASOURCE_URL: "jdbc:postgresql://pg-primary:5432/orders"
---
apiVersion: v1
kind: Secret
metadata: { name: order-secrets }
type: Opaque
stringData:
  SPRING_DATASOURCE_PASSWORD: "s3cr3t-from-vault"

Spring Boot automatically maps SPRING_DATASOURCE_URL to the property spring.datasource.url (relaxed binding). So without a single extra line of code, config is injected from the environment.

3.5 HPA: automatic scaling

The Horizontal Pod Autoscaler raises and lowers replica count based on a metric (CPU, memory, or a custom metric like Kafka queue length). Today's standard API is autoscaling/v2 (the v1 version is deprecated and CPU-only).

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata: { name: order-service }
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: order-service
  minReplicas: 3
  maxReplicas: 20
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 70   # relative to the CPU request
  behavior:
    scaleDown:
      stabilizationWindowSeconds: 300   # default: wait 5 min before scaling down

4. Service Mesh: when the network itself gets smart

4.1 The problem the mesh solves

Suppose you have a hundred services. You want all traffic between them encrypted (mTLS), all of them to have retries, timeouts, and circuit breakers, all to emit metrics and traces, and you want to precisely control traffic for canaries. If you put all of this in each service's code, you've repeated the same logic a hundred times (and in different languages). A service mesh pulls these concerns out of the code and hands them to the network layer.

4.2 Two architectures: sidecar vs. ambient

The classic model (sidecar): next to each service pod, a small proxy (usually Envoy) is injected, and all of that pod's inbound and outbound traffic flows through it. mTLS, retries, metrics — all in that sidecar. Powerful, but it costs: an extra container per pod, more CPU/RAM, and an added hop of latency.

The new model (ambient / sidecar-less): instead of a proxy per pod, Istio in ambient mode splits the work into two layers:

• ztunnel (one agent per node, not per pod): Layer 4 — mTLS, identity, basic telemetry. Lightweight.
• waypoint proxy (optional, only when you need Layer-7 policy): HTTP routing, smart load-balancing, advanced policies.

Flow of an mTLS request in the mesh (Persian: automatic encryption between two services; English: automatic encryption between two services):

sequenceDiagram
  participant A as order-service
  participant PA as Proxy/ztunnel (source)
  participant PB as Proxy/ztunnel (dest)
  participant B as payment-service
  A->>PA: plain HTTP (localhost)
  PA->>PB: mTLS / HBONE (encrypted, identity-verified)
  Note over PA,PB: certificates auto-issued & rotated
  PB->>B: plain HTTP (localhost)
  B-->>PB: response
  PB-->>PA: mTLS response
  PA-->>A: plain HTTP

The key point: the order-service code thinks it's making plain HTTP to localhost. mTLS, certificate issuance, and rotation all happen outside the code. That's separation of concerns.

4.3 Traffic management: canary in a few lines of YAML

The mesh's real power is precise traffic control. With Istio, two core concepts: DestinationRule (defining subsets) and VirtualService (the traffic-splitting rule):

apiVersion: networking.istio.io/v1
kind: DestinationRule
metadata: { name: order-service }
spec:
  host: order-service
  subsets:
    - name: v1
      labels: { version: v1 }
    - name: v2
      labels: { version: v2 }
---
apiVersion: networking.istio.io/v1
kind: VirtualService
metadata: { name: order-service }
spec:
  hosts: [ order-service ]
  http:
    - route:
        - destination: { host: order-service, subset: v1 }
          weight: 90        # 90% of traffic to the old version
        - destination: { host: order-service, subset: v2 }
          weight: 10        # 10% to the new version (canary)

By changing these weights (10 → 30 → 60 → 100) you gradually shift traffic to the new version, and if error metrics rise, you flip it back instantly — no redeploy, just a change to the mesh rule.

5. Deployment strategies: rolling, blue-green, canary

State machine of a canary (Persian: gradual traffic ramp with a metric gate; English: gradual traffic ramp with a metric gate):

stateDiagram-v2
  [*] --> Deploy_v2_10pct
  Deploy_v2_10pct --> Analyze: watch error rate & latency
  Analyze --> Ramp_50pct: metrics healthy
  Analyze --> Rollback: metrics bad
  Ramp_50pct --> Analyze2: watch again
  Analyze2 --> Promote_100pct: healthy
  Analyze2 --> Rollback: bad
  Promote_100pct --> [*]
  Rollback --> [*]

6. The other half of the world: legacy Java EE servers

Now we return from the shiny food court to the grand old restaurant. Because here's reality: a huge portion of the planet's business logic still runs on these — banks, insurers, telecoms, government. If you're becoming a senior, sooner or later you'll face WebLogic or WebSphere or JBoss. And not knowing them means going mute in that meeting.

6.1 The core idea of an app server

An application server is a heavy runtime that provides a set of enterprise services out of the box and deploys and manages your applications (as WAR or EAR files) inside itself. These services are the same ones injected into a process as libraries in the Spring Boot world:

• JNDI — a naming directory to find resources (datasources, queues, beans) by name.
• Managed datasource + connection pool — the server creates and manages the database connection pool.
• EJB — transactional server-side components.
• JMS / MDB — messaging and managed message-driven consumers.
• JTA — distributed two-phase (XA) transactions across multiple resources.
• Clustering / HA / session replication — multiple server instances forming a cluster and replicating state.

6.2 JNDI: the server's phone book

JNDI (Java Naming and Directory Interface) is an API for "name → object." Instead of hard-coding the DB password in code, you tell the server "create a datasource named jdbc/OrdersDS" and in code you just call it by name:

// classic JNDI lookup (Java EE)
InitialContext ctx = new InitialContext();
DataSource ds = (DataSource) ctx.lookup("java:comp/env/jdbc/OrdersDS");
try (Connection c = ds.getConnection()) {
    // ... use a connection from the server-managed pool
}

The benefit: config (address, password, pool size) lives in the server console, not in the artifact. The same WAR runs unchanged in dev and prod because each server has its own JNDI. (This is exactly the 12-factor idea, only twenty years earlier and in server-centric form.) In Spring Boot, the equivalent is defining spring.datasource.* from the environment.

6.3 Managed datasource and connection pool

Opening a TCP connection to a database is expensive (several round-trips, authentication). A connection pool keeps a set of pre-opened connections and lends them to requests. In an app server this pool is managed and configured in the console: min/max size, timeout, and most importantly a validation query that checks a connection's health before use.

Here's a dual-dialect SQL difference that matters in configuring exactly this pool — the connection-validation query:

-- PostgreSQL: no dummy table needed
SELECT 1;

-- Oracle: you must read from the system DUAL table
SELECT 1 FROM DUAL;

6.4 EJB, JMS, and MDB

EJB (Enterprise JavaBeans) were server-side components for which the server automatically managed transactions, security, pooling, and concurrency. A simple Stateless Session Bean:

@Stateless
public class OrderServiceBean {
    @PersistenceContext
    private EntityManager em;

    @TransactionAttribute(TransactionAttributeType.REQUIRED)
    public void placeOrder(Order o) {
        em.persist(o);      // transaction managed by the container (CMT)
    }
}

That @TransactionAttribute means "the container opens and commits/rolls back the transaction itself" — that's Container-Managed Transactions. This is exactly what @Transactional does in Spring; Spring borrowed the idea and simplified it.

JMS is the queue/messaging standard, and an MDB (Message-Driven Bean) is a bean that automatically consumes messages from a queue — the conceptual ancestor of today's @KafkaListener:

@MessageDriven(activationConfig = {
  @ActivationConfigProperty(propertyName = "destination",
                            propertyValue = "jms/OrderQueue")
})
public class OrderConsumer implements MessageListener {
    public void onMessage(Message msg) {
        // process the message; transaction and thread provided by the container
    }
}

6.5 The hierarchical classloading model — a source of pain

Spring Boot eliminates this complexity with a different philosophy: one process, one (nearly) flat classloader, one application. There's no multi-WAR isolation and no shared classloader; instead of "many apps in one server," we have "one app in one container." The entire class of classloader problems vanishes.

6.6 Clustering, HA, and session replication

App servers can form a cluster: several server instances working together. The most important classic capability is HTTP session replication: if a user logged in on server 1 and state sits in the HttpSession, the server replicates that session to server 2, so if server 1 dies, the user is moved to server 2 without being logged out (failover). In an era when sticky sessions and in-memory state were normal, this was vital.

6.7 A field guide: which server, where, in what shape

7. The migration path: from app server to Spring Boot

Suppose you have a ten-year-old EAR on WebLogic and must modernize it. The "big-bang rewrite" approach almost always fails — it takes years, the business doesn't pause meanwhile, and on switch day everything breaks at once. The right pattern is the Strangler Fig.

The strangler pattern (Persian: gradual capability migration behind a gateway; English: gradual capability migration behind a gateway):

flowchart LR
  Client([Client]) --> GW[API Gateway / Facade]
  GW -->|legacy paths| WLS[WebLogic EAR - monolith]
  GW -->|/orders migrated| NewOrder[Spring Boot: order-service]
  GW -->|/users migrated| NewUser[Spring Boot: user-service]
  WLS --> ODB[(Oracle DB)]
  NewOrder --> ODB
  NewUser --> ODB

Practical steps of a migration that works in real projects:

1. Put a facade in place. A gateway in front of the monolith so you can move traffic path by path without the client noticing.
2. Move the lowest-risk capability first. Pick a peripheral, low-dependency module (not the transactional core) so the team learns the CI/CD, observability, and deploy path.
3. Map the EE replacements. JNDI datasource → spring.datasource; CMT → @Transactional; MDB → @JmsListener; JAX-RS → Spring MVC/WebFlux; stateless EJB → @Service.
4. Watch out for distributed transactions (XA/JTA). This is the hardest part (see below).
5. Share the database at first, split later. Usually both (old and new) connect to one DB for a while; database splitting is a separate, later step.
6. Turn the migrated capability off in the legacy so no dead code remains.

8. Wrap-up