13 ms·

Serverless Computing: One Step Forward, Two Steps Back

465 points by snaky 8y ago

SlowRobotAhead 8y ago
I’m not sure I would call it two steps back. I think it’s quite obvious that every web application everywhere doesn’t need a full OS install chugging along all day everyday waiting for things like mouse input or having its own patches for services that will never be used. It’s first gen tech. Really curious to see where it goes.
- bpicolo 8y ago
  The paper authors agree: > Taken together, these challenges seem both interesting and surmountable.
- colemickens 8y ago
  I mean, where do we think the functions are executing now? It's not like Ubuntu Server is running Xorg, or has libinput installed, nor have any of those things ever been operational or developmental considerations on any "non-serverless" app. Or maybe you're in a super cutting edge functions deployment where you're actually deploying microkernels? Seems orthogonal to me, and doesn't seem to address the data locality, etc issues brought up in this article. There are so many people in this thread saying stuff like "PaaS doesn't allow auto-scaling" and I just don't really know what's going on. It's baffling to me. I guess if all you know is an archaic build process and manual deployment, then it looks great. But I'm willing to bet most of these function platforms bottom out on containers-on-k8s-on-vms anyway. I am increasingly, increasingly convinced that people don't really need or want "serverless". They want the final step in the build/development process that they thought they were going to get with Docker -- they want to write code and have it running somewhere. I really don't buy that Serverless/Lockin are the right or best way to that future.
  - SlowRobotAhead 8y ago
    >They want the final step in the build/development process that they thought they were going to get with Docker This isn’t my area, so I don’t know - but why didn’t people get that with Docker?
    - DATACOMMANDER 8y ago
      They didn’t get the magic functionality they wanted because magic isn’t real. Coming from a devops background with more of an emphasis on “ops” than “dev”, my (admittedly biased) opinion is that a lot of developers believe three things simultaneously: 1) Ops people are bitter, power-tripping killjoys who couldn’t make it as developers and do nothing but click buttons and think up ways to make the lives of developers difficult. 2) Ops/infra really isn’t as difficult as ops people would have you believe, and some day very soon all the ops people will be replaced by code. 3) Someone else should write the code that’s going to automate the ops people out of existence. These developers are like highly specialized scientists who think that their PhDs make them experts on everything. They have no idea what happens to their code once they commit it and they don’t care to learn, but they’re pretty sure that it can’t be all that complicated. Ops will—like everything else—eventually be eaten by software, but the people who drive that transformation sure as fuck won’t be JavaScript specialists who can’t troubleshoot their inability to connect to the VPN. They’ll either be systems/infra people who can code, or well-rounded coders who understand that infra is actually nontrivial (or a group comprised of both). If it seems like I have a problem with devs, it’s honestly only because a vocal minority of devs have a big problem with me.
      - deleted 8y ago
        [deleted]
aub3bhat 8y ago
Translation for those not proficient in Academese: Serverless computing a novel paradigm enabled by a large cloud provider, does not matches our past research, thus we argue why it's not the right thing. This is classic "if theory does not matches practice lets change the practice" approach, which is far too common in academic systems research. I trust AWS with knowing what its customers truly want (in terms of performance and cost) and what it can provide,Since AWS has real financial stakes in its success. A decade ago the same researchers would have mourned emergence of cloud computing as a wrong thing and instead asked for P2P computing since that's what they had spent the decade before doing research on.
- hliyan 8y ago
  I'm afraid your "translation" does a disservice to all the potential readers of the paper, to those who want to decide whether to use serverless computing at present and to the authors. Quoting from the conclusion of the paper: "Taken together, these challenges seem both interesting and surmountable. The FaaS platforms from cloud providers are not fully open source, but the systems issues delineated above can be explored in new systems by third parties using cloud features like container orchestration. The program analysis and scheduling issues are likely to open up significant opportunities for more formal research, especially for data-centric programs. Finally, language design issues remain a fascinating challenge, bridging program analysis power to programmer productivity and design tastes. In sum, we are optimistic that research can open the cloud’s full potential to programmers. Whether we call the new results “serverless computing” or something else, the future is fluid."
- rfonseca 8y ago
  Interestingly, a paper not 10, but 9 years ago, not by the same authors, but by the same group (systems folks at Berkeley), was proclaiming the cloud as an idea whose time had finally come. No mourning there. https://www2.eecs.berkeley.edu/Pubs/TechRpts/2009/EECS-2009-28.pdf https://www2.eecs.berkeley.edu/Pubs/TechRpts/2009/EECS-2009-...
Jhsto 8y ago
On the same note, CloudFlare’s approach to serverless computing by leveraging V8 sandboxing instead of traditional virtualization is fascinating: https://blog.cloudflare.com/cloud-computing-without-containers/ https://blog.cloudflare.com/cloud-computing-without-containe... Considering challenges of interconnected cloud computing and common IR (of which the latter is mentioned in this paper) an interesting distinction arises: WASM, in comparison to containers, brings us a single language (JS), and through this, possibly a single “orchestrator” (V8 Isolates). Of course, this is more or less saying that the world would be a better place if everyone would be driving a Volkswagen. But this is like a second chance to iterate such idea and maybe do something about it. Isn't this a step towards the future of cloud computing?
- zackbloom 8y ago
  Workers are network addressible which seems to directly respond to one of the complaints in the article. Beautifully, if you call one Worker from another they have a decent chance of running on not just the same server, but in the same process. When one Worker calls another its data doesn't even leave user-space, even if the two Workers are owned by different people. Imagine calling a third-party API and having your request never even need to leave the process to be handled.
  - hueving 8y ago
    If the request never has to leave the process, that means there isn't anything the third party API is doing that persists state or calls out to another backend. In that case, wouldn't it just be better to import this third party API directly as code and call it for significantly better reliability, performance, and reduced complexity?
    - woah 8y ago
      Then your engineers are responsible for maintaining and updating it. Calling to a third party allows you to offload that.
    - zackbloom 8y ago
karmakaze 8y ago
TL;DR 3 WHY SERVERLESS TODAY IS TOO LESS (1) Limited Lifetimes. After 15 minutes, function invocations are shut down by the Lambda infrastructure. Lambda may keep the function’s state cached in the hosting VM to support “warm start”, but there is no way to ensure that subsequent invocations are run on the same VM. Hence functions must be written assuming that state will not be recoverable across invocations. (2) I/O Bottlenecks. Lambdas connect to cloud services—notably, shared storage—across a network interface. In practice, this typically means moving data across nodes or racks. With FaaS, things appear even worse than the network topology would suggest. Recent studies show that a single Lambda function can achieve on average 538Mbps network bandwidth; numbers from Google and Azure were in the same ballpark [26]. This is an order of magnitude slower than a single modern SSD. Worse, AWS appears to attempt to pack Lambda functions from the same user together on a single VM, so the limited bandwidth is shared by multiple functions. The result is that as compute power scales up, per-function bandwidth shrinks proportionately. With 20 Lambda functions, average network bandwidth was 28.7Mbps—2.5 orders of magnitude slower than a single SSD [26]. (3) Communication Through Slow Storage. While Lambda functions can initiate outbound network connections, they themselves are not directly network-addressable [...] can only communicate through an autoscaling intermediary service; today, this means a storage system like S3 [...] (4) No Specialized Hardware. FaaS offerings today only allow users to provision a timeslice of a CPU hyperthread and some amount of RAM [...] no API or mechanism to access specialized hardware. However, [...], hardware specialization will only accelerate in the coming years.
- karmakaze 8y ago
  While each of the above points are mostly quite factual, I don't personally find any of them to be restricting. We run a mixture of stateless and stateful services and serverless is suitable for the stateless ones. The original problems for network security being solved by running functions in a VPC and secure connections to databases and even connection pools makes pretty much everything work.
  - sanxchit 8y ago
    Running functions in a VPC cause them to have cold starts of ~5 seconds. Connection pools need to be centralized to be of any use, since lambdas scale automatically.
