Hacker News Reader

Comment by drderidder | Hacker News Reader

This looks great, but it's important to bear in mind the architecture you intend to run on. I recently made an application blazingly fast by - among other things - parallelization using the node cluster module. On my 4-core laptop it flies. Imagine my surprise when I deployed to the cloud environment and found the typical virtual server in our cluster has only a single CPU core. The worker threads just sit around waiting for their turn to run, one at a time. On the other hand, the platform for serverless functions has 8 cores. At a minumum, before you jump into multi-threading, know what `require('os').cpus()` tells you on your target platform.

View on HN

Great reminder of just how expensive of cloud compute cycles are.

Imagine buying a new desktop computer, not the most expensive but a good performing one, and setting it up at home to serve some kind of cloud services. With its cpu fully utilized 24x7, I bet buying equivalent compute at AWS would be crazy expensive per month.

Of course there are many reasons most people don’t use desktop systems as home servers, but I bet there are a few scenarios where it could payoff.

One example might be a bootstrapped startup tight on cash flow, with cpu biased workload, so ISP bandwidth and local disk throughput didn’t bottleneck before the compute did. And it couldn’t be a mission critical service, something where some maintenance windows wouldn’t kill your reputation.

Finally you’d need a way to really minimize admin/devops costs. That kind of work doesn’t take many hours to kill your savings not to mention opportunity costs.

I use a laptop for my CI server. 8 cores and 16gb ram, hides in my basement. Would easily be $400 a month for those specs.

An m4.2xlarge on AWS EC2 provides 8 cores and 32 gig of RAM for 40 cents/hour. That'd be $288/month. You could also get an m4.xlarge with 4 cores and 16 gig for $144/month.

Of course, that doesn't include storage and bandwidth.

I mean, sure. I've got a 5 year old laptop that will outperform the t2.micro I'm pay $8.35/month for. But I don't trust my home internet to be stable or fast enough. Not to mention that my primary usage is an IRC bouncer, so I need it to not be on my home internet connection so some script kiddie doesn't DDoS me after I ban them from a channel because they were spamming racial slurs. Yes, that has actually happened.

In the US you can't really get a reliable network connection to your residence. The entire shift towards the cloud is in no small part due to crappy internet. The large ISPs really missed the boat on this.

This is not at all true for me at least. I get very reliable internet, both at home and at my office. At my office I have static IPs and am allowed to host stuff..

Now I would not host my main customer site there. But dev servers? Beta servers? QA servers? Hey why not.. save some massive bills.

Exactly... you won't host a main customer site at home. If ISPs were smarter, they would make this easier for you and provide the tools to make it extremely easy. ISPs could have been AWS or Azure, instead they preferred to be a flaky bundle of wires.

Depends how reliable you need.

I average probably a single 5 minute hiccup each month. That's 99.988% uptime. For someone wanting to run their WoW guild's voice chat server, or just a toy server, or a development/staging environment, that's plenty.

But I mean, my home internet is only 35 mbps anyways via Frontier FIOS. I can get 150 mbps through Comcast, but I refuse to give that company a penny of my money. In either case, I'm not going to be running any major production servers at home anyways.

I have Time Warner, and experience about 10-15 minutes of downtime a week on my home wifi and once a year it'll go down for an entire evening. That's annoying, but fine for home wifi and maybe a hobby website, but you couldn't run a company like that.

>An m4.2xlarge on AWS EC2 provides 8 cores and 32 gig of RAM for 40 cents/hour. That'd be $288/month

used ThinkPad W540 with same config goes for ~1.5 months of your AWS rent.

And it even comes with a "free" UPS :)

Laptops are surprisingly good as little dev servers. In fact, you can find ones with broken screens for even cheaper, which is fantastic!

Few hundred bucks can get you a nice i5 or i7 processor

Hetzner basically uses cheap desktop computers as dedicated cloud computing servers. Just keep it backed up. If anything catches on fire, they replace it. Cheap hardware mitigated by excellent customer service. If you can deal with that, the prices are great. I've used them for years for my personal dedicated server, and not had any problems. The current EX41 line starts at 39 EUR / month. You have to buy the "flexi pack" if you want luxury services like extra ip addresses.

https://news.ycombinator.com/item?id=4063929

https://www.hetzner.com/dedicated-rootserver/matrix-ex

https://www.hetzner.com/flexipack/

Extra IP addresses don't require Flexipack, maybe subnets do.

Which platform for serverless functions has 8 cores? I have a CPU intensive data deployment script (Node.js) that takes 12 hours on a single thread but can be chopped up to take advantage of more cores. Our build server on ec2 has 2 cores so it's about 6 hours. It would be great to know if we could push the job into serverless and get it done a lot faster.

Time limits on serverless functions are 9 minutes on GCE and even less on AWS, so for long-running stateful tasks they're probably not suitable, unless you can divide the work into serial as well as parallel subsets.

Thanks for the reply. The task is not stateful. It's just pulling data from a db, performing some transforms, and then pushing it into elasticsearch. I suppose that I could slice the tasks up to be arbitrarily small though having a longer window would be helpful. I guess I will take a look at GCE. Thank you!

