10 ms·

The next generation of serverless

103 points by kiyanwang 3y ago

robertlagrant 3y ago
I think Cloudflare Workers belong pretty high up the list on this one.
deleted 3y ago
[deleted]
deleted 3y ago
[deleted]
isoprophlex 3y ago
I know I am being sold something, but this is a very convincing post IMO. I enjoyed the historical perspective, and all the mentioned downsides of serverless up until now really resonate with my own experience. Seems like these people understand their problem space very well. Good stuff!
- marcod 3y ago
  I feel like AWS (and Lambda in this article) doesn't get enough credit for a bunch of revolutionary things they did. Don't get me wrong, I bitch about them every day, but credit where credit is due :p
madspindel 3y ago
I'm not convinced on their solution. They say you should run Web assembly in containers? How is that next-gen serverless?
- mikkelhegn 3y ago
  Mikkel from Fermyon here. That's a misunderstanding. Spin runs your webassembly directly from disk. Spin does support distributing application using OCI registries, but they do not run in a container runtime, just a webassembly runtime (Wasmtime).
  - madspindel 3y ago
    Ah, I see, thanks!
romanichm12 3y ago
I see that there's some skepticism about running WebAssembly in containers and how it constitutes a next-gen serverless solution. It's important to note that the use of WebAssembly here is not just about the runtime environment but also about the features it brings. WebAssembly binaries can start up significantly faster than traditional VMs or containers. They also have a strong isolation model and security sandbox that allows running multiple tenants in the same supervisor, which can lead to reduced costs and better utilization of resources
- pjmlp 3y ago
  Java servlets in application servers, and IIS CLR Handlers, WebAssembly sales pitch is so 2001.
  - imtringued 3y ago
    Except you run a separate tomcat instance per app or better yet, embedded tomcat anyway. Source: Someone who runs two dozen Tomcat containers.
    - pjmlp 3y ago
      Doesn't change the fact of the "clever" Webassembly marketing.
snops 3y ago
This sales pitch ignores cloudflare workers, which sound pretty similar to me, with both webassembly and key-value storage. The distinguishing part of the articles option seems to be that webassembly functions are uploaded in an OCI container, which I don't think anyone else supports, and I don't think was designed with this use case in mind?
- Cupprum 3y ago
  I dont think they are going to run the web-assembly in docker. That would not change the status-quo at all. Already now aws lambda, which executes container has a longer cold start then the zipped code.
- sofixa 3y ago
  > The distinguishing part of the articles option seems to be that webassembly functions are uploaded in an OCI container, which I don't think anyone else supports, and I don't think was designed with this use case in mind? OCI is just the storage and registry format, and is being used for all sorts of things (e.g. you can store OPA policies for conftest in it). I'm not familiar with Fermyon's internal workings, but my read of it was that they simply use the storage format, not that there's an intermediate container layer. Edit: can confirm, there are no containers: https://news.ycombinator.com/item?id=36352869 https://news.ycombinator.com/item?id=36352869
  - snops 3y ago
    If its "just storage", how is it any better for this application than a zip file?
    - sofixa 3y ago
      OCI is a standard that supports layers (and cache thereof), hashes and has a verified way of sharing (via OCI image registries). A .zip is much more monolithic, and there are no ready-made .zip registries you can upload your .zip to that will automatically checksum it, or allow it to be delivered in layers (and skipping the layers already present on the registry/destination).
gabrieledarrigo 3y ago
> Serverless apps are applications that are not written as software servers. “Server-less” code is code that responds to events (such as HTTP requests), but does not run as a daemon process listening on a socket. The networking part of serverless architectures is relegated to the infrastructure. The networking part was always and always will be relagated to the infrastructure. Really not sold to the all "serverless" fiasco.
- nickstinemates 3y ago
  Most apt use cases imo are not part of the "main loop" of a webapp but instead to supporting functions, like sending an email, resizing an image, any sort of cron, etc. Or, the micro part of microservices.
  - 9dev 3y ago
    To me, that always feels like it should be close to my app, as in, part of the code base. Serverless functions always seem to be very remote from everything else, particularly if I’m not sold completely to AWS. I end up with web and worker containers running in the same deployment plus some sort of queue, which is also not very satisfying. Oh well.
irjustin 3y ago
We use AWS Lambda as a monolithic "serverless" to run our Django stack since Lambda can now take standard containers[0]. The full environment, costs us US$100/mnth to run production b2b application. Traffic is quite light, but we literally don't pay for non-usage. The most expensive thing of our monthly bill is the postgres RDS+Elasticache. So for our use case it is extremely cost effective, esp for UAT, Staging where there's no traffic and using the smallest machines possible <US$50/mth. To me this is the "next generation" of serverless. Back to monolith but where we don't manage even CPU time. We get all the benefits of monolithic repo, debugging, deployment and key benefits of serverless namely pricing+CPU management. It's not edge lambda but admittedly that's not a need of ours. [0] https://stackoverflow.com/questions/69512271/will-the-cold-starts-of-my-aws-lambda-function-take-longer-if-i-use-an-ecr-image/74383087#74383087 https://stackoverflow.com/questions/69512271/will-the-cold-s...
- foreigner 3y ago
  But cold start time. This article claims their cold start time is only one or two milliseconds. Lambda's cold start time is orders of magnitude slower.
  - irjustin 3y ago
    This is fair, if WASM can do 1-2 ms cold start then that's incredible! If you have a 100 function chain w/ 100ms cold start times in between, then that's a nightmare, but for us, we're monolothic so all our cold starts are bundled together. In the end I can't truly benefit from the 1-2ms. I suspect so many teams are in the same boat. But I do lose a lot w/o the debugging and ease of testing that come with monolithic applications.
- vladvasiliu 3y ago
  What does your cold start time look like with containers? I was contemplating deploying a similar stack for very occasional internal use: django + postgres rds (no need for cache). Had some horror stories with Java where the startup time was brutal, so they ended "pre-warming" lambdas. In the end, the whole ordeal cost more than an EC2 running 24/7. This was several years ago, so I'm curious whether things have improved.
