Ce diaporama a bien été signalé.
Nous utilisons votre profil LinkedIn et vos données d’activité pour vous proposer des publicités personnalisées et pertinentes. Vous pouvez changer vos préférences de publicités à tout moment.

Microservices pros and cons dark

697 vues

Publié le

A discussion about microservices and concepts to think about prior to building your next app with this approach.

Publié dans : Logiciels
  • Soyez le premier à aimer ceci

Microservices pros and cons dark

  1. 1. MICROSERVICES Pros & Cons Things to Think About
  2. 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. 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. 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. 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. 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. 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. 8. ARE MICROSERVICES LESS COMPLEX? • Code wise, yes • Deployment wise, yes • Infrastructure configuration wise, no • Dependency management wise, no
  9. 9. MICROSERVICE MANAGEMENT OVERVIEW
  10. 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. 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. 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. 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. 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. 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. 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. 17. CIRCUIT BREAKERS WITH HYSTRIX FIND/MAKE SOMETHING SIMILAR!
  18. 18. 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

×