stochastician 8y ago
I actually agree with many of the suggestions in the paper, but of course am biased as these are my colleagues and we disagree on some of the interesting capabilities of modern serverless architectures (see https://arxiv.org/abs/1810.09679 https://arxiv.org/abs/1810.09679 ) . But it comes across like this DeWitt/Stonebraker piece from back in the day, "MapReduce: a major step backwards" https://homes.cs.washington.edu/~billhowe/mapreduce_a_major_step_backwards.html https://homes.cs.washington.edu/~billhowe/mapreduce_a_major_...
sytse 8y ago
I loved the article https://arxiv.org/pdf/1812.03651.pdf https://arxiv.org/pdf/1812.03651.pdf It mentions two temporary bottlenecks: 1. Functions can run only for 15 minutes and experience cold-starts. 2. You can't use specialized hardware like GPUs. It also mentions two fundamental bottlenecks: 1. Serverless functions are run on isolated VMs, separate from data. In addition, serverless functions are short-lived and non-addressable, so their capacity to cache state internally to service repeated requests is limited. Hence FaaS routinely “ships data to code” rather than “shipping code to data.” 2. Because there is no network addressability of serverless functions, two functions can work together serverlessly only by passing data through slow and expensive storage. This stymies basic distributed computing. , With all communication transiting through storage, there is no real way for thousands (much less millions) of cores in the cloud to work together efficiently using current FaaS platforms other than via largely uncoordinated (embarrassing) parallelism. Disclosure: We just shipped serverless in GitLab https://about.gitlab.com/2018/12/11/introducing-gitlab-serverless/ https://about.gitlab.com/2018/12/11/introducing-gitlab-serve...
- Normal_gaussian 8y ago
  So knowing this what has Gitlab done to overcome it? If they haven't, why not? Why is it hard or inconvenient?
  - sytse 8y ago
    What we now shipped is a Minimal Viable Change (MVC). I suspected that serverless wasn’t ideal for all use-cases but I couldn’t articulate this until I read this paper. We have taken no steps to overcome these problems, I think we’re likely to follow the leaders in the industry like Knative from Google and TriggerMesh. In general I think serverless is more of a pattern then a technology. We’ll use Knative to offer PaaS functionality (Heroku) on Kubernetes with GitLab.
- ramzyo 8y ago
  I'm interested to pick your brain about the second fundamental bottleneck you/the article mentioned. I'm not sure that I agree that serverless functions are fundamentally non-addressable. Today they're not addressable, but why can't they be in some future evolution of serverless? Sure serverless functions are ephemeral, but during their brief lifetime, is there something fundamental keeping them from being addressable?
zozbot123 8y ago
Interesting article. It has often seemed to me that efforts such as Urbit (urbit.org) deserve our attention, precisely because they might actually deliver on the 'serverless' premise to a far greater extent than current solutions.
- akhilcacharya 8y ago
  Really? Isn’t urbit based on a computation model multiple orders of magnitude less efficient than KVM?
zygotic12 8y ago
One size never fits all. The end.
- DATACOMMANDER 8y ago
  Not exactly. The authors are part of the (large) camp that envisions serverless eventually becoming ubiquitous. In that sense, they hope that one size will fit all, some day.
  - bartread 8y ago
    > In that sense, they hope that one size will fit all, some day. Nothing new under the sun there. And, that being the case, they're likely to be disappointed.
sheeshkebab 8y ago
Am I the only one that thinks severless is about creating a bunch of vendor locked-in technical debt?
- unreal37 8y ago
  The increase in CPU utilization efficiency (and lower costs) is decreased by lack of portability. Everything has a cost. And so being able to move your code around at will is the cost of saving money.
  - WrtCdEvrydy 8y ago
    Actually, most modern FaaS based on Amazon's is portable, it's the other rest of the stack that isn't very portable.
- 2StepsOutOfLine 8y ago
  I would say that broadly categorizing FaaS as vendor lock-in would be disingenuous on its own. Practical FaaS is a simple concept as far as developer implementation is concerned. Write functions, get HTTP context, and return a result. This article really only touches on problems with vendor implementation of FaaS, AWS may have these issues with I/O and lifetime of a function, but there are many open source implementations that you could install on custom hardware that bypasses these issues. Even some of the issues that seem like fundamental issues with FaaS (non-addressable instances, unable to use specialized hardware) are already solved by other open source self-hosted FaaS solutions.
  - DATACOMMANDER 8y ago
    Care to elaborate? Edit: to clarify, I’m referring to the assertion at the end of your comment, and I’m genuinely interested.
- colllectorof 8y ago
  You're not the only one. Some time ago I worked with a bunch of people who staked their careers on moving everything to AWS and converting it to serverless architecture. Here is just one example of how fishy it was. They used Dynamo. During presentations to the outgroup, they constatly praised Dynamo as being flexible, scalable and fast. However, internally they constantly struggled with various limitations of the database, from limitations of indexing to not being able to get certain types of metadata. My point is, the architecture they were designing was heavily bent around Dynamo's strength and weaknesses. Considering how extreme and peculiar those strength and weaknesses are, switching to another database would require heavy re-engineering of the rest of their architecture, much more so than, say, switching between Oracle, MS SQL and Postgress.
i_phish_cats 8y ago
Oh look a bunch of academics telling developers how to do their job, again.
spullara 8y ago
Going through the article I think they made some mistakes in analysis and also miscategorized some features. 1) Limited Lifetimes, Stickiness: These is good and leads to good design when you scale beyond a single server. It prepares you for dealing with the reality that if you want to run a service 24/7 with no downtime you need to prepare for things like different versions being in production, failures, and stale caches. 2) I/O Bottlenecks: If you are parallelizing your workloads you will actually see more aggregate bandwidth than you could scale up quickly with normal server hardware. Sure a single Lambda might not have the full amount but you can run 1000 of them at once. 3) Communication through slow storage: This is not entirely true, you can call another Lambda directly but yes you can't access a particular instance. That is a good thing. Designing systems where you need to return to the same instance is an anti-pattern. 4) No Specialized Hardware: I don't expect this to be a limitation for long. There is no reason why you couldn't ask for specialized hardware in the definition of a Lambda and the scheduler take care of it. It will, in fact, be better than the status quo because parts of your application that don't need that specialized hardware won't need to pay for it. In a typical larger application you would probably end up running part of your heavy CPU load inefficiently on your GPU hardware because it would be convenient. Also, most of this might be unnecessary in many cases since you would likely take advantage of a service that was specifically designed to run specialized workloads. Only if you DIY would need this support. Lambda is especially good at coordinating such services. 5) Faas is a datashipping arch: Not even true today. Lambda lets you move the computation to the data like they are with CloudFront Lambda, S3 Batch and Snowball Edge Compute. It is in fact easier to execute the code near the data when encapsulated in this way. 6) FaaS Stymies Dist Computing: Maybe they have applications that can afford to fail at any point and not recover but keeping your global state in a distributed data storage system is the right thing to do generally, not just with Lambda. Might not work for HPC but it generally doesn't need to be reliable in the same way applications do. At least in section 3.2 they finally seem to understand that most of the limitations are a good thing and if you are building software that don't have them you are likely not building scalable, reliable software systems. Also, if they think that their section 4 is somehow non-obvious to AWS and others they really aren't paying attention.
iamleppert 8y ago
Having your functions be stateless is actually an asset and forces you to write your code in a way that doesn’t make assumptions about the state of some cache, which makes it inherently more reliable. Cold starts aren’t much of a problem if you have non-interactive workloads, or can design UI’s in such a way to let the user know the first interaction will be slow but the rest fast, and if your modality allows for such. These problems tend to go away with any moderate scale in any event. The time limits I’ve found to be an asset as well, and forces me to think about how to structure my task into discrete and well known units of work. This makes development harder but leads to an overall more reliable system where any one invocation failure won’t seriously jeopardize the larger task and can easily be recovered. You can’t say the same for a process that’s been running for hours and suddenly dies without committing its work. That said, I’d love to have serverless GPU functions. I’d love to be able to somehow run shaders over superresolution images. That would be amazing for me working in the mapping world.
tirumaraiselvan 8y ago
A much needed paper which goes into the programming model in serverless rather than the operational model. Although, the first cases study is obviously bad for serverless (training a ML model) whereas the second case study does not indicate bad results (using trained ML model) as half a second latency is acceptable. As the paper itself quotes: `One might argue that FaaS encourages a new, event-driven distributed programming model based on global state.` Yes, exactly. It is not made for cluster computing or data-centric applications. It is made for making applications more modular, atomic and compositional with the upside of less ops and more scale and the downside of lower performance.
- DATACOMMANDER 8y ago
  I think that the authors of the paper would say that, ideally, serverless would be ubiquitous, the obvious choice for the vast majority of use cases. A pipe dream? Perhaps. But that’s the dream, and we’ll never be able to make the dream a reality unless people write papers like this one that highlight the work that separates where we are from where we want to be.