avereveard 3y ago
This pivots from serverless applications hosting to... a database? I mean just sell me on the wasm in the cloud premise, that's sounds awesome enough. The k/v store angle is just confusing. If devs don't want to manage their Dev environment, you can spin one on any cloud. Especially serverless services, which are billed per api usage, are not going to break bank if each developer has it's own Dev backend ok the cloud.
syrusakbary 3y ago
A very timed response to Wasmer Edge release yesterday! [1] Even though I don't agree with their take, I have to congratulate their team for the fast response. At the end this is what startups are about. https://wasmer.io/posts/announcing-wasmer-edge https://wasmer.io/posts/announcing-wasmer-edge
- benatkin 3y ago
  If you go to the bottom, underneath the author's name is JUNE 06, 2023. So I guess it was the other way around. Makes sense because 3 regions don't make an edge offering, so WasmerEdge must have been rushed out there.
  - syrusakbary 3y ago
    I didn't realize of the date, thanks for the correction. I guess my compliment doesn't make that much sense either. Indeed, we have a rush for shipping great products to the world (although Wasmer Edge is been more than a year in the making!)
FpUser 3y ago
At some point they will "invent" RPC / CORBA / EJB / Vitria BusinessWare / your favorite ancient pet tech.
BohdanPetryshyn 3y ago
What about file system? AWS Lambda allows working with the FS and running child processes. I assume this is not the case when using WebAssembly sandboxes?
- mikkelhegn 3y ago
  This spec describes how to work with the filesystem in WASI (WebAssembly System Interface). That's the spec adopted by Wasmtime, which is the runtime being used by Spin. (Fermyon employee here)
  - mikkelhegn 3y ago
    Forgot the link: https://github.com/WebAssembly/wasi-filesystem#introduction https://github.com/WebAssembly/wasi-filesystem#introduction
ctippett 3y ago
Google App Engine came out in 2008, several years before AWS Lambda. I'd also argue the developer experience (especially for its time) was pretty fantastic. If you're wanting 'serverless' compute these days you'd probably deploy to something like Cloud Run – containers being the ultimate hedge against vendor lock-in.
- imustbeevil 3y ago
  I would love to use Google's cloud, but I just can't risk my email, map, and browser services being cut off because some AI determined that my application looks suspicious, with no human customer support to contact, as has been reported multiple times.
  - RadiozRadioz 3y ago
    Actually I find their support to be pretty good. Granted I am at a large tech company who likely pays for premium support, but I can always get through to a human who knows what they're talking about. They've even helped with issues inside my app that were my fault.
    - solarkraft 3y ago
      You could probably profitably resell that kind of access to people who lost everything and have no other way to reach them.
      - FooBarWidget 3y ago
        Phone support is tied to an account. It doesn't work on random accounts.
  - FooBarWidget 3y ago
    I tried moving off Gmail, I really did. But all the EU-based alternatives just suck so much. So now I'm back to Gmail, but I pay for it (Google Workspace). This way I at least have a commercial relationship with Google which gives me various contractual rights, and access to phone support. I also have a contingency plan: I have my email address on my own domain, and I backup my mailbox once in a while, so that I can migrate off Gmail should I need to do that at some point.
charcircuit 3y ago
>and then invoked the CGI program directly. There was no security sandbox, and CGI was definitely not safe for multi-tenancy This isn't true. Linux is the security sandbox. Multitenacy is safe using a user for each site. >Like CGI, PHP was never multi-tenant safe. This is isn't a problem with PHP. The following story about the author's site on a shared host getting hacked was a problem of shared hosts not caring about security.
- DonHopkins 3y ago
  Speaking of not caring: "We have things like protected properties. We have abstract methods. We have all this stuff that your computer science teacher told you you should be using. I don't care about this crap at all." -Rasmus Lerdorf "I really don't like programming. I built this tool to program less so that I could just reuse code." -Rasmus Lerdorf "I was really, really bad at writing parsers. I still am really bad at writing parsers." -Rasmus Lerdorf "I'm not a real programmer. I throw together things until it works then I move on. The real programmers will say "Yeah it works but you're leaking memory everywhere. Perhaps we should fix that." I’ll just restart Apache every 10 requests." -Rasmus Lerdorf "I don't know how to stop it, there was never any intent to write a programming language [...] I have absolutely no idea how to write a programming language, I just kept adding the next logical step on the way." -Rasmus Lerdorf "For all the folks getting excited about my quotes. Here is another - Yes, I am a terrible coder, but I am probably still better than you :)" -Rasmus Lerdorf "PHP is just a hammer. Nobody has ever gotten rich making hammers." -Rasmus Lerdorf Ian Baker's PHP Hammer: https://blog.codinghorror.com/the-php-singularity/ https://blog.codinghorror.com/the-php-singularity/ PHP: a fractal of bad design: https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/ https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/ >I can’t even say what’s wrong with PHP, because— okay. Imagine you have uh, a toolbox. A set of tools. Looks okay, standard stuff in there. >You pull out a screwdriver, and you see it’s one of those weird tri-headed things. Okay, well, that’s not very useful to you, but you guess it comes in handy sometimes. >You pull out the hammer, but to your dismay, it has the claw part on both sides. Still serviceable though, I mean, you can hit nails with the middle of the head holding it sideways. >You pull out the pliers, but they don’t have those serrated surfaces; it’s flat and smooth. That’s less useful, but it still turns bolts well enough, so whatever. >And on you go. Everything in the box is kind of weird and quirky, but maybe not enough to make it completely worthless. And there’s no clear problem with the set as a whole; it still has all the tools. >Now imagine you meet millions of carpenters using this toolbox who tell you “well hey what’s the problem with these tools? They’re all I’ve ever used and they work fine!” And the carpenters show you the houses they’ve built, where every room is a pentagon and the roof is upside-down. And you knock on the front door and it just collapses inwards and they all yell at you for breaking their door. >That’s what’s wrong with PHP.
Cupprum 3y ago
Was this blog post written by chat gpt?
kristianov 3y ago
This generation of serverless ushered in the next generation of monoliths.
eschaton 3y ago
If you really want serverless, there’s this thing you can write called a “native application” that, once deployed, a user can interact with entirely without a network connection!
- lionkor 3y ago
  Oh, like electron? /s
