Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The next generation of serverless

fermyon.com

Post reply on HN
Print view View original

51–60 of 93 posts

Re: The next generation of serverless

#51

Post by erhaetherth »

comex wrote: post #36

> 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…

Is WebAssembly even fundamentally different from Java/JVM or C#/CLR? I like WebAssembly but I don't think it brings anything new except that it can kind of run in a browser, but so could Java and C# for a brief period of time.

Re: The next generation of serverless

#53

Post by erhaetherth »

jsty wrote: post #48
comex wrote: post #36

> 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…

> 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 o…

I don't understand why we need a 'custom kernel'. Have your serverless server give you the specs for whatever the heck they want to run and compile against that. Why do we need a new kernel?

Re: The next generation of serverless

#54

Post by mikkelhegn »

BohdanPetryshyn wrote: post #17

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?

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)

Re: The next generation of serverless

#55

Post by danpalmer »

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.

Re: The next generation of serverless

#56

Post by sam_goody »

DonHopkins wrote: post #25
charcircuit wrote: post #22

>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 abou…

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…

I mean, I get that you don't like PHP. Which is fine, we need people to keep the other communities humming as well.

IMO, PHP is better than any other language I have used, so I actually respect it.

The fact that the creator is open about his figuring it out along the way is pretty cool in my eyes - after all, he started before there was anything, [Alta Vista, Lycos, and a lot of friendly geeks trying to figure out how this was better than usenet?] and he made something which is very popular and really works very well.

Imagine what would happen if Vitalik was as honest as Rasmus ;)

My 2c.

Re: The next generation of serverless

#58

Post by mikkelhegn »

nsonha wrote: post #52
OJFord wrote: post #37

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

I could be wrong but key value is so simple there is nothing to lock-in

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/

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...

Re: The next generation of serverless

#59

Post by mikkelhegn »

mikkelhegn wrote: post #54
BohdanPetryshyn wrote: post #17

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?

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)

Forgot the link: https://github.com/WebAssembly/wasi-filesystem#introduction

Re: The next generation of serverless

#60

Post by Mandatum »

mikkelhegn wrote: post #58
nsonha wrote: post #52

Earlier quoted context omitted.

I could be wrong but key value is so simple there is nothing to lock-in

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/ 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...

Why on earth would you want to commoditize your platform?
Post reply on HN