From Monolith to Microservices and Containerization: Architecture, CI/CD, and Operations Practices

Monolith Era

Initially the team of two built a single‑page application (SPA) with a front‑end/back‑end split, serving static HTML via Nginx and routing API calls to a Java server on port 8080.

API Definition

Versioning is placed after /api/, e.g., /api/v2.

Resources are expressed in plural, e.g., /api/contacts or nested like /api/groups/1/contacts/100.

URLs avoid verbs; naming consistency is enforced during code review.

Supported HTTP methods: POST / PUT / DELETE / GET. The team treats PUT as a partial update by ignoring empty fields, which can cause subtle bugs.

Swagger is used to generate documentation for front‑end developers.

Continuous Integration (CI)

The team introduced a CI pipeline early, using Jenkins to run integration tests that exercise APIs, databases, and message queues, providing high coverage and realistic test scenarios. Tests are triggered on Gerrit commits, and successful builds generate reports before code review.

Microservice Era

Service Splitting Principles

Services are separated based on low data coupling (e.g., user management) or domain‑driven design (DDD) where each service owns related domain models, often using a rich (active) model rather than anemic POJOs.

Framework Choice

Spring Boot evolved to Spring Cloud; the team uses Zuul as a gateway, Eureka for service discovery, Hystrix for circuit breaking, and Feign/Ribbon for inter‑service calls. They note performance and extensibility limits of Zuul and consider Spring Cloud Gateway or Kong as alternatives.

Architecture Refactoring

Over half a year the monolith was broken into more than ten microservices, complemented by a Spark‑based BI platform (OLAP) and multiple data sources (MySQL, ES, Hive).

Automated Deployment

Jenkins builds JARs, which are transferred via a jump host and deployed with Ansible. The approach is simple but relies on thorough testing before deployment.

Link Tracing

The team implements lightweight tracing by injecting RequestId and TraceId into HTTP headers (or message headers for MQ). ThreadLocal stores the context within a service, and downstream services propagate it, enabling rapid root‑cause analysis.

Operations Monitoring

Before containerization they used Telegraf + InfluxDB + Grafana for metrics, and Spring Boot Actuator with Jolokia for JVM exposure. The stack required only configuration, no code changes.

Containerization Era

Architecture Refactoring

Each service now has a Dockerfile; CI pipelines build Docker images and push them to Harbor. Database upgrade tools are containerized and run as one‑off Docker containers.

Spring Cloud & Kubernetes Integration

Running on Red Hat OpenShift (Kubernetes), services use native K8s Service objects for discovery, replacing Eureka. For local development Eureka remains enabled, but production disables it via configuration:

eureka.client.enabled = false
ribbon.eureka.enabled = false
foo.ribbon.listofservers = http://foo:8080

CI Refactoring

CI now builds Docker images, pushes them to Harbor, and runs database migrations with Flyway‑style scripts packaged in containers. To avoid concurrent migrations, each service runs its own migration container as a single‑process task.

Conclusion

The evolution demonstrates that architecture changes must be driven by business complexity, require close collaboration across development, testing, and operations, and that small teams can adopt microservices and containerization responsibly by focusing on incremental improvements rather than chasing every new trend.