amelius 8y ago
If a marketing term means exactly the opposite of what you think it means (that's some hefty server they've got there), then you probably should look elsewhere anyway. Unless you enjoy dealing with a community and support team that speaks an inverted lingo, of course.
- deleted 8y ago
  [deleted]
- millstone 8y ago
  Only programs that talk to servers can be serverless. In two years we'll discover the benefits of running serverless workloads on the client and there will be a new name for that.
Agebor 8y ago
I'm not sure if i understand their view on fundamental limitations - they don't seem fundamental to me: 1. It does not seem impossible to imagine a function that spawns code close to data, be it on a VM with a connected fast SSD drive already populated with data. Also, Lambda-at-edge and Cloudflare workers are already more like “shipping code to data.”, or " the customer" in this case. 2. Functions are load-balanced and potentially parallelisable to millions of invocations. The only missing piece is some kind of parallel-invoke call, to give each instance of a function a distinct piece of data to process, and an identifier to save the result under. The identifier could easily refer to a local disk location, in some future implementation. Also, another point from the article: "FaaS discourages Open Source service innovation". seems wrong to me, as it may be said only about current super-early implementations, reason being, they are new. In the long-run, I'd expect serverless to help open source, because of a simplicity of deployment. We will likely have projects working on an abstraction layer of compute and storage, hiding the underlying cloud or multi-cloud implementation. (Kubernetes is one candidate, it just needs ideas in the like of Virtual Kubelet to become more serverless).
- hueving 8y ago
  >Cloudflare workers are already more like “shipping code to data.”, or " the customer" in this case. That's shipping code further from the data, unless you store all of your data on your customers' hardware.
  - TeMPOraL 8y ago
    Is this your data or your customers' data? I'd much prefer the code that runs on my data to come to me, instead of me having to give my data away.
  - Agebor 8y ago
    The closest data would be in the datacenter closest to the customer, not on customer's hardware. But I mentioned it to illustrate that the code already is location-independent a little.
- quacker 8y ago
8bitsrule 8y ago
"Cloud" = back to dumb terminals & mainframes. Giant step back. Edit: and pulling content from two dozen separate servers ... madness^2
- DATACOMMANDER 8y ago
  Yeah, simpler to just serve all content from the file server sitting in your garage. After all, you tested your site from the laptop on your kitchen table, and everything loaded just fine.
