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.
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.
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.
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.
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.
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.
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!
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.
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.
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.
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.
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 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"?
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.
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.
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.
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.
"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.
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.
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.
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.
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.
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.
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.
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.
