Microservices pros and cons
Download as PPTX, PDF1 like707 views
The document outlines the concept of microservices as small, autonomous software components that address specific tasks while being loosely coupled and independently scalable. It discusses the conditions under which microservices should be considered, the appropriate size for a microservice, communication methods, and management strategies, including deployment tools and self-healing practices. The complexities and challenges associated with microservices, particularly in terms of infrastructure and dependency management, are also highlighted.
Microservices pros and cons
- 1. Microservices Pros & Cons Things to Think About
- 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: 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 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 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
- 20. Questions? James Allen http://www.linkedin.com/in/jamesallenatx Miguel Gonzalez https://www.linkedin.com/in/magonz @doesnotcompile Gabriel Schenker https://www.linkedin.com/in/gabrielschenker @gnschenker Andrew Siemer https://www.linkedin.com/in/andrewsiemer @asiemer