Transcription: a Twitter thread from Gary Bernhardt.
- You, the one who is reading this! You don't need Kubernetes!
- Also microservices.
- Also queues that are separate from your primary database (for most apps).
- Google cosplay is not business-critical.
Source: https://twitter.com/garybernhardt/status/1344341213575483399
Absolutes in programming tend to lead to bad designs. This is more a “I’m gonna stir up some shit on Twitter” post than real wisdom.
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?
Even if what you say isn't true I'm giving my vote of confidence so I can just shrug whenever someone disagrees with my architecture.
Don't like that I chose a single API server? We're avoiding sprawling microservice deployments with tightly coupled dependencies.
Don't like all the docker containers? We're avoiding bloated, tightly coupled logic that ignores business domains.
Monoliths are the answer to bad microservices. Microservices are the answer to bad monoliths. It’s all cyclic and four different architects are going to have fifteen different opinions on how your system should be built. Do the thing that makes sense for your team and try to stay flexible.