OpenShift Microservices Architecture

Learn how to design, deploy, and operate Spring Boot microservices on OpenShift. Understand microservice architecture, service communication, API Gateway, service discovery, resilience, scalability, observability, and enterprise best practices.

Introduction

Enterprise applications have evolved significantly over the last decade.

Earlier, organizations built Monolithic Applications, where every business function was packaged into a single deployable application.

Although simple initially, monoliths become difficult to:

Scale
Maintain
Deploy
Test
Upgrade

Modern cloud-native applications instead use Microservices Architecture, where each business capability is implemented as an independent Spring Boot service.

OpenShift provides an ideal platform for deploying, scaling, securing, and managing these microservices.

Learning Objectives

By the end of this article, you will understand:

Monolith vs Microservices
OpenShift Microservices Architecture
API Gateway
Service Discovery
Database per Service
Inter-Service Communication
Resilience Patterns
Observability
Enterprise Best Practices

Monolithic Architecture

flowchart LR
    A[Client]
    B[Monolithic Application]
    C[(Single Database)]

    A --> B
    B --> C

Characteristics

Single deployment
Shared database
Tight coupling
Difficult scaling
Large release cycles

Microservices Architecture

flowchart LR
    A[Client]
    B[API Gateway]

    C[Customer Service]
    D[Payment Service]
    E[Order Service]
    F[Notification Service]

    G[(Customer DB)]
    H[(Payment DB)]
    I[(Order DB)]

    A --> B

    B --> C
    B --> D
    B --> E

    D --> F

    C --> G
    D --> H
    E --> I

Each service owns its business capability.

Why Microservices?

Benefits include:

Independent deployments
Independent scaling
Fault isolation
Faster releases
Technology flexibility
Better team ownership

OpenShift Architecture

flowchart TD
    A[Internet]
    B[OpenShift Router]
    C[API Gateway]

    D[Customer Service]
    E[Payment Service]
    F[Order Service]
    G[Inventory Service]
    H[Notification Service]

    I[(Customer DB)]
    J[(Payment DB)]
    K[(Order DB)]

    A --> B
    B --> C

    C --> D
    C --> E
    C --> F

    E --> G
    E --> H

    D --> I
    E --> J
    F --> K

Typical Spring Boot Services

Service	Responsibility
Customer Service	Customer Management
Payment Service	Payments
Order Service	Orders
Inventory Service	Stock
Notification Service	Email & SMS
Fraud Service	Fraud Detection
Gateway	Request Routing

Request Flow

sequenceDiagram
    participant Client
    participant Gateway
    participant Payment
    participant Inventory
    participant Notification

    Client->>Gateway: Create Order

    Gateway->>Payment: Payment Request

    Payment->>Inventory: Reserve Product

    Inventory-->>Payment: Reserved

    Payment->>Notification: Send Email

    Notification-->>Client: Confirmation

API Gateway

The API Gateway acts as the single entry point.

Responsibilities:

Authentication
Authorization
Routing
Rate Limiting
SSL Termination
Logging
Monitoring

API Gateway Architecture

flowchart LR
    A[Client]
    B[API Gateway]

    C[Customer Service]
    D[Payment Service]
    E[Order Service]

    A --> B

    B --> C
    B --> D
    B --> E

Service Discovery

Each Spring Boot application is exposed as an OpenShift Service.

Example

payment-service

customer-service

inventory-service

Applications communicate using service names.

Service Communication

flowchart LR
    A[Payment Service]
    B[Customer Service]
    C[Inventory Service]
    D[Notification Service]

    A --> B
    A --> C
    A --> D

Communication options:

REST
gRPC
Kafka
AMQP

Database per Service

Each microservice owns its own database.

flowchart LR
    A[Customer Service]
    B[(Customer DB)]

    C[Payment Service]
    D[(Payment DB)]

    E[Order Service]
    F[(Order DB)]

    A --> B
    C --> D
    E --> F

Benefits:

Loose coupling
Independent schema evolution
Better scalability

Synchronous Communication

