From Monolith to Microservices and Containerization: A Small Team’s Evolution Journey

Monolith Era

Initially a two‑person team built a single‑page application with front‑back separation, using Nginx to proxy static assets and forwarding API calls to a Java server on port 8080.

API Definition

Versioning: /api/v2 Resource‑centric URLs: /api/contacts or nested like /api/groups/1/contacts/100 Avoid verbs in URLs; enforce naming conventions via code review.

Supported HTTP methods: POST / PUT / DELETE / GET. Note the distinction between PUT (full update) and PATCH (partial update).

Swagger generates documentation for front‑end consumption.

Continuous Integration (CI)

The team introduced integration tests that exercise the API, database, and message queue, running automatically via Jenkins. Test reports are generated and code reviews follow successful execution.

Microservice Era

Service Splitting Principles

Services are separated based on low‑coupling database tables (e.g., user management) or domain‑driven design where a service owns one or several related domain models, possibly with limited data redundancy.

Framework Choice

Building on a Spring Boot monolith, the team adopted Spring Cloud for microservices, using Zuul as a gateway, Eureka for service discovery, Hystrix for circuit breaking, and Feign/Ribbon for inter‑service calls. Performance concerns with Zuul led to exploring Spring Cloud Gateway and alternatives like Kong.

Architecture Transformation

After more than half a year, the monolith was split into over ten microservices, complemented by a Spark‑based BI platform. Data sources expanded from MySQL to include Elasticsearch and Hive.

Automated Deployment

Jenkins builds JARs, which are transferred via a jump host and deployed with Ansible. Full CD was not yet implemented due to resource constraints.

Link Tracing

Open‑source tracing (Spring Cloud Sleuth + Zipkin, Meituan CAT) is used to attach RequestId and TraceId to each request. The IDs are propagated via HTTP headers or message headers (e.g., RabbitMQ) and stored in ThreadLocal for intra‑service correlation.

Operations Monitoring

Before containerization, the stack consisted of telegraf + influxdb + grafana for metrics, with spring‑boot‑actuator and jolokia exposing JVM endpoints.

Containerization Era

Architecture Refactor

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

Spring Cloud and Kubernetes Integration

Running on Red Hat OpenShift (Kubernetes), native services replace Eureka. Configuration disables Eureka registration:

eureka.client.enabled=false

ribbon.eureka.enabled=false

Service URLs are set directly, e.g., foo.ribbon.listofservers=http://foo:8080.

CI Refactor

The CI process now includes Docker image builds, image pushes to Harbor, and a container‑based database migration tool that avoids Flyway’s locking issues during concurrent service startups.

Conclusion

The evolution from monolith to microservices and finally to containerized cloud‑native deployment required close collaboration across development, testing, and operations, illustrating how small teams can adopt divide‑and‑conquer strategies without blindly chasing trends.