FWIW I think Azure's Functions are 10 minutes and I hear they're talking about upping it again.

How can a "serverless function" have cores if it doesn't have servers and "it is just code" :/

Because "server" started taking on the meaning of "configurable box" to people who were frustrated with configuration, so "serverless" means "unprovisioned/unconfigurable" machines.

Now if we started talking about "computeless" architecture I'll be confused. (Though maybe that'll be the trendy name for serverless data sources/sinks in a few years...)

> so "serverless" means "unprovisioned/unconfigurable" machines

I am pretty sure in English serverless means no server and "unprovisioned/unconfigurable" machines means you didn't provision them and you cannot configure them. Even in analogical sense this makes no sense. Something i could relate to is something like "Pay as you use" or "configurationless servers".

But that is just me, and if you think it is ok to randomly change the meaning of words that means me personally and randomly don't need to accept your new meaning (not giving out, just trying to explain my rationale)

Downvote all you want, but please do point out where i am wrong.

I get it, I do. But that ship sailed loooong ago

The "serverless" in this context means that they may as well be invisible to you, since you don't need to care about them. In the case of Lambda, you upload your code somehow Amazon runs it on a spare server somewhere.

Language is all about context. The meaning of words changes depending on it, even in plain English settings.

You're not wrong. "Pay as you use" doesn't quite capture it, and "configurationless servers" isn't quite buzz-wordy (eg. short and memorable) to make marketable.

Wide spread terminology suffers from the evolutionary pressures of marketing. Only the catchiest, most marketable terms propagate.

> please do point out where i am wrong

Because speech (and writing) can be figurative, not just literal. And because the term has reached wide adoption (at least, in the subset interested in discussing such things) and so not using the term makes conversation difficult and litigating the issue every time it's discussed adds no value to the discussion whatsoever.

The ship sailed a while ago for common nomenclature for “function in the cloud” services. You can’t really fault someone for using the term the way the entire industry uses it.

For what it’s worth, I don’t think calling them “configuration-less” or “pay as you go” servers is any more accurate. You’re really just buying processing time.

You're not wrong. I usually call them "application-less" architectures. That's really what's going on here.

In a very literal sense, you're not wrong. But the concept of a serverless architecture (as of common parlance today in 2017) has a lot of nuances which are hard to convey in any single word.

So eventually people picked one. Today, the most common are "serverless architecture", "FaaS", or simply "Lambda" (borrowing from AWS).

You don't have to do anything. But it's simply a fact that many people know what you're talking about if you say the word "serverless". And that's what language is, a (kinda) agreed upon set of words which let you communicate with other people. If everyone but you understands a word, and you are crusading that they change it to something else, what is the point?

If you're interested, the concept of "prescriptivism" may be enlightening.

My point is that i was not aware what "serverless" meant when i first came upon it and the word itself did not convey any meaning without a lot of context as it does not lend it self to analogies such as "server", "container" or even "cloud" for that matter.

I get you. Neither was I. But at a certain level, words are arbitrary and imperfect anyway. In your own example, "cloud" is often regarded as a bad term, because it tends to abstract away too much that it's just "somebody else's computer", as it's often defined.

