Microservices pros and cons dark

Andrew Siemer
Andrew SiemerI build great engineering teams - with a smile
MICROSERVICES
Pros & Cons
Things to Think About
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
• Monolith 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 management
wise, no
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 PREFERRED
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
FIND/MAKE SOMETHING SIMILAR!
Microservices pros and cons dark
Microservices pros and cons dark
QUESTIONS?
James Allen
in/jamesallenatx
Miguel Gonzalez
in/magonz
@doesnotcompile
Gabriel Schenker
in/gabrielschenker
@gnschenker
Andrew Siemer
in/andrewsiemer
@asiemer
Seth Orell
in/sethorell
Campbell McNeill
in/campbellmcneill
@campbellmcneill
http://www.slideshare.net/asiemer/microservices-prosandconsdark
1 of 20

More Related Content

What's hot(20)

Microservices architectureMicroservices architecture
Microservices architecture
Faren faren1.4K views
From Monolith to MicroservicesFrom Monolith to Microservices
From Monolith to Microservices
Amazon Web Services1.7K views
Deep Dive on Microservices and Amazon ECSDeep Dive on Microservices and Amazon ECS
Deep Dive on Microservices and Amazon ECS
Amazon Web Services3.8K views
Microservices: next-stepsMicroservices: next-steps
Microservices: next-steps
Boyan Dimitrov7.4K views

Similar to Microservices pros and cons dark(20)

More from Andrew Siemer(8)

Microservices pros and cons dark

  • 2. 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
  • 3. 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
  • 4. 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 • Monolith 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
  • 5. 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
  • 6. 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
  • 7. HOW SHOULD A MICROSERVICE COMMUNICATE? • Synchronous • Asynchronous • Messaging • Fan out • HTTP/REST • TCP/IP • Pub/sub ...but zero logic in the communication pipeline!
  • 8. ARE MICROSERVICES LESS COMPLEX? • Code wise, yes • Deployment wise, yes • Infrastructure configuration wise, no • Dependency management wise, no
  • 10. 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
  • 11. 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
  • 12. 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
  • 13. 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 PREFERRED
  • 14. 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
  • 15. 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
  • 16. 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
  • 17. CIRCUIT BREAKERS WITH HYSTRIX FIND/MAKE SOMETHING SIMILAR!
  • 20. QUESTIONS? James Allen in/jamesallenatx Miguel Gonzalez in/magonz @doesnotcompile Gabriel Schenker in/gabrielschenker @gnschenker Andrew Siemer in/andrewsiemer @asiemer Seth Orell in/sethorell Campbell McNeill in/campbellmcneill @campbellmcneill http://www.slideshare.net/asiemer/microservices-prosandconsdark