# Microservices 3 March 2017 Dan Hersam

## But first, a short interlude...

 Note: Gives a view of how a technology or application will evolve over time. Technology Trigger Peak of Inflated Expectations Trough of Disillusionment Slope of Enlightenment Plateau of Productivity

## Google Trends of Microservices 

## What Are Microservices?

> An independently deployable component of bounded scope that supports interoperability through message-based communication. -- Irakli Nadareishvili

> Loosely coupled service-oriented architecture with bounded contexts. -- Adrian Cockcroft, Battery Ventures

> Small, autonomous services that work together. -- Sam Newman, Thoughtworks

## How To Recognize One in the Wild 

## Does One Thing Well (Single Responsibility Principle) Note: Small and Focused - Specialized. Like updateCustomer, or calculatePrice

## Autonomous Note: Must be decoupled from other services and isolated - decentralized, Replaceability Golden rule: can you make a change to a service and deploy it by itself without changing anything else?

## Elastic Note: Scale appropriately depending on the usage

## Resilient Note: Fault-tolerant and provide a reasonable recovery timeframe if something goes wrong.

## Decentralized Note: Data too - no need for one massive database

## Microservices  Note: Separate business units. Large company = employees = one job.

## ... vs a Monolith  Note: Startup, one employee = many hats. Don't know how the tracks fit the analogy

## Best Practices? * Data Store for Each Microservice * Keep Code at a Similar Level of Maturity * Do a Separate Build for Each Microservice * Deploy in Containers * Treat Servers as Stateless Note: From Netflix's experience. Treat servers as cattle, not pets. Avoid "snowflake" systems in which you depend on individual servers to perform specialized functions.

## Why Use Microservices?

## Common Problems with Monoliths * Technical debt * Fear to change * Tightly-coupled * Lack of ownership * Hard to scale out * All or nothing deployment * Code complexity and maintainability Note: Explain each one on this slide

## Key Benefits of Microservices * Scaling * Resilience * Composable * Evolutionary * Ease of Deployment * Choose Your Technology * Organizational Alignment * Increased Development Speed Note: Briefly - following slides in more detail

## Scaling  Note: Instead of trying to scale one part of your tricycle, use a Ferrari and a Jeep.

Resilience

## Composable  Note: Flexible - put together for different purposes

## Evolutionary 

## Ease of Deployment 

Choose Your Technology

## Organizational Alignment  Note: Reduce the number of people working on a single codebase. Great for distributed teams

...The Two Pizza Rule

## Increased Development Speed 

## Production Ready? * Uber * Amazon * Netflix * Spotify * SoundCloud

# BUT...

## Not A Silver Bullet

New Common Problems

• Traceability
• Network Latency
• Message Routing
• Service Discovery
• Operations Overhead
• Eventual Consistency

## What About SOA? Note: Service Oriented Architecture - very sensible idea - modularity and message-based communication. But much of the SOA principles don't help to split big parts into smaller ones. SOA - shared domain models, Microservices - distributed. Enterprise Service Bus vs HTTP

## What About Decomposition? * Requires Same Technology * Lose Scaling Independently * Lose Independent Deployment * Less Resiliency Note: E.g. Modules or Shared Libraries Many of the advantages of a microservice-based architecture come from its granular nature and the fact that it gives you many more choices for solving problems. Can similar decompositional techniques achieve the same benefits? Technically, it should be possible to create well-factored, independent modules within a single monolithic process. And yet this rarely happens. The modules themselves soon become tightly coupled with the rest of the code, surrendering one of their key benefits. Having a process boundary separation does enforce clean hygiene in this respect (or at least makes it harder to do the wrong thing)

## Should You Start Using Microservices?

## Conway's Law > Any organization that designs a system will produce a design whose structure is a copy of the organization's communication structure. -- Mel Conway

## Questions to Ask * How big are the teams? * What skills do they have? * How are development and operations divided? * How are responsibilities divided between teams?

## Other Considerations...

## Sufficiently Large Project Note: Microservices are ideal for big systems that warrant the complexity of microservices (they don't come for free). Large, distributed teams.

## Focused on replaceability Note: Microservices can allow you to be more flexible and swap out components that aren't working well

## Deep Understanding of Problem Domain Note: You need to know the problem domain well before being able to correctly break it down into subdomains.

## Second Version of Existing System Note: Ideal scenario because you know the domain extremely well

## How To Introduce Change? > Find small changes that can unfold in a way that creates large > effects -- Gareth Morgan Note: Author of Images of Organization

## This Presentation [microservices.xt.ws](https://microservices.xt.ws/)

## References 1. _Microservice Architecture_ by Irakli Nadareishvili 1. _Building Microservices_ by Sam Newman 1. _Microservices from Day One_ by Cloves Carneiro Jr. 1. _Production-Ready Microservices_ by Susan J. Fowler 1. _Microservices on AWS by Matthias_ Jung Note: Microservices on AWS = presentation at AWS Summit 2016. Yes, that Susan Fowler

# Questions?