Disasters I've seen in a microservices world

# · 🔥 252 · 💬 137 · 2 years ago · world.hey.com · gregdoesit · 📷
A new feature? Bam, let's start a service! Suddenly, teams with 20 engineers were maintaining 50 services. That's more than one service per person! The problem with code, in general, is that it rots. Another smell was when someone told me that deploying a new feature in service A also needed a deployment - at the same time - in service B. Or when people started to write services to generate CSVs. Why would someone introduce network hops to produce a worldwide known file format? Who would maintain that? Some teams were suffering from servicitis. How much time does it cost to do so? What if, when a mobile engineer starts to develop a feature, there's a set of services in a given version, and when they finish, there are ten new versions deployed into production? Do you create a user per service? Do you have fine-grained permissions so service A can only read or write from specific tables? What if someone removes an index unintentionally? How do we know how many services are using different tables? What about scaling? I've seen teams using circuit breakers and then increase the timeouts of an HTTP call to a service downstream. It's even worse than that: your service might be able to get all these new requests, but if the retries mechanism doesn't implement exponential backoff and jitter, you might experience a distributed denial-of-service from your mobile applications.
Disasters I've seen in a microservices world



Send Feedback | WebAssembly Version (beta)