'

From Monolith To Microservices

Agile In The Cloud 2016

Owen Rogers - @exortech
Nic Waller - @nic_waller

http://www.exortech.com/presentations/monolith_to_microservices/

Hi!

Owen Rogers / @exortech

Lead Consultant @ Exortech Consulting

(formerly) Product Owner / Solutions Architect @ EnerNOC

Founder @ Carbon Choices

Nic Waller / @nic_waller

Site Reliability Engineer @ EnerNOC

An 8-year Odyssey

mon·o·lith·ic

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. You must leave within two days.";
	}
	return "I'm sorry, Dave. I'm afraid I can't do that.";
}
							
						

Canalizing Design

http://michaelfeathers.typepad.com/michael_feathers_blog/2009/06/canalizing-design.html

Path of least resistance

ac·crete

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

Big Ball Of Mud

http://www.laputan.org/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

http://www.martinfowler.com/bliki/StranglerApplication.html

Hub and spokes

So, how do we get from

A bit of guidance

Our recommendations

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

Technology

Choose language / framework that make asynchronous communication easy

The Dark Side of Polyglot

Design

Align service boundaries to bounded contexts / value streams

Design

Share nothing architecture

Mono-repo vs repo-per-service

Integration

Default to HTTP RESTful endpoints

Safety through isolation / compartmentalization

Deployment

Separate build and deploy targets per service

Continuous deployment (where feasible)

Zero-downtime deployment

Provisioning

Common cookbook for service creation

Single-command provisioning

Version production cookbooks

Containerization of runtime environments

Security

Keep it simple - shared secrets

Encapsulate session storage

Private load balancers for back-end services

Monitoring

Standard health-check per service: /_hc

Monitoring

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!

owen@exortech.com | @exortech
nicwaller@gmail.com | @nic_waller