31–40 of 251 posts
Imagine you’ve inherited a 10 year old PHP monolith. The code is almost indecipherable and the business wants new features in a timely and predictable manner.
The easiest way is to implement the new features in their own micro services.
Sure it makes the complexity problem worse, but that’s a problem for someone else in five years time.
> sqlite.org answers more than 500,000 HTTP requests per day (about 5 or 6 per second) delivering about 200GB of content per day (about 18 megabits/second) on a $40/month Linode. The load average on this machine normally stays around 0.5.
My personal website,
Two multiplayer game servers for the games I built,
frp for tunnelling;
and I'm planning on squeezing more in until it gives up.
All reverse-proxied by nginx under subdomains of my personal domain address, absolutely seamless.
Similarly, other applications I built so far all also run under five euro VMs. There's no denying you might need more because you have serious peaks in traffic that you cannot handle with only one server, but do the accounting. It's a worthwhile decision to think through.
I can confirm. I've had quite a few projects that made it to the front page of HN and handled the traffic like cake. All of them ran on 5$ digital ocean droplets. I accept some projects are more resource expensive than others, but majority of the time you can get away with a bit of asynchronous responses + scheduler/queue to spread the load horizontally over time. Unpopular opinion: I blame the new age devops culture…
If you're hiring, you want to be able to add/replace people as easily as possible. If you're being hired, you want to charge as much as you can. And to satisfy those two demands, the current web stack is great. Almost like it's been built for it.
It's got very little to do with the tech itself, a lot more to do with market dynamics. That's the problem it's trying to solve.
Earlier quoted context omitted.
The problem with devops replacing the old title “sysadmin” was that the dev part dragged in the worst thing about developer culture: the love of complexity and the tendency to build massive towers of it. Sysadmins usually avoided complexity because their attitude toward it was more sensible: it’s expensive, fragile, and tends to actually multiply failure modes. I also blame cloud marketing. This stuff is a gigantic m…
If you guys don't see the value of being able to click on a button on a website to deploy, perfectly, everytime over some guy sshing into the box and running git pull I dunno what to tell you.
Can the majority of webapps run on a single machine? Probably. Do most of your customers expect close to 100% uptime? Yes. Does one machine provide the uptime required by your customers? Most definitely not.
Master slave failover will give you less than a second of downtime.
I can confirm. I've had quite a few projects that made it to the front page of HN and handled the traffic like cake. All of them ran on 5$ digital ocean droplets. I accept some projects are more resource expensive than others, but majority of the time you can get away with a bit of asynchronous responses + scheduler/queue to spread the load horizontally over time. Unpopular opinion: I blame the new age devops culture…
> I've never come across a devops person who'd say "Hey, that sofware is too simple to prematurely scale for sudden spikes of irrational amounts of traffic, so why not just deploy it on a cheap vps?" It Is Difficult to Get a Man to Understand Something When His Salary Depends Upon His Not Understanding It
Can the majority of webapps run on a single machine? Probably. Do most of your customers expect close to 100% uptime? Yes. Does one machine provide the uptime required by your customers? Most definitely not.
Well if you can spin up a new environment in less than a minute – does it matter? I mean if you are Facebook yes, but having worked with a lot of people building things like web shops – having a minute downtime I would say is fine because I've seen so many of these people shoot themself in the foot trying to build high-availability solutions and having constant downtimes just because they can't handle their own compl…
Can the majority of webapps run on a single machine? Probably. Do most of your customers expect close to 100% uptime? Yes. Does one machine provide the uptime required by your customers? Most definitely not.
Well if you can spin up a new environment in less than a minute – does it matter? I mean if you are Facebook yes, but having worked with a lot of people building things like web shops – having a minute downtime I would say is fine because I've seen so many of these people shoot themself in the foot trying to build high-availability solutions and having constant downtimes just because they can't handle their own compl…
And spinning up a new VM typically takes longer than a minute. Even on cloud providers.
If you don't care about downtime or reliability, sure.
Every company out there loudly claims they need 100% uptime, which grifters will be happy to sell them knowing nobody will actually put their solution to the test and if it does fail they'll have a myriad of moving parts to shift the blame to.
If you look at the very few things that do actually need 100% uptime (real-time stock market, etc) you'll note the absence of most "cloud-native" and supposedly "best practice" bullshit. The reality there is much more boring, serious and rigorous - that's what you get when you actually need 100% uptime.