zackbloom

35MB is what Amazon reports and bills you based on. If that number is wrong, a great question is what are they charging people for?

Launching a process is different than launching a language runtime or interpreter. They generally are not optimized for initial start time in the way an Isolate is. The duration of a context switch varies, but when dealing with tens of thousands of requests per second per machine they are very significant.

Lambda@Edge is built on Cloudfront and pushing any change to Cloudfront generally takes 20-30 minutes in my experience. Can you tell me more about the change you're making? Is it code or config changing?

You can run any WebAssembly targeting language in a Worker.

The real hope is people start building applications this way. That's the innovation. The current serverless technologies they are using provide process level APIs which are fundamentally unnecessary for their application, and when you break free of that things change dramatically.

Yes, we would love to do that. Workers are lightweight enough that they appear to be a much more viable way to distribute compute than technologies like Kubernetes.

Hi! I work on KV at Cloudflare. Thank you so much for your interest in it, and for considering Workers at all. I'm pretty convinced if you keep considering it when situations allow, you'll choose it eventually when the moment is right for the product and your company.

I'm happy to give you beta access for you to experiment. That said, we take the distinction between a beta and GA very seriously. We don't want you relying on software we're not, at the very least, using in production ourselves.

That day will come very soon! We're moving several projects into KV (allowing us to move them out of centralized data centers), and we expect KV to track GA in the next few months.

One of the fundamental truths behind any innovation is it breaks at least one 'sacred' belief of the last generation. The JVM was not a technology built for this kind of multi-tenancy, it was bolted on later.

V8 is one of the most well tested and secured pieces of software in existance, and that it has a much smaller surface area than the Linux process isolation you're referring to.

(I sit next to Kenton)

I would actually argue with #1. The truth is, this appears to be a better tech even if it isn't globally distributed.

Lightweight serverless functions with no cold-start are a really great primitive to build on. We figured them out in this way to enable global distribution, but that's a bonus, not necessary to really love the concept.

I think the disease is actually political systems which dramatically misalign the well-being of the rich and the rest of us. If you fix that, everything else will fix itself through much more long-term political decision making.

That article never actually explained why Red Hat was successful where others weren't. It got lost on showing how _not_ successful they were, even as it said how exceptional their results were.

You can deploy WebAssembly to 154 data centers as a part of Cloudflare Workers if you'd like to play with it: https://blog.cloudflare.com/webassembly-on-cloudflare-worker...

Cloudflare is actually a totally different company, yes! Here is more info about Workers: https://developers.cloudflare.com/workers/about/

You might want to try Cloudflare Workers instead. (disclaimer: I work at Cloudflare)

It becomes even more problematic when one of the political parties view compromise as a part of its ideology and the other doesn't. One side is politely fighting and the other is waging a guerilla war.

Having the top-comment doesn't lie, THE PEOPLE ARE WITH ME!

Also, is there a badge or sash I can get somewhere saying "Not a Real C Programmer"?

It's worth realizing the multi-tenant nature of Workers happens within a single process, meaning from a cost perspective it's essentially indistinguishable from running your own hardware. It's actually one _less_ VM than if you were managing your own EC2 instances.

Each person can take their own meaning away from this, but for me the most impressive part will always be @kentonv's hand-rolled libc replacement: https://github.com/cloudflare/cloudflare-workers-wasm-demo/b...

Put the target channel name and a message id at the front of each key and you can use a tuple space for IPC.

We limit you to 50ms of CPU and 128 MB of memory now, but we're working on ways of raising those limits.

We haven't exposed it yet, but it's implemented internally. Follow our blog and we'll update you when it's released.

Fundamentally what I think we want to do is build the primitives you would need to create your own fanout. That means we need the ability to push events to Worker nodes, and for Workers to be able to terminate WebSockets for you.

If you can accept up to 10s of latency, I agree that KV could solve the 'pushing events' problem for you. (A tuple store is semantically equivalent to message passing, and it will get easier when we support range queries).

It would work just as most shopping carts do I imagine. You could store a session id in a cookie, and then use the data in KV to map that session id to a user account (if they're logged in) and their cart. So you would have a namespace full of sessions, and a namespace full of carts.

You could also store carts by session id until they're logged in, and then store the carts by account id when they are.

The ultimate goal is to let you do all of that within our network!

When you say overhead limit, are you talking about latency? Our goal is to keep reads on the order of 5ms in the 90th percentile.

Can you talk more about your specific use case?

You write the Worker code which runs on our infrastructure, not in a browser. You have complete control over who can access which piece of data, as it's your code doing the accessing.

We're planning on adding support for range requests (which becomes equivalent to prefixes a la CouchDB). Is there a reason you need glob specifically?

One thing to remember is you have at least two other ways of storing values. Each worker has global memory which persists between invocations (local, atomic), and you have access to the Cache API (per-data center, ephemeral).

By combining those with KV to do global coordination on a more course time scale, I think you could.

If you can find a good Javascript library for doing it you can build it into your Worker with Webpack.

It's moving that shopping cart data from being stored at a single origin, to being stored in the network all around the world. The advantage of that in that use-case is you can render your site just as quickly as if it was a static website, but it can contain the customer's personal shopping cart data.

The question I would ask is: once you have the ability to run code and store data on the network itself (which Cloudflare effectively is), why do you need an origin at all?