Downloaded 12 times
Uploaded byAndrew Siemer
Microservices pros and cons - houston tech fest
Microservices are small, loosely coupled pieces of software that each focus on doing one thing well. The document discusses when microservices may be a good approach and how to manage them effectively through continuous deployment, service discovery, containerization, request routing, self-healing capabilities, and monitoring of system health and performance. Automating processes and planning for failures are emphasized.
More Related Content
Similar to Microservices pros and cons - houston tech fest
Microservices pros and cons - houston tech fest
- 1. MICROSERVICES Pros & Cons- Things to Think About
- 2. Peter McKee in/pmckeetx @pmckee Miguel Gonzalez in/magonz @doesnotcompile GabrielSchenker in/gabrielschenker @gnschenker Andrew Siemer in/andrewsiemer @asiemer www.slideshare.net/asiemer/microservices-pros-and-cons-houston-techfest
- 3. WHAT IS AMICROSERVICE? • 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 USEMICROSERVICES? • 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 ICONSIDER 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 SHOULDA MICROSERVICE BE? • Small enough to fit full context in your head • Big enough to solve a problem • Owned by one team
- 7. WHAT DOES “BIGENOUGH” 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 AMICROSERVICE COMMUNICATE? • Synchronous • Asynchronous • Messaging • Fan out • HTTP/REST • TCP/IP • Pub/sub ...but zero logic in the communication pipeline!
- 9. ARE MICROSERVICES LESSCOMPLEX? • Code wise, yes • Deployment wise, yes • Infrastructure configuration wise, no • Dependency management wise, no
- 10. THE SKILL OFTHE TEAM will out weigh any monolith/microservice choice!
- 11.
- 12. HOW TO MANAGEMICROSERVICES? 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 • Publicabstraction 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 notIF 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 • Measureanything, 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 WITHHYSTRIX
- 22. QUESTIONS? Peter McKee in/pmckeetx @pmckee Miguel Gonzalez in/magonz @doesnotcompile GabrielSchenker in/gabrielschenker @gnschenker Andrew Siemer in/andrewsiemer @asiemer www.slideshare.net/asiemer/microservices-pros-and-cons-houston-techfest