Hacker News Reader

Why is the alternative to serverless, colocating servers in a DC?

The alternative is renting VMs from those same clouds. It works fine and is cheaper when you work on software that actually has users. It also doesn't result in the cloud provider cramming a crappy under-baked programming model down your throat.

Per request pricing and "scaling to zero" is just old fashioned unbundling. You are selling a smaller quantity of a product at a higher unit price and putting a bit of lipstick on that pig to convince people they are not getting hosed.

> Why is the alternative to serverless, colocating servers in a DC?

Because that’s what the author was comparing it to. Yes you can rent vms, and that works for many workloads. However serverless platforms provide other benefits like deployments, load balancing, and auto scaling that you’d need to setup yourself on raw vms. Plus, with services like AppEngine Flex you can run serverless on vms to cut costs if you have consistent traffic.

> Per request pricing and "scaling to zero" is just old fashioned unbundling. You are selling a smaller quantity of a product at a higher unit price and putting a bit of lipstick on that pig to convince people they are not getting hosed.

It really depends on your problem. Sometimes you might have a very low QPS service (like maybe a few QPH) and running a whole vm would be overkill. Some business have really bursty traffic and maybe some regions won’t get any traffic at all during the night but they still want to deliver low latency service to the people living on that side of the globe. Additionally, these are just reasons to serverless for scale to zero and ignores other benefits, like reduced operational costs, that business can use to justify paying more for compute time.

There are lots of reasons to use and not use serverless for compute. I don’t think it is the solution for everyone and everything, but I do think the hate and FUD directed towards it is unwarranted and uniformed.

Disclaimer: I work for Google, opinions are my own

Edit: typos and disclaimer

I agree. I am working on a devops team that has assembled a half decent CI/CD infrastructure for widespread use at our company of 600 devs and thousands of apps. We are on our second iteration, which is even leaner and more invisible to the devs. However, we are seeing a move to serverless would be a net gain for all involved, specifically the scale to zero and not caring about the container and kubernetes configuration.

I think "scaling from zero" is actually the more interesting part of server-less. With AWS for example, it's super trivial to get a lambda running: no EC2 instance size to choose or elastic IP address to set up. You don't even have to choose a back-end framework, or set up monitoring to make sure your system stays available. You can just start writing code directly in the console the very first hour you start your project if you want, and already have a functioning API.

When you're working on your MVP, you can skip dev ops completely and get your infrastructure cost very close to zero. Then if you actually do end up building a product which is fortunate enough to have to worry about scale, you can work on cost optimization. I think this is a very relevant and valid use case for server-less.

>when you work on software that actually has users.

And if I don't have users? What's the number of 'users' where it becomes cheaper?

Most of the web is idle 95% of the time. Theres no reason people should pay for so much VM time that they're not using.

The best alternative IMHO is to just rent machines in DCs, it's cheap and powerful and you don't have to manage the hardware: https://oneprovider.com/dedicated-servers-in-north-america

From my anecdotal evidence, people are attracted to serverless because they spend way to much on aws and they hope that by turning things off they'll spend less.

Not many people have the problems solved by a serverless architecture (or they need more freedom), which is why it's not as common as just running your own long running instances.

Not denying your experience, as it's probably true that the folks you've seen pursuing serverless may be misguided, but I want to contest your last point where you say "not many people" would benefit from serverless.

I would say that "literally any single person" benefits from serverless if they don't have the skills, knowledge, or time to handle the server/infrastructure responsibilities that come from running software.

If I'm a one man development shop with a sufficient budget, I'll probably find it far more productive when using serverless architecture to host my business logic than not.

Serverless comes with its own problems though - a less seamless dev experience and cold starts plus you have to host your data on their choice of data store etc.

> virtually infinite auto scaling

Ah, the bullshit. When we showed GCS engineers our hadoop workload, their eyes went really big and told us that they don't have that kind of capacity in a single AZ.

Then you are working at hyperscale yourselves already, and there are maybe 50 organisations like you out there.

Maybe.

Right now I don't think that there is a single telco that has the scale to break GCP, or a single manufacturing company (exempt Tesla) or a single energy company. Or bank.

I agree that pharma, social media and streaming may do this. But since Netflix is on AWS I am doubtful of the last.

Total & Aramco come to mind.

Ok I buy that one. Oil and gas have some big problems..

I worked for one of the top-10 ecommerce shops (by transaction value) in the world. It was interesting for me to find out that the aggregate CPU power of our hadoop cluster seems comparable to what an F1 teams uses to simulate air dynamics to tune their cars.

There's a big world out there, there are probably tons of big computer users that we are largely unaware of.

Plenty of scientific computing applications fall over on the "cloud", too.

The LHC produces somewhere between 20-30 petabytes/year[0][1] (at a rate of about 200 Megabyte/second[2] after ignoring many "uninteresting" events)

The LHC is a big name, but there are many other applications in disciplines like physics, genomics, meteorology etc for whom "just use the cloud" is a terrible suggestion.

[0] https://www.popularmechanics.com/science/a16716/lhc-data-vis...

[1] https://home.cern/resources/faqs/facts-and-figures-about-lhc