franciscop 3y ago
I remember vividly my intro to "serverless". I had been (ab)using Javascript and Node.js for a while, breaking the internals of Express.js and messing around with many things. Someone told me that serverless was "like Node.js but without server, you just write code for an endpoint" and it sounded cool. Just I didn't need it at the moment since I was happy with my servers (I'm the creator of npm's `server`). I kept hearing about it in multiple places, and after many months/years I decided to dig deeper. I found out that "serverless" was just an instance of Express all along! My disappointment was immeasurable, I thought that you really wrote a JS function, executed by "3rd party servers" (ofc there's a server _somewhere_), or in worst case you just wrote a function with the signature of Express' middleware and export it, then to be run by their instance. But no, you actually had to set up the whole server and listen to a port and all, it was just more ephemeral than Heroku's already ephemeral servers. It wasn't until next generation that "true serverless" came, with Cloudflare Workers and the such, where you truly write a plain JS function that takes a Request and returns a Response as I expected almost a decade earlier.
- jeffparsons 3y ago
  I could almost imagine WASI being born of the disappointment people felt when adopting the first generation of things branded "serverless". "What if this stuff was actually as good as it first sounded? Want to make it?"
- joshstrange 3y ago
  And we are still waiting on decent frameworks for this method of writing serverless services. I have 2 projects running like this with a cobbled together group of utils/helpers to make life easier. No routing layer or anything, that’s the job of SST/CDK/SF/etc, but things like a handler wrapper to handle errors uniformly, and other tools I regularly need (permissions checking, payload validation, etc). I know some of that work can be done at the API Gateway/Lambda layer before it hits my function but I’ve yet to go down that rabbit hole, it always felt too limiting/rigid, I could and do move way faster in JS (TS). I feel like we are on the cusp of it getting so much nicer and I have a blast working in this space. I absolutely love knowing my backend will “auto-scale” to whatever I need all the way down to $0 and even on the high end (at my scale) well under $10. My projects are for events (think festivals or “food week”) and so they are extremely bursty. They go months at a time with little to no traffic so “Serverless” and managed services that scale to $0 or near $0 are awesome for my needs.
yegle 3y ago
The author's definition of Serverless is pretty different from what I understand. It's called Serverless mostly because it's not billed based on the # of servers, instead it is mostly billed by # of requests and/or the CPU time * dedicated RAM. With this changed billing model comes with the expectations like relatively fast scaling up/down and "scale down to zero/minimum". Disclaimer I work on App Engine which is arguably the OG Serverless service.
comex 3y ago
> We imagine a feature in which a user can log into their dashboard and say, “This function is misbehaving. I would like to enable function tracing right now.” The serverless function runtime can then immediately begin tracing without any sort of recompile on the user’s side. So like dtrace or Frida or Intel Pin? Or perhaps like perf? Or good old GDB? It’s hard to say without a more specific description of ‘function tracing’. Perhaps it’s an entirely new user interface design that provides benefits never seen before. I could easily believe that, considering how often debugging tools have terrible UIs, don’t work in modern languages, or just don’t fit modern server workloads very well. Yet whatever it is, I would be surprised if it could not have been implemented for native code using the same underlying techniques as those tools. That doesn’t mean it should have been implemented for native. I think WebAsssembly is fine to base a platform around, really. Has its benefits, like hardware and OS independence, and being designed to run isolated components, and having its ecosystem designed from scratch without some of the mistakes of the past. But why are its proponents constantly ascribing to it supposedly unique capabilities that really aren’t? Even the cold start and memory benefits could largely be replicated for native code if you write a custom kernel. Sure, it’s very useful to be able to just run under an existing OS. But still, people act as if lightweight isolation is fundamentally impossible without a JITted platform like WebAssembly, or without putting everything in the same address space, when it is not. At most, the use of software bounds checks can reduce context switch times somewhat more than you could get with a custom kernel, but at the cost of potential Spectre skeletons in the closet (something I want to try attacking myself some day). And native context switch times are already a few microseconds at most.
- jsty 3y ago
  > Even the cold start and memory benefits could largely be replicated for native code if you write a custom kernel ... people act as if lightweight isolation is fundamentally impossible without a JITted platform I think when most people refer to this as being "impossible", they mean practically impossible, not dis-allowed by the laws of physics. "First write your custom kernel" is a step only a miniscule proportion of projects can justify. As to unique capabilities - none of its capabilities are really earth-shattering in and of themselves. But together and combined with the fact the barrier to entry is so much lower than alternatives like custom kernels, it's quite understandable why people see it as bringing something new and exciting to the table.
OJFord 3y ago
I was nodding along until key-value storage, which seems to contradict its own points about vendor lock-in and APIs?
- nsonha 3y ago
  I could be wrong but key value is so simple there is nothing to lock-in
  - mikkelhegn 3y ago
    Fermyon employee here. There's a WASI specification in the works, which is what is used in Spin and Fermyon Cloud: https://github.com/WebAssembly/wasi-keyvalue/ https://github.com/WebAssembly/wasi-keyvalue/ With Spin you can also swap the backend provider. It's using sqlite as the default, but there's a Redis provider as well: https://developer.fermyon.com/spin/dynamic-configuration#key-value-store-runtime-configuration https://developer.fermyon.com/spin/dynamic-configuration#key...
    - Mandatum 3y ago
      Why on earth would you want to commoditize your platform?
      - mikkelhegn 3y ago
        If it's a viable option, why not give users the benefit?