cnbeining 8y ago
Some questions: 1. The authors are quoting exact performance metrics and limits, which is making the article more about "Amazon Lambda" rather than "Serverless Computing". 2. The authors mentioned a "15-minute lifetime" problem. Although it could be concerning that cache may be invalided sooner than running the same code on other infrastructures, a use case like this could easily migrated by using container. Not to say this number could be adjustable - this is a limit that is set by AWS rather than some theological limit. Thus using this problem to attack the serverless computing idea would be unfair. 3. The authors mentioned low IO problem. As public cloud is a shard infrastructure, it is only reasonable for end users to assume a baseline IO performance when using the platform - and this applies to any service that any public cloud provides, currently and in the future. It would be more beneficial if AWS could reveal the baseline performance in number, as this would assist developers with planning. 4. The author attacked serverless computing about its "Communication Through Slow Storage". This is probably not avoidable and is common practise in modern developing and should not be used to attack the idea of serverless computing. AWS do provide u-12tb1.metal EC2 server that comes with 12TB of RAM for this use case, though. 5. The author mentioned that currently serverless has "No Specialized Hardware". Again, this is a attack on AWS Lambda rather than serverless computing, and is a particular function that could be easily added. (I have a feeling that Cloud TPU could be used with Google Cloud Function, but it's a assumption.) 6. The authors also attacked that "FaaS discourages Open Source service innovation." Supposedly one can only imagine that more software projects would be PORTED TO serverless, and there should be no real issue running them as standalone application. I lost track of what the authors are trying to argue.
chillaxtian 8y ago
Does anyone know why lambda is taking off, compared to heroku style PaaS? Heroku style still removes the burden of managing servers ("serverless"), but doesn't lock you in as much. You could easily move your own server process to a different provider. Is it just because Amazon doesn't offer anything similar to heroku?
- chrisco255 8y ago
  A number of reasons. For one, you pay per execution with Lambda (and other similar services like Azure Functions and Cloudflare Workers)...and the costs can be dramatically lower. Here's a great article by haveibeenpwned author explaining how they support 141 million requests a month at 2.6 cents per day: https://www.troyhunt.com/serverless-to-the-max-doing-big-things-for-small-dollars-with-cloudflare-workers-and-azure-functions/ https://www.troyhunt.com/serverless-to-the-max-doing-big-thi... Besides cost, automatic scaling is something traditional PaaS does not offer.
- Jedi72 8y ago
  Amazon is the new IBM - nobody gets fired for using it. I have personally moved services which were cheaper and more performant with other 3rd party providers to Amazon just becausr higher-ups wanted us to keep as much stuff with them as possible, for obscure reasons like "we already have a relationship with Amazon" i.e. their sales rep keeps sending me free stuff and sending me on BS "training courses" with free lunch.
tyteen4a03 8y ago
Why does serverless remind me of PHP?
- TeMPOraL 8y ago
  Maybe because a making a "lambda" is quite like putting some code in a .php file and uploading it to a LAMP server, except it's pay-as-you-go and it autoscales.
- paulddraper 8y ago
  Because it's CGI. Except with vendor lock-in.
orthecreedence 8y ago
I love how everyone always shat on PHP (the original serverless technology...convince me otherwise) and now everyone is scrambling to reinvent PHP.
- toddh 8y ago
  Don't forget perl and CGI as the even more original serverless tech.
  - fuball63 8y ago
    That's why I made http://bigcgi.com http://bigcgi.com. It's just CGI behind a reverse proxy that handles file sync between hosts. My blog runs on it.
    - captainperl 8y ago
      BigCGI looks interesting. I signed up for your newsletter.
      - fuball63 8y ago
        Thats great, thanks! Im working on getting the blog up and running, and plan to cross post there, along with any news about the platform. Feel free to email me any suggestions... my address is on the bigcgi site.
- CharlesW 8y ago
  > I love how everyone always shat on PHP (the original serverless technology... I like and use PHP, and you absolutely can create serverless solutions with PHP, but you may be confusing "serverless" with "stateless". PHP itself is in no way intrinsically more "serverless" than other options.
- mypalmike 8y ago
  Does PHP automatically scale infrastructure to meet demand? Can you bring up 1000 instances of your service for spikes in volume? And then scale back down when the spike is over? Without writing code? Nobody is reinventing PHP.
bfirsh 8y ago
Here's a web version if you're on a phone: https://www.arxiv-vanity.com/papers/1812.03651/ https://www.arxiv-vanity.com/papers/1812.03651/
suyash 8y ago
If you want to avoid vendor lock in, may I recommend open source FN Project - you can run anywhere as it's container native serverless platform. https://fnproject.io https://fnproject.io (Full Disclosure : My company supports development of this project).
bitL 8y ago
If I were a Machiavellian dominant player trying to keep my advantage in distributed systems, I'd invest into serverless propaganda to mislead everyone performance/cost-wise, keep my dominant position and get people doing real performant distributed systems for cheap due to market hunting slow/costly fad.
- abledon 8y ago
  How does someone grow up to be Machiavellian ? Bad childhood ? Extreme circumstances forcing them to always default in to a ruthless uncaring attitude?
InGodsName 8y ago
I built an Adtech platform on Lambda recently: It's processing 9 billion events per week. 1. We used Firehose which pushed the data to s3 2. Go binary on Lambda transformed the data into Parquet format 3. Used Athena to query this data 4. Using Lambda to adjust the machine learing data based on the ariving data in batches. 5. Using Lambda to query athene/bigquery for data dashboard queries. Again using Go binary for max performance. All this made our platform 10x cheaper.
- Jupe 8y ago
  Yep, there are workloads that benefit from the FaaS model, but not all. In my case, the cost / hassle of high-availability, scaling, no need for state, time-based triggers, and more, made Lambda an easy decision to make: and it's working quite well. A cron-triggered job every minute is still in the "free" tier, so even better!
iamtomcat 8y ago
One way to get around vendor lock-in if you're worried about it, is to use a shim that translates the proprietary code to a basic http interface. So you just write your code as it it were a basic interface. There are tools like apex up, https://github.com/apex/up https://github.com/apex/up which do this already, though at the moment only support aws, but could eventually be setup to push to any provider.
- styfle 8y ago
  Another alternative is ZEIT Now 2.0 which is supposed to be cloud-agnostic serverless. It puts a few more layers of abstractions between the developer and the cloud providers. https://zeit.co/blog/now-2 https://zeit.co/blog/now-2
  - omnimus 8y ago
    People will argue that there is vendor locking with Now 2.0 - it has its own config file and way of doing this. But i am running express and the config is tiny, just few lines. If you use some cloud db provider for db that you can host yourself (like postgres or mongo in my case). You can move to your infrastructure without any pain. Mind you using Express is not the "ideal" way Zeit seems to push. It is exactly like with PHP - you are supposed to use simple files and leave routing to webserver. I think they forget that there is no PHP framework that uses this. All of them use the "Front controller" pattern and webserver basically routes everything to it. There must be reason for this.
- checker 8y ago
  The Serverless Framework https://serverless.com/framework/ https://serverless.com/framework/ consolidates the functionality of all the major cloud providers behind one API, greatly reducing lock-in. Agree though, when you’re talking about Lambda it should just be another entry point into your business logic.
brightball 8y ago
I honestly don’t understand why this hasn’t been PHP’s niche for years. It’s exactly what the language has been doing for years. That’s why PHP hosting is so cheap.
Myrmornis 8y ago
One thing that stops me seriously thinking about serverless is : what would my application's test suite look like if the application made heavy use of AWS lambda?
- scarface74 8y ago
  It should look just like it does now: Production: Lambda handler -> business logic Test Test function -> business logic. Testing a lambda function is no different than testing an controller in an MVC framework.
WhitneyLand 8y ago
If you can write a paper like this, however right or wrong, that’s the standard for Berkeley Computer Science often cited as one of the best programs out there? It’s nothing bad per se it just seems closer to nice blog post than research.
- jahewson 8y ago
  It’s basically an opinion piece - CIDR is an unusual conference and encourages this: http://cidrdb.org/cidr2019/ http://cidrdb.org/cidr2019/
  - DATACOMMANDER 8y ago
    How is it an opinion piece? If you called it a bait-and-switch I might agree, since it starts off criticizing the performance of serverless architectures in general, and proceeds to critique the performance of one specific serverless architecture. But that critique uses the scientific method, and their conclusions appear to be reasonably well argued, so long as you substitute “Lamda + DynamoDB/S3” for “serverless”. What am I missing?
  - WhitneyLand 8y ago
    Maybe the perception has less to do with the paper or Berkeley that than a possible bias against Software Engineering research. I’ve always perceived it, maybe unfairly, as one of the least rigorous topics in Computer Science, and more removed from more foundational insights that can have eventually have more important, broader impact or increase fundamental understanding that enables advances in other areas. If any of the conjecture is true, it wouldn’t be a criticism of any researcher in this area or their capabilities. Maybe it’s just a matter of maturity. How rigorous can I expect theory to be when th top software companies in the word still have trouble estiming delivery and complexity of software implementations? We may just not know enough yet.
ciconia 8y ago
As others here have already noted, serverless is still not fundamentally any better than good old CGI, and despite recent advances in virtualisation it still follows the same stateless request-response paradigm. For me the biggest shortcoming in serverless is that it is actually a poor fit for modern interactive web apps (and apps in general) with a constantly changing state. Technologies such as HTTP/2, websocket and SSE are clearly pointing in the direction of long-running client-server interaction, yet current serverless solutions have (to the best of my knowledge) no answer for that. I think the big challenge is in how to do serverless computing with long-running processes, in a way that solves isolation and scalability at the same time.
- nostrebored 8y ago
  What's happening here that an Layer 7 Load Balancer, Multiple Serverless Functions, and a Websocket can't handle? AWS released exactly that during the last re:Invent with the Websocket-integrated ALB being capable of triggering Lambda
  - chii 8y ago
    You're basically locking yourself in with a particular vendor if you choose to use that tech (rather than a standard stack deployable anywhere with compute power).
    - bartread 8y ago
      Going beyond the vendor lock-in, one of the biggest initial draws of serverless - from speaking with friends - has been simplicity in situations where state isn't a concern. On the other hand, here we're discussing a bunch of hoop jumping to get stateful functionality that might more easily achieved by adding a library such as SignalR, or socket.io into your app. Whilst this is probably a few screens to set up via the AWS, and can obviously be automated, you add complexity to development and delivery. Critically you also make it harder to diagnose and fix problems. Like anything it's a trade-off: for some apps these issues won't matter so much, for others they will. For us, it would definitely be a problem.
hurricaneSlider 8y ago
I really wish that one of the big cloud providers was building out actors as a service. That would address a lot of the shortcomings of FaaS, whilst still having many of the important benefits.
patsplat 8y ago
Serverless applications suffer from a few under reported drawbacks: - Local development is complex. Does one provision a full cloud environment per developer? Emulate a cloud environment locally? These are solvable but it's a grind of special cases. - Limited customization. Eventually one needs to customize the language / libraries of the lambda. Again these are solvable with a grind of special cases. - Limited execution model. Not all compute tiers are the same. Some quickly assemble results from a database. Others run for a long time. Others build up a model in RAM before delivering results. Serverless optimizes for some but not all models. Unlike serverless / lambda, all of the above can be addressed by containers. - Containers have orchestration solutions for local development and deployment - Containers are designed to support customization - Containers can be deployed to run in many different ways. Not to be a booster, but in my experience containers are the scalable compute architecture.
- deleted 8y ago
  [deleted]
- jiveturkey 8y ago
  > drawbacks: > ... Serverless optimizes for some but not all models. How is this a drawback? General purpose things are equally bad at all things. If serverless is optimal for some models, those are the places you use serverless!
  - patsplat 8y ago
    Please, share the use cases where serverless is the optimal choice. Because I've tried it. For problems like thumbnail generation which is literally the canonical example [1]. And even in that case, found myself switching the workload back to containers to control the exact version of imagemagick to prevent a color gamut bug. 1. https://docs.aws.amazon.com/lambda/latest/dg/with-s3-example.html https://docs.aws.amazon.com/lambda/latest/dg/with-s3-example...
- romeisendcoming 8y ago
  > ...containers*scalable, etc... Depends on your domain. Say you are containerizing nodes sharing KVM hypervisor resources with full VMs. The container application in use is resident on a file served backend, heavily dependent on SQL RDB for input, result outputs to file and db and application programmed using MPI via openmp. Processing is in real time and time sensitive. One size doesn't fit all. Containers are web tier solutions. They require too many compromises and work for a truly global solution.
dragosbulugean 8y ago
Came to conclusions really close to these when I investigated FaaS/Lambda a couple moths ago. Here's the blog post (faster read): https://archbee.io/blog/why-serverless-is-not-there-yet/ https://archbee.io/blog/why-serverless-is-not-there-yet/
- popasmurf 8y ago
  We have found the same when working on our own projects. Within the last few months a friend and I have been working on our own FaaS: https://3clouds.io/ https://3clouds.io/ We believe it solves about 90% of those issues - it's currently under heavy development and not ready to be used in production yet, but we think we are on to something here. Check it out, let us know what you think.
  - dragosbulugean 8y ago
    Interesting that you have the Docker option. I wish big cloud providers would be able to allow us to provide a Docker image to run as serverless. And not be as expensive as AWS Fargate..

465 points by snaky 8y ago

I’m not sure I would call it two steps back. I think it’s quite obvious that every web application everywhere doesn’t need a full OS install chugging along all day everyday waiting for things like mouse input or having its own patches for services that will never be used. It’s first gen tech. Really curious to see where it goes.

bpicolo 8y ago
The paper authors agree: > Taken together, these challenges seem both interesting and surmountable.
colemickens 8y ago
I mean, where do we think the functions are executing now? It's not like Ubuntu Server is running Xorg, or has libinput installed, nor have any of those things ever been operational or developmental considerations on any "non-serverless" app. Or maybe you're in a super cutting edge functions deployment where you're actually deploying microkernels? Seems orthogonal to me, and doesn't seem to address the data locality, etc issues brought up in this article. There are so many people in this thread saying stuff like "PaaS doesn't allow auto-scaling" and I just don't really know what's going on. It's baffling to me. I guess if all you know is an archaic build process and manual deployment, then it looks great. But I'm willing to bet most of these function platforms bottom out on containers-on-k8s-on-vms anyway. I am increasingly, increasingly convinced that people don't really need or want "serverless". They want the final step in the build/development process that they thought they were going to get with Docker -- they want to write code and have it running somewhere. I really don't buy that Serverless/Lockin are the right or best way to that future.
- SlowRobotAhead 8y ago
  >They want the final step in the build/development process that they thought they were going to get with Docker This isn’t my area, so I don’t know - but why didn’t people get that with Docker?
  - DATACOMMANDER 8y ago
    They didn’t get the magic functionality they wanted because magic isn’t real. Coming from a devops background with more of an emphasis on “ops” than “dev”, my (admittedly biased) opinion is that a lot of developers believe three things simultaneously: 1) Ops people are bitter, power-tripping killjoys who couldn’t make it as developers and do nothing but click buttons and think up ways to make the lives of developers difficult. 2) Ops/infra really isn’t as difficult as ops people would have you believe, and some day very soon all the ops people will be replaced by code. 3) Someone else should write the code that’s going to automate the ops people out of existence. These developers are like highly specialized scientists who think that their PhDs make them experts on everything. They have no idea what happens to their code once they commit it and they don’t care to learn, but they’re pretty sure that it can’t be all that complicated. Ops will—like everything else—eventually be eaten by software, but the people who drive that transformation sure as fuck won’t be JavaScript specialists who can’t troubleshoot their inability to connect to the VPN. They’ll either be systems/infra people who can code, or well-rounded coders who understand that infra is actually nontrivial (or a group comprised of both). If it seems like I have a problem with devs, it’s honestly only because a vocal minority of devs have a big problem with me.
    - deleted 8y ago
      [deleted]

