Hacker News Reader

Comment by tyingq | Hacker News Reader

It feels like if they released a serverless/Lambda equivalent they would start taking a lot of business from the big 3. Workers are somewhat close, but the v8/isolate pattern limits them to narrower use cases. A more traditional serverless that could sit at the center and be optionally fronted by Workers would be nice.

View on HN

A big turn off for me is wanting to use Python on Cloudflare Workers and then reading that it needs to compile to JavaScript.

https://developers.cloudflare.com/workers/platform/languages

I definitely understand that Cloudflare Workers are likely to be unsatisfying as a Lambda replacement for people who want to use a language like Python.

I think there is a decent reason why Cloudflare, at least initially, went the route that it did. V8 Isolates allow them to run code from many different people without many of the cold-start, memory, and performance issues of offering a more full environment. V8 Isolates allow them to be a lot more efficient than something like Lambda. It does come with the cost of being more limited for things like language support.

I think it's a pretty good bet. Lots of people are comfortable with JavaScript/TypeScript (even if you or I don't love it) and WebAssembly is likely to become a decently supported compilation target over the next 5 years from a lot more languages. Microsoft has done a lot for C#/.NET support of WebAssembly and it should be quite good with .NET 6 coming in 2 months. Python, Go, and many other languages have at least some support for WebAssembly and it seems like that will only get better over time.

I definitely understand it being a turn-off. If you haven't read their post introducing them, I'd read it: https://blog.cloudflare.com/cloud-computing-without-containe.... It doesn't solve your problem, but I think it's a good read on why they made that trade-off.

Good explanation! Helped my understanding of their choices. :)

Cloudflare acquiring fly.io would be interesting to see.

I'd bet more on them using their internal stack/expertise from building workers.

As I was reading this article, I thought to myself, oh, this is the acquirer fly.io has in mind…

I think we're a year ahead of Cloud Flare on learning but we do not want to be acquired. They also don't like us much.

That's what they all say.

Sometimes it's a negotiation stance. Sometimes it just means "getting acquired sucks and we would rather do our own thing in the way that we think is best". Like this time!

> They also don't like us much

Huh, that's too bad! Meaning they've caused trouble for your customers? Definitely disappointing to hear...

Oh no. I don't want to imply anything nefarious. I think we've just been irritating.

when can we see some real competition with CF? as in offering a modular CDN, WAF, etc? Your build-your-CDN blog post left me hoping you’ll build one for us :)

I think we'll solve some of this, most people who want a WAF just want to check a box. It makes sense to sell them a WAF. It's not where we're most valuable, though, our customers are pushing us towards much more interesting infrastructure. :)

Cloudflare acquiring Lumen and Fly would be interesting to see.

All of Lumen’s value is in the nationwide backbone fiber although they are trying to make a play in edge computing. IMO those fiber assets in the hands of a company like CF combined with a service like Fly would be pretty incredible.

You prefer monopoly?

While this doesn't preclude your scenario, note that cloudflare acquired appfleet recently, which was a similar service:

https://appfleet.com/pricing

https://appfleet.com/blog/appfleet-joins-cloudflare/

100% agree with this. Running docker images on serverless is really great and allows you to deploy your environment to any provider with minimal effort. would be cool if they can add something like this, even if it does not provide 0s startup time..

To me, that's like saying that web browsers should be able to run existing native applications, so we can lift and shift more existing code. But just as JavaScript-based web applications enabled frictionless code distribution on the client side, JavaScript-based Cloudflare Workers is doing the same on the server side. Sometimes progress requires breaking backward compatibility, and I think this is one of those cases. And I'm confident that there will be other runtime environments that emulate Cloudflare Workers, mitigating the risk of vendor lock-in.

I'm skeptical that JavaScript and WASM are anywhere near being suitable for any and all backend services.

For example, Cloudflare workers can't even talk to the outside world with anything other than fetch(). There's websockets, but only as a pair to talk to a browser that connected to you.

I'm a fan of Workers, but they do have limitations.

Likewise, there was a time when microcomputers weren't suitable for many applications. Sometimes a new approach (edit: and ultimately a better one) has to start at the low end and work its way up.

Reply on news.ycombinator.com