busfahrer 3y ago
Can someone please elaborate on how this differs from Firebird, which also seems to be a lightweight VM that can spin up very fast
- mikkelhegn 3y ago
  Are you thinking about Firecracker (https://firecracker-microvm.github.io/ https://firecracker-microvm.github.io/). If so, one of our colleagues (I work for Fermyon) did touch upon this in a talk at Cloud Native WasmDay recently: https://youtu.be/-cJ_Cn_mgqI?list=PLj6h78yzYM2Pdj8vnO0wfFyKcbKNy3e5j&t=457 https://youtu.be/-cJ_Cn_mgqI?list=PLj6h78yzYM2Pdj8vnO0wfFyKc... This talk is actually a really nice compendium to the blog post.
- AntonCTO 3y ago
  Can you please provide more information? I only found Firebird SQL.
racktash 3y ago
At the risk of sounding very green, what is the best way to learn serverless/cloud? My decade or so of experience in the industry has been solely application development in C and C++. I've some personal experience in server side programming with PHP. Any time cloud concepts come up, it all seems very foreign to me.
- mikkelhegn 3y ago
  I work for Fermyon, but have been at a major cloud provider in the past, working with cloud for a decade now. Spin and Fermyon Cloud is a really nice and easy way to get started: https://developer.fermyon.com/cloud/quickstart https://developer.fermyon.com/cloud/quickstart. It doesn't introduce a whole lot of the inner workings of a cloud. With a lot of other services you'll fairly quickly get to the point, where you'll have to dive in to concepts of distributed systems and infra. If you want to work with containers and servers in the cloud, fly.io is really easy to get started with as well.
pjmlp 3y ago
Hardly new, ever heard of Java Servlets or .NET IIS Handlers?
danpalmer 3y ago
I'm quite the serverless skeptic, but honestly this sounds quite appealing. I particularly like the definition of serverless given at the beginning of this post. It's refreshingly straightforward and realistic, without the marketing BS that the cloud providers tend to give. I've always felt like developing for serverless hosting is like writing a plugin for a piece of closed-source software, and that sucks from a dev experience and lock-in point of view. Doing for serverless what CGI did back in the day seems like a good idea, and containers/WASM seem like good options for it at the moment.
SvenAl 3y ago
I've been dealing with serverless since 2018 and have a company with a 100% serverless and open-source product (webiny.com). I'm not sure I fully agree with your 4 issues and the fact that Web Assembly is the answer. "Serverless functions are slow" -> not really, only if designed poorly "DX serverless functions is sub-par" -> where's your proof, again you'll have bad experience as a developer only if you don't know what you're doing. Which I see mainly from people trying to approach building serverless applications by having a container-like mindset and that leads them to bad design choices. "Serverless functions come with vendor lock in" -> I think most of us are beyond the point of that vendor locking is bad choice. Worse choice is picking a sub-optimal technology with lower performance, higher cost and lesser reliability. "Cost eventually gets in the way" -> Again, only if you don't know what you're doing and make bad design choices. When it comes to Web Assembly, I don't see how this is a better choice of technology vs something like Node. In node I have a much wider support of the technology than WA (talk about vendor-locking), I have a proven eco system of libraries, knowledge and a much bigger talent pool to source from. The cold start issue you mentioned on your website, I can tell you first hand, the cold start is not really that big of a problem, not big enough that you would want to switch to a different technology and there are many ways to mitigate the cold start problem. Just saying, I'm far from convinced that there is a benefit in switching. I would love to see more detailed benchmarks and examples I would be able to replicate than just statements in a blog post.
- rcoder 3y ago
  If you have Node apps running in Lambda and are happy with the architecture, cost, and operating model: great! You've done good work and/or are very lucky and there's no need for you to rip everything out and start over. Heck, even if you're curious about WASM and want to try some experiments with (say) fast Rust crypto libraries or embedded database engines w/o the risk of flaky native code crashing your V8 runtime: again, you can just run WASM from a Node worker thread and keep cruisin'. For those of us who _don't_ have a huge investment in Node, have hard requirements around e.g. memory usage, cold start times, or even just plain old _cost_ (which can become a major factor when you consider the AWS lock-in) that Lambda doesn't meet really benefit from another option. Your good fortune in finding a stack that works well doesn't mean that folks who have different needs or constraints are dumb, ignorant, or lazy. As an aside, I think you also might be underestimating the depth of experience and knowledge of the Fermyon crew when it comes to containers, cloud runtimes, and serverless development. This is substantially the same team that built Helm, and a lot of other Kubernetes and cloud-native ecosystem projects along the way.
kaishin 3y ago
This going to be a naive question due to my lack of familiarity with WebAssembly, but what does it it being to the table that wasn’t possible to do with any other standalone program packaged as a binary?
- regularfry 3y ago
  Strong isolation guarantees, mainly, which let hosters (like the OP) resource share more densely and with better startup profiles than virtualisation gives you.
NorwegianDude 3y ago
> PHP was never multi-tenant safe You're running on the same host, so there might be exploits that allow you to break free, but that goes for most other "serverless" solutions too.
rcoder 3y ago
Since it sounds like very few folks in this thread have actually fired up Spin and built a thing, I thought I might offer a few observations based on my experience working on a little app over the last 2-3 weeks. First, the good stuff: - As a Rust developer, the SDK tooling is really good. I went from running the installer to generating a templated app to dropping in my own app logic in about 15 minutes. - Local development iteration is also very fast and low-friction. Building everything as small WASM components means you effectively get hot module reloading for free, without needing to shim in a bunch of extra dev-mode-only code loading logic (with all the inherent incompatibilities and heisenbugs) - The component reuse model feels a lot easier for me to reason than interminable chains of Express middleware (YMMV, of course) - You get actual static (WASM) binaries, which can be as small as your compiler makes them. I'm normally pretty thrilled to get a production app container down to <100MB, and the app I've been working on, even without really paying any attention to my dependency graph, is around 2MB. Storage may be cheap, but pulling ~GBs of new container layers for a given release or deployment isn't free or instantaneous. There are some less-great things: - The "outbound" DB adapters are _very_ bare-bones. You only have access to a small list of datatypes, and you can't really layer higher-level libraries on top b/c the APIs aren't compatible with standard backend drivers. (Furthermore, if you want to use e.g. MongoDB, Clickhouse, Dynamo, etc., etc.: sorry, I hope you have some sort of HTTP adapter lying around ready to use.) - WIT (WebAssembly Interface Types) is a cool _emerging_ standard, but like a lot of WAS* community stuff it's still in a fractured "draft" state, and many of the actual interfaces exposed in Spin are unique to their runtime. (This also means that _extending_ something like the PG bindings requires a ton of indirection code spelunking; I gave up trying to add a few new native types after realizing I would also have to support them for MySQL and every other backend DB.) - The development environment, while relatively complete and usable on its own, doesn't really play nice with Nix or other high-level dev environment tooling. (There are literally invocations of `rustup` inside the top-level `build.rs` for the project, so good luck providing your own paths for e.g. `rustc`.) On balance, I'm enjoying the experience thus far and starting to think about more thing-ish was to apply the tools. I'm also looking forward to trying out more of the self-hosted infrastructure stack. I'm not opposed to paying for managed hosting, but I do occasionally build things that need to run in "offline" or air-gapped environments, so being able to bring up a full hosting environment is pretty clutch.
JohnFen 3y ago
My wish for the next generation of "serverless" is that they find a better thing to call it than "serverless".

103 points by kiyanwang 3y ago

robertlagrant 3y ago

I think Cloudflare Workers belong pretty high up the list on this one.

deleted 3y ago

[deleted]

deleted 3y ago

[deleted]

isoprophlex 3y ago

I know I am being sold something, but this is a very convincing post IMO. I enjoyed the historical perspective, and all the mentioned downsides of serverless up until now really resonate with my own experience. Seems like these people understand their problem space very well. Good stuff!

marcod 3y ago
I feel like AWS (and Lambda in this article) doesn't get enough credit for a bunch of revolutionary things they did. Don't get me wrong, I bitch about them every day, but credit where credit is due :p

madspindel 3y ago

I'm not convinced on their solution. They say you should run Web assembly in containers? How is that next-gen serverless?

mikkelhegn 3y ago
Mikkel from Fermyon here. That's a misunderstanding. Spin runs your webassembly directly from disk. Spin does support distributing application using OCI registries, but they do not run in a container runtime, just a webassembly runtime (Wasmtime).
- madspindel 3y ago
  Ah, I see, thanks!

romanichm12 3y ago

I see that there's some skepticism about running WebAssembly in containers and how it constitutes a next-gen serverless solution. It's important to note that the use of WebAssembly here is not just about the runtime environment but also about the features it brings. WebAssembly binaries can start up significantly faster than traditional VMs or containers. They also have a strong isolation model and security sandbox that allows running multiple tenants in the same supervisor, which can lead to reduced costs and better utilization of resources

pjmlp 3y ago
Java servlets in application servers, and IIS CLR Handlers, WebAssembly sales pitch is so 2001.
- imtringued 3y ago
  Except you run a separate tomcat instance per app or better yet, embedded tomcat anyway. Source: Someone who runs two dozen Tomcat containers.
  - pjmlp 3y ago
    Doesn't change the fact of the "clever" Webassembly marketing.

snops 3y ago

This sales pitch ignores cloudflare workers, which sound pretty similar to me, with both webassembly and key-value storage. The distinguishing part of the articles option seems to be that webassembly functions are uploaded in an OCI container, which I don't think anyone else supports, and I don't think was designed with this use case in mind?

Cupprum 3y ago
I dont think they are going to run the web-assembly in docker. That would not change the status-quo at all. Already now aws lambda, which executes container has a longer cold start then the zipped code.
sofixa 3y ago
> The distinguishing part of the articles option seems to be that webassembly functions are uploaded in an OCI container, which I don't think anyone else supports, and I don't think was designed with this use case in mind? OCI is just the storage and registry format, and is being used for all sorts of things (e.g. you can store OPA policies for conftest in it). I'm not familiar with Fermyon's internal workings, but my read of it was that they simply use the storage format, not that there's an intermediate container layer. Edit: can confirm, there are no containers: https://news.ycombinator.com/item?id=36352869 https://news.ycombinator.com/item?id=36352869
- snops 3y ago
  If its "just storage", how is it any better for this application than a zip file?
  - sofixa 3y ago
    OCI is a standard that supports layers (and cache thereof), hashes and has a verified way of sharing (via OCI image registries). A .zip is much more monolithic, and there are no ready-made .zip registries you can upload your .zip to that will automatically checksum it, or allow it to be delivered in layers (and skipping the layers already present on the registry/destination).

gabrieledarrigo 3y ago

> Serverless apps are applications that are not written as software servers. “Server-less” code is code that responds to events (such as HTTP requests), but does not run as a daemon process listening on a socket. The networking part of serverless architectures is relegated to the infrastructure. The networking part was always and always will be relagated to the infrastructure. Really not sold to the all "serverless" fiasco.

nickstinemates 3y ago
Most apt use cases imo are not part of the "main loop" of a webapp but instead to supporting functions, like sending an email, resizing an image, any sort of cron, etc. Or, the micro part of microservices.
- 9dev 3y ago
  To me, that always feels like it should be close to my app, as in, part of the code base. Serverless functions always seem to be very remote from everything else, particularly if I’m not sold completely to AWS. I end up with web and worker containers running in the same deployment plus some sort of queue, which is also not very satisfying. Oh well.

irjustin 3y ago

We use AWS Lambda as a monolithic "serverless" to run our Django stack since Lambda can now take standard containers[0]. The full environment, costs us US$100/mnth to run production b2b application. Traffic is quite light, but we literally don't pay for non-usage. The most expensive thing of our monthly bill is the postgres RDS+Elasticache. So for our use case it is extremely cost effective, esp for UAT, Staging where there's no traffic and using the smallest machines possible <US$50/mth. To me this is the "next generation" of serverless. Back to monolith but where we don't manage even CPU time. We get all the benefits of monolithic repo, debugging, deployment and key benefits of serverless namely pricing+CPU management. It's not edge lambda but admittedly that's not a need of ours. [0] https://stackoverflow.com/questions/69512271/will-the-cold-starts-of-my-aws-lambda-function-take-longer-if-i-use-an-ecr-image/74383087#74383087 https://stackoverflow.com/questions/69512271/will-the-cold-s...

foreigner 3y ago
But cold start time. This article claims their cold start time is only one or two milliseconds. Lambda's cold start time is orders of magnitude slower.
- irjustin 3y ago
  This is fair, if WASM can do 1-2 ms cold start then that's incredible! If you have a 100 function chain w/ 100ms cold start times in between, then that's a nightmare, but for us, we're monolothic so all our cold starts are bundled together. In the end I can't truly benefit from the 1-2ms. I suspect so many teams are in the same boat. But I do lose a lot w/o the debugging and ease of testing that come with monolithic applications.
vladvasiliu 3y ago
What does your cold start time look like with containers? I was contemplating deploying a similar stack for very occasional internal use: django + postgres rds (no need for cache). Had some horror stories with Java where the startup time was brutal, so they ended "pre-warming" lambdas. In the end, the whole ordeal cost more than an EC2 running 24/7. This was several years ago, so I'm curious whether things have improved.

avereveard 3y ago

This pivots from serverless applications hosting to... a database? I mean just sell me on the wasm in the cloud premise, that's sounds awesome enough. The k/v store angle is just confusing. If devs don't want to manage their Dev environment, you can spin one on any cloud. Especially serverless services, which are billed per api usage, are not going to break bank if each developer has it's own Dev backend ok the cloud.

syrusakbary 3y ago

A very timed response to Wasmer Edge release yesterday! [1] Even though I don't agree with their take, I have to congratulate their team for the fast response. At the end this is what startups are about. https://wasmer.io/posts/announcing-wasmer-edge https://wasmer.io/posts/announcing-wasmer-edge

benatkin 3y ago
If you go to the bottom, underneath the author's name is JUNE 06, 2023. So I guess it was the other way around. Makes sense because 3 regions don't make an edge offering, so WasmerEdge must have been rushed out there.
- syrusakbary 3y ago
  I didn't realize of the date, thanks for the correction. I guess my compliment doesn't make that much sense either. Indeed, we have a rush for shipping great products to the world (although Wasmer Edge is been more than a year in the making!)

FpUser 3y ago

At some point they will "invent" RPC / CORBA / EJB / Vitria BusinessWare / your favorite ancient pet tech.

BohdanPetryshyn 3y ago

What about file system? AWS Lambda allows working with the FS and running child processes. I assume this is not the case when using WebAssembly sandboxes?

mikkelhegn 3y ago
This spec describes how to work with the filesystem in WASI (WebAssembly System Interface). That's the spec adopted by Wasmtime, which is the runtime being used by Spin. (Fermyon employee here)
- mikkelhegn 3y ago
  Forgot the link: https://github.com/WebAssembly/wasi-filesystem#introduction https://github.com/WebAssembly/wasi-filesystem#introduction

ctippett 3y ago

Google App Engine came out in 2008, several years before AWS Lambda. I'd also argue the developer experience (especially for its time) was pretty fantastic. If you're wanting 'serverless' compute these days you'd probably deploy to something like Cloud Run – containers being the ultimate hedge against vendor lock-in.

imustbeevil 3y ago
I would love to use Google's cloud, but I just can't risk my email, map, and browser services being cut off because some AI determined that my application looks suspicious, with no human customer support to contact, as has been reported multiple times.
- RadiozRadioz 3y ago
  Actually I find their support to be pretty good. Granted I am at a large tech company who likely pays for premium support, but I can always get through to a human who knows what they're talking about. They've even helped with issues inside my app that were my fault.
  - solarkraft 3y ago
    You could probably profitably resell that kind of access to people who lost everything and have no other way to reach them.
    - FooBarWidget 3y ago
      Phone support is tied to an account. It doesn't work on random accounts.
- FooBarWidget 3y ago
  I tried moving off Gmail, I really did. But all the EU-based alternatives just suck so much. So now I'm back to Gmail, but I pay for it (Google Workspace). This way I at least have a commercial relationship with Google which gives me various contractual rights, and access to phone support. I also have a contingency plan: I have my email address on my own domain, and I backup my mailbox once in a while, so that I can migrate off Gmail should I need to do that at some point.

charcircuit 3y ago

>and then invoked the CGI program directly. There was no security sandbox, and CGI was definitely not safe for multi-tenancy This isn't true. Linux is the security sandbox. Multitenacy is safe using a user for each site. >Like CGI, PHP was never multi-tenant safe. This is isn't a problem with PHP. The following story about the author's site on a shared host getting hacked was a problem of shared hosts not caring about security.

DonHopkins 3y ago
Speaking of not caring: "We have things like protected properties. We have abstract methods. We have all this stuff that your computer science teacher told you you should be using. I don't care about this crap at all." -Rasmus Lerdorf "I really don't like programming. I built this tool to program less so that I could just reuse code." -Rasmus Lerdorf "I was really, really bad at writing parsers. I still am really bad at writing parsers." -Rasmus Lerdorf "I'm not a real programmer. I throw together things until it works then I move on. The real programmers will say "Yeah it works but you're leaking memory everywhere. Perhaps we should fix that." I’ll just restart Apache every 10 requests." -Rasmus Lerdorf "I don't know how to stop it, there was never any intent to write a programming language [...] I have absolutely no idea how to write a programming language, I just kept adding the next logical step on the way." -Rasmus Lerdorf "For all the folks getting excited about my quotes. Here is another - Yes, I am a terrible coder, but I am probably still better than you :)" -Rasmus Lerdorf "PHP is just a hammer. Nobody has ever gotten rich making hammers." -Rasmus Lerdorf Ian Baker's PHP Hammer: https://blog.codinghorror.com/the-php-singularity/ https://blog.codinghorror.com/the-php-singularity/ PHP: a fractal of bad design: https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/ https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/ >I can’t even say what’s wrong with PHP, because— okay. Imagine you have uh, a toolbox. A set of tools. Looks okay, standard stuff in there. >You pull out a screwdriver, and you see it’s one of those weird tri-headed things. Okay, well, that’s not very useful to you, but you guess it comes in handy sometimes. >You pull out the hammer, but to your dismay, it has the claw part on both sides. Still serviceable though, I mean, you can hit nails with the middle of the head holding it sideways. >You pull out the pliers, but they don’t have those serrated surfaces; it’s flat and smooth. That’s less useful, but it still turns bolts well enough, so whatever. >And on you go. Everything in the box is kind of weird and quirky, but maybe not enough to make it completely worthless. And there’s no clear problem with the set as a whole; it still has all the tools. >Now imagine you meet millions of carpenters using this toolbox who tell you “well hey what’s the problem with these tools? They’re all I’ve ever used and they work fine!” And the carpenters show you the houses they’ve built, where every room is a pentagon and the roof is upside-down. And you knock on the front door and it just collapses inwards and they all yell at you for breaking their door. >That’s what’s wrong with PHP.

