No microservices usually leads to bloated, tightly coupled logic that ignores business domains
No monoliths usually leads to sprawling microservice deployments with tightly coupled dependencies and flavor-of-the-week new ones
No Kubernetes usually leads to VPS pets or crazy obstacle courses trying to get SSL termination without a million fucking dependencies in a cloud container orchestration system that isn’t as good as Kubernetes
All Kubernetes usually leads to huge SRE costs for a tiny app

The same shit happened last summer when AWS came out with their “we dropped microservices for a monolith and look at our speed increase” article which ignored good design principles. Sometimes you should split things over business domains so you can deploy and code independently. Sometimes Kubernetes is the best way to handle your scale needs. The stories we normally read are about people doing it wrong (eg AWS making a bunch of microservices inside a domain sending fucking gigs of data between what should have been functions in a single service). Inexperienced folks don’t always know when to move from their minimum viable solution to something that can scale. That doesn’t mean you remove these things, it means you train on when you need them.

Should we abandon design patterns because singletons or flywheels aren’t the correct solution all of the time?

[–] docAvid@midwest.social 3 points 8 months ago* (last edited 8 months ago)

Saying that some projects, at some point in their lifecycle, don't need certain things, is not saying that those things have no place. Also, if one can't design a monolith that isn't bloated and tightly coupled, one definitely has no business designing microservices. Using microservices is neither necessary, nor sufficient to achieve decoupling.

Monolithic services are the ideal way to begin a project, as using basic good practices, we can build a service that does many things with minimal coordination, and as it grows and requirements change or are discovered, we can easily refactor to keep things simple. As the software matures, we find the natural service boundaries, and find that certain pieces would perform better if they were separated out and could scale independently, or act asynchronously. Since we have followed good practices, this should usually be a simple matter of removing a class or module to a new service, and replacing it with a facade, such that the rest of the monolith doesn't have to change at all.

load more comments (6 replies)