microservices pros and cons - houston tech fest
Post on 14-Apr-2017
59 Views
Preview:
TRANSCRIPT
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
top related