Hi!

Owen Rogers / @exortech

Lead Consultant @ Exortech Consulting

Product Owner / Solutions Architect @ EnerNOC

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.";
	}
	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