JDD 2022: Nicolas Frankel - Chopping the monolith

### Overview In this presentation at JDD 2022, Nicolas Frankel challenges the prevailing industry consensus that microservices are universally superior to monolithic architectures. Drawing from his 17 years of experience across software engineering, architecture, and developer advocacy, Frankel argues that organizations often adopt microservices for the wrong reasons—such as resume building or misguided organizational fixes—without understanding the real problems they are trying to solve. Instead of completely decomposing an application into microservices or following a full migration path like the strangler pattern toward a pure microservices end state, he advocates for an alternative pragmatic architecture: keeping the monolith intact and selectively "chopping" out only the specific components that change frequently.

### Key Topics - **Microservices Definitions and Conway's Law:** Frankel references Martin Fowler's definitions, emphasizing that true microservices require organizing around products rather than short-lived projects with end dates. He also highlights Conway's law and the "reverse Conway's law" (such as AWS's two-pizza teams), noting that layered teams cannot simply adopt microservices purely through technical edicts. - **Evaluating Microservice Benefits:** - *Strong Module Boundaries:* Can be achieved without microservices via Java modules or static analysis rules (e.g., Sonar). - *Technology Diversity:* While polyglot databases make sense due to specialized storage needs, having multiple programming languages across services often satisfies developer ego rather than business needs and leaves a maintenance mess. - *Independent Deployment and Lead Time:* Accelerating implementation and deployment lead time has historically been approached via release trains, rule engines, or microservices, but each comes with its own trade-offs and organizational bottlenecks. - **Identifying Variable vs. Stable Components:** Within any software application, certain parts remain stable (e.g., product catalog or delivery integrations), while others change frequently or arbitrarily due to business promotions, marketing rules, or legal shifts (e.g., pricing engines in e-commerce). - **The "Chopping the Monolith" Architecture:** Rather than breaking everything apart, teams can place an API gateway in front of the monolith and route only the fast-changing endpoint to an isolated service or serverless function.

### Technical Details Frankel demonstrates this architectural approach using a live coding example of an e-commerce store: - **Monolith Implementation:** The original sample application ("ChopShop") is written in Kotlin using Spring Boot, containerized via Docker Compose, backed by an SQL database, and fronted by the Apache APISIX API Gateway (which stores its configuration in etcd). - **Isolating the Pricing Endpoint:** In the initial monolithic state, the application handles catalog browsing, cart operations, and pricing calculation within a single integrated request flow. To chop the component, Frankel first refactors the web layer so that the cart and pricing operations are decoupled into two distinct HTTP routes (version 1.3). - **Offloading via API Gateway to Serverless:** Using Apache APISIX route configuration, requests directed to the pricing route (`/pricing`) are redirected away from the Spring Boot monolith to an independent Azure Function written in JavaScript. Frankel demonstrates that this allows pricing calculation logic to be modified and deployed independently on serverless infrastructure on the fly without redeploying the core monolith.

### Takeaways - Teams should understand their application over time before making major architectural decisions; jumping straight into microservices means not knowing which parts are actually stable and which truly need rapid iteration. - Microservices introduce significant operational complexity; isolating only the few fast-changing, volatile components provides the agility of independent deployment without the burden of maintaining an entirely distributed system.