22 ms·

WebAssembly: The New Kubernetes?

328 points by signa11 5y ago

ReleaseCandidat 5y ago
This sounds like the generic comparison websites that compare just about anything. Kubernetes is for _managing_ containers. Btw. Betteridge's law of headlines holds.
tayo42 5y ago
Shipping self contained modules, this whole things sounds like reinventing what the jvm is.
politelemon 5y ago
I predict an amusing PoC in a few years, implementing k8s in w9y. It will spark discussions about microfrontends.
_robbywashere 5y ago
I agree! Let’s come to terms with the ubiquity lesson of JavaScript and make a proper vm, that for now interplay’s with ubiquitous-JavaScript. But also will not leave out the evolution of other languages or software concerns at the language level. Let’s go down a layer and have a ubiquitous vm. I think the possibilities for this are huge. Before you say “ok but the jvm”, “history repeats” - I don’t think that argument is fair. the jvm was built at a very different time and has its own niche and it’s own bloat. Again, we’re transitioning from JavaScript first. Great things will follow.
raesene9 5y ago
My guess here is that WebAssembly will become more popular for new developments, but I don't see it supplanting containers/Kubernetes across the board. One of the reasons that containers have been successful is that, in many cases, you can lift and shift an existing application into a containerized environment with no or minimal changes. I don't think that's the case with web assembly at the moment. I kind of liken it to Serverless, which is great where it fits your application architecture, but hasn't really become ubiquitous the way some predicted it would.
- darkwater 5y ago
  > I kind of liken it to Serverless, which is great where it fits your application architecture, but hasn't really become ubiquitous the way some predicted it would. This. I would really like to hear the opinion today of all those 2016-2017 gurus that were telling us "serverless is the only future".
  - bluepizza 5y ago
    Serverless could have been the future. But it’s too expensive and not worth it.
    - cyberpunk 5y ago
      Our backend is 100% lambdas and it's significantly cheaper than running our services on eks. Can you elaborate on where the cost is? Definitely not cloud spend.. Engineering time? Serverless Stack takes almost all the pain away (vs serverless framework)
      - tehbeard 5y ago
        I can make a function that returns the current time in cowsay ascii art, and claim a "100% lambda serverless webscale backend". A bit more detail on the scale / general usecase or features would be handy to know.
        cyberpunk 5y ago
        30 services (so far), maybe 400 lambdas, very little traffic, all gql apis. Pg backends, db per service that requires it, maybe 20 aws accounts (per squad). 50 devs (mix of perm and contract maybe 80/20), established multi million revenue business, not funded externally.
      - bsder 5y ago
        > Our backend is 100% lambdas and it's significantly cheaper than running our services on eks. Could you elaborate? We've got both, but we're not seeing a lot of differential in price. It could simply be we don't have enough traffic that would drive this correctly.
johnnypangs 5y ago
Does anyone have any examples of a sort of self hosted way to do functions as a service with web assembly? I know you can do web assembly FaaS with Cloudflare Workers (https://github.com/cloudflare/workers-rs https://github.com/cloudflare/workers-rs among others) but am unaware of a way to self host.
- thelastbender12 5y ago
  That would indeed be super useful to extend self hosted automation tools like Huginn. From what I understand, wasm/wasi modules don't have full networking or filesystem access support yet. So you probably have to rely on specific runtimes to provide hooks for doing that, and regular code won't work out of the box. 1. https://github.com/suborbital/reactr https://github.com/suborbital/reactr 2. https://wasmedge.org/ https://wasmedge.org/
- callahad 5y ago
  It's still early days, but as far as I understand it, one of Suborbital's explicit goals is to commoditize wasm-backed FaaS platforms: https://suborbital.dev https://suborbital.dev
- immibis 5y ago
  This is amusing to me because CGI is basically self-hosted functions-as-a-service.
  - jabl 5y ago
    So now (or in the near future) you can run WASM functions on a WASM FaaS platform running in a container running on K8S running in a VM on a cloud platform, and achieve what you could do in 1993 with Apache CGI and Perl 4.x! Progress!
rryan 5y ago
nit: Kubernetes is the container orchestration, not the container technology itself. So the comparison is apples vs. oranges. You could replace the containers that are being scheduled by Kubernetes with WebAssembly. Others already linked to Krustlet which is effectively this.
- stavros 5y ago
  Yeah, exactly. This comparison is a stretch, it compares different things and tries to shoehorn them together. I'm surprised that your comment is this low in the thread.
dsign 5y ago
I want a simple life where I program and run programs. I don't want to fight layer after layer of abstraction, some of which will inevitably impair my programs (i.e. by not allowing me to use SIMD or access the graphics coprocessor) and multiply tenfold my expenditure in cloud services. If you think I'm exaggerating, try to configure a GPU passwover to a virtual machine. It is doable, in your server in your garage, after you spend a considerable amount of hours of your life. In your cloud deployment? Only if you use Google or AWS, and even then, only for a price. Please, call the Spanish Inquisition, this guy needs to be prosecuted before he gathers a coven and gets away with this perversion.
- gypsyharlot 5y ago
- cmeacham98 5y ago
  I'm not aware of any surcharge for using a GPU in a VM on AWS or GCP, could you link documentation of this? Of course AWS and GCP charge extra for units with GPUs in them, but I can't seriously expect you think they should stick a GPU in every VM instance for free?
- honkycat 5y ago
  > I want a simple life where I program and run programs... I feel like this is an oversimplification. The company I work for has tens of thousands of concurrent users, plus dozens (hundreds?) of business partners all of whom are integrating with our platform. We are not serving static HTML pages like StackOverflow, we have dynamic content and our customers want up-to-date analytics. So.. how am I supposed to "program and run programs" in this environment? You act like we invent complexity for no reason, but we are dealing with scale and "I want a simple life where I program and run programs" is like saying: "I want an easier job." Cool. They are out there. They probably don't pay as well. Meanwhile I'm going to try and fix the mess someone made 8 years ago in the monolith so the business paying my bills can keep making money. it ain't pretty, but its a living.
  - dmitriid 5y ago
jokoon 5y ago
It's difficult to compare kubernetes and WASM. Also WASM doesn't look very mature to me, and chrome and apple can decide to stop supporting it if they want. I'm also curious how well WASM works on mobile. I wish WASM could replace mobile apps somehow.
- anonporridge 5y ago
  Apple and Google have too much power via the app stores to ever allow pure web apps to become significantly viable competitors to native apps.
  - mhoad 5y ago
    I just want to make clear here that in reality that it is Apple and Apple alone which is holding back web apps from competing with their ecosystem.
    - randomsilence 5y ago
      Maybe the best pivot ever (since the iPhone was made for web apps [1]). Can Apple ever switch back? Since their valuation depends on their income from the app store, they are forced to continue their policy. However, is this a valid long-term strategy? Right now, most apps are by requirement single-purpose tools. Is Apple prepared for the time when there are user-generated apps? Much of what web3.0 can be is inhibited if Apple puts a tax on every transaction and prevents apps that change their source code. Since the US mobile phone market is dominated by Apple, does this give China a huge advantage for developing the next generation of software? [1] https://9to5mac.com/2011/10/21/jobs-original-vision-for-the-iphone-no-third-party-native-apps/ https://9to5mac.com/2011/10/21/jobs-original-vision-for-the-...
  - jokoon 5y ago
    And how would they do that?
- alex_duf 5y ago
  I think this article is very much about wasm running on the server rather than in a web browser. In fairness there's been some very exciting development on that front, mainly pushed by Fastly with their own compute @ edge proposal and opensourcing a set of tools like cranelift. I think their use case of cloud fonction @ edge is absolutely perfect for webassembly on the server, and I'm actually impressed. I agree the technology needs to mature a bit more. We need broader langage support, and then we'll have a very powerful and exciting tool to add to our tool-belt.
lewisjoe 5y ago
Here's a tweet from Solomon Hykes noting, if WASM existed back in 2008, he wouldn't have created Docker! https://twitter.com/solomonstre/status/1111004913222324225?s=21 https://twitter.com/solomonstre/status/1111004913222324225?s... My biggest concern with K8s is how the entire ecosystem is a costly affair. Can I run a service with multiple nodes for 10-50$ per month? This is why I'd love WASM to win. Right now your browser can run 100s of tabs, with inter-tab communications and all the security sophistications on a single machine. For me, this symbolises a future where WASM can bring cheaper computing to the cloud as well. I don't want to pay a fortune as AWS/Azure bills just because k8s is a costly ecosystem.
- harpratap 5y ago
  > My biggest concern with K8s is how the entire ecosystem is a costly affair. Can I run a service with multiple nodes for 10-50$ per month? If your service can run on few nodes, do you really need a scheduler like K8s? Why not go serverless like Fargate or CloudRun?
- option_greek 5y ago
  More and more it appears that k8s is designed to extract maximum value from the tenants of the cloud companies. You need to connect your cluster to public Internet? No problem that's $x for each load balancer (whether its needed or not). Ohh you are feeling the whole thing feels like a blackbox and difficult to debug or observe? No problem that is $x for data dog. Gcp is the worst when it comes to setting up k8s with preemptive nodes. Thought you could get away with preemptive nodes? Not so fast, we restart all the nodes together at end of 24 hours period so that your multi node cluster will have zero availability for 5 minutes everyday. Or jump through hoops to killing your own nodes periodically to keep them all restarting at the same time.
  - robertlagrant 5y ago
    Those aren't features of Kubernetes. If you like you can install a free ingress such as NginX and route traffic to it. If you like you can just have logs on your physical nodes and go look one by one, just as you would have to before things like k8s came along. Datadog is a value add. It's not essential. GCP preemptible VMs are nothing to do with k8s - they are literally designed to be short-term (up to 24 hours) VMs to do things with. Yes, GKE can use them, but not as persistent resources. That's not what they're for. Here's what they're for: > Preemptible VMs are Compute Engine VM instances that last a maximum of 24 hours, and provide no availability guarantees. I.e. don't try and "get away with" them. There are plenty of options for cheap K8s.
the_duke 5y ago
This is topical for me because I'm working on a distributed Webassembly runtime that aims to combine the best parts of Kubernetes and Erlang. The big benefits: * Much easier deployment. All you need is a small .wasm file, usually hosted in a registry similar to Docker. No need for messing with cumbersome Docker files. No need for tooling that audits Docker images for vulnerabilities. No huge image downloads for each service. * Language interop. Progress is slow, but interface types [1] will soon provide a standardized way for type-safe abstract interfaces between Webassembly instances. This makes cross-language interop seamless and very efficient. * Much smaller applications. You can move expensive dependencies like http servers/clients, database clients, etc into the runtime and let the environment provide those. This leads to way fewer dependencies, so you don't need to constantly update your apps and aren't harassed by Dependabot PRs. More importantly: smaller attack surface and less opportunity for compromises. * Security. Webassembly is sandboxed and has a much smaller attack surface than a whole operating system syscall sandboxing layer (aka Docker et al). Wasm also naturally lends itself to capability based security with handles that are passed around, so you can even scope permissions inside your application code. (hint: reference types) * Easier local development. It's much easier and quicker to download and start 100 small .wasm based services than it is with (often large) Docker images / Kubernetes setups. * Quasi-instant startup (after the wasm is compiled, or with an interpreter) * Less resource usage. It's relatively easy to freeze and persist Wasm instances to disk when they aren't used. Or do things like seamlessly migrate them between nodes. Or snapshot and resume them locally for debugging. * In-browser usage: you can even just run the same code in your browser anytime you want. ( the runtime I'm working on can provide a mostly complete dev environment just in the browser, which works mostly identically to server deployments, excluding obvious deficiencies like no direct network or storage access) --- Of course things aren't just rosy. Some downsides/risk factors: * There are quite a few proposals that are crawling through the standardization process. (GC, more control over the stack, tail calls, interface types, WASI, multi threading, module linking, ...). Several of those would be really important especially for interpreted languages. * Language support. Rust, C and C++ work. This is not so much the case for other languages. As mentioned above, the spec leaves a lot wanting for running interpreters, and few of the popular languages can be AOT compiled. There is a Spidermonkey WASM build that makes running JS feasible, but it's of course much slower than a regular JIT enabled v8. * Tooling and ubiquity. WASM is basically the next iteration of serverless. And there are many areas where serverless is frowned upon. I feel like this is mostly a tooling problem though that can be solved by a good ecosystem and a powerful runtime. --- All in all I do believe WASM has the potential to be a very prominent (and hopefully the preferred) way to deploy a lot of applications, eventually. [1] https://github.com/WebAssembly/interface-types/blob/main/proposals/interface-types/Explainer.md https://github.com/WebAssembly/interface-types/blob/main/pro...
pjmlp 5y ago
No, the old Java Application Servers rebranded for Java haters.
- jabl 5y ago
  So instead of Enterprise Java Beans (EJB) we'll get Enterprise Webasm Workers (EWW)? Might have to work on that acronym, though.
  - pjmlp 5y ago
    We already have them, that is the thing. https://deislabs.io/posts/introducing-hippo/ https://deislabs.io/posts/introducing-hippo/ https://docs.microsoft.com/en-us/azure/aks/use-wasi-node-pools https://docs.microsoft.com/en-us/azure/aks/use-wasi-node-poo... https://suborbital.dev/ https://suborbital.dev/ https://blog.cloudflare.com/webassembly-on-cloudflare-workers/ https://blog.cloudflare.com/webassembly-on-cloudflare-worker... Just a sample, plenty of others chasing WASM gold.
- asteroidbelt 5y ago
  Java application server could run only Java, had really no control over the application (eg kill it if it uses too much memory or throttle it’s cpu), and provided hard to use APIs. The idea was great, but it was premature and not well thought.
  - pjmlp 5y ago
    Nope, it could run any language that targeted JVM bytecode and HP-UX Vault already provided container like support for Java Application Servers.
    - asteroidbelt 5y ago
      > any language that targeted JVM bytecode Any language similar to Java. Small subset of languages.
      - 5y ago
samwillis 5y ago
WASM being the “new k8s” is only one small fragment of where it is going to go. I think there is a good chance it’s going to become the defacto deployment target for a lot of software, so in addition to browser and server: - Plugins for desktop/mobile apps, wasm provides a nicely sandboxed environment for them. - Gaming, the combination of WASM and WebGPU will be the perfect platform for cross platform game development. I could see Steam, for example, creating their own runtime. - Embedded electronics, simplifying the development and deployment of IoT devices. When it comes to wasm on the server, it’s often talked about as targeting the “edge”. I believe this the next area of massive growth, however the part that I don’t think is fully solved yet is on the database side. If your server app is making multiple database calls from the edge to a central db there is a good chance that it will slower than a traditional (single location) deployment. What’s needed is a edge first database, we need at least read replicas to be at the edge with your app. Fly.io have something like this with their Postgres’s product. The alternative is to use an eventually consistent db such as CouchBD, but that causes other problems. I’m interested to see if CloudFlare do anything in this area as it’s the part of their stack that’s missing.
- kaba0 5y ago
  Do we have a bright lookout at WebGPU? Based on historic trends, similar projects seldom come to fruition, and not even cross-platform graphics frameworks managed to stick (vulkan, metal, directx, opengl, basically none of them run on all 3 major platforms, let alone if we add mobile platforms as well to the list)
  - bobthebuilders 5y ago
    As much as I hate it, I think economics will make WebGPU a thing the same way it did electron.
  - codeflo 5y ago
    I don’t think it’s a matter of trends, we have to look at the particulars of each API. OpenGL/WebGL aren’t well enough aligned with modern hardware to serve as a cross-platform graphics layer. That’s where the newer APIs come in. Vulkan, Metal and DirectX 12 all follow similar principles that would work from a technical standpoint, but we live in an age where platform vendors would rather cripple their platform than make it easy to port software. Apple is the worst offender here, because while Microsoft isn’t happy about it and disables it in “metro” apps, at least they don’t prevent GPU vendors from shipping Vulkan support for normal “desktop” apps. But I’m optimistic about WebGPU: It’s designed to be efficiently implemented on top of the vendor APIs, so platform vendors can’t block it. And it’s low-level enough that it should allow implementing modern games on top of it. (To clarify: I’m optimistic about WebGPU as an API for desktop applications. For browser apps, it seems like all vendors are on board already.)
wolframhempel 5y ago
I'm not sure we're thinking about this the right way. What we want (and have) is: A) a way to package any bit of functionality in a standardized way B) run it in any environment. Docker delivers both, although docker images are large (as they include their own OS) and (contrary to what the article claims) somewhat less efficient than running on bare metal. Executable files provide A, but are specific to an operating system. They are however much smaller and make better use of the hosts resources as they don't require virtualization. WASM delivers A for a subset of languages and B in so far as it runs in a browser and specific standalone runtimes. These are certainly some attractive qualities, but it leaves me wondering: does it make sense to introduce yet another standard into the mix or wouldn't it be better to write a "Kubernetes for executables" rather than having the additional abstraction layer of WASM?
- chriswarbo 5y ago
  Docker can't "run in any environment": it relies on Linux kernel features, which do not exist on other operating systems. There are workarounds for invoking Docker containers from some other operating systems (e.g. Docker Desktop for macOS and Windows), but those work by installing Linux into a virtual machine/hypervisor, and using that to run the containers. If that's what counts as cross-platform these days, then the term is meaningless (e.g. there are Gameboy emulators for some OSes, so Gameboy ROMs "run in any environment"). Considering that Docker containers themselves often bundle an entire Linux OS, that results in multiple layers of virtualised Linux operating systems. At which point, why not remove a layer and just ship a VM image?
  - vbezhenar 5y ago
    Docker supports Windows-native containers.
    - chriswarbo 5y ago
      So they've even managed to break their own weak definition of cross-platform/run-anywhere, by forking into two incompatible versions? The more I learn about Docker, the more I'm astounded by the sheer scale of anti-patterns being built into the bizzaro-world they're constructing.