Cupprum 3y ago

Was this blog post written by chat gpt?

kristianov 3y ago

This generation of serverless ushered in the next generation of monoliths.

eschaton 3y ago

If you really want serverless, there’s this thing you can write called a “native application” that, once deployed, a user can interact with entirely without a network connection!

lionkor 3y ago
Oh, like electron? /s

franciscop 3y ago

I remember vividly my intro to "serverless". I had been (ab)using Javascript and Node.js for a while, breaking the internals of Express.js and messing around with many things. Someone told me that serverless was "like Node.js but without server, you just write code for an endpoint" and it sounded cool. Just I didn't need it at the moment since I was happy with my servers (I'm the creator of npm's `server`). I kept hearing about it in multiple places, and after many months/years I decided to dig deeper. I found out that "serverless" was just an instance of Express all along! My disappointment was immeasurable, I thought that you really wrote a JS function, executed by "3rd party servers" (ofc there's a server _somewhere_), or in worst case you just wrote a function with the signature of Express' middleware and export it, then to be run by their instance. But no, you actually had to set up the whole server and listen to a port and all, it was just more ephemeral than Heroku's already ephemeral servers. It wasn't until next generation that "true serverless" came, with Cloudflare Workers and the such, where you truly write a plain JS function that takes a Request and returns a Response as I expected almost a decade earlier.

