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

61–70 of 93 posts

Re: The next generation of serverless

#61

Post by mikkelhegn »

racktash wrote: post #43

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.

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

Re: The next generation of serverless

#62

Post by SvenAl »

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.

Re: The next generation of serverless

#63

Post by mikkelhegn »

Mandatum wrote: post #60
mikkelhegn wrote: post #58

Earlier quoted context omitted.

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?

If it's a viable option, why not give users the benefit?

Re: The next generation of serverless

#64

Post by 9dev »

nickstinemates wrote: post #12
gabrieledarrigo wrote: post #10

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

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.

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.

Re: The next generation of serverless

#65

Post by FooBarWidget »

imustbeevil wrote: post #26
ctippett wrote: post #21

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.

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.

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.

Re: The next generation of serverless

#66

Post by FooBarWidget »

solarkraft wrote: post #42
RadiozRadioz wrote: post #35

Earlier quoted context omitted.

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.

Phone support is tied to an account. It doesn't work on random accounts.

Re: The next generation of serverless

#67

Post by trallnag »

FooBarWidget wrote: post #65
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.

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…

Have you considered Zoho? It's a company based in India, but they have European servers.

Re: The next generation of serverless

#68

Post by creshal »

charcircuit wrote: post #44
creshal wrote: post #41

Earlier quoted context omitted.

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

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

That's the whole point: If you have to chroot/container everything because it violates regular permission models too much, PHP is not multi-tenant capable by itself.

Re: The next generation of serverless

#69

Post by sofixa »

snops wrote: post #9

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?

> 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

Re: The next generation of serverless

#70

Post by snops »

sofixa wrote: post #69
snops wrote: post #9

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?

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

If its "just storage", how is it any better for this application than a zip file?
Post reply on HN