FreeHugs 5y ago
So be it! Until XyZ is the new WebAssembly and @!# is the new XyZ! As long as my Django backend works and browsers support my HTML/CSS/JS frontend, I am fine. I have the same LAMP (Linux, Apache, MariaDB, Python) SAAS project running for decades now, paying all my bills, letting me live a free life. As long as nobody touches that, you can do all you want. Invent new fancy stacks every other year, make courses for it, migrations to it, a religion of it - I don't mind.
- aenario 5y ago
  I think your LAMP (Linux, Apache, MariaDB, Python) is a fancy new LAMP (Linux, Apache, MySQL, PHP).
- stavros 5y ago
  Having been wrangling with a monster Nuxt.js front-end that takes 30 minutes to compile for what is essentially a few pages of an eshop, I long for it to be reimplemented in Django. SPAs are good for some things, but those things are much fewer than what we use them for.
  - jack_riminton 5y ago
    I really hope this use of SPAs for CRUD apps like eshops is going to end soon, it's completely unhinged. There's a reason why Shopify went with Rails
    - chrisweekly 5y ago
      Agreed -- but going back to Rails isn't the answer. Remix.run is moving things forward in the right way, ie PHP/Rails -> SPA -> NextJS -> Remix.
      - jack_riminton 5y ago
        It sure does sound like the latest "next best thing"! I'll stick to Rails though thanks :)
      - 5y ago
deleted 5y ago
[deleted]
progval 5y ago
This would be the last step predicted by this 2014 (!) talk: https://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript https://www.destroyallsoftware.com/talks/the-birth-and-death... At the time it seemed unrealistic; asm.js was only just invented
- stavros 5y ago
  Yeah, that talk proved extremely prescient.
- paavohtl 5y ago
  It's an excellent talk, but IIRC the point was that hypothetical Metal language was still a subset of JavaScript. From the technology point of view WebAssembly has basically nothing to do with JavaScript, except that both are part of the web platform and commonly implemented by JavaScript engines. It's just a low-level VM which happens to be included in web browsers.
  - hajile 5y ago
    Wasm was definitely inspired by asm.js (though I think asm.js is still faster). The MVP for wasm was basically "do what asm.js does."
- ksec 5y ago
  The Nuke was COVID, so we need another 5 years or so to release our emotional energy from those C infrastructure. At least I hope the nuke was COVID.....
jeroenhd 5y ago
It's similar in that it adds even more overhead to just running your software to make your life just a tiny bit easier. You don't need to think about files and networking if you can't do any IO, after all! I don't see how webassembly would by any different from just running a JAR file or similar in terms of ease and usability. It's just a new method of writing bytecode that can do less. Bytecode interpreters already struggle to make efficient use of things like SIMD and this is just another layer on top of that. What's the point of using low level languages if you're going to compile them to semi bytecode. You can already set up virtual machines with predetermined state of any kind, see Firecracker for example, there's no need for a WASM overlay. WASM is a cool technology, don't get me wrong, but in my opinion this is a stupid way to use it.
lloydatkinson 5y ago
Overhyped, over engineered, and overly used?
- otabdeveloper4 5y ago
  Not "overly used" yet.
  - lloydatkinson 5y ago
    "not" yet then
