[ecmascript]

I have never understood the rush for "the cloud".

I run all my shit on a VPS (which could be called a cloud) or a dedicated rented server but that is so easy to setup and I can run all projects on the same server. Easy, simple and if I need to scale I just rent a bigger server.

Scaling vertically is easy, scaling horizontally is hard. Most people never need to scale horizontally but does so anyway because they think they do.

You also get like 10x the perf for the same money. Using SQLite makes it easy to have backups and even time-specific testing databases.

[Jcampuzano2]

Because most companies/startups have this in-built assumption that they will eventually grow like wildfire. Obviously this is because they are selling to investors who want this to happen so they can cash out on their unicorn. So they just build it in the cloud in the first place with that in mind.

Now in some miniscule amount of cases this is true and probably did help some people who's business 100x'd overnight, but in the vast majority of cases your business just will never get to the point it needs to be "cloud scale" in the first place. Nevermind accidentally shooting yourself in the foot with a recursive lambda here and there in certain instances or a misconfuguration causing a huge bill.

Edit: Another is because lots of companies who do actually end up succeeding negotiate a shit-load of credits with cloud providers so they can basically grow their business for free for a while. That is until those credits run out and they get hit with the actual costs.

[anonylizard]

For most tech startups, when the growth period hits, its vital there must be NO DELAY to scale. Miss the timing and its permanently gone. If word of mouth leads to a sudden surge of orders, you must be able to supply the good, or you get very angry customers who walk straight into the competitors door.

Most of the value generated by startups is highly concentrated in the few that succeed. So naturally the industry should optimize itself to go big or go home, not penny pinch. That's also, why they hire expensive engineers rather than offshored developers, because speed matters more than cost.

As for non-tech companies. Their demand is more stable in the long run, but they are not tolerant of outages. Amazon cannot have its servers go down during a big sale, too many physical ongoing costs that gets wasted for every second the central nervous system is down. So the cloud is good for its reliability.

[crowcroft]

For most people I agree.

When AWS was first getting big though they solved genuine, really hard problems for a lot of organisations that were large or growing quickly. NVME drives didn't exist, SSDs were expensive and a lot of servers still had spinning SAS drives – A little box with some ram and some NVME drives didn't scale as ridiculously far as they do now.

I do think as computers keep getting faster and smaller the number of use cases that need a 'cloud' shrink very quickly though.

[benterix]

The problem is, the larger your organization is, the more difficult is to break free from vendor lock-in.

[benterix]

The initial rush for what is now called the public cloud was caused by many factors, the main ones being "you don't need to manage things as we will do it for you" (=you save on operations) and "you can scale up and down how much you want without any commitment" (=you save on recurring costs) with success stories like the NYT resizing tons of images fast without having to rent servers, configure them etc.

Fast forward and what we now have is a terribly complex beast with nets of dependencies that got developed partly by marketing and product teams, partly by demands of larger customers. And it's more or less clear that if you are small, you will be much better off using VPS (that's why Amazon decided to offer Lightsail), and if you are very big, you will save a lot of money moving at least part of your infra away from the public cloud.

But what remains is a large part of the market: medium sized businesses and large organizations that depend on the public cloud for many reasons. But they are not stupid: once a project becomes expensive, someone starts asking questions. And after you've exhausted the path of reserved instances, spot etc., and still burn a lot of money with not-always-stellar performance, you'll find a way of moving these workloads where it makes business sense.

[zevv]

One recurring pattern I have seen at multiple customer sites is that scaling makes the engineers lazy to optimize. One production performance calamity requires the team to add CPU as a quick fix, and from that time on the baseline for the product's requirement has been set to the new number of CPUs.

"Back in the olden days", if your product was slow but the number of CPUs was fixed (or could not be increased instantly), the solution was to go and fix your code.

Basic system level skills are now no longer taught or practiced at the appropriate levels, so teams end up without engineers who actually know how to profile and optimize.

The cloud providers are the big winners here.

[mgkimsal]

"scaling makes the engineers lazy to optimize"