flowchart LR
    A[Payment Service]
    B[Customer Service]

    A --> B

Uses:

REST
gRPC

Asynchronous Communication

flowchart LR
    A[Payment Service]
    B[Kafka]
    C[Notification Service]

    A --> B
    B --> C

Benefits:

Loose coupling
High throughput
Better resilience

Resilience Architecture

flowchart LR
    A[Payment Service]
    B[Circuit Breaker]
    C[Fraud Service]

    A --> B
    B --> C

Common resilience patterns:

Retry
Timeout
Circuit Breaker
Bulkhead
Fallback

Scaling

Each service scales independently.

flowchart LR
    A[Payment Service]

    B[Pod 1]
    C[Pod 2]
    D[Pod 3]

    A --> B
    A --> C
    A --> D

Horizontal Pod Autoscaler can increase replicas during high traffic.

Configuration Management

Store configuration using:

ConfigMaps
Secrets

Never hardcode configuration.

Security

Use:

OAuth2
JWT
TLS
Network Policies
RBAC
Service Accounts

Observability

Enterprise applications combine:

Logs
Metrics
Traces

flowchart LR
    A[Spring Boot Services]

    B[Logs]
    C[Metrics]
    D[Traces]

    E[Operations Dashboard]

    A --> B
    A --> C
    A --> D

    B --> E
    C --> E
    D --> E

Banking Example

flowchart TD
    A[Customer]

    B[API Gateway]

    C[Account Service]
    D[Payment Service]
    E[Fraud Service]
    F[Notification Service]

    G[(Accounts DB)]
    H[(Payments DB)]

    A --> B

    B --> C
    B --> D

    D --> E
    D --> F

    C --> G
    D --> H

Each service is independently deployable and scalable.

Enterprise OpenShift Platform

flowchart TD
    A[Internet]

    B[OpenShift Router]

    C[API Gateway]

    D[Spring Boot Microservices]

    E[Kafka]

    F[Prometheus]

    G[Loki]

    H[Jaeger]

    I[Grafana]

    A --> B
    B --> C
    C --> D

    D --> E
    D --> F
    D --> G
    D --> H

    F --> I
    G --> I
    H --> I

Useful Commands

View Pods

oc get pods

View Services

oc get svc

View Routes

oc get routes

View Deployments

oc get deployment

Scale Service

oc scale deployment payment-service --replicas=5

Common Problems

Tight Coupling

Avoid direct database sharing between services.

Large Services

Keep each service focused on a single business capability.

Synchronous Chains

Too many REST calls increase latency.

Prefer asynchronous messaging where appropriate.

Shared Database

Never allow multiple services to modify the same schema.

Production Best Practices

One business capability per service.
One database per service.
Deploy independently.
Use API Gateway.
Prefer asynchronous messaging for long-running workflows.
Use centralized logging.
Enable distributed tracing.
Monitor every service.
Secure service communication.
Automate deployments using GitOps.

Common Mistakes

❌ Creating hundreds of tiny services.

❌ Sharing one database.

❌ Hardcoding service URLs.

❌ Ignoring resilience patterns.

❌ Deploying without monitoring.

❌ No API Gateway.

Advantages

Independent deployment
Independent scaling
Better fault isolation
Faster development
Cloud-native architecture
High availability
Improved resilience
Enterprise scalability

Summary

Microservices architecture is the foundation of modern cloud-native applications on OpenShift.

Key takeaways:

Split applications into independently deployable Spring Boot services.
Use OpenShift Services and Routes for communication.
Introduce an API Gateway for centralized request handling.
Keep databases isolated per service.
Combine synchronous and asynchronous communication appropriately.
Add observability, resilience, and automated deployment pipelines for production-ready systems.

Interview Questions

What is Microservices Architecture?
What are the advantages of microservices over monoliths?
Why should each microservice own its database?
What is the role of an API Gateway?
How do services discover each other in OpenShift?
When should REST be preferred over Kafka?
What resilience patterns are commonly used?
How do you scale a single microservice?
What observability components are required in production?
What are the best practices for designing Spring Boot microservices on OpenShift?