aub3bhat 8y ago

Translation for those not proficient in Academese: Serverless computing a novel paradigm enabled by a large cloud provider, does not matches our past research, thus we argue why it's not the right thing. This is classic "if theory does not matches practice lets change the practice" approach, which is far too common in academic systems research. I trust AWS with knowing what its customers truly want (in terms of performance and cost) and what it can provide,Since AWS has real financial stakes in its success. A decade ago the same researchers would have mourned emergence of cloud computing as a wrong thing and instead asked for P2P computing since that's what they had spent the decade before doing research on.

hliyan 8y ago
I'm afraid your "translation" does a disservice to all the potential readers of the paper, to those who want to decide whether to use serverless computing at present and to the authors. Quoting from the conclusion of the paper: "Taken together, these challenges seem both interesting and surmountable. The FaaS platforms from cloud providers are not fully open source, but the systems issues delineated above can be explored in new systems by third parties using cloud features like container orchestration. The program analysis and scheduling issues are likely to open up significant opportunities for more formal research, especially for data-centric programs. Finally, language design issues remain a fascinating challenge, bridging program analysis power to programmer productivity and design tastes. In sum, we are optimistic that research can open the cloud’s full potential to programmers. Whether we call the new results “serverless computing” or something else, the future is fluid."
rfonseca 8y ago
Interestingly, a paper not 10, but 9 years ago, not by the same authors, but by the same group (systems folks at Berkeley), was proclaiming the cloud as an idea whose time had finally come. No mourning there. https://www2.eecs.berkeley.edu/Pubs/TechRpts/2009/EECS-2009-28.pdf https://www2.eecs.berkeley.edu/Pubs/TechRpts/2009/EECS-2009-...

Jhsto 8y ago

On the same note, CloudFlare’s approach to serverless computing by leveraging V8 sandboxing instead of traditional virtualization is fascinating: https://blog.cloudflare.com/cloud-computing-without-containers/ https://blog.cloudflare.com/cloud-computing-without-containe... Considering challenges of interconnected cloud computing and common IR (of which the latter is mentioned in this paper) an interesting distinction arises: WASM, in comparison to containers, brings us a single language (JS), and through this, possibly a single “orchestrator” (V8 Isolates). Of course, this is more or less saying that the world would be a better place if everyone would be driving a Volkswagen. But this is like a second chance to iterate such idea and maybe do something about it. Isn't this a step towards the future of cloud computing?

zackbloom 8y ago
Workers are network addressible which seems to directly respond to one of the complaints in the article. Beautifully, if you call one Worker from another they have a decent chance of running on not just the same server, but in the same process. When one Worker calls another its data doesn't even leave user-space, even if the two Workers are owned by different people. Imagine calling a third-party API and having your request never even need to leave the process to be handled.
- hueving 8y ago
  If the request never has to leave the process, that means there isn't anything the third party API is doing that persists state or calls out to another backend. In that case, wouldn't it just be better to import this third party API directly as code and call it for significantly better reliability, performance, and reduced complexity?
  - woah 8y ago
    Then your engineers are responsible for maintaining and updating it. Calling to a third party allows you to offload that.
  - zackbloom 8y ago

karmakaze 8y ago

TL;DR 3 WHY SERVERLESS TODAY IS TOO LESS (1) Limited Lifetimes. After 15 minutes, function invocations are shut down by the Lambda infrastructure. Lambda may keep the function’s state cached in the hosting VM to support “warm start”, but there is no way to ensure that subsequent invocations are run on the same VM. Hence functions must be written assuming that state will not be recoverable across invocations. (2) I/O Bottlenecks. Lambdas connect to cloud services—notably, shared storage—across a network interface. In practice, this typically means moving data across nodes or racks. With FaaS, things appear even worse than the network topology would suggest. Recent studies show that a single Lambda function can achieve on average 538Mbps network bandwidth; numbers from Google and Azure were in the same ballpark [26]. This is an order of magnitude slower than a single modern SSD. Worse, AWS appears to attempt to pack Lambda functions from the same user together on a single VM, so the limited bandwidth is shared by multiple functions. The result is that as compute power scales up, per-function bandwidth shrinks proportionately. With 20 Lambda functions, average network bandwidth was 28.7Mbps—2.5 orders of magnitude slower than a single SSD [26]. (3) Communication Through Slow Storage. While Lambda functions can initiate outbound network connections, they themselves are not directly network-addressable [...] can only communicate through an autoscaling intermediary service; today, this means a storage system like S3 [...] (4) No Specialized Hardware. FaaS offerings today only allow users to provision a timeslice of a CPU hyperthread and some amount of RAM [...] no API or mechanism to access specialized hardware. However, [...], hardware specialization will only accelerate in the coming years.

karmakaze 8y ago
While each of the above points are mostly quite factual, I don't personally find any of them to be restricting. We run a mixture of stateless and stateful services and serverless is suitable for the stateless ones. The original problems for network security being solved by running functions in a VPC and secure connections to databases and even connection pools makes pretty much everything work.
- sanxchit 8y ago
  Running functions in a VPC cause them to have cold starts of ~5 seconds. Connection pools need to be centralized to be of any use, since lambdas scale automatically.

stochastician 8y ago

