Live data from Hacker News

Our container platform is in production. It has GPUs. Here's an early look

blog.cloudflare.com

61–70 of 76 posts

Re: Our container platform is in production. It has GPUs. Here's an early look

#61

Why does it take 4 minutes (after being optimized from 8 minutes!) to move a 30 GB (compressed) docker image ...? The read slowness of docker registries continues to surprise me ...

Perhaps they are throttling this transfer to 1Gbps so as to not slam their network or disk I/O? It does seem quite slow.

Re: Our container platform is in production. It has GPUs. Here's an early look

#62
post #57

I like using Workers for smallish http services. The uptime, pricing, and latency are fantastic. I would never use them for anything complex as the vendor lock in is quite strong and the dev experience still needs to improve. Containers on the edge with low cold starts, scalability, the same reliability as Workers, etc would be super cool. In part to avoid the lock in but also to be able to use other languages like G…

Workers use the web worker API so theoretically there’s less lock in. I’ve also found wrangler pretty good, what problems have you run into?

You can't really run the Worker code without modifications somewhere else afaik (unless you're using something like Hono with an adapter). And for most use cases, you're not going to be using Workers without KV, DO, etc.

I've hit a bunch of issues and limitations with Wrangler and Workers locally over the years.

Eg:

https://github.com/cloudflare/workers-sdk/issues/2964

https://github.com/cloudflare/workerd/issues/1897

Re: Our container platform is in production. It has GPUs. Here's an early look

#63
I love they built all this infra for running js to avoid building a container runtime and ended up building a container platform using all the hypervisors. On more serious note, I do not understand why they can't fix the 500mb upload limit. I hit that with r2 registry and ended switching away instead changing all the dockepush tooling. Not super excited re using more weird tools rather than fixing platform

Re: Our container platform is in production. It has GPUs. Here's an early look

#64
post #57

I like using Workers for smallish http services. The uptime, pricing, and latency are fantastic. I would never use them for anything complex as the vendor lock in is quite strong and the dev experience still needs to improve. Containers on the edge with low cold starts, scalability, the same reliability as Workers, etc would be super cool. In part to avoid the lock in but also to be able to use other languages like G…

This is why I switched to deno deploy. Much of the same benefits and much more portable stack.

Re: Our container platform is in production. It has GPUs. Here's an early look

#65
post #8

This seems like a pretty big deal. I want to like CloudFlare over DO/AWS. I like their DevX focus too -- I could see issues if devs can't get into the abstractions though. Any red flags folks would stake regarding CF? I know they are widely used but not sure where the gotchas are.

Won't apply to everyone (most?), but some compliance assurances your customers may require can't be fulfilled by Cloudflare. And personally, I would hope their laissez faire attitude towards protecting hate speech should damage their business, but I suspect most people not targeted by such just don't give a damn.

What’s hate speech to you is free speech to someone else.

Re: Our container platform is in production. It has GPUs. Here's an early look

#66
post #19

Earlier quoted context omitted.

Is Cloudflare the one that goes from free to "call for pricing" ($100K+) at the drop of a hat?

https://blog.cloudflare.com/cloudflares-commitment-to-free/

The https://developers.cloudflare.com/calls/turn/overview/ link in that article 404s. Looks like it should be https://developers.cloudflare.com/calls/turn/?

Re: Our container platform is in production. It has GPUs. Here's an early look

#67
post #66

Earlier quoted context omitted.

https://blog.cloudflare.com/cloudflares-commitment-to-free/

The https://developers.cloudflare.com/calls/turn/overview/ link in that article 404s. Looks like it should be https://developers.cloudflare.com/calls/turn/ ?

I'll get that fixed. Thanks for reporting it.

Re: Our container platform is in production. It has GPUs. Here's an early look

#68

I love they built all this infra for running js to avoid building a container runtime and ended up building a container platform using all the hypervisors. On more serious note, I do not understand why they can't fix the 500mb upload limit. I hit that with r2 registry and ended switching away instead changing all the dockepush tooling. Not super excited re using more weird tools rather than fixing platform

Agreed; after 7 hopeful years this feels like a declaration of defeat for V8 isolate-based FaaS.

Re: Our container platform is in production. It has GPUs. Here's an early look

#69
surprised they didn't go straight into cloud-hypervisor, though I haven't actually tested with gpu yet but it is on my todo list. OCI layers can use zstd compression. I wonder if they are defeating layer sharing by splitting in 500 mb chunks. Lambda splits your image into chunks and shares at the block layer (I believe even same chunk different (user's?) container on a single host). Esp for 15 GB images I'd think using lazy pulling with nydus/stargz or whatever would be beneficial. I'd like to test out snapshotting, though my testing already boots a guest and runs a container in ~170ms; and I'm not actually sure how you write the guest init to signal it is ready for snapshotting and then wait properly (maybe you just sleep 1000?) so it resumes from the snapshot in a good state. I know fly has written about their use of snapshotting but I don't think it went into that detail. Cool stuff overall though, not worrying about locations and the yucky networking to do so seems nice

Re: Our container platform is in production. It has GPUs. Here's an early look

#70
post #57

I like using Workers for smallish http services. The uptime, pricing, and latency are fantastic. I would never use them for anything complex as the vendor lock in is quite strong and the dev experience still needs to improve. Containers on the edge with low cold starts, scalability, the same reliability as Workers, etc would be super cool. In part to avoid the lock in but also to be able to use other languages like G…

This is why I switched to deno deploy. Much of the same benefits and much more portable stack.

It's great you can run Deno anywhere you want. Their KV service is phenomenal too.

Personally I don't want to keep using JS in the server anymore. As more time passes I feel like TS is a hack compared to the elegance of something like Go.

Post reply on HN