MICROSERVICESPros & Cons - Things to Think About

Peter McKeein/pmckeetx@pmckee

Miguel Gonzalez in/magonz@doesnotcompile

Gabriel Schenker in/gabrielschenker@gnschenker

Andrew Siemer in/andrewsiemer@asiemer

www.slideshare.net/asiemer/microservices-pros-and-cons-houston-techfest

WHAT IS A MICROSERVICE?

• Small piece of software that does one thing really well • Loosely coupled • Separate data store • Just enough to solve a problem • Right technology for the job • Autonomous • Can update as often as is needed • Intelligence in the service, not the routing/infrastructure/bus • Immutable infrastructure

SHOULD I USE MICROSERVICES?

• It depends! • Likely no • Think about fallacies of distributed computing:

• The network is reliable • Latency is zero • Bandwidth is infinite • The network is secure • Topology doesn’t change • There is one administrator • Transport cost is zero • The network is homogeneous

WHEN SHOULD I CONSIDER MICROSERVICES?

• Many teams work on the same code base • Merge hell, cross team dependencies, ... • Huge monolithic application which is difficult to deploy • Monolithic application that cannot be scaled horizontally • Different parts of the application have totally different requirements

• CPU bound • I/O bound • Memory bound • etc.

• Some but not all areas of the application change frequently • Development stack is outdated. New tools and patterns are hard if

not impossible to embrace

HOW BIG SHOULD A MICROSERVICE BE?

• Small enough to fit full context in your head • Big enough to solve a problem • Owned by one team

WHAT DOES “BIG ENOUGH” LOOK LIKE...

Some examples: • Docker: https://github.com/docker/docker-birthday-3 • Lambda: https://github.com/meconlin/lambda-generic-microservice • C#: https://github.com/AFASSoftware/CQRS-Microservices • Spring: https://github.com/kbastani/spring-cloud-microservice-example • akka: https://github.com/theiterators/akka-http-microservice • https://github.com/dustinbarnes/microservice-example

HOW SHOULD A MICROSERVICE COMMUNICATE?

• Synchronous • Asynchronous • Messaging • Fan out • HTTP/REST • TCP/IP • Pub/sub

...but zero logic in the communication pipeline!

ARE MICROSERVICES LESS COMPLEX?

• Code wise, yes • Deployment wise, yes

• Infrastructure configuration wise, no

• Dependency managementwise, no

THE SKILL OF THE TEAMwill out weigh any monolith/microservice choice!

MICROSERVICE MANAGEMENT OVERVIEW

HOW TO MANAGE MICROSERVICES?

It’s a big world with lots of cutely named tools!

• Deploy: Jenkins / TeamCity / Ansible / Chef / Capistrano / StackStorm • Discovery/config: Consul / Consul-Templates / etcd / Registrator / skydns • Containers: Docker / Compose / Vagrant / Otto / Lambda • Container Clustering: ECS / Kubernetes / Mesos / Docker Swarm • Request Routing: Nginx / HAProxy / Kong / API Gateway • Self Healing: Consul / ZooKeeper / Serf • System Health: hystrix, SumoLogic, Nagios, NewRelic, statsd, LogEntries

AUTOMATE EVERYTHING

DEPLOYMENT

• Continuous Deployment • Continuous Delivery • Versioned • Blue / Green • A-B Testing • Net new, add to routing • Zero downtime

Tools: Jenkins / TeamCity / Ansible / Chef / Capistrano / StackStorm

NEVER DESTRUCTIVE

SERVICE DISCOVERY & CONFIGURATION

• Minimize known dependencies • No bottlenecks due to outage allowed • Down stream health monitoring • Configuration at deployment time when possible • Configuration in runtime if you have to (adds fragility/degradation)

Tools: Consul / Consul-Templates / etcd / Registrator / skydns

NO DEPENDENCY KNOWLEDGE

CONTAINERS & CLUSTERING

• Removes “works on my box” story • Installed software dependencies become constrained to your need • No more “servers as pets” • Infrastructure as code becomes a reality • Can deploy to fabric/cluster for better auto scaling story • Serverless truly abstracts hardware from application

Tools: Docker / Compose / Vagrant / Otto / Lambda / AWS ECS / Kubernetes / Mesos / Docker Swarm / cAdvisor

NO HARDWARE DEPENDENCY

REQUEST ROUTING

• Public abstraction from internal details • Internal location can become dynamic • Multiple versions of the same thing can be long lived • Makes deployment story more flexible • Live traffic can be drained over • Warming up new instances is possible

Tools: Nginx / HAProxy / Kong / API Gateway / Kubernetes

NEVER EXPOSE YOUR SERVICES DIRECTLY

SELF HEALING

It’s not IF it will fail but WHEN it will fail!

• Auto healing • Automated Remediation • Circuit breaker • Fallbacks • Graceful degradation • Don’t cascade failures

Tools: Consul / ZooKeeper / Serf

PLAN FOR FAILURE FIRST

SYSTEM HEALTH

• Measure anything, measure everything • https://codeascraft.com/2011/02/15/measure-anything-measure-everything/

• Performance monitoring, exception monitoring, logs, metrics • NewRelic, nagios, SumoLogic • statsd / graphite (hosted graphite) / kibana / grafana • Centralized logging (logentries, logstash) • Circuit Breaker (hystrix)

Tools: hystrix, SumoLogic, Nagios, NewRelic, statsd, LogEntries

VISUALIZE EVERYTHING

CIRCUIT BREAKERS WITH HYSTRIX

QUESTIONS?

Peter McKeein/pmckeetx@pmckee

Miguel Gonzalez in/magonz@doesnotcompile

Gabriel Schenker in/gabrielschenker@gnschenker

Andrew Siemer in/andrewsiemer@asiemer

www.slideshare.net/asiemer/microservices-pros-and-cons-houston-techfest