MICROSERVICES ARCHITECTURE AS IF YOU MEANT IT
summary
A small company (<10 people) builds a blog and an ecommerce as separate services and ends up with heavy infrastructure: RabbitMQ per-event queues with a separate queue per event type, at-least-once delivery, Docker containers on Docker Swarm, Terraform for provisioning, Ansible/Chauffeur, ELK/Graylog, Zabbix, Sentry and Consul/nginx for discovery. Rule: each service needs two owners. Result: many upfront decisions and ~15 infra tools for essentially two services, high maintenance cost; suits large orgs or splitting big monoliths, not tiny startups.
AI-written summary · about
chapters (11)
- 0:00Introduction to microservices
- 1:05High-level architecture overview
- 2:30Organizational impact of microservices
- 4:40Key decisions in microservices
- 7:28Deployment platform choices
- 10:00Creating new microservices
- 12:28When to split microservices
- 13:56Development and delivery practices
- 15:45Operations and maintenance
- 18:43When to use microservices
- 21:45Q&A
related talks
01h 01mMicroservices Gone Wrong
43mGo micro with Microservices
48mChallenges in Implementing MicroServices
52mI Have a Microservices Architecture and I Didn't Know.
37mKnee Deep in Microservices
50mChallenges in Implementing Microservices
35mMicroservices: A Tale of 3 Heroes
45mContinuously delivering containerized, highly available microservices