I actually agree with many of the suggestions in the paper, but of course am biased as these are my colleagues and we disagree on some of the interesting capabilities of modern serverless architectures (see https://arxiv.org/abs/1810.09679 https://arxiv.org/abs/1810.09679 ) . But it comes across like this DeWitt/Stonebraker piece from back in the day, "MapReduce: a major step backwards" https://homes.cs.washington.edu/~billhowe/mapreduce_a_major_step_backwards.html https://homes.cs.washington.edu/~billhowe/mapreduce_a_major_...

sytse 8y ago

I loved the article https://arxiv.org/pdf/1812.03651.pdf https://arxiv.org/pdf/1812.03651.pdf It mentions two temporary bottlenecks: 1. Functions can run only for 15 minutes and experience cold-starts. 2. You can't use specialized hardware like GPUs. It also mentions two fundamental bottlenecks: 1. Serverless functions are run on isolated VMs, separate from data. In addition, serverless functions are short-lived and non-addressable, so their capacity to cache state internally to service repeated requests is limited. Hence FaaS routinely “ships data to code” rather than “shipping code to data.” 2. Because there is no network addressability of serverless functions, two functions can work together serverlessly only by passing data through slow and expensive storage. This stymies basic distributed computing. , With all communication transiting through storage, there is no real way for thousands (much less millions) of cores in the cloud to work together efficiently using current FaaS platforms other than via largely uncoordinated (embarrassing) parallelism. Disclosure: We just shipped serverless in GitLab https://about.gitlab.com/2018/12/11/introducing-gitlab-serverless/ https://about.gitlab.com/2018/12/11/introducing-gitlab-serve...

Normal_gaussian 8y ago
So knowing this what has Gitlab done to overcome it? If they haven't, why not? Why is it hard or inconvenient?
- sytse 8y ago
  What we now shipped is a Minimal Viable Change (MVC). I suspected that serverless wasn’t ideal for all use-cases but I couldn’t articulate this until I read this paper. We have taken no steps to overcome these problems, I think we’re likely to follow the leaders in the industry like Knative from Google and TriggerMesh. In general I think serverless is more of a pattern then a technology. We’ll use Knative to offer PaaS functionality (Heroku) on Kubernetes with GitLab.
ramzyo 8y ago
I'm interested to pick your brain about the second fundamental bottleneck you/the article mentioned. I'm not sure that I agree that serverless functions are fundamentally non-addressable. Today they're not addressable, but why can't they be in some future evolution of serverless? Sure serverless functions are ephemeral, but during their brief lifetime, is there something fundamental keeping them from being addressable?

zozbot123 8y ago

Interesting article. It has often seemed to me that efforts such as Urbit (urbit.org) deserve our attention, precisely because they might actually deliver on the 'serverless' premise to a far greater extent than current solutions.

akhilcacharya 8y ago
Really? Isn’t urbit based on a computation model multiple orders of magnitude less efficient than KVM?

zygotic12 8y ago

One size never fits all. The end.

DATACOMMANDER 8y ago
Not exactly. The authors are part of the (large) camp that envisions serverless eventually becoming ubiquitous. In that sense, they hope that one size will fit all, some day.
- bartread 8y ago
  > In that sense, they hope that one size will fit all, some day. Nothing new under the sun there. And, that being the case, they're likely to be disappointed.

sheeshkebab 8y ago

Am I the only one that thinks severless is about creating a bunch of vendor locked-in technical debt?

unreal37 8y ago
The increase in CPU utilization efficiency (and lower costs) is decreased by lack of portability. Everything has a cost. And so being able to move your code around at will is the cost of saving money.
- WrtCdEvrydy 8y ago
  Actually, most modern FaaS based on Amazon's is portable, it's the other rest of the stack that isn't very portable.
2StepsOutOfLine 8y ago
I would say that broadly categorizing FaaS as vendor lock-in would be disingenuous on its own. Practical FaaS is a simple concept as far as developer implementation is concerned. Write functions, get HTTP context, and return a result. This article really only touches on problems with vendor implementation of FaaS, AWS may have these issues with I/O and lifetime of a function, but there are many open source implementations that you could install on custom hardware that bypasses these issues. Even some of the issues that seem like fundamental issues with FaaS (non-addressable instances, unable to use specialized hardware) are already solved by other open source self-hosted FaaS solutions.
- DATACOMMANDER 8y ago
  Care to elaborate? Edit: to clarify, I’m referring to the assertion at the end of your comment, and I’m genuinely interested.
colllectorof 8y ago
You're not the only one. Some time ago I worked with a bunch of people who staked their careers on moving everything to AWS and converting it to serverless architecture. Here is just one example of how fishy it was. They used Dynamo. During presentations to the outgroup, they constatly praised Dynamo as being flexible, scalable and fast. However, internally they constantly struggled with various limitations of the database, from limitations of indexing to not being able to get certain types of metadata. My point is, the architecture they were designing was heavily bent around Dynamo's strength and weaknesses. Considering how extreme and peculiar those strength and weaknesses are, switching to another database would require heavy re-engineering of the rest of their architecture, much more so than, say, switching between Oracle, MS SQL and Postgress.

i_phish_cats 8y ago

Oh look a bunch of academics telling developers how to do their job, again.

spullara 8y ago

Going through the article I think they made some mistakes in analysis and also miscategorized some features. 1) Limited Lifetimes, Stickiness: These is good and leads to good design when you scale beyond a single server. It prepares you for dealing with the reality that if you want to run a service 24/7 with no downtime you need to prepare for things like different versions being in production, failures, and stale caches. 2) I/O Bottlenecks: If you are parallelizing your workloads you will actually see more aggregate bandwidth than you could scale up quickly with normal server hardware. Sure a single Lambda might not have the full amount but you can run 1000 of them at once. 3) Communication through slow storage: This is not entirely true, you can call another Lambda directly but yes you can't access a particular instance. That is a good thing. Designing systems where you need to return to the same instance is an anti-pattern. 4) No Specialized Hardware: I don't expect this to be a limitation for long. There is no reason why you couldn't ask for specialized hardware in the definition of a Lambda and the scheduler take care of it. It will, in fact, be better than the status quo because parts of your application that don't need that specialized hardware won't need to pay for it. In a typical larger application you would probably end up running part of your heavy CPU load inefficiently on your GPU hardware because it would be convenient. Also, most of this might be unnecessary in many cases since you would likely take advantage of a service that was specifically designed to run specialized workloads. Only if you DIY would need this support. Lambda is especially good at coordinating such services. 5) Faas is a datashipping arch: Not even true today. Lambda lets you move the computation to the data like they are with CloudFront Lambda, S3 Batch and Snowball Edge Compute. It is in fact easier to execute the code near the data when encapsulated in this way. 6) FaaS Stymies Dist Computing: Maybe they have applications that can afford to fail at any point and not recover but keeping your global state in a distributed data storage system is the right thing to do generally, not just with Lambda. Might not work for HPC but it generally doesn't need to be reliable in the same way applications do. At least in section 3.2 they finally seem to understand that most of the limitations are a good thing and if you are building software that don't have them you are likely not building scalable, reliable software systems. Also, if they think that their section 4 is somehow non-obvious to AWS and others they really aren't paying attention.

iamleppert 8y ago

Having your functions be stateless is actually an asset and forces you to write your code in a way that doesn’t make assumptions about the state of some cache, which makes it inherently more reliable. Cold starts aren’t much of a problem if you have non-interactive workloads, or can design UI’s in such a way to let the user know the first interaction will be slow but the rest fast, and if your modality allows for such. These problems tend to go away with any moderate scale in any event. The time limits I’ve found to be an asset as well, and forces me to think about how to structure my task into discrete and well known units of work. This makes development harder but leads to an overall more reliable system where any one invocation failure won’t seriously jeopardize the larger task and can easily be recovered. You can’t say the same for a process that’s been running for hours and suddenly dies without committing its work. That said, I’d love to have serverless GPU functions. I’d love to be able to somehow run shaders over superresolution images. That would be amazing for me working in the mapping world.

tirumaraiselvan 8y ago