tlarkworthy 5y ago
I am building a compute layer for Observablehq which enables services to brought up using nothing other than a web browser. It's a bit too soon to call it a K8s replacement but the motivation was the complexity and laggyness of bringing up services on cloud or k8s. The WEB + on demand infrastructure is the distributed replacement of K8S https://webcode.run/ https://webcode.run/ WEBCode is about eliminating environments and the difference between backend and front end to radically reduce the number of tools necessary and to enable new development workflows like live debugging production trafic with the vanilla Chrome debugger.
aavshr 5y ago
it makes sense to compare WASM to Docker or other container runtimes but not Kubernetes.
cogman10 5y ago
C++: the new jquery? What a nonsense title. K8s is about far more than simply running containers. WebAssembly only, at best, solves the problem of running a distributable. This article focuses on one of the smallest aspects of k8s.
jabl 5y ago
Seems this has some potential to simplify the server side stack. Hopefully it won't be just be yet another abstraction layer piled on top, increasing complexity? I can well imagine running WASM components managed by a WASM runtime, running in a container managed by K8S, running on a VM managed by a cloud provider orchestration system.
kitd 5y ago
I don't think he understands what K8s is. WASM is the new Docker, but you still need something to manage/orchestrate/schedule all those WASM instances. What if your WASM process goes down, who will restart it? What if you need 10 extra instances to handle a traffic burst? How do you isolate associated WASM instances from the rest of the environment, and manage their access to/from the outside world? How do you provide them with configuration or credentials? You still need something like K8s, even if you're not using docker underneath . Indeed you can already use other runtimes under K8s, so what he is proposing is nothing new anyway.
- Hokusai 5y ago
  > I don't think he understands what K8s is. WASM is the new Docker Or the new Java virtual machine, as they are literally the same thing. Kubernetes has nothing to do with it.
  - brabel 5y ago
    > Or the new Java virtual machine, as they are literally the same thing. Kubernetes has nothing to do with it. Before containers became a thing, everyone was happily deploying their Java applications on Java application containers (Tomcat, Weblogic, those things, remember?)... so I wouldn't say it has nothing to do with Kubernetes... just wait a bit and you might as well see the new generation of Weblogic written on WASM.
- x3ro 5y ago
  You mean like the author says, at the end of the article: > I compare WebAssembly to K8s, but really it's more like processes and private namespaces. So one answer to the question as initially posed is that no, WebAssembly is not the next Kubernetes; that next thing is waiting to be built, though I know of a few organizations that have started already. > One thing does seem clear to me though: WebAssembly will be at the bottom of the new thing, Edit: formatting
  - kitd 5y ago
    Yes, you're right. I missed that. A bit of a shame to leave it to the end though.
jerryluc 5y ago
A project that's kind of an implementation of this idea: https://github.com/lunatic-solutions/lunatic https://github.com/lunatic-solutions/lunatic. I find it interesting at least, but I haven't had the time yet to play around with it.
rob_c 5y ago
Trust me no, one is something that can be used in production by a small team of developers, the other is kubernetes and needs to be taken out back and shot. Mainly for the huge gulf of support that exists between a mock-VM and Amazon support. There's a tonne of people who just want something in the middle and to build their infrastructure and not be _forced_ to rely on the cloud nonsense.
PanosJee 5y ago
Checkout krustlet https://github.com/krustlet/krustlet https://github.com/krustlet/krustlet Kubernetes orchestrating wasm runtimes
folex 5y ago
Multiplexing between several WASM modules is exactly how services are organized on https://fluence.network https://fluence.network Each peer in a p2p network can host multiple services and expose their API to the network. Each service, then, is a collection of WASM modules that interact with each other in FFI manner.
TruthWillHurt 5y ago
WASM is like K8S in that 90% of projects don't need it.
joshuanapoli 5y ago
I don’t understand how WebAssembly compares with Kubernetes. It seems like WebAssembly is a nice replacement for JVM / CLR but it does not provide standards for service orchestration.
- folex 5y ago
  I'd say that article compares WebAssembly to Docker/moby/other container runtimes, not k8s.
  - joshuanapoli 5y ago
    Even so, the scope is different. I don’t use WebAssembly to define networks. Limiting privilege within the WebAssembly runtime is weaker than limiting it at the OS namespace.
    - folex 5y ago
      It depends on specific WASM runtime implementation, but usually you have to be explicit about allowing each syscall.
JasonFruit 5y ago
I have an irrational hatred for Kubernetes based solely on people writing "K8s". I understand that this is my problem and not theirs. I am, in a word, triggered.
- deleted 5y ago
  [deleted]
- GiorgioG 5y ago
  I have a general dislike for Kubernetes because most folks don't need its complexity.
shireboy 5y ago
It seems like a more accurate comparison would be container images and webassembly. Kubernetes is a orchestrator that tells containers where to run, how many, etc. For WebAssembly to replace Kubernetes, enterprises would need some other orchastration engine - or conceivably, Kubernetes could run webassembly packages in addition to container images.
- cogman10 5y ago
  There is a node image you can use to run web assembly. Assuming everything you do is web assembly then using that as a base image would cut down the amount of downloads that'd have to happen for new applications.
  - mr_toad 5y ago
    How do you orchestrate your Node runtimes? In containers?
    - cogman10 5y ago
      Yup, that's what I was suggesting. If all the containers have the same baseline node image then the only difference will be the app code.
- mr_toad 5y ago
  > Kubernetes could run webassembly packages in addition to container images. https://github.com/krustlet/krustlet https://github.com/krustlet/krustlet https://cloudblogs.microsoft.com/opensource/2020/04/07/announcing-krustlet-kubernetes-rust-kubelet-webassembly-wasm/ https://cloudblogs.microsoft.com/opensource/2020/04/07/annou... “Despite the excitement about Wasm and WASI, it should be clear that containers are the major workload in K8s, and for good reason. No one will be replacing the vast majority of their workloads with WebAssembly. Our usage so far makes this clear. Do not be confused by having more tools at your disposal.”
PaulHoule 5y ago
It’s like saying that beans are the new cars.
dusted 5y ago
"a software virtualization substrate"
kokizzu2 5y ago
yes, but way better even it's not apple to apple - only big companies need kubernetes (as kesley hightower said, only use it if you building a platform and solving million dollar problem) while desktop app that runs in browser (games, graphics design, etc) can benefit from wasm, also if you want your service to run users' code, it's better to use wasm so they can choose whatever language they want that able to target wasm
kortex 5y ago
Obviously the "Oranges: the new apples?" title is off-base; k8s is fundamentally a control loop engine, Wasm is a runtime. What I want to know is, is there anything out there like kubernetes but stripped down to just the control loop engine part? Like a glorified IFTTT but without all the overhead and baked-in assumptions of k8s. Some kind of daemon/library where I can write an arbitrary controller which reads a spec, queries some state, and has actions to push the system toward the desired state. The actual I/O is just writing an API and could basically just be a CRUD. What I'm looking for is the state management engine; that is tricky.
- williamscs 5y ago
  That's what Terraform pretty much is. All it does is manage a graph of dependencies/resources and then relies on a provider, which implements the CRUD. Not super familiar with Hashicorp's other product Nomad but I'd think it have a similar approach, but more of a continuous lifecycle check?
- DanielVZ 5y ago
  For the infra side of things you have hashicorp terraform, which will manage state of your infra and can also manage the state of your workloads. For the workload side of things you have hashicorp nomad. Which is basically a stripped down version of k8s.
  - hinkley 5y ago
    I don't know if it's Terraform or our implementation but I've not been particularly impressed by Terraform's error state recovery functionality. If something takes to long to pass a health check you often do not end up in State A or State B. There is a lot of surface area for undefined behavior.
- tapoxi 5y ago
  Mesos, but it seemed like Kubernetes ate it’s lunch since most use cases are handled with a single controller.
- cassianoleal 5y ago
rcarmo 5y ago
I can't help but have flashbacks about the JVM, managed code and all the discussions the Forerunners in traditional IT used to have. It's like we are doomed to reinvent certain kinds of technology (with circumstantial advantages due to historical context). Runtimes, process orchestration, databases, the works, everything old is "new" again.
- gorjusborg 5y ago
  It's exactly like that :) Hang around long enough and you eventually see all the old culprits re-branded and sold as the solution to the world's problems. At some point, one might get wise and look at the points of stability in the industry and try to understand why. Nobody is going to sell you on stable, though. There's less money to be had if you are satisfied already.
Bayart 5y ago
Interesting that this subject came up today. A few days ago I was looking back at Capsicum [1], a project meant to bring a capabilities framework to UNIX I knew about from years back. The impetus behind it being a short review of containerization primitives I was doing. Sadly it doesn't seem Capsicum went anywhere in Linux-land beyond kernel patches. But one of the subsequent project that pages on Capsicum often pointed to is the WebAssembly System Interface [2]. POSIX APIs, capabilities and portability sounds strangely apt for microservices, but at this point I'm still not too sure how to think about it. I'd appreciate it if anyone had good WASM/ASI resources for stupid devs like me. In any case I don't see why k8s or Terraform couldn't orchestrate WASI-defined containers. If anything it's a dig at containerd/docker/podman. [1]: https://www.cl.cam.ac.uk/research/security/capsicum/ https://www.cl.cam.ac.uk/research/security/capsicum/ [2]: https://wasi.dev https://wasi.dev
kordlessagain 5y ago
> K8s itself is an evolution on a previous architecture, OpenStack. OpenStack had each container be a full virtual machine, with a whole kernel and operating system and everything. Linux containers (LXC) are designed for running applications whereas Virtual Machines (VMs) are designed for running Operating Systems. So, they are nothing alike and any hint to "evolution" is just more complexity layered on by people who have nothing better to do than make things seem complicated. Not every application needs this type of complexity. Sometimes an idea or application can just run on a regular old VM until such time it doesn't and then I put it on AppEngine, where it's technically K8 and Docker, except I don't have to think about it. The amount of complexity K8 and Docker brings is not worth the time and effort require to learn those things well if doing one's own deployments. I'm thinking back to Docker literally uninstalling itself SEVERAL times on my laptop, leaving itself in a broken state. Sure, I can learn these technologies a little, but I am certain problems will crop up over time that whittle away at the usefulness of choosing to use them over just using older, more well known methods to get shit done.
- zekrioca 5y ago
  I think Linux containers (LXC) are not only for applications, so that's why they are often called "system containers". They are also useful when one wants to 'just' emulate a whole OS without actually emulating a whole machine (VM). For applications, I think Docker is the way to go.
- gainsurier 5y ago
  The trade-off of resources Isolation matters, eg. OS->Container->Namespace(wasm)
  - immibis 5y ago
    also layer 0: hardware isolation (e.g. Yubikey)
haolez 5y ago
Genuine question: outside of the web browser, what's the advantages of WebAssembly over the JVM or a similar VM?
- runlaszlorun 5y ago
  I’d say the ability to compile other code to it by using it as an LLVM backend. Also, designs like V8 isolates seem to be much lighter weight to spin up than the designs Amazon Lambdas use. Cloudflare has some blog posts on this. I’ve been fiddling with it currently, mostly at the level of its of text assembly format (WAT). The still in progress WASI spec gives OS access like file systems for server use. In short, if the JVM works for you in an enterprise type role, I’d see little reason to switch now to WebAssembly. But it’s future path as a possible mainstream compile target and functions-as-a-service type platform are interesting. Currently performance gains in the browser vs JS appear minimal- mostly I’m guessing because V8 et al are so damn good at runtime optimization. The fact that WebAssembly seems to have fallen off of the hype train means that it may have a shot at being the future of serverless. edit: I’d add that its origins in the browser leave it with a “download and stream code to compiler” that strengthen its serverless scenario visbility.
  - pjmlp 5y ago
    https://news.microsoft.com/2001/10/22/massive-industry-and-developer-support-for-microsoft-net-on-display-at-professional-developers-conference-2001/ https://news.microsoft.com/2001/10/22/massive-industry-and-d... > More than 20 programming tools vendors offer some 26 programming languages — including C++, Perl, Python, Java, COBOL, RPG and Haskell — on .NET. But hey, WebAssembly invented the language agnostic backend.