I've lost track of the times I've heard "compute is cheap! engineers are expensive!" Except... that compute cost will live forever. The time it takes someone to debug a bad loop or poor query is at worst a one time cost. Longer term, it may even make other stuff faster in the future.

[Ekaros]

Looking at some numbers on cloud, yeah I don't believe in that statement anymore. End device compute might be cheap, but cloud services certainly are not.

[mgkimsal]

We've also seen a rise (or maybe I just notice it more) of stories of "I changed these 3 lines in 5 minutes and saved my company $40k/month!"

And then you'll get responses like "pfft.... that's hardly the cost of one part time FAANG person who makes $680k/year - what's the point?"

And around we go...

[jazz9k]

Because it's cheaper now to throw hardware at a problem than actually try to fix the code or root of the issue. This wasn't the case a couple of decades ago.

It also means less engineers are needed for most companies.

[jjav]

> Because it's cheaper now to throw hardware at a problem than actually try to fix the code or root of the issue.

It's not cheaper, it's just more opaque.

Back when your service was deployed on that 2 CPU box and it was too slow for obvious reasons, you optimized it and then it was good.

Today you just shrug and increase that kubernetes cluster from 16 to 48 nodes and forget about it. Costs a lot but the bill shows up somewhere else, in most groups the engineer doesn't even know what it is.

[bluGill]

It isn't engineers that are lazy, it is management that tells the engineers to work on features that make money not performance that will save money.

Sometimes management is correct in that decision, sometimes it is "penny wise, pound foolish".

[duxup]

"scaling makes the engineers lazy to optimize"

More often I think that's more of an overall engineering department time budgeting / culture issue.

[cdavid]

For large companies, a big reason is to transform capex into opex, and the predictability. Moreover, large organizations tend to favor predictivity over levels, i.e. are ok to increase average if variance is decreased.

[RajT88]

This. The beginning of my career on cloud was a POC, where the director shared with me this was a major driving factor (capex > opex), as well as some of the fringe benefits.

I got to see close up that a team of devs ran their whole solution (with a bunch of paying customers and everything) in the cloud, because cloud automation was good enough that they didn't need dedicated ops people.

Now I work for a cloud provider. I can't say that if I was running a business that I'd build it cloud-first instead of OnPrem. Certain use cases, sure. If I didn't need a lot of horsepower, I might build it on a cluster of VM's with some segmentation of duties - not quite microservices, not quite a monolith. Most likely if I was hosting on the cloud, I'd use the provider I work for, just because I know the system and how to get things done and how to talk to support.

I will say though - learning the ins and outs of cloud computing has made for a great career. Challenging, but lucrative.

FTA:

> Microsoft and Google decided not to officially comment on the survey's findings. However, a representative for one of the hyperscalers retorted that the figures seemed cherry-picked and pointed out that, as an example, customers using reserved instances could realize significant savings.

Reserved instances are a thing for sure. There's lots of other ways you can control cloud spend (enterprise agreements, dev/test subscriptions, spot instances, automated shut down / scale down, etc.) - it's enough complexity by itself that big companies hire entire teams of people to just work on tracking, projecting and controlling cloud costs.

[arkh]

The value proposition of "the cloud" is to ease all the "not important at first but you'll need one day" things: logging, alerting, availability, backups, SSO etc which usually requires different know-how from what devs have.

But it has become so complex that instead of an OPS team you now have a Cloud team. With a huge wallet.

Best of both worlds is to setup your own Cloud on multiple VPS which is relatively easy nowadays: HAproxy, Rancher, Kubernetes, , Keycloack, Openwhisk, Gitlab, Harbor, Opentelemtry + Prometheus + Grafana and your devops will feel right at home.

[bluGill]

If you can run everything on just a couple servers then the cloud doesn't make sense. There are a lot of companies that have tens of thousands of servers scattered around the world. just tracking them is a headache and you can offload a lot other overhead as well. Remember you are paying for the people full time to be in that computer room either if you do it in the cloud or not, but the cloud allows sharing those costs better when you don't need the computer.