[2] https://www.lhc-closer.es/taking_a_closer_look_at_lhc/0.lhc_...

I think that alphafold may indicate that biotech isn't as disjoint from cloud solutions as many suppose. Super computing is also getting eaten as grid solutions go into hyperscale, but yes ..I find you LHC and the mega telescopes.

Actually, Grid Computing.

i think you greatly misunderstand the size of some telco's and Infrastructure providers.

also, some manufacturing giants are truly enormous..

samsung for instance makes everything from smartphones to artillery installations..

same goes for hyundai, mitsubishi etc..

I did big data at one of the biggest European telcos. The only thing that kept any of it on prem was capex Vs opex (and we had sunk capex so that wasn't coming back into the budget) AT&T claimed their Hadoop installation was ten times bigger than ours, but it was still will within the parameters of any of the hyperscalers.

> or a single manufacturing company (exempt Tesla)

Tesla is TINY.

Try things like Siemens.

EDIT Besides, the point is not the whole of AWS of GCS; it's the about availability zones vs singular datacentres. Distributed computing doesn't really like to throw data even within the same AZ - in-DC will always be faster. AZ and the modern idea of distribution suit certain things - streaming, for example, benefits from it, but not everything.

> You’d have to pay engineers to build the same systems provided by serverless if you want smooth deployments and high availability. Also, imagine if you wanted to start operations outside of the continental United States. You’d need to find a data center provider, buy machines, pay someone to install them (and hope they do it correctly), and then, when ever you have a technical problem, you need to email the datacenter team to have someone plug in a KVM with 5 seconds of lag so your engineers can debug, and then you have to pay admins to constantly maintain the servers, and consistently pay for their rack space even if they aren’t being fully utilized. None of this is a problem on a fully managed serverless platform.

What are you even talking about dude? You don't have to build a rack in a colo to run a non-Serverless app. There's this thing called The Cloud now, and Virtual Machines, and other fancy new technologies from 15 years ago.

"Serverless" as in Lambda is a joke. "Serverless" as in Fargate is legitimately great at lowering ops overhead. But "zero operational overhead" is absolute bullshit. Even Lambda has operational overhead.

Serverless is just the abstraction of a function into a compute unit. There's like 20 other things you need for a functioning product, many of which literally cannot be replaced by Serverless-anything. And the severe limitations of many Serverless technologies make it very unwieldy to use.

Give it 10 years and it may morph into something more like a monolith whose functions become "Serverless", like a Beowulf cluster where forks are executed on remote nodes and there's some ugly glue to tie it all together. That seems a lot more seamless and useful than trying to architect 100 tiny pieces together with crappy custom integrations everywhere.

> What are you even talking about dude? You don't have to build a rack in a colo to run a non-Serverless app. There's this thing called The Cloud now, and Virtual Machines, and other fancy new technologies from 15 years ago

I think you are miss understanding my comment. I was comparing serverless to colo because that’s essentially what the author was doing. I agree that there are plenty of other cloud compute solutions that work for many workloads.

> There's like 20 other things you need for a functioning product, many of which literally cannot be replaced by Serverless-anything

I totally agree. Serverless is usually just a piece of infrastructure that is combined with other resources like databases, batch clusters, blob storage, vms, etc. I don’t think you’d be able to create a very interesting app using stateless functions alone, though I could be proven wrong ;)

I totally see the advantages, but how many benefit from that? Most companies don't need to deploy on servers world-wide, and don't need infinite scaling.

And cloud debugging has its issues too: I remember endless fudging with print statements, deploying once more and waiting for the changes to propagate in a AWS lambda handler, because the bloody thing simply wouldn't run locally.

> I totally see the advantages, but how many benefit from that? Most companies don't need to deploy on servers world-wide, and don't need infinite scaling.

That’s a good question. I think serverless has a lot to offer, global compute, and infinite scaling are a subset of features. I think it really comes down to your specific workload—it’s definitely not a be all end all silver bullet

One example I can think of I mentioned in another comment in this article which I have pasted below:

the first company I worked at was very small, under 30 people, sales included, and I was hired on as an SA. If they were using serverless, they would not have needed to hire me. Deployments and system upgrades were very toilsome. The dev lead would spend a few hours deploying new code and we’d only do it around midnight in case there was a problem (our customers were almost entirely US based). I spent a lot of my time automating OS upgrades on the web servers behind our proxy. All of this work would be unnecessary for that small company if they were using serverless. Additionally, as mentioned before, the majority of their traffic was during the day so they could have scaled down automatically at night, cutting costs. Would this be cheaper than running machines 24/7? I’m not sure, but I could see why you’d be interested in at least looking into it

lol. You are totally conflating 'serverless' with using the cloud, period.

Not going with Lambda in AWS doesn't mean you can't use EC2, EKS, ECS, Elastic Beanstalk, and so on and so forth. You're the one spreading FUD.

I think you are miss understanding my comment. I was responding to the author’s comparison of serverless and the cloud to collocated servers in a DC, I never argued that other services in the cloud are bad/shouldn’t be used/inferior to serverless in all cases.

I suppose this wasn’t clear because another commenter had a similar question/response