261–270 of 383 posts
The public cloud provided a way to avoid all of this headache.
Once it got figured out, the cloud wasn't the only way to scale anymore.
Except, more people than not might not know that today about the cloud.
Linux has gotten orders of magnitude more efficient and effective, so has the public cloud, and by extension, so has scaling (and self hosting)..
On the load side, if you're accumulating "statistics" about user behavior, do you really need them for every user? Maybe only one user in a hundred. Or a thousand.
When you exceed the limits of that, you're a big company and can afford AWS.
A few years ago, we had those guys with the liquid meal (not Jucero, the Soylent guys) boasting about their "infrastructure". Not for making the product, for their web site. From their financials, you could calculate that they were doing about four sales a minute. Their "infrastructure" could run on an Raspberry Pi.
I've seen startups killed because of one or two "influential" programmers deciding they need to start architecturing the project for 1000TPS and 10K daily users, as "that's the proper way to build scalable software", while the project itself hasn't even found product-market fit yet and barely has users. Inevitably, the project needs to make a drastic change which now is so painful to do because it no longer fits the…
Earlier quoted context omitted.
Legitimately asking, how? The only bottleneck should be the DB, and if you can saturate a 128-core DB, I want to see your queries and working set size. Not saying it can’t happen, but it’s rare that someone has actually maxed out MySQL or Postgres without there being some serious schema and query flaws, or just poor / absent tuning.
You’re thinking purely in terms of app performance. have you ever seen a terrible db schema? Having to suddenly iterate fast with a brittle codebase that doesnt really allow that ive seen bring teams to their knees for a year+. I’ve seen monoliths because of their sheer size and how much crap and debt is packed into them, build and deploy processes taking several hours if not an entire day for some fix that could be…
The schema wasn't really a problem, but the sheer amount of queries per request. Often a user opening a page or clicking a button would cause 100-200 database queries, including updates. This would prevent strategies such as "just replicating the data somewhere". It was so badly architected that every morning the app would stop responding due to users doing their morning routine operations. And they only had around 300 employees.
And this was just an internal app, the B2C part was already isolated because we couldn't afford to be offline.
The solution I started working on was doing similar to the strangler fig pattern and replacing parts of the API with new code that talked directly to the ORM. Naturally this didn't made the people who wrote the legacy code happy, but at least the outages stopped.
Earlier quoted context omitted.
I do consulting in this space, and I'm torn: I make much more money managing infrastructure from clients who insist on AWS. But it's much more enjoyable to work with people who knows how to keep it simple.
I worked on a project for my company (a low volume basic web app) and I suggested we could just start the whole thing on one server. They brought on some Azure consultants and the project ballooned out to months of work and all kinds of services. I’m convinced most of the consultants were just piling on services so they could make more money.
I've been offering to help people cut costs for a while, and it's a shockingly hard sell even with offers of guarantees, so we're deemphasizing it to focus more on selling more complex DevOps assistance and AI advice instead... Got to eat (well, I do much better than that, but anyway), but I refuse to over engineer things just to make more money.
This piece is written with a pretty cliche dismissive tone that assumes that everything everyone else does is driven by cargo-culting if not outright ignorance. That people make these choices because they're just rushing to chase the latest trend. They're just trying to be cool, you see. Here's the thing, though: Almost every choice that leads to scalability also leads to reliability. These two patterns are effective…
A distributed monolith - which is what nearly all places claiming to run microservices actually have - has N^m uptime. Even if you do truly have a microservices architecture, you’ve also now introduced a great deal of complexity, and unless you have some extremely competent infra / SRE folk on staff, that’s going to bite you. I have seen this over and over and over again. People make these choices because they don’t…
But if it was just a monolith and had proper startup checks, when they roll out a new version and it fails, just kill it right there. Leave the old working version up.
Monoliths have their issues too. But doing microservices correctly is quite the job.
>Modules cannot call each other, except through specific interfaces (for our Python monolith, we put those in a file called some_module/api.py, so other modules can do from some_module.api import some_function, SomeClass and call things that way. This is a solution to a large chunk of what people want out of microservices. There are just two problems, both of which feel tractable to a language/runtime that really wan…
Yeah, just put some gRPC services in a single pod and have them communicate over unix domain socket. You now have a single unit of modules that can only communicate over IPC using a well-defined type-safe boundary. As a bonus you can set resource quotas separately according to the needs of the module.
Want to scale? Rewrite some config and expose a few internal services and have them communicate over TCP.