Many of us would love to embrace microservices in our day-to-day work. But most of us don’t have the opportunity to start over with a pure greenfield effort. We have to understand how to refactor our existing monolithic applications toward microservices. Practical steps include building new features as microservices, leveraging anti-corruption layers, strangling the monolith.

In this presentation we’ll go light on the theory and walk through the actual process of turning a strawman monolith into a family of well-factored microservices.

The Monolito brothers started their dream business of running their own chain of pizza parlors. They’ve expanded their business to include 20 locations across a large metro area, and they want to expand to other cities and states. Their original careers were as software engineers, so naturally they built their own systems to manage their business. These systems included:

• an online ordering system for customers to place pizza orders via the web

• a dispatch system to send these orders to the correct store locations

• a menu management system to keep up with all of the allowable pizza combinations, toppings, etc.

As they’ve grown their business, they’ve felt pressure from their customers to add additional features that “the big pizza chains” have, such as:

• managing multiple customer addresses

• reordering past orders

• managing coupons

• tracking the status of an order

• conducting business via mobile devices

Their current system is very monolithic and is deployed at every store! As their software development team has grown in size to meet their customers' demands, they’ve become paralyzed by the difficulty of adding new features to an ever-growing codebase that must be redeployed to every Monolito’s Pizza location with every change.

Recently the Monolito brothers learned about the promise of microservices architectures enabling continuous delivery of business value. They’ve contracted our team of consultants to help decompose their monolith so that they can get back on track.

The refactoring can be traced through a series of tagged commits:

monolith-v1

version 1 of the monolitos monolith

refactoring-v1

Independent Deployability of Store and Site

refactoring-v2

Finish Up Store Order Details Feature

refactoring-v3

Decouple the Contract between Site and Store

refactoring-v4

Implement Order Tracking Updates as Microservices

refactoring-v5

Separate Store UI from Store Service

refactoring-v6

Integrate Store Microservices via Spring Cloud

The refactoring is documented here in detail.

While these subtopics deserve consideration, in the interest of fitting in to the allotted time (90 minutes), I simply couldn’t include everything. I also wanted to focus on the decomposition of the business functionality, and not on the tedium of technology stack migration:

• J2EE/Java EE to Spring Migration

• Classic Spring to Spring Boot Migration

• Polyglot Persistence

• Distributed Transactions, Event Sourcing/CQRS

• Fancy, modern, Javascript-y web UI’s - I am not a UI developer.

• Separating the projects into individual Gradle builds for maintenance by separate teams (only for expediency!).

• Securing the interactions between various microservices (for now!).

Here is a list of resources that you can review before attending the session to provide useful context.