This post is coated with lots of marketing fluff, while not directly answering the questions I most care about;
How does it work? What can I host with it? How does the pricing compare (free tier?)?
It has even deployment instructions that don't tell you when your code will run, what resources are available or even on what URL you can access it. They say you can host a tokio server, but there's no mention of database or filesystem.
I imagine that admin panel has those answers, but well, I'm really not doing a deployment to see it. (I'm not even creating an account.)
If you are interested in knowing how it works I recommend reading the docs [1], we have invested quite some time in them. Please let us know if more info might be useful and we will work on updating them.
> What can you host with it
Right now any static sites and Rust applications (including webservers and other TCP/UDP applications). Support for Node.js and Python is coming very soon!
> How does the pricing compare (free tier?)?
During the private alpha, Wasmer Edge will be completely free for its users.
Once the beta becomes public and available to everyone, pricing is expected to be comparable to Cloudflare Workers. We have also drafted the pricing on the product page [2]
I'm Syrus, from Wasmer. We have created Wasmer Edge as a powerful alternative to the Clouds. An alternative that allows reusing the codebases that worked in the Cloud without rewriting them to custom SDKs (such as Amazon Lambda, or Cloudflare Workers), and running them at CDN-like prices.
With Wasmer Edge you can use a normal http-server in any language or even write a full DNS server based on it.
We are incredibly excited of the paths that will open ahead.
For those interested, here's the document showcasing how everything is architected:
I feel your pain. We need to scale it slowly to provide the best experience for the people and companies using it (including tight and free support!) but hopefully we will be able to open the service to everyone soon.
I guess we really internalized YC's motto: we rather have one person having a great experience and loving us, than 10 liking us with an ok experience than 100 using us with a poor experience ...and the waitlist helps on that quest.
Although it seems there's a good chance you'll love the product. Feel free to message me to syrus@wasmer.io and we'll be in touch soon!
I don't get what "the edge" is here. I understand what the edge is with Cloudflare and how it makes sense to run certain applications there but Wasmer doesn't have this kind of infrastructure, does it? Is there any difference to a very small CDN (or APN - application delivery network)?
Now when I read about the architecture and the locations it just seems like ordinary cloud hosting, albeit serverless, to me. I can't make much sense of phrases like "The core design of what makes up the Wasmer Edge code base is a distributed monolith" either.
> I don't get what "the edge" is here. I understand what the edge is with Cloudflare and how it makes sense to run certain applications there but Wasmer doesn't have this kind of infrastructure, does it?
It does, and the product page (https://wasmer.io/products/edge) makes it a lot clearer than the linked announcement that Wasmer Edge is basically "Cloudflare Workers for Wasm".
The chart at the bottom of the page¹ shows what Wasmer thinks Wasmer Edge completes with — Cloudflare Workers, Amazon Lambda, Fly.io, and "Cloud" (whatever that is). The most significant differentiator seems to be that Wasmer Edge runs on browsers and phones in addition to servers in the cloud, which makes it "edgier" than the alternatives.
¹ Note that it calls the service "Wasmer Deploy" instead of "Wasner Edge", which I assume is a mistake.
> You're a master at communicating technical concepts to developers by being concise, removing fluff, and speaking plainly without any marketing speak. Please explain what the following means...
Sure. Here is my explanation of the quote you provided:
1. Distributed monolith: A distributed monolith is a software architecture that combines the benefits of both monolithic and microservices architectures. Like a monolith, all of the code for a distributed monolith is contained in a single binary. However, like a microservices architecture, the code is divided into independent libraries that can be deployed and scaled independently.
2. Separation of concerns: Separation of concerns is a software design principle that breaks down a software system into smaller parts, each of which is responsible for a single, well-defined task. This makes the system easier to understand, maintain, and evolve.
3. Rust libraries: Rust is a programming language that is designed for speed, safety, and reliability. Rust libraries are compiled into machine code at compile time, which makes them faster and more efficient than interpreted languages like Python or JavaScript.
4. Scalability: Scalability is the ability of a software system to handle increased demand without sacrificing performance. Distributed monoliths can be scaled out by adding more nodes to the system. This makes them a good choice for applications that need to be able to handle a large number of users or requests.
a distributed monolith is an antipattern that's common to badly executed microservices -- it's essentially an epithet, in no sense a design goal
what's being described here is an _elegant_ monolith, which is entirely different, and definitely does not provide the property that independent libraries can be deployed and scaled independently
"Edge" refers to the fact the workload runs close to the customer either a few network hops away or on their browser.
In traditional Cloud Computing the customer must "select" where it runs (i.e. pick a data centre or region) - for instance, when you go in the Azure portal for many services like AKS you must select where it is hosted. In Edge computing you don't need to do this as it automatically serves the request at the closest "pop" (point of presence), this is also how Wasmer Edge works.
Wasmer Edge are in an alpha release phase thus the edge network is kept purposely limited in this early pilot to take a careful approach to its expansion.
Wasmer also have plans to build a hybrid environment between the browser itself and the edge network which will unlock some really exciting use cases thanks to WASIX.
Ignore the troll reply... he is paid (or just sells himself for free) by the competition to discredit... just downvote him.
> "Edge" refers to the fact the workload runs close to the customer either a few network hops away or on their browser.
But Wasmer Edge does not run close to most customers and does not run on their browser.
> Wasmer Edge are in an alpha release phase thus the edge network is kept purposely limited in this early pilot to take a careful approach to its expansion.
I think Edge is something where a limited pilot makes no sense. It would be like selling a database that is only available in the morning. If having very low latency is a key concern of mine then a service close to half my users is much less than half as useful as a service close to most of my users.
> Wasmer also have plans to build a hybrid environment between the browser itself and the edge network which will unlock some really exciting use cases thanks to WASIX.
If this isn't running in the browser than it has to be running in a server. By between the browser and the edge network I'm guessing you mean you'll purchase a large number of servers even closer to users than existing edge networks. That's hard, and your product so far doesn't suggest expertise in that area. I don't see how wasm will significantly help you get more servers closer to users than existing companies in this space.
> Ignore the troll reply... he is paid (or just sells himself for free) by the competition to discredit...
Based on your parenthesis I'm assuming that you don't actually know anything, you just assumed that because he's critical he's a troll?
> But Wasmer Edge does not run close to most customers and does not run on their browser.
It does run in the browser, that is what https://wasmer.sh uses to launch things published via the `wasmer publish` command. There are more plans to integrate these closer together into a hybrid system in the future with converged networking and transparent offloading work to servers, needs more work but its for sure possible with this foundation.
> I think Edge is something where a limited pilot makes no sense.
One does not just hit a button and servers appear everywhere in the world at once for free, all CDN's do the same thing, they run in racks of servwrs and expand their POP's based off real data and not just guess work. For instance, apparently Japan has a massive interest in WASIX, so perhaps the next POP should go there. Its also worth mentioning that if Wasmer Edge had been built on top of someone elses Edge (as others have done) then they would never be able to offer the cheap pricing.
> I think Edge is something where a limited pilot makes no sense.
It is a good point you make here about perception versus alpha relaity but with the architecture of the design and the huge amount of interest coming from the community the locations will expand quickly so it will be a growing pain of history fairly quickly.
> I don't see how wasm will significantly help you get more servers closer to users than existing companies in this space
No other company I am aware of are trying to build a distributed computer that lets developers write a program that runs in a hybrid setup of running in the literal browser of the user and connected to high performance compute in data centres. Honestly this is the bit that really excites me, imagine a program that runs in the browser but has real threads that also run in a data center. Exciting times.
Congrats on the launch. Other wasm PaaS services are focused on HTTP endpoints where the wasm modules are run ephemerally, which is cool, but this gets me excited because it's more general. As I understand it, this could replace many of the things people containerize as network services (in a sibling comment you mention using it to serve DNS!)
If you use tokio in this, is it effectively a single-threaded tokio runtime, or do you have a way to take advantage of multiple cores?
Also curious about how Node.js support would work?
I've heard about efforts to compile SpiderMonkey to WASM to run JS, but never V8 and the entirety of Node.js. That would be super exciting if that's what you're looking to accomplish. Would love to follow along and contribute if this is part of an open source effort!
Curious if you think cold starts could be a problem with this approach? Share-nothing architecture sounds great until you realize you have to load the entirety of V8 and Node.js on every request, but maybe you've figured out some way to work around that?
Also, how do you think the lack of JIT could affect real-world JS runtime performance? Or is there a solution for that too?
TLDR: support for WASIX [1] enabled builds that can start a web server (Rust with axum works well, Python and PHP are coming soon), and WCGI, with which you can use all languages that currently have WASI support , by using the standard CGI interface.
We'll also add support for standard WASI with pre-opened sockets, which will add support for a bunch of additional ecosystems (like dotnet / C#), but haven't gotten around to that yet.
If you are asking more about how code is managed and executed: stateless, spawned on demand is the default. Proxy mode will re-use instances for multiple requests. Stateful/persistent instances with persistent volumes are on the horizon.
I'd also really love to hear an answer to this question. The difference isn't really clear from the comparison on this page: https://wasmer.io/products/edge
I like this way of making software, but calling 'Edge' and saying decentralized is confusing. This is a service that hosts my software on their computers. How is this different than AWS or CloudFlare or any of the other cloud providers? I understand their VM tech is different, but what does makes it 'Edge' or 'decentralized'?
Just today I was hacking together something to enable spawning gRPC endpoints on remote host that would run as WASI modules. Didn't get far with wasmer-go bindings so I went with Wazero for now, but I hope to see the former getting some love.
Did you come across any good documentation around this? Last time I checked it all still felt very early, with Go itself not supporting WASI as compile target yet (this will change soon) and TinyGo not fully suporting `net/http`, and not many examples of how to pass structs between a Go wasm host and Go wasm module, with even strings requiring unsafe pointers IIRC.
You can compile for GOOS="wasip1" with Go 1.21, check out the builtin "gotip" command to use the master branch. Unfortunately exporting functions back to Go seems to be a work in progress, since "//go:wasmexport" directive is not yet implemented. Maybe for 1.22?
In addition to that, I added some constants to "..sdk\gotip\src\syscall\syscall_wasip1.go" by hand that were throwing errors about being undefined, just by copying the values from the default unix syscall package. They were about OS files and I figured I shouldn't need them for the WASI module.
But the documentation is lacking and sometimes out of date as you perhaps found out. I'm currently stuck at having the gRPC server object in Go, and the service implementation on the WASM side, and in need of a way to register that service on the server. This means for server.RegisterService(pb ServiceDesc, &server{}) I would need to smuggle out pb and a pointer to the implementation, or for server.RegisterService(pb ServiceDesc, &server{}) smuggle in a grpc.Server pointer...
