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

Python Cloudflare Workers

blog.cloudflare.com

Post reply on HN
Print view View original

61–70 of 101 posts

Re: Python Cloudflare Workers

#61

Post by adam_arthur »

I would like to see CloudFlare implement workers with WASM as the first class citizen, and a general purpose API not tied to JS workers.

Up until now you've been able to deploy WASM code (e.g. effectively can use any language), but it runs within a JS context, rather than natively.

Just a bit more overhead/awkwardness in deployment. I believe eventually all services will be deployed directly to WASM (securitized) runtimes, rather than via containers, similar to how we moved from images -> containers).

There's very little benefit currently to trying to use something like Rust on the edge (in CF), because a lot of the perf advantage is negated by the overhead and startup times.

e.g. https://github.com/WasmEdge/WasmEdge

Re: Python Cloudflare Workers

#62

Post by kflansburg »

syrusakbary wrote: post #58
kflansburg wrote: post #56

Earlier quoted context omitted.

We discussed a separate configuration field for Python version. It’s not technically challenging, this was a design choice we made to simplify configuration for users and encourage more efficiencies in terms of shared dependencies. Your concerns about V8 would impact JavaScript Workers as well and do not match what we see in production. It is also definitely possible to invoke C++ host functions directly from Wasm wi…

> Your concerns about V8 would impact JavaScript Workers as well and do not match what we see in production Interesting! I thought V8 snapshots were mainly used in the Pyodide context, as I could not find any other usage in WorkerD (other than promise tagging and jsg::MemoryTracker). Are you using V8 snapshots as well for improving cold starts in JS applications?

I was responding to your point about isolates and cold starts. Snapshots are unique to Python, but V8 does not seem relevant here, all this is doing is initializing the linear buffer that backs Wasm memory for a particular instance. We have a lot of ideas here, some of which are mentioned in the blog post.

Re: Python Cloudflare Workers

#63

Post by dom96 »

garrettgu10 wrote: post #53
harikb wrote: post #48

Is the choice of lzma to demonstrate isolation intentional or was it just a coincidence considering last week's tech news...[1] [1] https://news.ycombinator.com/item?id=39865810

Haha, we included it just because it's part of the standard library. Total coincidence in terms of timing but it's nice that using Wasm gives us isolation guarantees :-)

Yeah, pure coincidence. I picked it before the xz news broke.

Re: Python Cloudflare Workers

#64

Post by syrusakbary »

kflansburg wrote: post #62
syrusakbary wrote: post #58

Earlier quoted context omitted.

> Your concerns about V8 would impact JavaScript Workers as well and do not match what we see in production Interesting! I thought V8 snapshots were mainly used in the Pyodide context, as I could not find any other usage in WorkerD (other than promise tagging and jsg::MemoryTracker). Are you using V8 snapshots as well for improving cold starts in JS applications?

I was responding to your point about isolates and cold starts. Snapshots are unique to Python, but V8 does not seem relevant here, all this is doing is initializing the linear buffer that backs Wasm memory for a particular instance. We have a lot of ideas here, some of which are mentioned in the blog post.

Awesome. Eager to see how the product evolves :)

Re: Python Cloudflare Workers

#65

Post by VHRanger »

dandaka wrote: post #51
jatins wrote: post #9

Clouflare has a lot of great stuff for hosting and databases but I think they haven't done a great job marketing themselves as developer platform which has lead to platforms like Vercel, Netlify taking significant mindshare. Tangential: does Cloudflare provide container hosting service agnostic of language -- something like Google Cloud Run?

It is not only about marketing. Initially, I was optimistic about Cloudflare's offerings. However, I encountered significant issues with compatibility, especially with website generators such as Next.js and Astro. Some features didn't work at all, while others were only partially supported. Faced with the prospect of dedicating valuable development time to troubleshooting these issues, I found it more efficient to us…

Anecdata: I've just switched over to cloudflare pages for an 11ty site and it works really well.

Re: Python Cloudflare Workers

#66

Post by derefr »

nstart wrote: post #44
Difwif wrote: post #18

Earlier quoted context omitted.

I agree something is wrong with their marketing. I was also initially drawn to Vercel and Netlify but after extended use and not being happy with either I eventually tried Cloudflare and discovered I love it. The pricing and the product is fantastic.

I think it’s because the experience of familiarizing oneself with the platform and getting to a hello world level crud app/basic static site is done a lot better with vercel and netlify than it is with cloudflare. Cloudflares site and docs are not built with the approach of getting an app from 0 to 1 ASAP.

I get the sense that Cloudflare Workers is targeted almost exclusively at existing customers of Cloudflare, who have a “legacy” app proxied through Cloudflare DNS, who use Page Rules and Firewall Rules and the like.

For these customers, Workers are an incremental optimization of an existing app — shifting some work to the edge, or allowing some systems to have a previously-internal backend stripped out, leaving them as e.g. Workers in front of an object-storage bucket. And that’s exactly how Cloudflare advertises them.

It looks like Cloudflare’s outreach advertising, meanwhile, is all about CF Pages and CF Sites. You can find SEOed landing pages for these; whereas Workers is mentioned ~never in external media as a “solution” — even though it totally can be.