- gainsurier 5y ago
  Some WASM interpreter can run on MCU. https://github.com/bytecodealliance/wasm-micro-runtime https://github.com/bytecodealliance/wasm-micro-runtime
amq 5y ago
The new Docker, rather. We would still need something like Kubernetes to orchestrate.
msoad 5y ago
Nobody mentioned Deno. They're also building similar to WASI architecture but with a focus on JavaScript applications. The future is super isolated processes on a giant server instead of this container craziness we are having today!
- brettdeveffect 5y ago
  Isn't that all a "container" is anyway? There is the image ecosystem of docker (which I think is a pretty big success) for the content that will be in the initial bootstrap of the isolated process, but beyond that containers are just very isolated processes no?
  - immibis 5y ago
    Yes, a container is just a different kind of process. For that matter, so is a VM. All the supposed differences are just implementation details, like the difference between buses and trains.
hosh 5y ago
That's not a great comparison. The author probably should have compared Docker with Webassembly. Kubernetes isn't really about running many containers sharing a physical hardware. You can do that with Docker as well. What Kubernetes offers that Docker does not offer, is self-healing and resilience when managing many containers spread across many underlying nodes. There is no monolithic "Kubernetes" running. Rather, Kubernetes is designed as a set of microservices loosely coupled and maintaining desired states. The resiliency comes from that design. Because it is architected as microservices, Kubernetes is also extensible. Operators, for example, which manage a single distributed system (such as etcd, or postgres, or mongodb) can only be created because Kubernetes was architected as a set of loosely-coupled microservices. WebAssembly is the container runtime without the orchestration capabilities. However, Kubernetes is capable of being modified such that it can schedule, orchestrate, and manage WebAssembly containers: https://cloudblogs.microsoft.com/opensource/2020/04/07/announcing-krustlet-kubernetes-rust-kubelet-webassembly-wasm/ https://cloudblogs.microsoft.com/opensource/2020/04/07/annou...
dqpb 5y ago
The WASM/container comparison doesn't even make sense, let lone WASM/container-orchestrator.
torginus 5y ago
The part about the startup performance of WASM being good - yeah, nah. It's another bytecode language, much like LLVM IR, so it needs at least one compile pass, like Java/.NET does. I wouldn't be surprised if Python/JS beat it in this metric in interpreted mode. It's a far cry from mmap-ing a binary blob, and jumping to the entry point.
unemphysbro 5y ago
kubernetes is my personal afghanistan
lstroud 5y ago
Sounds a lot more like WebAssembly is the new JavaVM. WORA, security, portability, edge, etc.
thrower123 5y ago
The promise of WebAssembly is that we can stop writing shitty Javascript and write shitty web apps in slightly less shitty languages, without having to transpile it to shitty Javascript. Ideally this will lead to less overall shittiness. I don't really think we'll ever actually get there, but that's the hope. And even if we do, we're stuck with the DOM APIs until the heat death of the universe.
nmitchko 5y ago
Time to investigate WASM-security holes for a next generation security firm
eyberg 5y ago
I'll ask the same questions I had over on lobsters since I didn't get satisfactory answers there: * 64bit - Can I run a database that addresses more than 4 gig of memory (eg: keep all my indices in memory so perf doesn't fall off a cliff)? I think the answer is no. This effectively rules out most 'enterprise' software and most things involving 'big data' (eg: all ai/ml projects), not to mention I haven't deployed 32bit to prod in something like 10 years. * threads - shared array buffers && web workers aren't threads - this isn't the biggest deal in the world since all interpreted languages are effectively single process/single thread but there is quite a lot of software that would like real threads. * security - You can overwrite constants in what traditionally would be read-only. You can overwrite portions of the stack. You can overwrite the heap. You can overwrite function pointers. You can overwrite and redirect indirect calls. Taking an existing linux binary and converting it to wasm severely downgrades the security of it. * real sockets/TLS - https://github.com/WebAssembly/WASI/pull/312 https://github.com/WebAssembly/WASI/pull/312 && https://github.com/bytecodealliance/wasmtime/issues/71 https://github.com/bytecodealliance/wasmtime/issues/71 ? yes, I understand some people have shimmed in various layers here but most applications would currently require modification to use said shims - what's the best of breed to not require application mods?
rektide 5y ago
> But, in WebAssembly you get a few more things. One is fast start. This is one of the key things I think is differentiating versus the container world. The idea of per-request instantiation is possibly within reach. This is a possible return to a very old, very simple architectural pattern, of cgi-bin! Running a process per request. Which we left because creating processes was expensive. Our new architectures- discussed in this write up- revolve around long running applications, which are compelled upon us for performance reasons. But WebAssembly seems well suited to very fast instantiation of new contexts. It re-opens the possibility that we can have (return to) smaller more discrete chunks of work, safer little units of execution running. We could go back to a Apache HTTPD style prefork world, the very old[1]! This is part of the gradient we've been walking down, it feels like. VMs -> containers -> lighter weight containers. Returning to finer grained processes. For anyone interested in a deep dive into some of the super neat systems programming going into making WebAssembly starts/instantiation fast, there's a bunch of active work to reengineer module instantiation, using memfd [2][3]. Really fun to see this getting hashed out. > * So one answer to the question as initially posed is that no, WebAssembly is not the next Kubernetes; that next thing is waiting to be built, though I know of a few organizations that have started already.* And as others have recommended, worth noting Krustlet[4], which allows running WebAssembly instances via Kubernetes. This could definitely make sense for a lot of our workloads. I think a lot of people also expect though that the cloud infrastructure itself will get rewritten or recompiled into webassembly. Where-as today we tend to wire systems together over protocols, via http or grpc, we'll be able to more directly stitch together plugably modular systems, where a generic control process to govern, i dunno pick an example, load balancers say, has a bunch of specific webassembly modules plugged in with the specific actuators / configuration for your set up. There's a real potential to fulfill much of the idea of micro-kernels here, of decomposing big applications into looser assemblages of generic code, drivers, and configuration. [1] https://httpd.apache.org/docs/2.4/misc/perf-tuning.html#compiletime https://httpd.apache.org/docs/2.4/misc/perf-tuning.html#comp... [1] https://github.com/bytecodealliance/wasmtime/pull/3697 https://github.com/bytecodealliance/wasmtime/pull/3697 [2] https://github.com/bytecodealliance/wasmtime/pull/3691 https://github.com/bytecodealliance/wasmtime/pull/3691 [3] https://krustlet.dev/ https://krustlet.dev/
gerash 5y ago
Excuse my lack of expertise but I don't like web as a platform. Isn't it basically Javascript (an now WASM) + CSS on the client side and a browser as the VM? On all platforms web is a second class citizen and the feature set is the common denominator which means it's always lacking something. It doesn't have access to all the hardware, it runs in a VM (which I assume means it is slower) and the dev languages are meh. I prefer something along the lines of what Fuschia promises. That is, ephemeral software that gets downloaded lazily and runs natively as a first class citizen of the underlying OS
- ozten 5y ago
  WASM is a new portable runtime with very few capabilities exposed, so it has a much better security model than the web's JavaScript engine. You write your code in any language and compile it to WASM. You inject capabilities such as file system access, network access, etc. There is no UI layer, so CSS has nothing to do with WASM. Although WASM was invented and developed primarily in the browser, it is now being deployed standalone by companies like Fastly that let you customize their CDN with WASM running at the edge of the cloud via point of presence (POP) data centers.
  - immibis 5y ago
    The CPU already offers a non-portable runtime with very few capabilities exposed. Then we exposed the capabilities and didn't provide a way to unexpose them. That was the mistake.
    - ozten 5y ago
      Agreed that there are many ways to skin this cat. Operating Systems, Hypervisors, containers, Unikernels, etc. WASM is a very low level building block that you could build something like Docker out of, but it isn't a high level virtualization product.
- justshowpost 5y ago
  If WASI gets GPU support, WASM can also replace HTML + CSS and make the browser essentially a thin compatibility layer for nearly native apps.
pablok2 5y ago
Anything that runs 1's and 0's will do!
syrusakbary 5y ago
I'm very excited to see more people are jumping into this vision. I commented about this a few times here in Hacker News [1] [2]. I believe WebAssembly/Wasmer will become the new Docker (fun fact: the name Wasmer comes from Wasm + Docker) and there is a greater opportunity for it to become the base for the future Kubernetes for the Edge. Excited for what's to come! [1] https://news.ycombinator.com/item?id=27158187 https://news.ycombinator.com/item?id=27158187 [2] https://news.ycombinator.com/item?id=26271806 https://news.ycombinator.com/item?id=26271806
peterth3 5y ago
Web3 isn’t going to be about crypto or the metaverse. It will be all about WASM.
pablodavila 5y ago
If I recall correctly, Saša Jurić mentioned in an interview that he envisions the BEAM being used as an OS in the future, where you can run your database, web server and other services under one VM. While I don't personally have much use for it (at the moment), I'm curious about how this would look like with Lumen [0] where you can run your whole web stack with a single binary and being internally supervised by the BEAM. Lumen's development has been slow but I remember seeing a tweet from a team member stating that development is slowly ramping back up (not a criticism in any way, just providing some context). [0] https://github.com/lumen/lumen https://github.com/lumen/lumen
Shadonototra 5y ago
Today? no Too much javascript glue code to write Tomorrow? hell yeah! it is perfect, desktop no longer the lowest common denominator when building crossplatform solutions!
mikewarot 5y ago
> It's even better in some ways because WebAssembly provides "allowlist" security -- it has no capabilities to start with, requiring that the "host" that runs the WebAssembly explicitly delegate some of its own capabilities to the guest WebAssembly module. Compare to processes which by default start with every capability and then have to be restricted. In other words, WebAssembly is another step in the saga of systems that try to fill the hole left by the absence of capability based security in the Operating System. If it gets me a way to get back into the business of developing programs for a desktop, and avoiding worry about details of web servers, tls, caching, and endless browser specific bugs, I'm all for it, especially if I can write a program that uses a PowerBox to get a capability to a local file. At that point, I could just load the file from a disk, or via the web server/browser pipe, and it will work the same. Eventually, someone will figure out that a capability based OS for the desktop could launch a trillion dollar market for new applications without the need for a vendor specific web store or lock-in, and we'll be off to the races again, like in the 1980s shareware boom.
u_rml2555 5y ago
Many misconceptions in the article. It is a good example of an apples to oranges comparison. Kubernetes is first and foremost an orchestrator. Docker is an environment. You can run Redis, proxies and all kind of infrastructure in Docker containers. Or your own binaries. The article is making a valid point in distributing binaries. That's all. Nothing new here. If WASM will conquer the world - we'll see. Potential is there. But WASM for the browser was already overhyped. Hype seems necessary in our times but is clearly not enough.

328 points by signa11 5y ago

This sounds like the generic comparison websites that compare just about anything. Kubernetes is for _managing_ containers. Btw. Betteridge's law of headlines holds.

tayo42 5y ago

Shipping self contained modules, this whole things sounds like reinventing what the jvm is.

politelemon 5y ago

I predict an amusing PoC in a few years, implementing k8s in w9y. It will spark discussions about microfrontends.

_robbywashere 5y ago

I agree! Let’s come to terms with the ubiquity lesson of JavaScript and make a proper vm, that for now interplay’s with ubiquitous-JavaScript. But also will not leave out the evolution of other languages or software concerns at the language level. Let’s go down a layer and have a ubiquitous vm. I think the possibilities for this are huge. Before you say “ok but the jvm”, “history repeats” - I don’t think that argument is fair. the jvm was built at a very different time and has its own niche and it’s own bloat. Again, we’re transitioning from JavaScript first. Great things will follow.

raesene9 5y ago

My guess here is that WebAssembly will become more popular for new developments, but I don't see it supplanting containers/Kubernetes across the board. One of the reasons that containers have been successful is that, in many cases, you can lift and shift an existing application into a containerized environment with no or minimal changes. I don't think that's the case with web assembly at the moment. I kind of liken it to Serverless, which is great where it fits your application architecture, but hasn't really become ubiquitous the way some predicted it would.

darkwater 5y ago
> I kind of liken it to Serverless, which is great where it fits your application architecture, but hasn't really become ubiquitous the way some predicted it would. This. I would really like to hear the opinion today of all those 2016-2017 gurus that were telling us "serverless is the only future".
- bluepizza 5y ago
  Serverless could have been the future. But it’s too expensive and not worth it.
  - cyberpunk 5y ago
    Our backend is 100% lambdas and it's significantly cheaper than running our services on eks. Can you elaborate on where the cost is? Definitely not cloud spend.. Engineering time? Serverless Stack takes almost all the pain away (vs serverless framework)
    - tehbeard 5y ago
      I can make a function that returns the current time in cowsay ascii art, and claim a "100% lambda serverless webscale backend". A bit more detail on the scale / general usecase or features would be handy to know.
      - cyberpunk 5y ago
        30 services (so far), maybe 400 lambdas, very little traffic, all gql apis. Pg backends, db per service that requires it, maybe 20 aws accounts (per squad). 50 devs (mix of perm and contract maybe 80/20), established multi million revenue business, not funded externally.
    - bsder 5y ago
      > Our backend is 100% lambdas and it's significantly cheaper than running our services on eks. Could you elaborate? We've got both, but we're not seeing a lot of differential in price. It could simply be we don't have enough traffic that would drive this correctly.

johnnypangs 5y ago

Does anyone have any examples of a sort of self hosted way to do functions as a service with web assembly? I know you can do web assembly FaaS with Cloudflare Workers (https://github.com/cloudflare/workers-rs https://github.com/cloudflare/workers-rs among others) but am unaware of a way to self host.

thelastbender12 5y ago
That would indeed be super useful to extend self hosted automation tools like Huginn. From what I understand, wasm/wasi modules don't have full networking or filesystem access support yet. So you probably have to rely on specific runtimes to provide hooks for doing that, and regular code won't work out of the box. 1. https://github.com/suborbital/reactr https://github.com/suborbital/reactr 2. https://wasmedge.org/ https://wasmedge.org/
callahad 5y ago
It's still early days, but as far as I understand it, one of Suborbital's explicit goals is to commoditize wasm-backed FaaS platforms: https://suborbital.dev https://suborbital.dev
immibis 5y ago
This is amusing to me because CGI is basically self-hosted functions-as-a-service.
- jabl 5y ago
  So now (or in the near future) you can run WASM functions on a WASM FaaS platform running in a container running on K8S running in a VM on a cloud platform, and achieve what you could do in 1993 with Apache CGI and Perl 4.x! Progress!

rryan 5y ago

nit: Kubernetes is the container orchestration, not the container technology itself. So the comparison is apples vs. oranges. You could replace the containers that are being scheduled by Kubernetes with WebAssembly. Others already linked to Krustlet which is effectively this.

stavros 5y ago
Yeah, exactly. This comparison is a stretch, it compares different things and tries to shoehorn them together. I'm surprised that your comment is this low in the thread.

dsign 5y ago

I want a simple life where I program and run programs. I don't want to fight layer after layer of abstraction, some of which will inevitably impair my programs (i.e. by not allowing me to use SIMD or access the graphics coprocessor) and multiply tenfold my expenditure in cloud services. If you think I'm exaggerating, try to configure a GPU passwover to a virtual machine. It is doable, in your server in your garage, after you spend a considerable amount of hours of your life. In your cloud deployment? Only if you use Google or AWS, and even then, only for a price. Please, call the Spanish Inquisition, this guy needs to be prosecuted before he gathers a coven and gets away with this perversion.

gypsyharlot 5y ago
cmeacham98 5y ago
I'm not aware of any surcharge for using a GPU in a VM on AWS or GCP, could you link documentation of this? Of course AWS and GCP charge extra for units with GPUs in them, but I can't seriously expect you think they should stick a GPU in every VM instance for free?
honkycat 5y ago
> I want a simple life where I program and run programs... I feel like this is an oversimplification. The company I work for has tens of thousands of concurrent users, plus dozens (hundreds?) of business partners all of whom are integrating with our platform. We are not serving static HTML pages like StackOverflow, we have dynamic content and our customers want up-to-date analytics. So.. how am I supposed to "program and run programs" in this environment? You act like we invent complexity for no reason, but we are dealing with scale and "I want a simple life where I program and run programs" is like saying: "I want an easier job." Cool. They are out there. They probably don't pay as well. Meanwhile I'm going to try and fix the mess someone made 8 years ago in the monolith so the business paying my bills can keep making money. it ain't pretty, but its a living.
- dmitriid 5y ago

jokoon 5y ago

It's difficult to compare kubernetes and WASM. Also WASM doesn't look very mature to me, and chrome and apple can decide to stop supporting it if they want. I'm also curious how well WASM works on mobile. I wish WASM could replace mobile apps somehow.

anonporridge 5y ago
Apple and Google have too much power via the app stores to ever allow pure web apps to become significantly viable competitors to native apps.
- mhoad 5y ago
  I just want to make clear here that in reality that it is Apple and Apple alone which is holding back web apps from competing with their ecosystem.
  - randomsilence 5y ago
    Maybe the best pivot ever (since the iPhone was made for web apps [1]). Can Apple ever switch back? Since their valuation depends on their income from the app store, they are forced to continue their policy. However, is this a valid long-term strategy? Right now, most apps are by requirement single-purpose tools. Is Apple prepared for the time when there are user-generated apps? Much of what web3.0 can be is inhibited if Apple puts a tax on every transaction and prevents apps that change their source code. Since the US mobile phone market is dominated by Apple, does this give China a huge advantage for developing the next generation of software? [1] https://9to5mac.com/2011/10/21/jobs-original-vision-for-the-iphone-no-third-party-native-apps/ https://9to5mac.com/2011/10/21/jobs-original-vision-for-the-...
- jokoon 5y ago
  And how would they do that?
alex_duf 5y ago
I think this article is very much about wasm running on the server rather than in a web browser. In fairness there's been some very exciting development on that front, mainly pushed by Fastly with their own compute @ edge proposal and opensourcing a set of tools like cranelift. I think their use case of cloud fonction @ edge is absolutely perfect for webassembly on the server, and I'm actually impressed. I agree the technology needs to mature a bit more. We need broader langage support, and then we'll have a very powerful and exciting tool to add to our tool-belt.

lewisjoe 5y ago

Here's a tweet from Solomon Hykes noting, if WASM existed back in 2008, he wouldn't have created Docker! https://twitter.com/solomonstre/status/1111004913222324225?s=21 https://twitter.com/solomonstre/status/1111004913222324225?s... My biggest concern with K8s is how the entire ecosystem is a costly affair. Can I run a service with multiple nodes for 10-50$ per month? This is why I'd love WASM to win. Right now your browser can run 100s of tabs, with inter-tab communications and all the security sophistications on a single machine. For me, this symbolises a future where WASM can bring cheaper computing to the cloud as well. I don't want to pay a fortune as AWS/Azure bills just because k8s is a costly ecosystem.

harpratap 5y ago
> My biggest concern with K8s is how the entire ecosystem is a costly affair. Can I run a service with multiple nodes for 10-50$ per month? If your service can run on few nodes, do you really need a scheduler like K8s? Why not go serverless like Fargate or CloudRun?
option_greek 5y ago
More and more it appears that k8s is designed to extract maximum value from the tenants of the cloud companies. You need to connect your cluster to public Internet? No problem that's $x for each load balancer (whether its needed or not). Ohh you are feeling the whole thing feels like a blackbox and difficult to debug or observe? No problem that is $x for data dog. Gcp is the worst when it comes to setting up k8s with preemptive nodes. Thought you could get away with preemptive nodes? Not so fast, we restart all the nodes together at end of 24 hours period so that your multi node cluster will have zero availability for 5 minutes everyday. Or jump through hoops to killing your own nodes periodically to keep them all restarting at the same time.
- robertlagrant 5y ago
  Those aren't features of Kubernetes. If you like you can install a free ingress such as NginX and route traffic to it. If you like you can just have logs on your physical nodes and go look one by one, just as you would have to before things like k8s came along. Datadog is a value add. It's not essential. GCP preemptible VMs are nothing to do with k8s - they are literally designed to be short-term (up to 24 hours) VMs to do things with. Yes, GKE can use them, but not as persistent resources. That's not what they're for. Here's what they're for: > Preemptible VMs are Compute Engine VM instances that last a maximum of 24 hours, and provide no availability guarantees. I.e. don't try and "get away with" them. There are plenty of options for cheap K8s.

the_duke 5y ago

This is topical for me because I'm working on a distributed Webassembly runtime that aims to combine the best parts of Kubernetes and Erlang. The big benefits: * Much easier deployment. All you need is a small .wasm file, usually hosted in a registry similar to Docker. No need for messing with cumbersome Docker files. No need for tooling that audits Docker images for vulnerabilities. No huge image downloads for each service. * Language interop. Progress is slow, but interface types [1] will soon provide a standardized way for type-safe abstract interfaces between Webassembly instances. This makes cross-language interop seamless and very efficient. * Much smaller applications. You can move expensive dependencies like http servers/clients, database clients, etc into the runtime and let the environment provide those. This leads to way fewer dependencies, so you don't need to constantly update your apps and aren't harassed by Dependabot PRs. More importantly: smaller attack surface and less opportunity for compromises. * Security. Webassembly is sandboxed and has a much smaller attack surface than a whole operating system syscall sandboxing layer (aka Docker et al). Wasm also naturally lends itself to capability based security with handles that are passed around, so you can even scope permissions inside your application code. (hint: reference types) * Easier local development. It's much easier and quicker to download and start 100 small .wasm based services than it is with (often large) Docker images / Kubernetes setups. * Quasi-instant startup (after the wasm is compiled, or with an interpreter) * Less resource usage. It's relatively easy to freeze and persist Wasm instances to disk when they aren't used. Or do things like seamlessly migrate them between nodes. Or snapshot and resume them locally for debugging. * In-browser usage: you can even just run the same code in your browser anytime you want. ( the runtime I'm working on can provide a mostly complete dev environment just in the browser, which works mostly identically to server deployments, excluding obvious deficiencies like no direct network or storage access) --- Of course things aren't just rosy. Some downsides/risk factors: * There are quite a few proposals that are crawling through the standardization process. (GC, more control over the stack, tail calls, interface types, WASI, multi threading, module linking, ...). Several of those would be really important especially for interpreted languages. * Language support. Rust, C and C++ work. This is not so much the case for other languages. As mentioned above, the spec leaves a lot wanting for running interpreters, and few of the popular languages can be AOT compiled. There is a Spidermonkey WASM build that makes running JS feasible, but it's of course much slower than a regular JIT enabled v8. * Tooling and ubiquity. WASM is basically the next iteration of serverless. And there are many areas where serverless is frowned upon. I feel like this is mostly a tooling problem though that can be solved by a good ecosystem and a powerful runtime. --- All in all I do believe WASM has the potential to be a very prominent (and hopefully the preferred) way to deploy a lot of applications, eventually. [1] https://github.com/WebAssembly/interface-types/blob/main/proposals/interface-types/Explainer.md https://github.com/WebAssembly/interface-types/blob/main/pro...

pjmlp 5y ago

No, the old Java Application Servers rebranded for Java haters.

jabl 5y ago
So instead of Enterprise Java Beans (EJB) we'll get Enterprise Webasm Workers (EWW)? Might have to work on that acronym, though.
- pjmlp 5y ago
  We already have them, that is the thing. https://deislabs.io/posts/introducing-hippo/ https://deislabs.io/posts/introducing-hippo/ https://docs.microsoft.com/en-us/azure/aks/use-wasi-node-pools https://docs.microsoft.com/en-us/azure/aks/use-wasi-node-poo... https://suborbital.dev/ https://suborbital.dev/ https://blog.cloudflare.com/webassembly-on-cloudflare-workers/ https://blog.cloudflare.com/webassembly-on-cloudflare-worker... Just a sample, plenty of others chasing WASM gold.
asteroidbelt 5y ago
Java application server could run only Java, had really no control over the application (eg kill it if it uses too much memory or throttle it’s cpu), and provided hard to use APIs. The idea was great, but it was premature and not well thought.
- pjmlp 5y ago
  Nope, it could run any language that targeted JVM bytecode and HP-UX Vault already provided container like support for Java Application Servers.
  - asteroidbelt 5y ago
    > any language that targeted JVM bytecode Any language similar to Java. Small subset of languages.
    - 5y ago

samwillis 5y ago

WASM being the “new k8s” is only one small fragment of where it is going to go. I think there is a good chance it’s going to become the defacto deployment target for a lot of software, so in addition to browser and server: - Plugins for desktop/mobile apps, wasm provides a nicely sandboxed environment for them. - Gaming, the combination of WASM and WebGPU will be the perfect platform for cross platform game development. I could see Steam, for example, creating their own runtime. - Embedded electronics, simplifying the development and deployment of IoT devices. When it comes to wasm on the server, it’s often talked about as targeting the “edge”. I believe this the next area of massive growth, however the part that I don’t think is fully solved yet is on the database side. If your server app is making multiple database calls from the edge to a central db there is a good chance that it will slower than a traditional (single location) deployment. What’s needed is a edge first database, we need at least read replicas to be at the edge with your app. Fly.io have something like this with their Postgres’s product. The alternative is to use an eventually consistent db such as CouchBD, but that causes other problems. I’m interested to see if CloudFlare do anything in this area as it’s the part of their stack that’s missing.

kaba0 5y ago
Do we have a bright lookout at WebGPU? Based on historic trends, similar projects seldom come to fruition, and not even cross-platform graphics frameworks managed to stick (vulkan, metal, directx, opengl, basically none of them run on all 3 major platforms, let alone if we add mobile platforms as well to the list)
- bobthebuilders 5y ago
  As much as I hate it, I think economics will make WebGPU a thing the same way it did electron.
- codeflo 5y ago
  I don’t think it’s a matter of trends, we have to look at the particulars of each API. OpenGL/WebGL aren’t well enough aligned with modern hardware to serve as a cross-platform graphics layer. That’s where the newer APIs come in. Vulkan, Metal and DirectX 12 all follow similar principles that would work from a technical standpoint, but we live in an age where platform vendors would rather cripple their platform than make it easy to port software. Apple is the worst offender here, because while Microsoft isn’t happy about it and disables it in “metro” apps, at least they don’t prevent GPU vendors from shipping Vulkan support for normal “desktop” apps. But I’m optimistic about WebGPU: It’s designed to be efficiently implemented on top of the vendor APIs, so platform vendors can’t block it. And it’s low-level enough that it should allow implementing modern games on top of it. (To clarify: I’m optimistic about WebGPU as an API for desktop applications. For browser apps, it seems like all vendors are on board already.)

wolframhempel 5y ago

I'm not sure we're thinking about this the right way. What we want (and have) is: A) a way to package any bit of functionality in a standardized way B) run it in any environment. Docker delivers both, although docker images are large (as they include their own OS) and (contrary to what the article claims) somewhat less efficient than running on bare metal. Executable files provide A, but are specific to an operating system. They are however much smaller and make better use of the hosts resources as they don't require virtualization. WASM delivers A for a subset of languages and B in so far as it runs in a browser and specific standalone runtimes. These are certainly some attractive qualities, but it leaves me wondering: does it make sense to introduce yet another standard into the mix or wouldn't it be better to write a "Kubernetes for executables" rather than having the additional abstraction layer of WASM?

chriswarbo 5y ago
Docker can't "run in any environment": it relies on Linux kernel features, which do not exist on other operating systems. There are workarounds for invoking Docker containers from some other operating systems (e.g. Docker Desktop for macOS and Windows), but those work by installing Linux into a virtual machine/hypervisor, and using that to run the containers. If that's what counts as cross-platform these days, then the term is meaningless (e.g. there are Gameboy emulators for some OSes, so Gameboy ROMs "run in any environment"). Considering that Docker containers themselves often bundle an entire Linux OS, that results in multiple layers of virtualised Linux operating systems. At which point, why not remove a layer and just ship a VM image?
- vbezhenar 5y ago
  Docker supports Windows-native containers.
  - chriswarbo 5y ago
    So they've even managed to break their own weak definition of cross-platform/run-anywhere, by forking into two incompatible versions? The more I learn about Docker, the more I'm astounded by the sheer scale of anti-patterns being built into the bizzaro-world they're constructing.

FreeHugs 5y ago

So be it! Until XyZ is the new WebAssembly and @!# is the new XyZ! As long as my Django backend works and browsers support my HTML/CSS/JS frontend, I am fine. I have the same LAMP (Linux, Apache, MariaDB, Python) SAAS project running for decades now, paying all my bills, letting me live a free life. As long as nobody touches that, you can do all you want. Invent new fancy stacks every other year, make courses for it, migrations to it, a religion of it - I don't mind.

aenario 5y ago
I think your LAMP (Linux, Apache, MariaDB, Python) is a fancy new LAMP (Linux, Apache, MySQL, PHP).
stavros 5y ago
Having been wrangling with a monster Nuxt.js front-end that takes 30 minutes to compile for what is essentially a few pages of an eshop, I long for it to be reimplemented in Django. SPAs are good for some things, but those things are much fewer than what we use them for.
- jack_riminton 5y ago
  I really hope this use of SPAs for CRUD apps like eshops is going to end soon, it's completely unhinged. There's a reason why Shopify went with Rails
  - chrisweekly 5y ago
    Agreed -- but going back to Rails isn't the answer. Remix.run is moving things forward in the right way, ie PHP/Rails -> SPA -> NextJS -> Remix.
    - jack_riminton 5y ago
      It sure does sound like the latest "next best thing"! I'll stick to Rails though thanks :)
    - 5y ago

deleted 5y ago

[deleted]

progval 5y ago

This would be the last step predicted by this 2014 (!) talk: https://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript https://www.destroyallsoftware.com/talks/the-birth-and-death... At the time it seemed unrealistic; asm.js was only just invented

stavros 5y ago
Yeah, that talk proved extremely prescient.
paavohtl 5y ago
It's an excellent talk, but IIRC the point was that hypothetical Metal language was still a subset of JavaScript. From the technology point of view WebAssembly has basically nothing to do with JavaScript, except that both are part of the web platform and commonly implemented by JavaScript engines. It's just a low-level VM which happens to be included in web browsers.
- hajile 5y ago
  Wasm was definitely inspired by asm.js (though I think asm.js is still faster). The MVP for wasm was basically "do what asm.js does."
ksec 5y ago
The Nuke was COVID, so we need another 5 years or so to release our emotional energy from those C infrastructure. At least I hope the nuke was COVID.....

jeroenhd 5y ago

It's similar in that it adds even more overhead to just running your software to make your life just a tiny bit easier. You don't need to think about files and networking if you can't do any IO, after all! I don't see how webassembly would by any different from just running a JAR file or similar in terms of ease and usability. It's just a new method of writing bytecode that can do less. Bytecode interpreters already struggle to make efficient use of things like SIMD and this is just another layer on top of that. What's the point of using low level languages if you're going to compile them to semi bytecode. You can already set up virtual machines with predetermined state of any kind, see Firecracker for example, there's no need for a WASM overlay. WASM is a cool technology, don't get me wrong, but in my opinion this is a stupid way to use it.

lloydatkinson 5y ago

Overhyped, over engineered, and overly used?

otabdeveloper4 5y ago
Not "overly used" yet.
- lloydatkinson 5y ago
  "not" yet then

tlarkworthy 5y ago

I am building a compute layer for Observablehq which enables services to brought up using nothing other than a web browser. It's a bit too soon to call it a K8s replacement but the motivation was the complexity and laggyness of bringing up services on cloud or k8s. The WEB + on demand infrastructure is the distributed replacement of K8S https://webcode.run/ https://webcode.run/ WEBCode is about eliminating environments and the difference between backend and front end to radically reduce the number of tools necessary and to enable new development workflows like live debugging production trafic with the vanilla Chrome debugger.

aavshr 5y ago

it makes sense to compare WASM to Docker or other container runtimes but not Kubernetes.

cogman10 5y ago

C++: the new jquery? What a nonsense title. K8s is about far more than simply running containers. WebAssembly only, at best, solves the problem of running a distributable. This article focuses on one of the smallest aspects of k8s.

jabl 5y ago

Seems this has some potential to simplify the server side stack. Hopefully it won't be just be yet another abstraction layer piled on top, increasing complexity? I can well imagine running WASM components managed by a WASM runtime, running in a container managed by K8S, running on a VM managed by a cloud provider orchestration system.

kitd 5y ago

I don't think he understands what K8s is. WASM is the new Docker, but you still need something to manage/orchestrate/schedule all those WASM instances. What if your WASM process goes down, who will restart it? What if you need 10 extra instances to handle a traffic burst? How do you isolate associated WASM instances from the rest of the environment, and manage their access to/from the outside world? How do you provide them with configuration or credentials? You still need something like K8s, even if you're not using docker underneath . Indeed you can already use other runtimes under K8s, so what he is proposing is nothing new anyway.

Hokusai 5y ago
> I don't think he understands what K8s is. WASM is the new Docker Or the new Java virtual machine, as they are literally the same thing. Kubernetes has nothing to do with it.
- brabel 5y ago
  > Or the new Java virtual machine, as they are literally the same thing. Kubernetes has nothing to do with it. Before containers became a thing, everyone was happily deploying their Java applications on Java application containers (Tomcat, Weblogic, those things, remember?)... so I wouldn't say it has nothing to do with Kubernetes... just wait a bit and you might as well see the new generation of Weblogic written on WASM.
x3ro 5y ago
You mean like the author says, at the end of the article: > I compare WebAssembly to K8s, but really it's more like processes and private namespaces. So one answer to the question as initially posed is that no, WebAssembly is not the next Kubernetes; that next thing is waiting to be built, though I know of a few organizations that have started already. > One thing does seem clear to me though: WebAssembly will be at the bottom of the new thing, Edit: formatting
- kitd 5y ago
  Yes, you're right. I missed that. A bit of a shame to leave it to the end though.

jerryluc 5y ago

A project that's kind of an implementation of this idea: https://github.com/lunatic-solutions/lunatic https://github.com/lunatic-solutions/lunatic. I find it interesting at least, but I haven't had the time yet to play around with it.

rob_c 5y ago

Trust me no, one is something that can be used in production by a small team of developers, the other is kubernetes and needs to be taken out back and shot. Mainly for the huge gulf of support that exists between a mock-VM and Amazon support. There's a tonne of people who just want something in the middle and to build their infrastructure and not be _forced_ to rely on the cloud nonsense.

PanosJee 5y ago

Checkout krustlet https://github.com/krustlet/krustlet https://github.com/krustlet/krustlet Kubernetes orchestrating wasm runtimes

folex 5y ago

Multiplexing between several WASM modules is exactly how services are organized on https://fluence.network https://fluence.network Each peer in a p2p network can host multiple services and expose their API to the network. Each service, then, is a collection of WASM modules that interact with each other in FFI manner.

TruthWillHurt 5y ago

WASM is like K8S in that 90% of projects don't need it.

joshuanapoli 5y ago

I don’t understand how WebAssembly compares with Kubernetes. It seems like WebAssembly is a nice replacement for JVM / CLR but it does not provide standards for service orchestration.

folex 5y ago
I'd say that article compares WebAssembly to Docker/moby/other container runtimes, not k8s.
- joshuanapoli 5y ago
  Even so, the scope is different. I don’t use WebAssembly to define networks. Limiting privilege within the WebAssembly runtime is weaker than limiting it at the OS namespace.
  - folex 5y ago
    It depends on specific WASM runtime implementation, but usually you have to be explicit about allowing each syscall.

JasonFruit 5y ago

I have an irrational hatred for Kubernetes based solely on people writing "K8s". I understand that this is my problem and not theirs. I am, in a word, triggered.

deleted 5y ago
[deleted]
GiorgioG 5y ago
I have a general dislike for Kubernetes because most folks don't need its complexity.

shireboy 5y ago

It seems like a more accurate comparison would be container images and webassembly. Kubernetes is a orchestrator that tells containers where to run, how many, etc. For WebAssembly to replace Kubernetes, enterprises would need some other orchastration engine - or conceivably, Kubernetes could run webassembly packages in addition to container images.

cogman10 5y ago
There is a node image you can use to run web assembly. Assuming everything you do is web assembly then using that as a base image would cut down the amount of downloads that'd have to happen for new applications.
- mr_toad 5y ago
  How do you orchestrate your Node runtimes? In containers?
  - cogman10 5y ago
    Yup, that's what I was suggesting. If all the containers have the same baseline node image then the only difference will be the app code.
mr_toad 5y ago
> Kubernetes could run webassembly packages in addition to container images. https://github.com/krustlet/krustlet https://github.com/krustlet/krustlet https://cloudblogs.microsoft.com/opensource/2020/04/07/announcing-krustlet-kubernetes-rust-kubelet-webassembly-wasm/ https://cloudblogs.microsoft.com/opensource/2020/04/07/annou... “Despite the excitement about Wasm and WASI, it should be clear that containers are the major workload in K8s, and for good reason. No one will be replacing the vast majority of their workloads with WebAssembly. Our usage so far makes this clear. Do not be confused by having more tools at your disposal.”

PaulHoule 5y ago

It’s like saying that beans are the new cars.

dusted 5y ago

"a software virtualization substrate"

kokizzu2 5y ago

yes, but way better even it's not apple to apple - only big companies need kubernetes (as kesley hightower said, only use it if you building a platform and solving million dollar problem) while desktop app that runs in browser (games, graphics design, etc) can benefit from wasm, also if you want your service to run users' code, it's better to use wasm so they can choose whatever language they want that able to target wasm

kortex 5y ago

Obviously the "Oranges: the new apples?" title is off-base; k8s is fundamentally a control loop engine, Wasm is a runtime. What I want to know is, is there anything out there like kubernetes but stripped down to just the control loop engine part? Like a glorified IFTTT but without all the overhead and baked-in assumptions of k8s. Some kind of daemon/library where I can write an arbitrary controller which reads a spec, queries some state, and has actions to push the system toward the desired state. The actual I/O is just writing an API and could basically just be a CRUD. What I'm looking for is the state management engine; that is tricky.

williamscs 5y ago
That's what Terraform pretty much is. All it does is manage a graph of dependencies/resources and then relies on a provider, which implements the CRUD. Not super familiar with Hashicorp's other product Nomad but I'd think it have a similar approach, but more of a continuous lifecycle check?
DanielVZ 5y ago
For the infra side of things you have hashicorp terraform, which will manage state of your infra and can also manage the state of your workloads. For the workload side of things you have hashicorp nomad. Which is basically a stripped down version of k8s.
- hinkley 5y ago
  I don't know if it's Terraform or our implementation but I've not been particularly impressed by Terraform's error state recovery functionality. If something takes to long to pass a health check you often do not end up in State A or State B. There is a lot of surface area for undefined behavior.
tapoxi 5y ago
Mesos, but it seemed like Kubernetes ate it’s lunch since most use cases are handled with a single controller.
cassianoleal 5y ago

rcarmo 5y ago

I can't help but have flashbacks about the JVM, managed code and all the discussions the Forerunners in traditional IT used to have. It's like we are doomed to reinvent certain kinds of technology (with circumstantial advantages due to historical context). Runtimes, process orchestration, databases, the works, everything old is "new" again.

gorjusborg 5y ago
It's exactly like that :) Hang around long enough and you eventually see all the old culprits re-branded and sold as the solution to the world's problems. At some point, one might get wise and look at the points of stability in the industry and try to understand why. Nobody is going to sell you on stable, though. There's less money to be had if you are satisfied already.

Bayart 5y ago

Interesting that this subject came up today. A few days ago I was looking back at Capsicum [1], a project meant to bring a capabilities framework to UNIX I knew about from years back. The impetus behind it being a short review of containerization primitives I was doing. Sadly it doesn't seem Capsicum went anywhere in Linux-land beyond kernel patches. But one of the subsequent project that pages on Capsicum often pointed to is the WebAssembly System Interface [2]. POSIX APIs, capabilities and portability sounds strangely apt for microservices, but at this point I'm still not too sure how to think about it. I'd appreciate it if anyone had good WASM/ASI resources for stupid devs like me. In any case I don't see why k8s or Terraform couldn't orchestrate WASI-defined containers. If anything it's a dig at containerd/docker/podman. [1]: https://www.cl.cam.ac.uk/research/security/capsicum/ https://www.cl.cam.ac.uk/research/security/capsicum/ [2]: https://wasi.dev https://wasi.dev

kordlessagain 5y ago

> K8s itself is an evolution on a previous architecture, OpenStack. OpenStack had each container be a full virtual machine, with a whole kernel and operating system and everything. Linux containers (LXC) are designed for running applications whereas Virtual Machines (VMs) are designed for running Operating Systems. So, they are nothing alike and any hint to "evolution" is just more complexity layered on by people who have nothing better to do than make things seem complicated. Not every application needs this type of complexity. Sometimes an idea or application can just run on a regular old VM until such time it doesn't and then I put it on AppEngine, where it's technically K8 and Docker, except I don't have to think about it. The amount of complexity K8 and Docker brings is not worth the time and effort require to learn those things well if doing one's own deployments. I'm thinking back to Docker literally uninstalling itself SEVERAL times on my laptop, leaving itself in a broken state. Sure, I can learn these technologies a little, but I am certain problems will crop up over time that whittle away at the usefulness of choosing to use them over just using older, more well known methods to get shit done.

zekrioca 5y ago
I think Linux containers (LXC) are not only for applications, so that's why they are often called "system containers". They are also useful when one wants to 'just' emulate a whole OS without actually emulating a whole machine (VM). For applications, I think Docker is the way to go.
gainsurier 5y ago
The trade-off of resources Isolation matters, eg. OS->Container->Namespace(wasm)
- immibis 5y ago
  also layer 0: hardware isolation (e.g. Yubikey)

haolez 5y ago

Genuine question: outside of the web browser, what's the advantages of WebAssembly over the JVM or a similar VM?

runlaszlorun 5y ago
I’d say the ability to compile other code to it by using it as an LLVM backend. Also, designs like V8 isolates seem to be much lighter weight to spin up than the designs Amazon Lambdas use. Cloudflare has some blog posts on this. I’ve been fiddling with it currently, mostly at the level of its of text assembly format (WAT). The still in progress WASI spec gives OS access like file systems for server use. In short, if the JVM works for you in an enterprise type role, I’d see little reason to switch now to WebAssembly. But it’s future path as a possible mainstream compile target and functions-as-a-service type platform are interesting. Currently performance gains in the browser vs JS appear minimal- mostly I’m guessing because V8 et al are so damn good at runtime optimization. The fact that WebAssembly seems to have fallen off of the hype train means that it may have a shot at being the future of serverless. edit: I’d add that its origins in the browser leave it with a “download and stream code to compiler” that strengthen its serverless scenario visbility.
- pjmlp 5y ago
  https://news.microsoft.com/2001/10/22/massive-industry-and-developer-support-for-microsoft-net-on-display-at-professional-developers-conference-2001/ https://news.microsoft.com/2001/10/22/massive-industry-and-d... > More than 20 programming tools vendors offer some 26 programming languages — including C++, Perl, Python, Java, COBOL, RPG and Haskell — on .NET. But hey, WebAssembly invented the language agnostic backend.
gainsurier 5y ago
Some WASM interpreter can run on MCU. https://github.com/bytecodealliance/wasm-micro-runtime https://github.com/bytecodealliance/wasm-micro-runtime

amq 5y ago

The new Docker, rather. We would still need something like Kubernetes to orchestrate.

msoad 5y ago

Nobody mentioned Deno. They're also building similar to WASI architecture but with a focus on JavaScript applications. The future is super isolated processes on a giant server instead of this container craziness we are having today!

brettdeveffect 5y ago
Isn't that all a "container" is anyway? There is the image ecosystem of docker (which I think is a pretty big success) for the content that will be in the initial bootstrap of the isolated process, but beyond that containers are just very isolated processes no?
- immibis 5y ago
  Yes, a container is just a different kind of process. For that matter, so is a VM. All the supposed differences are just implementation details, like the difference between buses and trains.

hosh 5y ago

That's not a great comparison. The author probably should have compared Docker with Webassembly. Kubernetes isn't really about running many containers sharing a physical hardware. You can do that with Docker as well. What Kubernetes offers that Docker does not offer, is self-healing and resilience when managing many containers spread across many underlying nodes. There is no monolithic "Kubernetes" running. Rather, Kubernetes is designed as a set of microservices loosely coupled and maintaining desired states. The resiliency comes from that design. Because it is architected as microservices, Kubernetes is also extensible. Operators, for example, which manage a single distributed system (such as etcd, or postgres, or mongodb) can only be created because Kubernetes was architected as a set of loosely-coupled microservices. WebAssembly is the container runtime without the orchestration capabilities. However, Kubernetes is capable of being modified such that it can schedule, orchestrate, and manage WebAssembly containers: https://cloudblogs.microsoft.com/opensource/2020/04/07/announcing-krustlet-kubernetes-rust-kubelet-webassembly-wasm/ https://cloudblogs.microsoft.com/opensource/2020/04/07/annou...

dqpb 5y ago

The WASM/container comparison doesn't even make sense, let lone WASM/container-orchestrator.

torginus 5y ago

The part about the startup performance of WASM being good - yeah, nah. It's another bytecode language, much like LLVM IR, so it needs at least one compile pass, like Java/.NET does. I wouldn't be surprised if Python/JS beat it in this metric in interpreted mode. It's a far cry from mmap-ing a binary blob, and jumping to the entry point.

unemphysbro 5y ago

kubernetes is my personal afghanistan

lstroud 5y ago

Sounds a lot more like WebAssembly is the new JavaVM. WORA, security, portability, edge, etc.

thrower123 5y ago

The promise of WebAssembly is that we can stop writing shitty Javascript and write shitty web apps in slightly less shitty languages, without having to transpile it to shitty Javascript. Ideally this will lead to less overall shittiness. I don't really think we'll ever actually get there, but that's the hope. And even if we do, we're stuck with the DOM APIs until the heat death of the universe.

nmitchko 5y ago

Time to investigate WASM-security holes for a next generation security firm

eyberg 5y ago

I'll ask the same questions I had over on lobsters since I didn't get satisfactory answers there: * 64bit - Can I run a database that addresses more than 4 gig of memory (eg: keep all my indices in memory so perf doesn't fall off a cliff)? I think the answer is no. This effectively rules out most 'enterprise' software and most things involving 'big data' (eg: all ai/ml projects), not to mention I haven't deployed 32bit to prod in something like 10 years. * threads - shared array buffers && web workers aren't threads - this isn't the biggest deal in the world since all interpreted languages are effectively single process/single thread but there is quite a lot of software that would like real threads. * security - You can overwrite constants in what traditionally would be read-only. You can overwrite portions of the stack. You can overwrite the heap. You can overwrite function pointers. You can overwrite and redirect indirect calls. Taking an existing linux binary and converting it to wasm severely downgrades the security of it. * real sockets/TLS - https://github.com/WebAssembly/WASI/pull/312 https://github.com/WebAssembly/WASI/pull/312 && https://github.com/bytecodealliance/wasmtime/issues/71 https://github.com/bytecodealliance/wasmtime/issues/71 ? yes, I understand some people have shimmed in various layers here but most applications would currently require modification to use said shims - what's the best of breed to not require application mods?

rektide 5y ago

> But, in WebAssembly you get a few more things. One is fast start. This is one of the key things I think is differentiating versus the container world. The idea of per-request instantiation is possibly within reach. This is a possible return to a very old, very simple architectural pattern, of cgi-bin! Running a process per request. Which we left because creating processes was expensive. Our new architectures- discussed in this write up- revolve around long running applications, which are compelled upon us for performance reasons. But WebAssembly seems well suited to very fast instantiation of new contexts. It re-opens the possibility that we can have (return to) smaller more discrete chunks of work, safer little units of execution running. We could go back to a Apache HTTPD style prefork world, the very old[1]! This is part of the gradient we've been walking down, it feels like. VMs -> containers -> lighter weight containers. Returning to finer grained processes. For anyone interested in a deep dive into some of the super neat systems programming going into making WebAssembly starts/instantiation fast, there's a bunch of active work to reengineer module instantiation, using memfd [2][3]. Really fun to see this getting hashed out. > * So one answer to the question as initially posed is that no, WebAssembly is not the next Kubernetes; that next thing is waiting to be built, though I know of a few organizations that have started already.* And as others have recommended, worth noting Krustlet[4], which allows running WebAssembly instances via Kubernetes. This could definitely make sense for a lot of our workloads. I think a lot of people also expect though that the cloud infrastructure itself will get rewritten or recompiled into webassembly. Where-as today we tend to wire systems together over protocols, via http or grpc, we'll be able to more directly stitch together plugably modular systems, where a generic control process to govern, i dunno pick an example, load balancers say, has a bunch of specific webassembly modules plugged in with the specific actuators / configuration for your set up. There's a real potential to fulfill much of the idea of micro-kernels here, of decomposing big applications into looser assemblages of generic code, drivers, and configuration. [1] https://httpd.apache.org/docs/2.4/misc/perf-tuning.html#compiletime https://httpd.apache.org/docs/2.4/misc/perf-tuning.html#comp... [1] https://github.com/bytecodealliance/wasmtime/pull/3697 https://github.com/bytecodealliance/wasmtime/pull/3697 [2] https://github.com/bytecodealliance/wasmtime/pull/3691 https://github.com/bytecodealliance/wasmtime/pull/3691 [3] https://krustlet.dev/ https://krustlet.dev/

gerash 5y ago

Excuse my lack of expertise but I don't like web as a platform. Isn't it basically Javascript (an now WASM) + CSS on the client side and a browser as the VM? On all platforms web is a second class citizen and the feature set is the common denominator which means it's always lacking something. It doesn't have access to all the hardware, it runs in a VM (which I assume means it is slower) and the dev languages are meh. I prefer something along the lines of what Fuschia promises. That is, ephemeral software that gets downloaded lazily and runs natively as a first class citizen of the underlying OS

ozten 5y ago
WASM is a new portable runtime with very few capabilities exposed, so it has a much better security model than the web's JavaScript engine. You write your code in any language and compile it to WASM. You inject capabilities such as file system access, network access, etc. There is no UI layer, so CSS has nothing to do with WASM. Although WASM was invented and developed primarily in the browser, it is now being deployed standalone by companies like Fastly that let you customize their CDN with WASM running at the edge of the cloud via point of presence (POP) data centers.
- immibis 5y ago
  The CPU already offers a non-portable runtime with very few capabilities exposed. Then we exposed the capabilities and didn't provide a way to unexpose them. That was the mistake.
  - ozten 5y ago
    Agreed that there are many ways to skin this cat. Operating Systems, Hypervisors, containers, Unikernels, etc. WASM is a very low level building block that you could build something like Docker out of, but it isn't a high level virtualization product.
justshowpost 5y ago
If WASI gets GPU support, WASM can also replace HTML + CSS and make the browser essentially a thin compatibility layer for nearly native apps.

pablok2 5y ago

Anything that runs 1's and 0's will do!

syrusakbary 5y ago

I'm very excited to see more people are jumping into this vision. I commented about this a few times here in Hacker News [1] [2]. I believe WebAssembly/Wasmer will become the new Docker (fun fact: the name Wasmer comes from Wasm + Docker) and there is a greater opportunity for it to become the base for the future Kubernetes for the Edge. Excited for what's to come! [1] https://news.ycombinator.com/item?id=27158187 https://news.ycombinator.com/item?id=27158187 [2] https://news.ycombinator.com/item?id=26271806 https://news.ycombinator.com/item?id=26271806

peterth3 5y ago

Web3 isn’t going to be about crypto or the metaverse. It will be all about WASM.

pablodavila 5y ago

If I recall correctly, Saša Jurić mentioned in an interview that he envisions the BEAM being used as an OS in the future, where you can run your database, web server and other services under one VM. While I don't personally have much use for it (at the moment), I'm curious about how this would look like with Lumen [0] where you can run your whole web stack with a single binary and being internally supervised by the BEAM. Lumen's development has been slow but I remember seeing a tweet from a team member stating that development is slowly ramping back up (not a criticism in any way, just providing some context). [0] https://github.com/lumen/lumen https://github.com/lumen/lumen

Shadonototra 5y ago

Today? no Too much javascript glue code to write Tomorrow? hell yeah! it is perfect, desktop no longer the lowest common denominator when building crossplatform solutions!

mikewarot 5y ago

> It's even better in some ways because WebAssembly provides "allowlist" security -- it has no capabilities to start with, requiring that the "host" that runs the WebAssembly explicitly delegate some of its own capabilities to the guest WebAssembly module. Compare to processes which by default start with every capability and then have to be restricted. In other words, WebAssembly is another step in the saga of systems that try to fill the hole left by the absence of capability based security in the Operating System. If it gets me a way to get back into the business of developing programs for a desktop, and avoiding worry about details of web servers, tls, caching, and endless browser specific bugs, I'm all for it, especially if I can write a program that uses a PowerBox to get a capability to a local file. At that point, I could just load the file from a disk, or via the web server/browser pipe, and it will work the same. Eventually, someone will figure out that a capability based OS for the desktop could launch a trillion dollar market for new applications without the need for a vendor specific web store or lock-in, and we'll be off to the races again, like in the 1980s shareware boom.

u_rml2555 5y ago

Many misconceptions in the article. It is a good example of an apples to oranges comparison. Kubernetes is first and foremost an orchestrator. Docker is an environment. You can run Redis, proxies and all kind of infrastructure in Docker containers. Or your own binaries. The article is making a valid point in distributing binaries. That's all. Nothing new here. If WASM will conquer the world - we'll see. Potential is there. But WASM for the browser was already overhyped. Hype seems necessary in our times but is clearly not enough.