Serverless Map/Reduce
tothestars.io
tothestars.io
http://i.imgur.com/BNAcSsn.png
I've been using Lambda quite a bit, I think it's SO amazingly useful. Tasks that are highly parallelized and CPU intensive can literally be infinitely scaled out. I find it weird that their poster child use case is still always a reactive event like watching S3 and formatting images. There are so many use cases for directly invoking a lambda directly from your code.
Imagine a case where you had to parse a million documents with a relatively expensive computation, let's say 250MS per document. Maybe you have a solid machine with a few cores that's running your server, but even then you can't have the server cpu locked for so long, so naturally you'd need some sort of worker server set up. With a good machine and multiple cores, maybe you get 8 running at once. With a lambda, you can forego the worker server altogether. Just invoke a million lambdas directly from your application server, completely parallelized.
Theoretically, you've taken something that would take 70 hours and had it run in 250ms without having to set up any additional infrastructure.
The only caveat for those considering taking this path - AWS has an account-wide limit of 100 concurrent lambdas running at once. There's no way to know how many are currently running unless you keep track of it yourself. You'll only find out when you try to kick off a job and it get's throttled. I haven't contacted support yet to find out how hard it is for the limit to get raised or what they'll raise it to.
It's not technological - it's about ensuring they have a reasonable handle on capacity and what they happen to have plenty of.
It's not a problem as long as you're not asking for astronomical limits, but people need to be aware of it and request increases in advance of starting to hit limits rather than assume it'll be near immediate to get them lifted.
And you've spent the cost of building out that 8 server infrastructure in one batch.
Assuming 70 hours at $0.000000834/100ms [1]
The whole job costs $2.10.
If you can peg the CPU and don't mind getting interrupted, spot instances are still a fair bit cheaper. But Lambda looks pretty attractive for any other use-case where the statelessness of Lambda doesn't bite you.
Meanwhile, on Lambda, you can actually run 1600 60s jobs (or 27 CPU-hours) in 3 minutes. This is inclusive of setup time, job submission, stragglers, etc. [1]
Of course, if you've got sustained load, it's cheaper to go with spot instances, but the "occasionally I need a buttload of compute," model is well-served by Lambda.
Joyent Manta: https://www.joyent.com/manta
Hyper: http://hyper.sh
Possibly Joyent Triton: https://www.joyent.com/triton
I personally often want to run a bunch of things for ~1-15 minutes, and have too much data or setup to fit neatly in a lambda function. However, I don't need 1000 things running simultaneously, although manta would help still there.
I'd love to see some more layers over the top of services like this, hopefully someday getting us back to picloud. I miss that service.
I also feel like your comment is implying that the outcomes of the lambda option vs the worker server are comparable. As mentioned, the worker machine will still run in hours, rather than less than a second.
The guts to make all that work was 50 or so lines of config. I think my auto scale script was 20 lines or so of Python.
I guess the biggest downside was spinning up the new server took about 2 minutes, so for big load spikes it took a bit for it to level out... but with GCE per minute billing, all the napkin math I did says it is a fair bit cheaper per cpu unit to do it this way.
In conclusion, someone good with devops + a normal work queue system could do this years ago. I guess it's cool to lower the barrier to entry, but not it does not seem like a game changer. It totally IS cool to scale out backend work to a job farm. Just seems like not the only way to do it.
- Per-minute billing
- 0-to-cluster in under 90 seconds (aim for 30 seconds)
- Pre-emptiblem VMs
- Custom VMs
Now you start with a job, pay a 30 second penalty, and execute it on an entirely ephemeral cluster. The "get a cluster and fill it with jobs and round up to an hour" model is indeed outdated IMHO.
(work at Google Cloud)
Because those are the things that need to be done in the real world, 99% of the time.
Sadly, we don't all get to work on cool stuff :)
But I think as more people get access to the power and find uses cases, it will get used more.
The 'next' step for Lambda is serverless hosting for web-sites, something which Lambda is 'almost but not quite' ready for, the limiting factor being transactional latency, especially in some weird cases. Once they have that sorted out, I will never want to see a server again :)
Also a simple conversation with AWS increases the limit[0].
They obviously don't want people to write absurd runaway structures and 100 is an arbitrarily chosen value to guard against that.
I've considered the possibility of having students do things on AWS (beyond web dev), including Lambda, and just expensing the costs. It seems feasible to quickly set up every student with controlled access via IAM...but is there a way to set up rate-limiting, ideally through a policy? That is, shut an IAM down if a student accidentally invokes a million processes? Or, for that matter, limiting the storage capacity of a S3 bucket?
Google cloud gives free edu grants.
I'm willing just to expense things on my account for the sake of simplicity but will see if AWS has a more streamlined process for class/per-student approval. Thanks!
If you go serverless though, it's probably not going to be an issue. I would be amazed if a student used more than $10 doing anything with lambda.
Such a model would allow infrastructure developers to abstract away most of the concerns around networking, collisions, security, etc., and let game developers concentrate their efforts on simply making the game.
I currently have a game server cluster written in Golang, where the locations are instantiated with an idempotent request operation. It doesn't matter if a particular location-instance exists at a particular moment. It's sufficient for the "master control" server to only approximately know the loads of the different cluster server processes. My experience leads me to believe that something like AWS Lambda, but optimized for implementing game loops would work well, so long as game developers could get their heads around pure functional programming and implement with soft real-time requirements in mind. (John Carmack already advocates the use of pure functions, and game devs in general already do the latter.)
The code was on GitHub but I can't seem to find it.
But what's the solution for structured data? DynamoDB is the obvious main candidate, but it's billed by hour and high concurrency is very expensive, requiring complicated temporary increases and decreases of concurrency that are hard to predict.
Is there a good solution for running massively parallel lamdas on stuctured data?
If you're dealing with a TON (5+ TB) of data I recommend heading in to RDS, BQ, or redshift.
It seems the only storage services compatible with variable unlimited bursts of concurrency are S3 and SimpleDB. S3 comes with many problems for handling structured data (no update of records only replace, locking, listing items is slow/costly, etc.). SimpleDB is no longer being iterated, is limited to 10gb per domain, and looks like it's being slowly phased out.
It seems like massively parallel lambdas depend on few fetches of large blobs of data - which is basically batch-processing EMR-style, or better suited to redshift. Not something that opens the door for novel use-cases.
I would have really liked for dynamodb to be more of a service than a vm. I wish its concurrency was unlimited and you paid for usage rather than time. Basically DynamoDB with SimpleDB pricing.
If you only need one index, then just name your s3 document by the compound index value and call it a day.
Otherwise, just use RDS for everything.
> In order to maximize your workload’s throughput on Amazon Aurora, we recommend building your applications to drive a large number of concurrent queries.
Perrrrfect. Thanks!
It's like saying deathless meat, because someone else killed the animal you are consuming.
It's a genuine business case, as running a lean and secure server farm is no child's play, but it's also oversold so much that my eyes hurts.
Actual serverless computing would be implemented as p2p. Possibly interesting in a typical EvilCorpesque large corporation.
Besides, Seti@home (Boinc) have been doing serverless computing for almost 20 years and it wasn't the first implementations.
Some uses of cloud services are superficially comparable to old-school bureau computing. But to say it is "just someone else's computer" is trite, grossly misleading and downright bad advice, because treating it as such will get you burned.
If you have the right workload, it is super awesome.
If you have a reasonably matching workload and you can spend spend time on all the things you counted, it's also probably good but it's far from a clear-cut certainty.
If you have heap of legacy systems you will basically need to rewrite a lot it to make it work, and then it might not be worth it at all. This is the case that is oversold.
If anything, this model can provide a more straightforward costing model. e.g: x transactions = x lambda calls = x cost
Also saves you the work of setting up an autoscaling infrastructure.
If you have seen "the interview", this is like when the guy says "on the line", and gets corrected each time.
The concept of 'server' loses all meaning in this given architecture.
You create 'Lambdas' - units of functionality - and they do that they are supposed to do entirely independent of the underlying architecture.
In fact, using the concept of 'server' in a Lambda situation probably obfuscates the situation and adds unnecessary complexity.
A 'server' is an implementation detail that concerns only those providing the container/Lambda services. As long as the implementation lives up to the SLA (i.e. performance, uptime, security, price, redundancy) that you have agreed to - then it doesn't matter how it works.
So it is, in fact, both a lie and misleading.
As seen in: human history, evolution, etc.
'Serverless Computing' as a term to describe the paradigm I think is very neutral, descriptive and apt. It's even a little bit boring but it does the job.
The primary difference between and Lambda architecture and a 'serverless architecture' is that the app-maker does not spend any effort, though, or concern in managing servers.
That there may or may not be servers under the hood is irrelevant.
Nobody ever used a social network and had to manage servers to do it, or ever referred to servers, nor where they implied.
Using a 'social network' has nothing to do with servers.
Managing back end infrastructure is fundamentally a 'server oriented' paradigm.
'Electric cars' are a perfectly apt name to refer to cars that are not gas/cylinder engines, just as 'steel roofing' is perfectly apt to differentiate from the standard tar based products at least in consumer roofing (in cold climes).
Salesforce's mantra for a long time was 'no software' - which was reasonable because IT departments didn't have to install and manage software, although obviously salesforce themselves use 'software'.
'Serverless computing' is a perfectly fine name, 99% are fine with it, they know what it means, and it has nothing to do with Amazon's marketing initiatives. In fact - Amazon is way behind in positioning it - they are not even properly catering to hosting websites using the service, they are still mostly focused on IT folks.
So when I goto facebook, instead of a server, I connect to a ______?
> 'Electric cars' are a perfectly apt name to refer to cars that are not gas/cylinder engines, just as 'steel roofing' is perfectly apt to differentiate from the standard tar based products at least in consumer roofing (in cold climes).
Electric cars are called so for semantically useful and intuitive reasons: They are electric instead of gasoline. Steel roofing is called so for semantically useful and intuitive reasons: its a roof made from steel instead of tar. That seems incoherent as a defense to using them term "serverless" to refer to something that is literally a several buildings full of servers.
It's perfectly reasonable IMO for that to be called "serverless".
It's perfectly reasonable IMO for that to be called "farmless chickens".
Don't worry about them. Just keep doing your math in roman numbers. It's fine.
It bothers me that some people don't like my roman numbers. They work! Look!!
I + I = II
MMMCMXCIX - CXXIII = MMMDCCCLXXVI
There's absolutely no way of making this better through representation! Anyone who says otherwise is a bike shedder!
In fact, also don't worry about words either. Instead of serverless, let's call them catgiraffetablechaircthulhu. It doesn't matter!
It's perfectly reasonable IMO for that to be called "factory-less car".
It sounds like the dislike comes from folks here who just want to be contrary is all.
Ok, maybe I'm not being contrarian, maybe I just like semantically useful and intuitive technical terms instead of blatantly wrong and misleading ones? Maybe the problem is that I care about my field of expertise and don't want it to be further watered down by the perpetual sloppiness of "who cares, it's just a name"?
You submit your job, function, whatever and it...just runs. You don't have to worry about servers, hence the name. Not sure why everyone feels like arguing over a simple concept, but alas.
We already have semantically useful terms/naming conventions for that. Shared Host, Cloud hosted, $LAYER-as-a-Service, etc.. No need to use a blatantly misleading term instead.
Is anyone using it in production that can comment?
FYI - we did some experiments and the limiting factor was latency. 250-300ms on average, you have to go through their API feature as well, and that's part of the delay. But worse - Lamda's that have not been called for several minutes (I'm assuming they are not 'hot') often take several seconds, up to 5s to be called. So it creates a problem for intermittent traffic.
If that kind of latency is acceptable to you, it might work for you so long as the cost equation is right.
I think some other people had issues with versioning, it's a problem we didn't go far enough to observe.
P.S. Quoting the author: "As you can see for these queries, the reference implementation performs reasonably well; it's nowhere near Redshift performance for the same queries, but for the price it really can't be beat today"
Disclosure: I work on Google Cloud, but I'm just pointing out a fact ;).
"With HyperContainer, we make the performance/overhead of virtualized container similar to linux container --- 130ms launch time, and sharing the read-only part of memory (kernel and init)." -gnawux
Lambda is a fully elastic infrastructure you can build, deploy, and execute functions.
Simply having docker-engine and docker-cli installed on my machine doesn't give me anything close to lambda.
I find that term confusing, too, but it seems to be well-established by now, so we have to live with that.
Please refrain from strawman arguments. I wrote "AWS lambda and/or similar services".
In the Fowler article, you find a nice classification of these services:
- BaaS (Backend as a Service)
- FaaS (Funciton as a Service)
That’s the linguistic descriptivist position.
We can also require all papers and journals and conferences to use "Function as a Service" everywhere, and force all professors to teach "Function as a Service", and require all official publications to use "Function as a Service", by defining an authoritative dictionary, which gets its authority by law.
Then wait a few months, and the term "serverless" will be gone.
Some countries handle their entire language that way – and have an official institution tasked with updating the language every few years, and the updates become mandatory for business communication, press releases, and schools.
Germany and France are some examples.
IMO, having grown up right after one of the largest such changes in recent German history, it’s a better system than letting the mob decide how to call things, or how to write words, because that leads to pure chaos.
I’m not sure why English speakers resist it so much, it simplifies the situation so much, and isn’t an issue anyway.
Similarly the metric system - which has actual advantages that mere linguistic change does not, and legal support - has been accepted only very grudgingly. ( https://en.wikipedia.org/wiki/Metric_Martyrs )
(Doesn't linguistic reform occasionally cause discontinuities in literature? What happens if you want to use a metaphor or turn of phrase that's been forcibly obsoleted?
Like, I might occasionally refer to something as being "tuppence-ha'penny", despite that coin being abolished over thirty years ago.
The same that happens when you try to read any old literature. Like the Illias, which talks about "wine-colored sea" (it was dark blue – the brightness was meant, not hue), or shakespear, etc.
> It's simply not something that belongs to the state, or even to the country.
That likely differs here because the German language was unified in the first place by an academic, and not through consensus.
When you hear "serverless", just think of it as a service where you don't have to worry about running or maintaining your own OS on a server weather that is virtual or bare metal. That's it, it's as simple as that.
We’ve renamed Camouflieren to Tarnen, and many other words like that.
There’s hundreds of cases of words being entire replaced.
A list of replacements of the past centuries, for example: Distanz → Abstand, Liberey → Bücherei, Moment → Augenblick, Passion → Leidenschaft, Projekt → Entwurf, Addresse → Anschrift, Korrespondenz → Briefwechsel, Komödie → Lustspiel, Dialekt → Mundart, Orthographie → Rechtschreibung, Journal → Tagebuch, Autor → Verfasser, Fundament → Grundlage, Antike → Altertum, Parterre → Erdgeschoss, Universität → Hochschule, Terrorismus → Schreckensherrschaft, Singular → Einzahl, Plural → Mehrzahl, poste restante → postlagernd, Coupé → Abteil, Perron → Bahnsteig, Billet → Fahrkarte, Retourbillet → Rückfahrkarte, download → herunterladen.
And even today there are large companies even funding groups working on replacing parts of the language, be it to replace foreign words, or to simplify words: https://www.rossmann.de/unternehmen/soziale-verantwortung/so...
Obviously, the far-right takes it to an extreme level, even replacing Internet with Weltnetz, but even in the left-wing there’s no opposition to replacing words, or simplifying the language.
And even those opposing those changes (see criticism section here https://de.wikipedia.org/wiki/Reform_der_deutschen_Rechtschr... ) don’t oppose these concepts in general, just would rather like to see different changes.
Recommendations by various authorities on what constitutes "good" use of language change, and in Germany there might be more reliance on the big dictionaries (but I honestly can't accurately gauge how this compares to various parts of society in English-speaking countries), but actual language use does not care all that much. The reforms and the dictionary are very relevant for spelling and grammar, but have not much influence on actual selection of words, even less in specialist subjects.
People try to change language use with all kinds of motivations all the time, but they can't do much more than suggest, individuals and organizations decide what they agree to and what they don't. And this exists in other languages just as much (trying to avoid offensive terms, trying to sound modern, trying to remove foreign influences).
And that person has pushed all of those words into popular use by cooperating with other authors, writers, newspapers at the time.
So, yes, that stuff is possible.
> but they can't do much more than suggest
Except, the authorative dictionaries have authority in Germany because, per definition, tests in schools have to be graded based on them, and official communication of companies has to be written with them.
If a dictionary says "deprecated", these have to switch.
Which, in turn, has a direct effect only a 13 years later (the maximum time it takes someone to go through school).
For purposes other than spelling and some grammar rules, dictionaries are nice suggestions, but even in school (where the Rechtschreibreform actually has legal "power", even if it doesn't anywhere else) a word not being in the Duden didn't mean it didn't exist (and conversely, just because it is in there doesn't mean it's good to use). Professional usage has its own conventions (newspaper styleguides, common terms and ways of writing in scientific disciplines, "PR speak"), even if they make for "worse" language, common usage varies even more. And nothing actually enforces language in all those areas, which make up most of our language use. On the contrary, it's used as input for new iterations of guidelines and dictionaries.
Spelling and grammar has been "designed by committee" and relatively successfully legally enforced, the words used are not. They are influenced by motivated groups, but that's part of the linguistic discription model just as well.
On AWS' side yes there are servers powering Lambda, but developers do not have worry about them at all. The code just runs.