A talk we gave on microservices at houston tech fest

1. MICROSERVICES
Pros & Cons - Things to Think About

2. Peter McKee
in/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

3. 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

4. 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

5. 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

6. 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

7. 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

8. HOW SHOULD A MICROSERVICE COMMUNICATE?
• Synchronous
• Asynchronous
• Messaging
• Fan out
• HTTP/REST
• TCP/IP
• Pub/sub
...but zero logic in the communication pipeline!

9. ARE MICROSERVICES LESS COMPLEX?
• Code wise, yes
• Deployment wise, yes
• Infrastructure
configuration wise, no
• Dependency management
wise, no

10. THE SKILL OF THE TEAM
will out weigh any monolith/microservice choice!

11. MICROSERVICE MANAGEMENT
OVERVIEW

12. 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

13. 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

14. 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

15. 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

16. 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

17. 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

18. 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

19. CIRCUIT BREAKERS WITH HYSTRIX

22. QUESTIONS?
Peter McKee
in/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