A much needed paper which goes into the programming model in serverless rather than the operational model. Although, the first cases study is obviously bad for serverless (training a ML model) whereas the second case study does not indicate bad results (using trained ML model) as half a second latency is acceptable. As the paper itself quotes: `One might argue that FaaS encourages a new, event-driven distributed programming model based on global state.` Yes, exactly. It is not made for cluster computing or data-centric applications. It is made for making applications more modular, atomic and compositional with the upside of less ops and more scale and the downside of lower performance.

DATACOMMANDER 8y ago
I think that the authors of the paper would say that, ideally, serverless would be ubiquitous, the obvious choice for the vast majority of use cases. A pipe dream? Perhaps. But that’s the dream, and we’ll never be able to make the dream a reality unless people write papers like this one that highlight the work that separates where we are from where we want to be.

amelius 8y ago

If a marketing term means exactly the opposite of what you think it means (that's some hefty server they've got there), then you probably should look elsewhere anyway. Unless you enjoy dealing with a community and support team that speaks an inverted lingo, of course.

deleted 8y ago
[deleted]
millstone 8y ago
Only programs that talk to servers can be serverless. In two years we'll discover the benefits of running serverless workloads on the client and there will be a new name for that.

Agebor 8y ago

I'm not sure if i understand their view on fundamental limitations - they don't seem fundamental to me: 1. It does not seem impossible to imagine a function that spawns code close to data, be it on a VM with a connected fast SSD drive already populated with data. Also, Lambda-at-edge and Cloudflare workers are already more like “shipping code to data.”, or " the customer" in this case. 2. Functions are load-balanced and potentially parallelisable to millions of invocations. The only missing piece is some kind of parallel-invoke call, to give each instance of a function a distinct piece of data to process, and an identifier to save the result under. The identifier could easily refer to a local disk location, in some future implementation. Also, another point from the article: "FaaS discourages Open Source service innovation". seems wrong to me, as it may be said only about current super-early implementations, reason being, they are new. In the long-run, I'd expect serverless to help open source, because of a simplicity of deployment. We will likely have projects working on an abstraction layer of compute and storage, hiding the underlying cloud or multi-cloud implementation. (Kubernetes is one candidate, it just needs ideas in the like of Virtual Kubelet to become more serverless).

hueving 8y ago
>Cloudflare workers are already more like “shipping code to data.”, or " the customer" in this case. That's shipping code further from the data, unless you store all of your data on your customers' hardware.
- TeMPOraL 8y ago
  Is this your data or your customers' data? I'd much prefer the code that runs on my data to come to me, instead of me having to give my data away.
- Agebor 8y ago
  The closest data would be in the datacenter closest to the customer, not on customer's hardware. But I mentioned it to illustrate that the code already is location-independent a little.
quacker 8y ago

8bitsrule 8y ago

"Cloud" = back to dumb terminals & mainframes. Giant step back. Edit: and pulling content from two dozen separate servers ... madness^2

DATACOMMANDER 8y ago
Yeah, simpler to just serve all content from the file server sitting in your garage. After all, you tested your site from the laptop on your kitchen table, and everything loaded just fine.

cnbeining 8y ago

