Microservices — Why (and How) We Are Breaking Apart Our Monolith

Our main product — an information system for mid-sized companies — is a classic monolith. One WAR, one GlassFish, one Oracle database. It works, clients are happy. So why are we touching it? Because every new feature takes longer, deploying a single change requires releasing the entire application, and the team has grown. Microservices look like the way out.

Why Not “Rewrite Everything”¶

Our first impulse was to throw away the monolith. Fortunately, a colleague pointed us to Martin Fowler’s article on the Strangler Pattern — gradually replacing parts of the monolith with new services. Evolution, not revolution.

We defined bounded contexts (DDD terminology): invoicing, user management, notifications, reporting. We started with notifications — the smallest risk, a clear scope.

Notification Service — Our First Microservice¶

The new notification service: a standalone Spring Boot application (yes, we moved away from Java EE for microservices). REST API, templates in the database, asynchronous delivery via a queue. Stack: Spring Boot 1.2, embedded Tomcat, PostgreSQL, RabbitMQ. The entire service is ~3,000 lines of code and deploys independently.

REST API — The Contract Is Law¶

We define APIs in Swagger. Specs live in git, changes go through review. Client code is generated from Swagger. Versioning: /api/v1/notifications. REST for synchronous operations, RabbitMQ for asynchronous events.

Deployment — Docker in Production (Almost)¶

Docker 1.5 is more stable. Docker Compose for local development. Orchestration? Not yet. I’ve heard about Kubernetes from Google — it looks interesting, but for 3 services it’s overkill. One server = one service, nginx as a load balancer. Primitive, but functional.

What We Underestimated¶

Distributed logging. With five services you need centralized logging. ELK stack + correlation IDs — it took two sprints.

Network failures. An HTTP call over the network is not reliable. Circuit breaker (Hystrix from Netflix) is a necessity. Our first production incident was a timeout cascading across the entire system.

Testing. Unit tests are straightforward. Integration tests across services are a nightmare. Contract testing (Pact) helps, but end-to-end tests across 4 services are fragile.

Is It Worth It?¶

After one year: 4 microservices and a reduced monolith. Deploying the notification service takes 2 minutes. We deliver new features 3× faster. But the overhead is real — more infrastructure, monitoring, and complexity. For a team of fewer than 5 developers I would not recommend microservices.

Evolution, Not Revolution¶

Microservices are not a silver bullet. You trade complexity inside the application for complexity between applications. But if the monolith is slowing you down, gradual decomposition makes sense. Start with a small, peripheral service.