jeffparsons 3y ago
I could almost imagine WASI being born of the disappointment people felt when adopting the first generation of things branded "serverless". "What if this stuff was actually as good as it first sounded? Want to make it?"
joshstrange 3y ago
And we are still waiting on decent frameworks for this method of writing serverless services. I have 2 projects running like this with a cobbled together group of utils/helpers to make life easier. No routing layer or anything, that’s the job of SST/CDK/SF/etc, but things like a handler wrapper to handle errors uniformly, and other tools I regularly need (permissions checking, payload validation, etc). I know some of that work can be done at the API Gateway/Lambda layer before it hits my function but I’ve yet to go down that rabbit hole, it always felt too limiting/rigid, I could and do move way faster in JS (TS). I feel like we are on the cusp of it getting so much nicer and I have a blast working in this space. I absolutely love knowing my backend will “auto-scale” to whatever I need all the way down to $0 and even on the high end (at my scale) well under $10. My projects are for events (think festivals or “food week”) and so they are extremely bursty. They go months at a time with little to no traffic so “Serverless” and managed services that scale to $0 or near $0 are awesome for my needs.

yegle 3y ago

The author's definition of Serverless is pretty different from what I understand. It's called Serverless mostly because it's not billed based on the # of servers, instead it is mostly billed by # of requests and/or the CPU time * dedicated RAM. With this changed billing model comes with the expectations like relatively fast scaling up/down and "scale down to zero/minimum". Disclaimer I work on App Engine which is arguably the OG Serverless service.

