From Monolith To Microservices

Agile In The Cloud 2016

Owen Rogers - @exortech
Nic Waller - @nic_waller


Owen Rogers / @exortech

Lead Consultant @ Exortech Consulting

Product Owner / Solutions Architect @ EnerNOC

Nic Waller / @nic_waller

Site Reliability Engineer @ EnerNOC

An 8-year Odyssey


characterized by massiveness, total uniformity, rigidity, invulnerability, etc.

The Unintended Monolith

Monolithic Pain

  • Code encumbrance
  • Regression costs
  • Less frequent deployments
  • Inefficient system scalability
  • Less resilient
  • Scales poorly across teams

Why did we end up with a monolith?

New and rapidly evolving system

Make HAL do something else

function askHAL(action) {
	if (isStatusCheck(action) {
		return "Affirmative, Dave.";
	} else if (isTimeToLeave(action)) {
		return "It is dangerous to remain here.";
	return "I'm sorry, Dave. I'm afraid I can't do that.";

Canalizing Design

Path of least resistance


  1. Grow by accumulation or coalescence
  2. Form (a composite whole or a collection of things) by gradual accumulation

Big Ball Of Mud

Rationalizing the monolith

  • Simplicity: one system
  • New domain: where are the context boundaries?
  • Never the right time to split
  • Conway's law
  • Lots of barriers

Barriers to service-orientation

  • Technology
  • Shared code
  • Versioning
  • Deployment
  • Messaging and APIs
  • Security
  • Monitoring and alerting
  • Performance

What's the alternative?

Alternative #1: Split the monolith

But how?

Easy right?

  1. Pull related functionality into a separate module
  2. Package module as a service
  3. Deploy
  4. Profit!

Not so fast, Dave

Alien goo

Test-driven decoupling

Using tests to enforce package structure and drive decoupling effort

Alternative #2: Write new service

Strangler application

Hub and spokes

So, how do we get from

A bit of guidance

Our recommendations

  • Technology
  • Design
  • Integration
  • Deployment & Provisioning
  • Security
  • Monitoring


Choose language / framework that make asynchronous communication easy

The Dark Side of Polyglot


Align service boundaries to bounded contexts / value streams


Share nothing architecture

Mono-repo vs repo-per-service


Default to HTTP RESTful endpoints

Safety through isolation / compartmentalization


Separate build and deploy targets per service

Continuous deployment (where feasible)

Zero-downtime deployment


Common cookbook for service creation

Single-command provisioning

Version production cookbooks

Containerization of runtime environments


Keep it simple - shared secrets

Encapsulate session storage

Private load balancers for back-end services


Standard health-check per service: /_hc


Pitfalls of microservices

  • Danger of distributed monolith
  • More builds, more deploys
  • Cascading failures
  • Service ownership

Future work

  • Containerization
  • Auto scaling
  • Consul
  • Terraform
  • Lambda
  • Blue-green deployment

Thanks! | @exortech | @nic_waller