Breaking Up Is Hard To Do From Monolith to Microservices

Jake Stevenson Technical Director — Improving Enterprises Systems Architecture, Software Development, Team Mentorship, DevOps Automation Theater Major

Monolithic Application Architecture Self-Contained and Independent from other applications Usually layered UI Business Logic Data

Microservices Architecture Small, Independant Applications Integration Logic Ties it Together Message Brokers RESTFull Services Presentation Layer Needs to Cross Applications

What's Wrong with Monoliths? Risk when Refactoring and Changing Deployment Time And Risk Hard to scale your Team IDE slowdown Friction when Updating Technologies

Story Time!

Quick look at code

Early times Had an idea and executed with agility YAGNI Smooth to Launch

Text CleanAir4You.com CleanAir4You.com Architecture CleanAir4You.com Monolith Organized By Areas

Tour the Monolith Divided into areas loosely related to bounded contexts Services for those context called directly from the controllers Unit tests (not shown) are also monolithic

Pain Starts New Developers Hired Merge conflicts start hitting Regression mistakes hurt Deployment brings the whole site down

Story Time!

Time to look at code

Developer learns about messaging patterns Plans to break up the application start CQRS ideas introduced (simple bus) Solution size explodes -- Seperate projects for bounded contexts

Messaging Pattern Simple Approach — Events vs Commands Events inform that something happened Commands tell someone to do something Simple bus to wire up handlers to these

More Growth - More Pain Hired More team members -- split into multiple teams Backlog growing faster -- success makes business want more Still more code conflicts More communication needs Deployment more painfull Longer builds Longer unit testsl

Time to Bite The Bullet Ensure Bounded Contexts are Sound Decide How to communicate -- APIs, Messaging and Contracts Write a new Solution Generate a new Database -- Migrate data

Ensuring Sound Bounded Contexts Who owns the data? Overlaps in ownership cause consistency concerns

Communications Patterns Shared Database Tables RESTFull/SOAP APIs Message Bus

Solutions and Builds One solution per micro service Nuget to distribute contracts

Who owns the Data Shared is easier to start, but will bite you Transactions across bounded contexts suck Eventual Consistency is Key

Strategies for Eventual Consistency Identify what’s really needed for the context of the action Do you care if they’ve billed before you create the account? Do you care if the account is created before you’ve billed? Is it acceptable to go back and let them know the bill failed?

Code Demo

Text CleanAir4You.com CleanAir4You.com Architecture CleanAir4You.com Now With Microservices!

Rabbit and NServicebus

Downfalls Deployment/IT complexity Source code explosion Data scatter -- Reporting considered it's own microservice Debugging Intersections

And now for the hard stuff!

What about the UI?

Code Demo

Text CleanAir4You.com CleanAir4You.com Architecture CleanAir4You.com With UI Composition