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

41–50 of 93 posts

Re: The next generation of serverless

#41

Post by creshal »

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…

> This is isn't a problem with PHP.

I'd argue it is, since PHP's common runtimes expect you to cross user boundaries all the time:

- as Apache2 module, PHP runs as the same user as the web server, so the web server needs to have write access across all tenants.

- FPM recommends running as a TCP socket, letting tenants freely access other tenants' PHP processes. Unix sockets can solve that issue with carefully permissions, but the documentation barely mentions that use case.

Containers are the minimum security boundary.

Re: The next generation of serverless

#42

Post by solarkraft »

RadiozRadioz wrote: post #35
imustbeevil wrote: post #26

Earlier quoted context omitted.

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.

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.

You could probably profitably resell that kind of access to people who lost everything and have no other way to reach them.

Re: The next generation of serverless

#43

Post by racktash »

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.

Re: The next generation of serverless

#44

Post by charcircuit »

creshal wrote: post #41
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…

> This is isn't a problem with PHP. I'd argue it is, since PHP's common runtimes expect you to cross user boundaries all the time: - as Apache2 module, PHP runs as the same user as the web server, so the web server needs to have write access across all tenants. - FPM recommends running as a TCP socket, letting tenants freely access other tenants' PHP processes. Unix sockets can solve that issue with carefully permiss…

>since PHP's common runtimes expect you to cross user boundaries all the time:

No they don't. Just because a default installation is single tenant that doesn't mean shared hosts can't configure it to be multitenant. It is simple to set up FPM to have a pool for each site use its designated user and have it chroot.

>Containers are the minimum security boundary.

Whose security boundary is also the kernel. It's not that much different.

Re: The next generation of serverless

#45

Post by jeffparsons »

franciscop wrote: post #33

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

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

Re: The next generation of serverless

#47

Post by pjmlp »

romanichm12 wrote: post #8

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

Java servlets in application servers, and IIS CLR Handlers, WebAssembly sales pitch is so 2001.

Re: The next generation of serverless

#48

Post by jsty »

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

Re: The next generation of serverless

#49

Post by irjustin »

radarsat1 wrote: post #38
irjustin wrote: post #23

Earlier quoted context omitted.

This does have to be managed, empty Django is ~3.5s ours is Heavy/slow libraries aren't loaded in the web via settings file, but are loaded in background workers. We've found that image processing libraries and PDF handlers are slowest to load. We use 3 minute crons to keep a set of concurrent workers alive (pre-warming as you describe). The number of requests that hit full cold start are But yeah, not all frameworks…

> We use 3 minute crons to keep a set of concurrent workers alive (pre-warming as you describe). The number of requests that hit full cold start are Does this mean you have a cron job just pinging the serverless function every 3 minutes? I'm curious how much this adds on to your costs. It means that the whole "don't pay for non-usage" thing is not quite true, but maybe it's still significantly cheaper than running an…

> Does this mean you have a cron job just pinging the serverless function every 3 minutes? I'm curious how much this adds on to your costs. It means that the whole "don't pay for non-usage" thing is not quite true, but maybe it's still significantly cheaper than running an EC2 instance or whatnot. I'm curious about the cost calculation here.

Yes, specifically it kicks off a Lambda function that does a parallel GET to our website at a special endpoint that has a 100ms "wait" and basic DB call. This keeps the lambda process alive/in-memory.

To keep a function alive costs ~125ms (100ms wait + 25ms full func roundtrip). every 3 minutes. ~0.041% of 1x CPU time. Our website server costs are tiny and lower for Staging and UAT. Benefit - can scale to 1000x (AWS Limit) servers at the speed of your cold start time.

But if you have a heavily used website, Lambda is not cost effective at all.

> Another thing I'm curious about, since you have a container-based deployment, did you compare with Fargate?

Yes we use Fargate for our core product which is built in Rails before containers could be deployed in Lambda. Rails works fine on Lambda[0] but the transition cost wasn't worth it for us. Fargate is great, but as you point out it is expensive if your application isn't a user heavy one like ours. To be highly available, we always have a minimum of 2 online but we're a b2b application so our night usage, 10pm-6am is zero. But I have 2 machines just sitting there. This is why i love Lambda >> Fargate.

Also, scalaing Fargate machines is slow if you get a traffic spike.

[0] https://github.com/rails-lambda/lamby

Re: The next generation of serverless

#50

Post by mikkelhegn »

busfahrer wrote: post #39

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

Are you thinking about Firecracker (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=PLj6h78yzYM2Pdj8vnO0wfFyKc...

This talk is actually a really nice compendium to the blog post.

Post reply on HN