Some questions: 1. The authors are quoting exact performance metrics and limits, which is making the article more about "Amazon Lambda" rather than "Serverless Computing". 2. The authors mentioned a "15-minute lifetime" problem. Although it could be concerning that cache may be invalided sooner than running the same code on other infrastructures, a use case like this could easily migrated by using container. Not to say this number could be adjustable - this is a limit that is set by AWS rather than some theological limit. Thus using this problem to attack the serverless computing idea would be unfair. 3. The authors mentioned low IO problem. As public cloud is a shard infrastructure, it is only reasonable for end users to assume a baseline IO performance when using the platform - and this applies to any service that any public cloud provides, currently and in the future. It would be more beneficial if AWS could reveal the baseline performance in number, as this would assist developers with planning. 4. The author attacked serverless computing about its "Communication Through Slow Storage". This is probably not avoidable and is common practise in modern developing and should not be used to attack the idea of serverless computing. AWS do provide u-12tb1.metal EC2 server that comes with 12TB of RAM for this use case, though. 5. The author mentioned that currently serverless has "No Specialized Hardware". Again, this is a attack on AWS Lambda rather than serverless computing, and is a particular function that could be easily added. (I have a feeling that Cloud TPU could be used with Google Cloud Function, but it's a assumption.) 6. The authors also attacked that "FaaS discourages Open Source service innovation." Supposedly one can only imagine that more software projects would be PORTED TO serverless, and there should be no real issue running them as standalone application. I lost track of what the authors are trying to argue.

chillaxtian 8y ago

Does anyone know why lambda is taking off, compared to heroku style PaaS? Heroku style still removes the burden of managing servers ("serverless"), but doesn't lock you in as much. You could easily move your own server process to a different provider. Is it just because Amazon doesn't offer anything similar to heroku?

chrisco255 8y ago
A number of reasons. For one, you pay per execution with Lambda (and other similar services like Azure Functions and Cloudflare Workers)...and the costs can be dramatically lower. Here's a great article by haveibeenpwned author explaining how they support 141 million requests a month at 2.6 cents per day: https://www.troyhunt.com/serverless-to-the-max-doing-big-things-for-small-dollars-with-cloudflare-workers-and-azure-functions/ https://www.troyhunt.com/serverless-to-the-max-doing-big-thi... Besides cost, automatic scaling is something traditional PaaS does not offer.
Jedi72 8y ago
Amazon is the new IBM - nobody gets fired for using it. I have personally moved services which were cheaper and more performant with other 3rd party providers to Amazon just becausr higher-ups wanted us to keep as much stuff with them as possible, for obscure reasons like "we already have a relationship with Amazon" i.e. their sales rep keeps sending me free stuff and sending me on BS "training courses" with free lunch.

tyteen4a03 8y ago

Why does serverless remind me of PHP?

TeMPOraL 8y ago
Maybe because a making a "lambda" is quite like putting some code in a .php file and uploading it to a LAMP server, except it's pay-as-you-go and it autoscales.
paulddraper 8y ago
Because it's CGI. Except with vendor lock-in.

orthecreedence 8y ago

I love how everyone always shat on PHP (the original serverless technology...convince me otherwise) and now everyone is scrambling to reinvent PHP.

toddh 8y ago
Don't forget perl and CGI as the even more original serverless tech.
- fuball63 8y ago
  That's why I made http://bigcgi.com http://bigcgi.com. It's just CGI behind a reverse proxy that handles file sync between hosts. My blog runs on it.
  - captainperl 8y ago
    BigCGI looks interesting. I signed up for your newsletter.
    - fuball63 8y ago
      Thats great, thanks! Im working on getting the blog up and running, and plan to cross post there, along with any news about the platform. Feel free to email me any suggestions... my address is on the bigcgi site.
CharlesW 8y ago
> I love how everyone always shat on PHP (the original serverless technology... I like and use PHP, and you absolutely can create serverless solutions with PHP, but you may be confusing "serverless" with "stateless". PHP itself is in no way intrinsically more "serverless" than other options.
mypalmike 8y ago
Does PHP automatically scale infrastructure to meet demand? Can you bring up 1000 instances of your service for spikes in volume? And then scale back down when the spike is over? Without writing code? Nobody is reinventing PHP.

bfirsh 8y ago

Here's a web version if you're on a phone: https://www.arxiv-vanity.com/papers/1812.03651/ https://www.arxiv-vanity.com/papers/1812.03651/

suyash 8y ago

If you want to avoid vendor lock in, may I recommend open source FN Project - you can run anywhere as it's container native serverless platform. https://fnproject.io https://fnproject.io (Full Disclosure : My company supports development of this project).

bitL 8y ago

If I were a Machiavellian dominant player trying to keep my advantage in distributed systems, I'd invest into serverless propaganda to mislead everyone performance/cost-wise, keep my dominant position and get people doing real performant distributed systems for cheap due to market hunting slow/costly fad.

abledon 8y ago
How does someone grow up to be Machiavellian ? Bad childhood ? Extreme circumstances forcing them to always default in to a ruthless uncaring attitude?

InGodsName 8y ago

I built an Adtech platform on Lambda recently: It's processing 9 billion events per week. 1. We used Firehose which pushed the data to s3 2. Go binary on Lambda transformed the data into Parquet format 3. Used Athena to query this data 4. Using Lambda to adjust the machine learing data based on the ariving data in batches. 5. Using Lambda to query athene/bigquery for data dashboard queries. Again using Go binary for max performance. All this made our platform 10x cheaper.

Jupe 8y ago
Yep, there are workloads that benefit from the FaaS model, but not all. In my case, the cost / hassle of high-availability, scaling, no need for state, time-based triggers, and more, made Lambda an easy decision to make: and it's working quite well. A cron-triggered job every minute is still in the "free" tier, so even better!

iamtomcat 8y ago

One way to get around vendor lock-in if you're worried about it, is to use a shim that translates the proprietary code to a basic http interface. So you just write your code as it it were a basic interface. There are tools like apex up, https://github.com/apex/up https://github.com/apex/up which do this already, though at the moment only support aws, but could eventually be setup to push to any provider.

styfle 8y ago
Another alternative is ZEIT Now 2.0 which is supposed to be cloud-agnostic serverless. It puts a few more layers of abstractions between the developer and the cloud providers. https://zeit.co/blog/now-2 https://zeit.co/blog/now-2
- omnimus 8y ago
  People will argue that there is vendor locking with Now 2.0 - it has its own config file and way of doing this. But i am running express and the config is tiny, just few lines. If you use some cloud db provider for db that you can host yourself (like postgres or mongo in my case). You can move to your infrastructure without any pain. Mind you using Express is not the "ideal" way Zeit seems to push. It is exactly like with PHP - you are supposed to use simple files and leave routing to webserver. I think they forget that there is no PHP framework that uses this. All of them use the "Front controller" pattern and webserver basically routes everything to it. There must be reason for this.
checker 8y ago
The Serverless Framework https://serverless.com/framework/ https://serverless.com/framework/ consolidates the functionality of all the major cloud providers behind one API, greatly reducing lock-in. Agree though, when you’re talking about Lambda it should just be another entry point into your business logic.

brightball 8y ago

I honestly don’t understand why this hasn’t been PHP’s niche for years. It’s exactly what the language has been doing for years. That’s why PHP hosting is so cheap.

Myrmornis 8y ago

One thing that stops me seriously thinking about serverless is : what would my application's test suite look like if the application made heavy use of AWS lambda?

scarface74 8y ago
It should look just like it does now: Production: Lambda handler -> business logic Test Test function -> business logic. Testing a lambda function is no different than testing an controller in an MVC framework.

WhitneyLand 8y ago

If you can write a paper like this, however right or wrong, that’s the standard for Berkeley Computer Science often cited as one of the best programs out there? It’s nothing bad per se it just seems closer to nice blog post than research.

jahewson 8y ago
It’s basically an opinion piece - CIDR is an unusual conference and encourages this: http://cidrdb.org/cidr2019/ http://cidrdb.org/cidr2019/
- DATACOMMANDER 8y ago
  How is it an opinion piece? If you called it a bait-and-switch I might agree, since it starts off criticizing the performance of serverless architectures in general, and proceeds to critique the performance of one specific serverless architecture. But that critique uses the scientific method, and their conclusions appear to be reasonably well argued, so long as you substitute “Lamda + DynamoDB/S3” for “serverless”. What am I missing?
- WhitneyLand 8y ago
  Maybe the perception has less to do with the paper or Berkeley that than a possible bias against Software Engineering research. I’ve always perceived it, maybe unfairly, as one of the least rigorous topics in Computer Science, and more removed from more foundational insights that can have eventually have more important, broader impact or increase fundamental understanding that enables advances in other areas. If any of the conjecture is true, it wouldn’t be a criticism of any researcher in this area or their capabilities. Maybe it’s just a matter of maturity. How rigorous can I expect theory to be when th top software companies in the word still have trouble estiming delivery and complexity of software implementations? We may just not know enough yet.

ciconia 8y ago

As others here have already noted, serverless is still not fundamentally any better than good old CGI, and despite recent advances in virtualisation it still follows the same stateless request-response paradigm. For me the biggest shortcoming in serverless is that it is actually a poor fit for modern interactive web apps (and apps in general) with a constantly changing state. Technologies such as HTTP/2, websocket and SSE are clearly pointing in the direction of long-running client-server interaction, yet current serverless solutions have (to the best of my knowledge) no answer for that. I think the big challenge is in how to do serverless computing with long-running processes, in a way that solves isolation and scalability at the same time.

nostrebored 8y ago
What's happening here that an Layer 7 Load Balancer, Multiple Serverless Functions, and a Websocket can't handle? AWS released exactly that during the last re:Invent with the Websocket-integrated ALB being capable of triggering Lambda
- chii 8y ago
  You're basically locking yourself in with a particular vendor if you choose to use that tech (rather than a standard stack deployable anywhere with compute power).
  - bartread 8y ago
    Going beyond the vendor lock-in, one of the biggest initial draws of serverless - from speaking with friends - has been simplicity in situations where state isn't a concern. On the other hand, here we're discussing a bunch of hoop jumping to get stateful functionality that might more easily achieved by adding a library such as SignalR, or socket.io into your app. Whilst this is probably a few screens to set up via the AWS, and can obviously be automated, you add complexity to development and delivery. Critically you also make it harder to diagnose and fix problems. Like anything it's a trade-off: for some apps these issues won't matter so much, for others they will. For us, it would definitely be a problem.

hurricaneSlider 8y ago

I really wish that one of the big cloud providers was building out actors as a service. That would address a lot of the shortcomings of FaaS, whilst still having many of the important benefits.

patsplat 8y ago

Serverless applications suffer from a few under reported drawbacks: - Local development is complex. Does one provision a full cloud environment per developer? Emulate a cloud environment locally? These are solvable but it's a grind of special cases. - Limited customization. Eventually one needs to customize the language / libraries of the lambda. Again these are solvable with a grind of special cases. - Limited execution model. Not all compute tiers are the same. Some quickly assemble results from a database. Others run for a long time. Others build up a model in RAM before delivering results. Serverless optimizes for some but not all models. Unlike serverless / lambda, all of the above can be addressed by containers. - Containers have orchestration solutions for local development and deployment - Containers are designed to support customization - Containers can be deployed to run in many different ways. Not to be a booster, but in my experience containers are the scalable compute architecture.

deleted 8y ago
[deleted]
jiveturkey 8y ago
> drawbacks: > ... Serverless optimizes for some but not all models. How is this a drawback? General purpose things are equally bad at all things. If serverless is optimal for some models, those are the places you use serverless!
- patsplat 8y ago
  Please, share the use cases where serverless is the optimal choice. Because I've tried it. For problems like thumbnail generation which is literally the canonical example [1]. And even in that case, found myself switching the workload back to containers to control the exact version of imagemagick to prevent a color gamut bug. 1. https://docs.aws.amazon.com/lambda/latest/dg/with-s3-example.html https://docs.aws.amazon.com/lambda/latest/dg/with-s3-example...
romeisendcoming 8y ago
> ...containers*scalable, etc... Depends on your domain. Say you are containerizing nodes sharing KVM hypervisor resources with full VMs. The container application in use is resident on a file served backend, heavily dependent on SQL RDB for input, result outputs to file and db and application programmed using MPI via openmp. Processing is in real time and time sensitive. One size doesn't fit all. Containers are web tier solutions. They require too many compromises and work for a truly global solution.

dragosbulugean 8y ago

Came to conclusions really close to these when I investigated FaaS/Lambda a couple moths ago. Here's the blog post (faster read): https://archbee.io/blog/why-serverless-is-not-there-yet/ https://archbee.io/blog/why-serverless-is-not-there-yet/

popasmurf 8y ago
We have found the same when working on our own projects. Within the last few months a friend and I have been working on our own FaaS: https://3clouds.io/ https://3clouds.io/ We believe it solves about 90% of those issues - it's currently under heavy development and not ready to be used in production yet, but we think we are on to something here. Check it out, let us know what you think.
- dragosbulugean 8y ago
  Interesting that you have the Docker option. I wish big cloud providers would be able to allow us to provide a Docker image to run as serverless. And not be as expensive as AWS Fargate..