comex 3y ago

> We imagine a feature in which a user can log into their dashboard and say, “This function is misbehaving. I would like to enable function tracing right now.” The serverless function runtime can then immediately begin tracing without any sort of recompile on the user’s side. So like dtrace or Frida or Intel Pin? Or perhaps like perf? Or good old GDB? It’s hard to say without a more specific description of ‘function tracing’. Perhaps it’s an entirely new user interface design that provides benefits never seen before. I could easily believe that, considering how often debugging tools have terrible UIs, don’t work in modern languages, or just don’t fit modern server workloads very well. Yet whatever it is, I would be surprised if it could not have been implemented for native code using the same underlying techniques as those tools. That doesn’t mean it should have been implemented for native. I think WebAsssembly is fine to base a platform around, really. Has its benefits, like hardware and OS independence, and being designed to run isolated components, and having its ecosystem designed from scratch without some of the mistakes of the past. But why are its proponents constantly ascribing to it supposedly unique capabilities that really aren’t? Even the cold start and memory benefits could largely be replicated for native code if you write a custom kernel. Sure, it’s very useful to be able to just run under an existing OS. But still, people act as if lightweight isolation is fundamentally impossible without a JITted platform like WebAssembly, or without putting everything in the same address space, when it is not. At most, the use of software bounds checks can reduce context switch times somewhat more than you could get with a custom kernel, but at the cost of potential Spectre skeletons in the closet (something I want to try attacking myself some day). And native context switch times are already a few microseconds at most.

jsty 3y ago
> Even the cold start and memory benefits could largely be replicated for native code if you write a custom kernel ... people act as if lightweight isolation is fundamentally impossible without a JITted platform I think when most people refer to this as being "impossible", they mean practically impossible, not dis-allowed by the laws of physics. "First write your custom kernel" is a step only a miniscule proportion of projects can justify. As to unique capabilities - none of its capabilities are really earth-shattering in and of themselves. But together and combined with the fact the barrier to entry is so much lower than alternatives like custom kernels, it's quite understandable why people see it as bringing something new and exciting to the table.

OJFord 3y ago

I was nodding along until key-value storage, which seems to contradict its own points about vendor lock-in and APIs?

nsonha 3y ago
I could be wrong but key value is so simple there is nothing to lock-in
- mikkelhegn 3y ago
  Fermyon employee here. There's a WASI specification in the works, which is what is used in Spin and Fermyon Cloud: https://github.com/WebAssembly/wasi-keyvalue/ https://github.com/WebAssembly/wasi-keyvalue/ With Spin you can also swap the backend provider. It's using sqlite as the default, but there's a Redis provider as well: https://developer.fermyon.com/spin/dynamic-configuration#key-value-store-runtime-configuration https://developer.fermyon.com/spin/dynamic-configuration#key...
  - Mandatum 3y ago
    Why on earth would you want to commoditize your platform?
    - mikkelhegn 3y ago
      If it's a viable option, why not give users the benefit?

busfahrer 3y ago

Can someone please elaborate on how this differs from Firebird, which also seems to be a lightweight VM that can spin up very fast