Lots of discussions have been had on how many people think "the cloud" is a sorta-magical thing, which "is just there". Just more recently some interesting aspects of "using the cloud" have been more thoroughly discussed (e.g. the jurisdiction it's hosted in, data breaches, etc). If the concept was described in a less abstract way, would these discussions have happened sooner? Later? Would it have become less of a "buzzword" amongst executives?

So, is "cloud" really a better term than "serverless"?

True. I regularly encounter words whose meanings in whatever context I don't understand. Usually, if a word sounds confusing or used in the wrong context, a quick Google search will clarify what I was missing. Sure its a bit irritating when words are recycled to have a different meaning, but its rarely an issue in practice, in my experience and opinion.

I'm also pretty sure most cloud systems contain very few condensed water droplets. The containers I work with are not 20 or 40 foot long, and while I ship stuff with their help, no actual ships are involved.

Could there have been a better word than serverless? Probably, but that is the one that is currently used for that general kind of architecture. I would have called that PaaS before, and sometimes still do.

I explicitly stated that by analogy it does not make sense, while containers contain something and works as analogy. But you chose to disregard that part of the answer.

"Serverless" means "I can run code without having to maintain my own server or execution environment". Using the term "serverless" for that might be confusing and non-literal, but that's how we use it, and the term has stuck. Arguing about that several years ago may have made sense, but that ship sailed long ago.

While you're at it, Don Quixote, please convince X-Windows to stop abusing the words client and server, too.

> please do point out where i am wrong.

In reality, words are often used in ways that don't necessarily meet the dictionary definition in the strictest sense.

For example, I complained to my local advertising authority that mobile providers are using the word "unlimited" to mean "limited by our fair usage policy" and I was told that this is fine as long as 95% (I don't remember the exact percentage, maybe it was 99) of customers will never reach the limit so its effectively unlimited. That's not really what the english language word means, but hey... that's life. Same thing applies here: words are recycled to have different meanings.

Its a bad example because saying something is unlimited when its not is kind of bullshit not just semantics.

There are situations when I think its best to just go with the flow of how people are commonly using words but simply accepting what others say in a blanket sense is not right either. In the case of "serverless" it doesnt really matter much to me, but if you think of the word "gyp" for example thats something many people have had to make a conceited effort to stop using. So in some cases, with effort we can improve the language we use and not always be swimming against the tide.

Though the functions are serverless in the sense that you needn't allocate virtual infrastructure, the platform obviously utilizes CPU resources to execute your function. That platform underlying the serverless function is, as it happens, multi-core in GCE.

> Though the functions are serverless in the sense that you needn't allocate virtual infrastructure, the platform obviously utilizes CPU resources to execute your function.

So it does allocate virtual infrastructure?

Someone does, but not you. Obviously, there's a server somewhere which runs your code. But since you don't deal with it directly, it's mostly as if there was no server - since it was abstracted away form you so you could focus on what you really want to do.

If you were to go down deeper, a server is just an electrical machine which shuffles eletrons around. So, you could say "there's no point in talking about 'servers', if we're just using transistors when you really think about it".

But it would convey no useful information if someone asked you "what are you using to run your service?" and you replied "well, I just move electrons around", would it?

No, i am not advocating reductionism, server has a analogical meaning as it serves something. Processing has analogical meaning as we do processes something, serverless implies there are no servers involved.

As far as managing goes, most of the server are not managed by you anyway. But yeah i get it, everyone likes it so...

On the management side, I'm curious what you mean by "most of the server are not managed by you anyway". In my experience, unless you're in a very big company, you are either managing or at least minding the server, or someone within earshot range is.

In that scenario, not having to even consider if the error you're getting is because your server is restarting/out-of-memory/needing-update/broken-by-a-coworker like 99% of the time is as close to "serverless" as it gets, in terms of day-to-day work activities and worries.

Not serverless, but we host our build servers on Scaleway. 8 cores and more importantly 32GB for 25$/m. Can't complain. Clean up is done by the ci agents from VSTS.

Project is a React client and express backend. It's built and tested dockerized. We use testcafe and Chrome headless, so more memory is always useful for parallel builds.

Different ec2 server types have different numbers of cores. You might be able to just change the server type to get some easy performance boost.

Just use EC2's r4.16xlarge instance.

The distinguishing factor between multi-processing on one machine and multi-"machining" is latency of communication.

Likewise, the distinguising factor between multi-threading and multi-processing is shared memory, i.e. again, the speed of communication.

Multi-threading does well for some problems, but often, multi-machining or multi-processing is sufficient, which is why so many runtimes don't really do multi-threading: Node.JS, Python, Ruby.

Very true, and we've seen better performance from multi-process than multi-threading in some high-traffic (10Gbps) systems (those were C++ however, not node). It was puzzling, but I put it down to the OS scheduler; I imagine that a single multi-threaded process would be pre-empted in the typical fashion, but that multiple single-threaded processes would, in aggregate, spend less time in a pre-empted state.

Context switching is expensive and very tempting to forget about in multi-threaded development. You eliminate that overhead constraining the execution code to a single thread context.

Yes, multi-threading has high overhead to provide the illusion of parallel operation, but when all the cores are saturated you are in the same boat, whether you have 1 or 100.

The benefit to programs that don't use threading and use event loop and shared nothing multi-process is that they don't have the overhead when things are maxed out.

This is why virtually every high performance server (nginx, redis, memcached, etc) is written this way and things like varnish (thread per request) are multiples or orders of magnitude slower.

Funny people criticizing nodejs for using the same architecture that all the best-in-class products use.

Note that Python does do multithreading - just the actual Python interpreter will not interpret Python code from two threads at once. If threads are busy running code that doesn't require the interpreter, whether it is CPU bound work or not, then as many threads can run as you have cores. In most CPU bound applications, the performance critical parts are not pure Python - they're calling out to some extension code such as numpy or cython or something. Such code runs in parallel in CPython if you start multiple threads.

This might have been what you meant when you said the runtime isn't really multi-threaded - but since the CPython ecosystem rests so heavily on C code, in practice multithreading is a good solution a lot of the time.

Right. And Ruby also has a GIL.

Node.JS, Python, and Ruby are in C/C++ so you can do multithreading in all three, if you are willing to write native modules.

Yes. Python gets all the heat for the GIL, but most similar languages have something with more or less the same effect.

If you're careful you can release the GIL when writing Cython code.

Better than C/C++ sometimes.

This is also a painpoint for me, I have an app that doesn't use much memory, but can use multiple cores/threads.. but most providers sell you on RAM, not CPU.

Also many providers charge by CPU usage, so it behooves customers to spec machines as lightly as possible and fall back on auto-scaling to spin up additional, equally lightly-spec'd VMs, on demand. Rarely are there many idle cores just sitting around.

good point. I’ve used pm2 to manage node apps and like how clear it makes what’s running on what.

Reply on news.ycombinator.com