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
• 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
• 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...
• 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
HOW SHOULD A MICROSERVICE
• Fan out
...but zero logic in the communication pipeline!
ARE MICROSERVICES LESS COMPLEX?
• Code wise, yes
• Deployment wise, yes
configuration wise, no
• Dependency management
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
• Continuous Deployment
• Continuous Delivery
• Blue / Green
• A-B Testing
• Net new, add to routing
• Zero downtime
Tools: Jenkins / TeamCity / Ansible / Chef / Capistrano / StackStorm
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
• 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
It’s not IF it will fail but WHEN it will fail!
• Auto healing
• Automated Remediation
• Circuit breaker
• Graceful degradation
• Don’t cascade failures
Tools: Consul / ZooKeeper / Serf
PLAN FOR FAILURE FIRST
CIRCUIT BREAKERS WITH HYSTRIX
FIND/MAKE SOMETHING SIMILAR!