mikkelhegn 3y ago
Are you thinking about Firecracker (https://firecracker-microvm.github.io/ https://firecracker-microvm.github.io/). If so, one of our colleagues (I work for Fermyon) did touch upon this in a talk at Cloud Native WasmDay recently: https://youtu.be/-cJ_Cn_mgqI?list=PLj6h78yzYM2Pdj8vnO0wfFyKcbKNy3e5j&t=457 https://youtu.be/-cJ_Cn_mgqI?list=PLj6h78yzYM2Pdj8vnO0wfFyKc... This talk is actually a really nice compendium to the blog post.
AntonCTO 3y ago
Can you please provide more information? I only found Firebird SQL.

racktash 3y ago

At the risk of sounding very green, what is the best way to learn serverless/cloud? My decade or so of experience in the industry has been solely application development in C and C++. I've some personal experience in server side programming with PHP. Any time cloud concepts come up, it all seems very foreign to me.

mikkelhegn 3y ago
I work for Fermyon, but have been at a major cloud provider in the past, working with cloud for a decade now. Spin and Fermyon Cloud is a really nice and easy way to get started: https://developer.fermyon.com/cloud/quickstart https://developer.fermyon.com/cloud/quickstart. It doesn't introduce a whole lot of the inner workings of a cloud. With a lot of other services you'll fairly quickly get to the point, where you'll have to dive in to concepts of distributed systems and infra. If you want to work with containers and servers in the cloud, fly.io is really easy to get started with as well.

pjmlp 3y ago

Hardly new, ever heard of Java Servlets or .NET IIS Handlers?

danpalmer 3y ago

I'm quite the serverless skeptic, but honestly this sounds quite appealing. I particularly like the definition of serverless given at the beginning of this post. It's refreshingly straightforward and realistic, without the marketing BS that the cloud providers tend to give. I've always felt like developing for serverless hosting is like writing a plugin for a piece of closed-source software, and that sucks from a dev experience and lock-in point of view. Doing for serverless what CGI did back in the day seems like a good idea, and containers/WASM seem like good options for it at the moment.

SvenAl 3y ago

I've been dealing with serverless since 2018 and have a company with a 100% serverless and open-source product (webiny.com). I'm not sure I fully agree with your 4 issues and the fact that Web Assembly is the answer. "Serverless functions are slow" -> not really, only if designed poorly "DX serverless functions is sub-par" -> where's your proof, again you'll have bad experience as a developer only if you don't know what you're doing. Which I see mainly from people trying to approach building serverless applications by having a container-like mindset and that leads them to bad design choices. "Serverless functions come with vendor lock in" -> I think most of us are beyond the point of that vendor locking is bad choice. Worse choice is picking a sub-optimal technology with lower performance, higher cost and lesser reliability. "Cost eventually gets in the way" -> Again, only if you don't know what you're doing and make bad design choices. When it comes to Web Assembly, I don't see how this is a better choice of technology vs something like Node. In node I have a much wider support of the technology than WA (talk about vendor-locking), I have a proven eco system of libraries, knowledge and a much bigger talent pool to source from. The cold start issue you mentioned on your website, I can tell you first hand, the cold start is not really that big of a problem, not big enough that you would want to switch to a different technology and there are many ways to mitigate the cold start problem. Just saying, I'm far from convinced that there is a benefit in switching. I would love to see more detailed benchmarks and examples I would be able to replicate than just statements in a blog post.

rcoder 3y ago
If you have Node apps running in Lambda and are happy with the architecture, cost, and operating model: great! You've done good work and/or are very lucky and there's no need for you to rip everything out and start over. Heck, even if you're curious about WASM and want to try some experiments with (say) fast Rust crypto libraries or embedded database engines w/o the risk of flaky native code crashing your V8 runtime: again, you can just run WASM from a Node worker thread and keep cruisin'. For those of us who _don't_ have a huge investment in Node, have hard requirements around e.g. memory usage, cold start times, or even just plain old _cost_ (which can become a major factor when you consider the AWS lock-in) that Lambda doesn't meet really benefit from another option. Your good fortune in finding a stack that works well doesn't mean that folks who have different needs or constraints are dumb, ignorant, or lazy. As an aside, I think you also might be underestimating the depth of experience and knowledge of the Fermyon crew when it comes to containers, cloud runtimes, and serverless development. This is substantially the same team that built Helm, and a lot of other Kubernetes and cloud-native ecosystem projects along the way.

kaishin 3y ago

This going to be a naive question due to my lack of familiarity with WebAssembly, but what does it it being to the table that wasn’t possible to do with any other standalone program packaged as a binary?

regularfry 3y ago
Strong isolation guarantees, mainly, which let hosters (like the OP) resource share more densely and with better startup profiles than virtualisation gives you.

NorwegianDude 3y ago

> PHP was never multi-tenant safe You're running on the same host, so there might be exploits that allow you to break free, but that goes for most other "serverless" solutions too.

rcoder 3y ago

Since it sounds like very few folks in this thread have actually fired up Spin and built a thing, I thought I might offer a few observations based on my experience working on a little app over the last 2-3 weeks. First, the good stuff: - As a Rust developer, the SDK tooling is really good. I went from running the installer to generating a templated app to dropping in my own app logic in about 15 minutes. - Local development iteration is also very fast and low-friction. Building everything as small WASM components means you effectively get hot module reloading for free, without needing to shim in a bunch of extra dev-mode-only code loading logic (with all the inherent incompatibilities and heisenbugs) - The component reuse model feels a lot easier for me to reason than interminable chains of Express middleware (YMMV, of course) - You get actual static (WASM) binaries, which can be as small as your compiler makes them. I'm normally pretty thrilled to get a production app container down to <100MB, and the app I've been working on, even without really paying any attention to my dependency graph, is around 2MB. Storage may be cheap, but pulling ~GBs of new container layers for a given release or deployment isn't free or instantaneous. There are some less-great things: - The "outbound" DB adapters are _very_ bare-bones. You only have access to a small list of datatypes, and you can't really layer higher-level libraries on top b/c the APIs aren't compatible with standard backend drivers. (Furthermore, if you want to use e.g. MongoDB, Clickhouse, Dynamo, etc., etc.: sorry, I hope you have some sort of HTTP adapter lying around ready to use.) - WIT (WebAssembly Interface Types) is a cool _emerging_ standard, but like a lot of WAS* community stuff it's still in a fractured "draft" state, and many of the actual interfaces exposed in Spin are unique to their runtime. (This also means that _extending_ something like the PG bindings requires a ton of indirection code spelunking; I gave up trying to add a few new native types after realizing I would also have to support them for MySQL and every other backend DB.) - The development environment, while relatively complete and usable on its own, doesn't really play nice with Nix or other high-level dev environment tooling. (There are literally invocations of `rustup` inside the top-level `build.rs` for the project, so good luck providing your own paths for e.g. `rustc`.) On balance, I'm enjoying the experience thus far and starting to think about more thing-ish was to apply the tools. I'm also looking forward to trying out more of the self-hosted infrastructure stack. I'm not opposed to paying for managed hosting, but I do occasionally build things that need to run in "offline" or air-gapped environments, so being able to bring up a full hosting environment is pretty clutch.

JohnFen 3y ago

My wish for the next generation of "serverless" is that they find a better thing to call it than "serverless".