Re: Python Cloudflare Workers

#67

Post by hoodchatham »

syrusakbary wrote: post #47
kflansburg wrote: post #40

Earlier quoted context omitted.

I believe that your summary misunderstands how we will handle versioning. The pyodide /package versions will be controlled by the compatibility date, and we will be able to support multiple in production at once. For packages like langchain (or numpy as you mentioned) the plan is to update quite frequently. Could you expand on why you believe V8 will be a limiting factor? It is quite a powerful Wasm runtime, and most…

> pyodide /package versions will be controlled by the compatibility date That's exactly the issue that I'm mentioning. Ideally you should be able to pin any Python version that you want to use in your app: 2.7, 3.8 or 3.9 regardless of a Workerd compatibility date. Some packages might work in Python 3.11 but not in 3.12, for example. Unfortunately, Python doesn't have the full transpiler architecture that JS ecosyste…

Are people maintaining wasi ports of Python 2.7 and 3.8?

Re: Python Cloudflare Workers

#68

Post by riazrizvi »

brendanib wrote: post #27
tyingq wrote: post #2

A performance comparison to a JS worker would be helpful. It does sound interesting, but also sounds potentially slow, given all the layers involved. Not that I'm expecting parity, but knowing the rough tradeoff would be helpful.

Three aspects of performance: 1. Cold start perf 2. Post-cold start perf - The cost of bridging between JS and WebAssembly - The speed of the Python interpreter running in WebAssembly Today, Python cold starts are slower than cold starts for a JavaScript Worker of equivalent size. A basic "Hello World" Worker written in JavaScript has a near zero cold start time, while a Python Worker has a cold start under 1 second.…

Very helpful- thanks

Re: Python Cloudflare Workers

#69

Post by syrusakbary »

kentonv wrote: post #60
syrusakbary wrote: post #47

Earlier quoted context omitted.

> pyodide /package versions will be controlled by the compatibility date That's exactly the issue that I'm mentioning. Ideally you should be able to pin any Python version that you want to use in your app: 2.7, 3.8 or 3.9 regardless of a Workerd compatibility date. Some packages might work in Python 3.11 but not in 3.12, for example. Unfortunately, Python doesn't have the full transpiler architecture that JS ecosyste…

(Cloudflare Workers tech lead here.) I disagree about V8 not being optimized for edge environments. The needs of a browser are actually very much aligned with needs of edge, namely secure sandboxing, extremely fast startup, and an extreme commitment to backwards compatibility (important so that all apps can always run on a single runtime version). Additionally, V8 is just much better at running JavaScript than you ca…

Hey Kenton, great to see you chiming in here as well!

> Additionally, V8 is just much better at running JavaScript than you can hope to achieve in a Wasm-based JS implementation. And JavaScript is the most popular web development language (even server-side).

I agree with this statement as of today. Stay tuned because very cool things are coming on Wasm land (Spidermonkey will soon support JITted workloads inside of Wasm, bringing the speed much closer to V8!)

> Note that the time to initialize an isolate isn't actually on the critical path to cold start, since we can pre-initialize isolates and have them ready to go before knowing what application they will run

That's a good point. Although, you are kind of optimizing now the critical path to cold start by actually knowing what the app is running (if is Python, restore it from a Snapshot). So even though if isolate initialization is not in the critical path, there are other things on the critical path that amounts for the extra second of latency in cold starts for Python, I would assume.

> Minimizing application size is really essential to making edge compute inexpensive

By leveraging on proper-defined dependencies, you just need to compile and load in memory the dependency module once (lets say Python) and have "infinite" capacity for initializing them. Basically, if you put Python out of the picture and consider it a dependency of an app, then you can suddenly scale apps as much as you want there!

For example: having 10 Python versions (running thousands of apps) will have a overhead of 5Mb (Python binary size in avg) * 10 versions (plus a custom memory for each initialization of the app, which is required in either strategy) ~= 50Mb, so the overhead of pinning a specific Python version should be truly minimal on the server (at least when fully leveraging on a Wasm runtime)

Re: Python Cloudflare Workers

#70

Post by ssijak »

kentonv wrote: post #32
ssijak wrote: post #16

Can we just get full node runtime? Cloudflare is amazing, but without a full node runtime, we (and most of the usual apps) can't switch from things like Vercel/Netlify to Cloudflare.

The unique architecture of our runtime is what enables most of our competitive advantages. It's what lets us run your application in hundreds of locations around the world while also charging less than competing serverless platforms. If we used a full Node runtime, we would need to charge a lot more money, or only run your app in a couple central locations, or both. So, no, we can't just offer full Node. However, we…

I understand what you said. I did not expect full node runtime workers with all the other benefits that you listed that current workers have (global distribution, no cold starts, cost..). But it would be great to have a choice. I feel it would benefit both users and Cloudflare to support both (with different tradeoffs). For example, selecting "I want node runtime for this app workers," I would need to select the region they will run in, and that's it, those functions/workers would not be globally distributed, would probably cost more, but when you need full node runtime you need it and that is fine.
Post reply on HN