[HN Gopher] WebAssembly: The New Kubernetes?
___________________________________________________________________
WebAssembly: The New Kubernetes?
Author : signa11
Score : 292 points
Date : 2022-01-21 06:59 UTC (16 hours ago)
(HTM) web link (wingolog.org)
(TXT) w3m dump (wingolog.org)
| kortex wrote:
| 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.
| cassianoleal wrote:
| > k8s is fundamentally a control loop engine, Wasm is a runtime
|
| Thank you for this comment. I was scratching my head wondering
| what developments I had missed on the wasm side of things that
| would replace k8s.
|
| So essentially wasm could replace or augment the CRI in k8s
| eventually. That sounds great if it can be properly integrated
| with the rest of the platform like Ingresses, PSPs, etc.
| hosh wrote:
| There are already people working on WASM as a CRI runtime in
| k8s: https://cloudblogs.microsoft.com/opensource/2020/04/07/a
| nnou...
| lykr0n wrote:
| Not really. Nomad is closer, and Mesos (the old one) is closer
| still.
|
| I wrote my own as a rust library, and I'm in the progress of
| further breaking it apart. Might get a prototype finished this
| weekend and if so, I'll share it here.
| qbasic_forever wrote:
| If it's process control specifically then systemd or a
| lightweight process manager like s6, supervisord, foreman, etc.
| are a good option. You can do things bare metal or just run
| containers as processes. systemd services + nspawn is pretty
| close to k8s container control for a single host
| DanielVZ wrote:
| 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 wrote:
| 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.
| williamscs wrote:
| 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?
| tapoxi wrote:
| Mesos, but it seemed like Kubernetes ate it's lunch since most
| use cases are handled with a single controller.
| johnnypangs wrote:
| 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 among others) but am
| unaware of a way to self host.
| callahad wrote:
| 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
| thelastbender12 wrote:
| 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 2.
| https://wasmedge.org/
| immibis wrote:
| This is amusing to me because _CGI_ is basically self-hosted
| functions-as-a-service.
| jabl wrote:
| 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!
| tlarkworthy wrote:
| 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/
|
| 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.
| nmitchko wrote:
| Time to investigate WASM-security holes for a next generation
| security firm
| amq wrote:
| The new Docker, rather. We would still need something like
| Kubernetes to orchestrate.
| joshuanapoli wrote:
| 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 wrote:
| I'd say that article compares WebAssembly to Docker/moby/other
| container runtimes, not k8s.
| joshuanapoli wrote:
| 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 wrote:
| It depends on specific WASM runtime implementation, but
| usually you have to be explicit about allowing each
| syscall.
| Bayart wrote:
| 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/
|
| [2]: https://wasi.dev
| pablodavila wrote:
| If I recall correctly, Sasa Juric 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
| kordlessagain wrote:
| > 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 wrote:
| 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 wrote:
| The trade-off of resources Isolation matters, eg.
| OS->Container->Namespace(wasm)
| immibis wrote:
| also layer 0: hardware isolation (e.g. Yubikey)
| dusted wrote:
| "a software virtualization substrate"
| JasonFruit wrote:
| 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.
| GiorgioG wrote:
| I have a general dislike for Kubernetes because most folks
| don't need its complexity.
| [deleted]
| progval wrote:
| This would be the last step predicted by this 2014 (!) talk:
| https://www.destroyallsoftware.com/talks/the-birth-and-death...
|
| At the time it seemed unrealistic; asm.js was only just invented
| ksec wrote:
| 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.....
| paavohtl wrote:
| 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.
| stavros wrote:
| Yeah, that talk proved extremely prescient.
| jeroenhd wrote:
| 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.
| peterth3 wrote:
| Web3 isn't going to be about crypto or the metaverse. It will be
| all about WASM.
| aavshr wrote:
| it makes sense to compare WASM to Docker or other container
| runtimes but not Kubernetes.
| lloydatkinson wrote:
| Overhyped, over engineered, and overly used?
| otabdeveloper4 wrote:
| Not "overly used" yet.
| lloydatkinson wrote:
| "not" yet then
| the_duke wrote:
| 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/pro...
| immibis wrote:
| How will you create the small .wasm file - probably with some
| kind of source code and build script, right? Is that not
| equivalent to a Dockerfile?
|
| How will the runtime know which dependencies to provide, and
| how won't it be similar to Docker layers?
| gwenzek wrote:
| The thing I'm not understanding is why WASM runtime is that
| fundamentally different from an OS? Isn't the OS already
| supposed to securely isolate the different programs? Shouldn't
| we try to fix that instead?
| thelastbender12 wrote:
| This was comprehensive, thanks! Lightweight deployment and
| better security (than configuring seccomp) are both interesting
| features. Could you please link to the product/project you're
| building (of course if it is open)?
| the_duke wrote:
| Not public yet.
|
| I'll post a SHOW HN once it's ready for an initial open
| source release.
| sitkack wrote:
| https://news.ycombinator.com/item?id=25160700
|
| see also, https://github.com/lumen/lumen
| smasher164 wrote:
| Is the "syscall layer" for this distributed runtime also
| designed to be distributed? I don't think WASI and POSIX-like
| abstractions lend themselves to be scheduled across a cluster.
| For instance, there's no way to mark a newly launched thread as
| not requiring shared memory. I see a lot of benefit in
| designing a syscall interface from the ground up for a
| distributed context.
| ReleaseCandidat wrote:
| This sounds like the generic comparison websites that compare
| just about anything. Kubernetes is for _managing_ containers.
|
| Btw. Betteridge's law of headlines holds.
| rektide wrote:
| > _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#comp...
|
| [1] https://github.com/bytecodealliance/wasmtime/pull/3697
|
| [2] https://github.com/bytecodealliance/wasmtime/pull/3691
|
| [3] https://krustlet.dev/
| rryan wrote:
| 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 wrote:
| 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.
| unemphysbro wrote:
| kubernetes is my personal afghanistan
| dsign wrote:
| 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.
| [deleted]
| cmeacham98 wrote:
| 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 wrote:
| > 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.
| jack_riminton wrote:
| > 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.
|
| Yeah that can all still be done with a simple monolithic CRUD
| app on just a few servers
| dmitriid wrote:
| > You act like we invent complexity for no reason, but we are
| dealing with scale
|
| 1. Yes, we do invent complexity for no reason
|
| 2. The absolute vast majority of us don't deal with "scale"
| and most of the things we do can be done with a single beefy
| server (even for "tens of thousands of concurrent users")
|
| 3. Sayin that all SO does is serving static html pages is
| hugely disingenuous at best
| mrweasel wrote:
| > The absolute vast majority of us don't deal with "scale"
| and most of the things we do can be done with a single
| beefy server
|
| Most simply fail to understand exactly what modern servers
| are capable of. We continue to read article after article
| about "scaling out", but you're right, the vast majority
| will never have the need to scale beyond just a few
| servers.
| immibis wrote:
| I remember seeing that Stack Overflow runs on half a rack
| of servers, plus a redundant copy.
| https://nickcraver.com/blog/2016/03/29/stack-overflow-
| the-ha...
|
| I bet most people are running sites smaller than Stack
| Overflow (Alexa rank #65 [did you know Alexa is getting
| permanently shut down in a few months?!]).
| marcos100 wrote:
| VM allowed cheaper computing by using resources in a more
| efficient way, but it came with the cost of abstracting the
| components.
|
| You can always buy bare metal and have your simple life.
| crdrost wrote:
| I mean everything is what you make of it.
|
| The fact that wasm is sandboxed allows some genuinely new
| things. Imagine a JSON file starting with a line that gives a
| base64-encoded WASM parser for JSON. (Or a hash on a public
| database if you're worried.) Switch to YAML or TOML by changing
| that line up top, or add comments to your JSON, or get fed up
| and ship SQLite databases instead. Oh wait I have security
| concerns, I need to encrypt this file at rest, better change
| the code that consumes it--why? The registry has a NaCl
| container, just prefix the encrypted version with the wasm hash
| to prompt for a password and decrypt it.
|
| It's a technique that used to be popular and then died out as
| networks proliferated--you could no longer be sure that your
| machine code did the right parse on someone else's
| architecture.
|
| Your container crashes and we coredump to an S3 bucket. You
| know what's better than downloading gigabytes of coredump? If
| S3 can just let you spin up a container or run a WASM program
| on the storage node itself. You send the programs to the data
| so you don't need to pull the data to yourself.
|
| This post describes something like Erlang actors, but if each
| can be a pure function encoded in WASM... That is also a neat
| dream. But the next step is the MonadArrow instance, programs
| sending programs to each other. Then we're "thinking with
| portals."
| immibis wrote:
| > It's a technique that used to be popular and then died out
| as networks proliferated--you could no longer be sure that
| your machine code did the right parse on someone else's
| architecture.
|
| This will be the case with WASM extensions. You won't be sure
| what's available in someone else's WASM environment.
|
| The only reason it's not the case with WASM on the web today
| is because it's so simple, and any differences are dealt with
| in the JavaScript layer.
|
| > Your container crashes and we coredump to an S3 bucket. You
| know what's better than downloading gigabytes of coredump? If
| S3 can just let you spin up a container or run a WASM program
| on the storage node itself.
|
| S3 literally has this feature, and it doesn't even have to be
| WASM. It's called "S3 Object Lambda". It's quite new, so
| you're forgiven for not knowing about it.
|
| Downloading from S3 is quick and free if it's within the same
| region, so you don't actually need this anyway.
| folex wrote:
| > This post describes something like Erlang actors, but if
| each can be a pure function encoded in WASM...
|
| Not just a dream. https://github.com/fluencelabs/fluence
| immibis wrote:
| I'm pretty sure in a cloud service you are not paying for GPU
| _passthrough_ , you are paying for the GPU itself!
| gypsyharlot wrote:
| msoad wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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/annou...
| lstroud wrote:
| Sounds a lot more like WebAssembly is the new JavaVM. WORA,
| security, portability, edge, etc.
| pjmlp wrote:
| No, the old Java Application Servers rebranded for Java haters.
| asteroidbelt wrote:
| 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 wrote:
| Nope, it could run any language that targeted JVM bytecode
| and HP-UX Vault already provided container like support for
| Java Application Servers.
| asteroidbelt wrote:
| > any language that targeted JVM bytecode
|
| Any language similar to Java. Small subset of languages.
| pjmlp wrote:
| So IBM TIMI then, or dozens of other examples that I can
| pull out of the hat since 1961.
|
| It is a big crufty old hat full of legacy papers and old
| scanned computer history.
| jabl wrote:
| So instead of Enterprise Java Beans (EJB) we'll get Enterprise
| Webasm Workers (EWW)? Might have to work on that acronym,
| though.
| pjmlp wrote:
| We already have them, that is the thing.
|
| https://deislabs.io/posts/introducing-hippo/
|
| https://docs.microsoft.com/en-us/azure/aks/use-wasi-node-
| poo...
|
| https://suborbital.dev/
|
| https://blog.cloudflare.com/webassembly-on-cloudflare-
| worker...
|
| Just a sample, plenty of others chasing WASM gold.
| eyberg wrote:
| 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/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?
| PanosJee wrote:
| Checkout krustlet https://github.com/krustlet/krustlet
|
| Kubernetes orchestrating wasm runtimes
| cogman10 wrote:
| 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.
| folex wrote:
| Multiplexing between several WASM modules is exactly how services
| are organized on 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.
| samwillis wrote:
| 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.
| kllrnohj wrote:
| > Gaming, the combination of WASM and WebGPU will be the
| perfect platform for cross platform game development.
|
| That storm already happened. It was called Unity. And since
| then others have joined, like Unreal.
|
| WASM + WebGPU doesn't bring anything to the table here other
| than being a decade late, slower, and with fewer features. Why
| would anything outside of a web app touch any of it? Why would
| steam bother? You still have to build so, so much platform-
| specific stuff to make it work (input, audio, windowing,
| etc...), why would you do all that and then just pay a massive
| performance overhead to avoid compiling a whopping ~5 times?
|
| WebGPU could potentially see a use as a middleware for things
| that want to use the GPU but aren't concerned all that much
| about performance or overhead, things like image filter
| effects. But there's also no shortage of existing solutions for
| them, either, like bgfx (as well as domain-specific offerings
| like halide of course)
| truemotive wrote:
| You left out the part where running WebGL via Unity was an
| absolute nightmare, and was fudged in as a stopgap when NPAPI
| was deprecated and there was no more Flash web player target.
| Barring that, before you even got the build up on the web you
| got to sit through 20 minutes of emscripten and wasm magic
| compiling, hoping and praying you considered any bridging
| methods to .Net from the frontend that don't appear until
| they're useless emscripten errors in the unity console. Oh,
| you'd like audio/video comms in your product? Well, hope
| you're ready to build the non-supported WebGL compatible
| version of Photon/Agora's voice subsystems.
|
| Don't get me wrong, I'm card carrying Unityman and just
| backed off of XR development recently in favor of more stable
| webdev work... but WebGL as a solution to high-performance
| browser gaming was an absolute shitshow from start to finish
| and I'm not even sure WebGPU lands in time for anything
| useful to be done with it to deprecate WebGL "support". I
| assume that the lightweight 3D solutions based on threejs,
| etc. are going to drag the rest of the game engine industry
| kicking and screaming into whatever best solution arises and
| this wasm-as-k8s sounds like a neat component of that.
| pjmlp wrote:
| 3D on the Web is only good for online shops and trivial
| first generation playstation games.
|
| 3D API for 2010 hardware or last generation raytracing
| hardware, what do you prefer?
|
| Unity cannot do anything against castrated 3D APIs.
|
| No wonder streaming is where everyone is going instead.
| echelon wrote:
| > 3D on the Web is only good for online shops and trivial
| first generation playstation games.
|
| That is absolutely not going to continue being the case.
|
| > No wonder streaming is where everyone is going instead.
|
| "Pixel streaming" is great if you don't have latency
| requirements or your client has a poor GPU, but otherwise
| native 3D is superior.
| pjmlp wrote:
| Until WebGPU provides parity with native 3D, it is going
| to be the case no matter what.
|
| Heck, 10 years of Web 3D and still there are no proper
| debugging tools that match native ones.
| echelon wrote:
| WASM is going to provide more than enough impetus for
| tooling.
|
| The ecosystem will explode, and the tooling will come
| with it.
| pjmlp wrote:
| The future is made of dreamers after all.
| kllrnohj wrote:
| I meant Unity already solved the "make creating a cross
| platform game trivial" thing.
|
| Games on the _web_ face far greater issues than WASM or
| WebGPU can solve (like a complete lack of an asset delivery
| pipeline), unless you 're only after casual flash-style
| gaming anyway. But mobile largely replaced that market.
| sleepybrett wrote:
| .. for money.
| nullifidian wrote:
| Installing a native unity game requires more trust than
| running a game in a web browser. Web browser games would
| also work on platforms like Chromebooks, and don't
| require Google's or Apple's store approval, with their
| 30% cut.
| kllrnohj wrote:
| And where are you going to get your game assets from? Are
| you going to try and stream those over the network? Good
| luck with that. Or are you going to show a long loading
| screen as you try and fight with local storage limits to
| prefetch all your assets?
|
| To give you a scope of the problem of game assets,
| "small" indie games like Stardew Valley or Terraria are
| close to 500MB. How on earth are you going to deploy that
| on the web?
|
| And if you are assuming a reliable, super-fast internet
| connection to stream game assets over (along with paying
| for the CDN to host it), well cloud gaming already does
| this better and already exists in a meaningful way. Why
| struggle to fight with the incredibly pathetic limits of
| a web browser when you can just stream a video?
| nullifidian wrote:
| >"small" indie games like Stardew Valley or Terraria are
| close to 500MB. How on earth are you going to deploy that
| on the web?
|
| With lazy loading? Or just an installation progress bar.
| What's the problem? The user has to click on the
| permissions dialog, allowing extended space usage, and
| that's it.
|
| >reliable, super-fast internet connection
|
| It wouldn't need a connection more reliable than what
| Steam requires for proper functioning.
|
| >along with paying for the CDN to host it
|
| I assure you the costs for a minimally successful game
| are minuscule when compared to the 30% cut Steam takes.
|
| What you lose is the exposure that a release on a store
| like Steam gives you. That's not an insignificant
| problem, and is much more problematic than all the
| technical stuff you've mentioned.
|
| >Why struggle to fight with the incredibly pathetic
| limits of a web browser when you can just stream a video?
|
| Answered in a different comment.
| kllrnohj wrote:
| > With lazy loading?
|
| And now you're back to 2006 era performance on a good
| day. 72 Mbit/s would be considered a pretty good internet
| connection. It's also the speed of a PS3's blu-ray drive.
|
| People have been complaining about the 80-100MB/s on the
| outgoing generation of consoles for a long time now.
| Regressing by ~10x isn't a compelling argument.
|
| > Or just an installation progress bar. What's the
| problem?
|
| Without background downloads or updates? Every time
| someone wants to play your game, they're forced to stare
| at a progress bar that can easily take upwards of an hour
| depending on the game ("smaller" 3d games like subnautica
| push 10GB)? And you somehow don't see the problem?
|
| > I assure you the costs for a minimally successful game
| are minuscule when compared to the 30% cut Steam takes.
|
| And I assure you that you don't have to deploy on steam,
| either. You can both be a native game and get all the
| benefits of it _and_ not pay anyone an app store fee! You
| don 't have to suffer the web's treadmill of being a
| decade+ behind to have that.
| nullifidian wrote:
| >Regressing by ~10x isn't a compelling argument.
|
| If it's loading faster than user "consumes" assets, it
| doesn't matter how fast it is. It's not different for
| native games that allow you to play earlier than the
| whole thing finishes downloading.
|
| >And you somehow don't see the problem?
|
| Don't stupidly update the entire thing every time? Send
| deltas? Don't update as often? As for not having
| background updates it's a minor issue anyway (I for
| example don't start Steam unless I'm going to play), and
| there are Progressive Web Apps and Service workers to
| solve this issue.
|
| >You don't have to suffer the web's treadmill of being a
| decade+ behind to have that.
|
| Whoever needs the latest features can of course use a
| native platform. For developers who don't need the latest
| features or especially heavy graphics, WASM+WebGPU will
| be a viable option. That's all.
|
| >You can both be a native game and get all the benefits
| of it and not pay anyone an app store fee!
|
| And the user has to risk trusting me executing native
| code, which would definitely lower conversion rate.
| jacobolus wrote:
| > _To give you a scope of the problem of game assets,
| "small" indie games like Stardew Valley or Terraria are
| close to 500MB. How on earth are you going to deploy that
| on the web?_
|
| Someone watching YouTube videos is sucking down hundreds
| of megabytes if not gigabytes per hour: the higher-
| resolution the video the more bandwidth required. Most
| video game assets require less bandwidth (megabytes per
| minute of consumption time), and can be cached locally.
|
| When designing games for the web, creators will have
| clear incentive to apply more aggressive compression to
| everything they send over the wire and figure out how to
| make do with smaller assets, to cut bandwidth. Games
| designed to be downloaded have a relaxed size budget and
| can afford plenty of inessential bloat.
| wbl wrote:
| Back in the early 2000's you could deliver a fun
| immersive flash based game in under a megabyte. Sites
| like miniclip had dozens of games that could easily
| absorb several hours of fun.
| nemothekid wrote:
| 1. Those types of games are still possible with HTML5.
|
| 2. The reason we don't see them anymore is because it's
| far easier to monetize them on mobile.
| jaegerpicker wrote:
| And Streaming games does that even better over WebRTC in
| the browser and we have that today! With a good internet
| connection (like 5g that is rolling out) the experience
| is fantastic. I bought my kids iPad Mini's for christmas,
| they have both 5g and we have 1gb internet at home and
| GeForce Now and XBox Cloud Gaming have been absolutely
| great for them. A ps5 controller and the ipad mini can be
| the best gaming device available today IMO.
| nullifidian wrote:
| Streaming games is no different from distribution using a
| large platform/store with accompanying commissions -- you
| can't do it independently as a small company. Also more
| demanding towards one's internet connection and has
| higher running costs, since you have to pay for both
| traffic and a server side GPU, so not viable for a
| certain percentage of lower budget/cheaper/free games.
| jaegerpicker wrote:
| Almost no one can do game development as a small company
| without a large platform of some kind. The economies of
| scale are just too much for small indie dev style game
| studios to overcome. Speaking as someone that was an
| indie dev and has been around the game industry for 20
| years. I highly doubt that is going to change anytime
| soon. Webassembly certainly won't fix that issue. I'm not
| sure what that comment has to do with the subject. With
| Webassembly you won't have to pay for server side gpu but
| you will have to pay for discovery, hosting/bandwidth,
| payment, likely some form of advertising, and some level
| of support. There is no free lunch and large platforms
| will nearly always win for software distribution.
| nullifidian wrote:
| I'm not denying any of that, and said something similar
| in another comment. But Minecraft, Escape from Tarkov
| came into existence without dependence on a store or a
| platform. Same for Runescape, albeit in a different time.
| WASM+WebGPU will make an appearance of such things more
| possible in 2022+. It's just a technical capability. A
| web implementation (of an online game) could come in
| addition to the ones available on Steam and
| Android/Apple, etc.
| y4mi wrote:
| To my knowledge (correct me if I'm wrong please), the
| performance issues from WASM only exist in the context of
| moving things back into the DOM. I was always of the
| understanding that WASM itself is super performant and if
| it's possible to run a WASM application without going through
| the DOM you'd get native performance, making it a valid
| choice for things like gaming.
|
| Most devs would obviously still use unreal engine etc, but
| these engines will be able to give you improved performance
| of your games by utilizing WASM
| elevader wrote:
| AFAIK you don't really get native performance, although
| it's hard to find good data on this
| (https://nickb.dev/blog/wasm-and-native-node-module-
| performan... was one I could find on the fly). WASM is
| still virtual machine based and not compiled to a native
| executable so this is to be expected I guess, it's supposed
| to be faster than JS and it achieves that goal. Maybe it
| can be an alternative to Unity, which would be good enough
| for a lot of games, but I don't know how that compares.
| dathinab wrote:
| > not compiled to a native executable
|
| except it is, WASM is designed to be AOT compiled to
| native code.
|
| Sure there is a bit of difference, WASM needs additional
| bounds checks and WASM also doesn't have all the info a
| more high level compiler has.
|
| Now Unity is so much more then just a tool to make cross
| platform easier. So comparing it to WASM is kinda
| pointless IMHO. Though it probably is a grate choice for
| any extension mechanism, like mods or even in game
| scripting.
| elevader wrote:
| > except it is, WASM is designed to be AOT compiled to
| native code.
|
| Interesting, I didn't know that. How does WASM handle
| different architectures? Do you build different binaries
| for x86/arm? Or does it do it the Apple way with the
| giant bundle that contains all binaries?
|
| > Now Unity is so much more then just a tool to make
| cross platform easier. So comparing it to WASM is kinda
| pointless IMHO. Though it probably is a grate choice for
| any extension mechanism, like mods or even in game
| scripting.
|
| Agreed, that was badly worded. Like you said, one could
| compare a module written in Unity and compiled to
| whatever Unity compiles to/is implemented in these days
| with a module in WASM.
|
| Edit: Or does the AOT mean that the format that is
| shipped is some non-native format but the client compiles
| everything before the first run?
| billti wrote:
| > How does WASM handle different architectures?
|
| The same way JavaScript or C#/Java do. It's a bytecode
| format (typically the first stage in today's JavaScript
| engines is to turn into a bytecode), which the different
| engines then JIT for the OS and architecture they are
| running on.
|
| For more details on a couple different engine
| implementations, you may find the below of interest.
|
| - https://v8.dev/docs/wasm-compilation-pipeline
|
| - https://hacks.mozilla.org/2020/10/a-new-backend-for-
| cranelif...
| kllrnohj wrote:
| WASM gets you faster performance than JavaScript, sure, but
| it's not native, either. Sandboxing & byte code aren't free
| to have. See the extremely long history of existing byte
| code VMs here - WASM isn't really doing anything new.
| manmal wrote:
| Modern hypervisors have astonishing performance, and I
| don't see why Chrome and Safari wouldn't manage to
| eventually provide a similarly efficient implementation.
| kllrnohj wrote:
| Modern hypervisors don't run bytecode and are using the
| CPU to do security enforcement, not software emulating it
| like WASM is forced to do (since it's not using a
| hardware protection domain, aka a process)
| nullifidian wrote:
| WASM is more secure than a hypervisor, since it prevents
| code injection.
| eyberg wrote:
| It is trivial to modify function pointers, implemented as
| indirect calls and "read-only" data in wasm.
| nullifidian wrote:
| Yes, WASM in combination with an unsafe language is less
| secure than memory safe languages, but more secure than a
| hypervisor. You can also use WASM with a memory safe
| language.
| kllrnohj wrote:
| WASM is less secure than a regular process boundary, and
| far less secure than a hypervisor. I'm not sure where
| you're getting this from? Things like spectre mitigations
| in CPUs are not doing anything for the likes of WASM,
| after all, they only target process & ring boundaries.
| It's why you have to enable COOP and COEP to use thread
| with WASM - because the security for WASM's threads comes
| from the CPU enforcing process boundaries, not from
| WASM's sandbox.
| nullifidian wrote:
| If we are concerned with leakage of user data available
| in your own web program, then unsafe WASM code is more
| secure than unsafe code in a hypervisor because it
| prevents RCE, which results in full control of the
| hypervisor environment, which also enables transient
| attacks against the host environment, if there are
| vulnerabilities in your hypervisor (previously
| hypervisors had to be patched for Spectre). If we are
| talking about host platform protection against arbitrary
| malicious code, information leakage from neighboring
| processes/tabs, WASM is no different from a process
| boundary, at least in chrome, because that's how it's
| implemented. It's an implementation detail independent of
| WASM. Could as well be implemented with hardware
| virtualization, but it would make interfacing with
| browser API's more expensive, probably to the point of
| impracticality.
| eyberg wrote:
| It doesn't matter if it's rust or not. You can still
| modify read only data and still redirect indirect calls.
| You can still modify the stack and the heap. Rust changes
| nothing.
|
| Also, not sure where the comparison to a hypervisor is
| coming into play. As @kllrnohj mentioned hypervisors are
| relying on actual hardware.
| nullifidian wrote:
| I'm not a rust expert, but I thought rust without unsafes
| should prevent such things at the compile time. C# and
| Java will be compiled into WASM differently, I believe no
| less securely than JVM or .NET. Having information leaks
| is still better than arbitrary code execution.
| paavohtl wrote:
| WASM was explicitly designed to be easy to into native
| code. No production-ready WASM runtime is interpreting
| bytecode in hot code paths.
| kllrnohj wrote:
| Easy to convert to native code is very different from
| easy to convert to _optimal_ native code. Just like WASM
| having performance as a design goal both doesn 't mean
| they achieved it nor does it mean that it won when a
| compromise had to be made against other design goals like
| portability or security.
|
| In fact I'm quite certain that whenever portability or
| security ran up against performance in WASM's design,
| that performance _always_ lost. Those other two goals
| were definitely a higher priority for WASM 's designers.
|
| Stable, portable byte codes are always inherently lossy.
| Information that could be (and often is) useful to
| optimizers is lost in that conversion. Then the
| conversion from byte code to running code also _is_ on
| the hot path - it 's on the hot path of starting
| execution. This is the same problem existing byte code
| solutions face, like CLR & JVM. WASM didn't manage to
| magic a solution where nobody else had. It's the same
| thing that's been done to death, just with "web" slapped
| on the front of it & bundled in a browser. That part of
| "being in a browser" makes it interesting for web devs,
| sure, but in the broader context of "all of computing"
| it's... just not? It's what we already have had (and been
| using!) for decades.
| [deleted]
| nullifidian wrote:
| Unity is not a free standard with multiple implementations.
| Unity doesn't support a plurality of programming languages,
| while it's the goal of the garbage collected WASM. Unity is
| higher level in the stack, and could be executed on top of
| WASM and WebGPU. The work of making GCd WASM (which could
| interface with browser APIs without an overhead) and WebGPU
| fast is ongoing.
| pjmlp wrote:
| There are plenty of other middleware options, Unity is not
| the only game in town.
|
| What all of them have, is being able to take advantage of
| 2022 hardware in 2022, with 2022 3D APIs.
| nullifidian wrote:
| Not all games need "to take advantage of 2022 hardware in
| 2022, with 2022 3D API". A good plenty would look fine
| with a middling level of graphical fidelity or
| "latestness" of employed GPU features. Using the web
| platform you also free yourself of gatekeeping, cut
| taking middlemen. So there is a niche for both WASM and
| WebGPU.
| pjmlp wrote:
| Sure, I also like to revisit my Playstation and Amiga 500
| games.
| nullifidian wrote:
| So in your world there are only games employing the
| latest features, and "retro" games from the 80s and the
| 90ies, and nothing else? Ok.
|
| As far as I know WebGPU doesn't lack any significant
| features beside raytracing (They are prioritizing the
| MVP, and raytracing could come later). Some of the newest
| features like mesh shaders are not yet supported by the
| native engines either, because there isn't a sufficient
| hardware base. Intel for example will support mesh
| shaders only in the yet to be released Alechemist GPU.
| pjmlp wrote:
| What can I say, that is the quality of most WebGL games
| anyway.
|
| 10 years later there still isn't something at the same
| level of Infinity Blade.
| nchi3 wrote:
| I think one big difference with WebGL and WebGPU is that
| WebGL was never really a target that you'd use for native
| applications. I've never heard of WebGL running outside
| of a browser (you'd use OpenGL ES for that), whereas I
| think native WebGPU has the potential to end up being the
| OpenGL replacement people have been asking for for years.
|
| It definitely won't kill Unity or Unreal, but I have
| hopes that it will make developing without a ready-made
| engine a bit more attractive at least!
| pjmlp wrote:
| I don't see any benefit in using a castrated 3D API
| outside the browser.
|
| Want Vulkan/DX12/Metal without boilerplate?
|
| Just use Ogre or Godot, among endless other options.
|
| Even Qt is better than what WebGPU is capable of.
| nchi3 wrote:
| >I don't see any benefit in using a castrated 3D API
| outside the browser.
|
| Castrated how? A single digit performance loss compared
| to the most extremely complex graphics APIs which aren't
| properly cross-platform?
|
| >Want Vulkan/DX12/Metal without boilerplate?
|
| >Just use Ogre or Godot, among endless other options.
|
| "I want a graphics API!"
|
| - "Use this game engine or this old and outdated graphics
| library instead"
|
| >Even Qt is better than what WebGPU is capable of.
|
| Ah, is it? Do you have any example of implementing
| forward+ rendering in pure Qt? No? What about GPU
| compute? Not that either?
| pjmlp wrote:
| Castrated by the security constraints of being a MVP 1.0
| API to fit into the security sandbox of a Web browser.
|
| By its nature cannot be more than that what browser do.
|
| In case you missed the train, Qt now makes direct use of
| Metal, Vulkan, and DirectX 12.
|
| I guess you were too busy keeping up with WGSL changes to
| notice that.
| nchi3 wrote:
| >Castrated by the security constraints of being a MVP 1.0
| API to fit into the security sandbox of a Web browser.
|
| What security contraints are you thinking of which are
| making it castrated? In what meaninful ways is it
| castrated?
|
| > In case you missed the train, Qt now makes direct use
| of Metal, Vulkan, and DirectX 12.
|
| So with Qt, can I write a complete renderer with advanced
| techniques, and have it run on all 3 platforms without
| changing a single file? If not, how is it relevant to
| even mention?
| [deleted]
| [deleted]
| astlouis44 wrote:
| Epic deprecated support back in the 4.23 release of Unreal
| Engine, so developers haven't been able to export to HTML5
| unlike Unity which has to this day maintained the abilit to
| target the browser, and in fact they are in the process of
| building out support for WebGPU. Check out this job ad:
|
| https://careers.unity.com/position/software-developer-
| unity-...
|
| Our startup is working on support for Unreal to support
| WebGPU from 4.24 onwards, and we've already upgraded support
| so developers can use WebGL 2.0 instead of WebGL 1.0 like was
| available previously before Epic made it a community
| supported platform extension.
| tlarkworthy wrote:
| I hope to create a wire compatible Firebase Realtime server for
| edge use https://observablehq.com/@tomlarkworthy/rtdb-protocol
| ignoramous wrote:
| > _What's needed is a edge first database, we need at least
| read replicas to be at the edge with your app... I 'm
| interested to see if CloudFlare do anything in this area as
| it's the part of their stack that's missing._
|
| Cloudflare already has a free caching layer, a freemium
| eventually-consistent KV store that optimises for frequently-
| read items, and a strongly-consistent datastore. Besides, they
| partner with other database vendors too:
| https://blog.cloudflare.com/partnership-announcement-db/
| samwillis wrote:
| > strongly-consistent datastore
|
| I think you are referring to the upcoming R2 object store?
| I'm not aware of what I would think of as a "strongly-
| consistent datastore" which would be closer to a traditional
| database with querying. It's that that I think is missing.
|
| Quite right they have partnered with other db providers,
| however I think there is a need for something native to their
| platform that ensures good proximity to Workers to ensure low
| latency.
| mwarkentin wrote:
| I think they're referring to Cloudflare Durablr Objects:
| https://developers.cloudflare.com/workers/learning/using-
| dur...
| delarq wrote:
| > - 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.
|
| We will finally be able to write code once and run it
| everywhere! I bet at least 3 billion devices will run WASM.
| It's a breakthrough, how come nobody came up with such great
| idea yet?
| csmpltn wrote:
| > "how come nobody came up with such great idea yet?"
|
| Cross-platform Virtual Machines have been around for a very
| long time, enabling exactly the kind of thing you're talking
| about. So in-fact, lots of people thought about this, and
| built various versions of this. The browser doesn't bring
| anything new to the table here: it's yet another high-level
| abstraction layer which inevitably will incur performance
| penalties in a setting where _performance means everything_.
| People want to play complex, immersive games at 60 FPS with
| amazing graphics and textures, sounds, single /multiplayer
| settings, and more.
|
| The browser was never built for modern triple-A gaming in
| mind, which means the APIs available for game creators will
| inevitably be less flexible and lag behind the more platform-
| native APIs we've had for 30+ years. This isn't a precedent
| by the way: recently developed APIs such as WebAudio &
| WebWorkers are just awful and don't come anywhere close to
| what a desktop application can do on a modern OS, and those
| are often considered "cutting edge". Synchronization APIs and
| locking primitives are only now being introduced to browsers
| - https://developer.mozilla.org/en-
| US/docs/Web/API/Web_Locks_A... - something games could easily
| make use of outside of the browser for the past 40+ years.
|
| Lightweight gaming can easily take place within the browser,
| and perhaps this new technology can make that easier to build
| and use. But to build a proper heavy-weight game - you'll
| need much more than a browser can offer.
| samwillis wrote:
| I think unfortunately the post you are replying to was
| another sarcastic joke about the JVM and probably didn't
| deserve your thoughtful reply.
|
| Completely agree that web despite being perfect for light
| weight and casual gaming, is not (yet) the platform for AAA
| games.
| torginus wrote:
| Isn't multithreading support, which is kinda essential for
| high-performance applications, spotty under WASM? I've read
| that threads in WASM are hack built-on top of Web Workers +
| SharedArrayBuffer, which is kinda dodgy at best, and most
| importantly, not even supported under Safari.
| azakai wrote:
| Safari does support wasm threads now! It's pretty recent:
|
| https://twitter.com/RReverser/status/1471623675623481356
|
| Yes, wasm threading support on the web uses workers + SAB.
| There are some limitations (the usual issues with blocking on
| the main thread on the web), but it works well in production
| for many things.
| astlouis44 wrote:
| Agree 100% on gaming, which is why my team and I at Wonder
| Interactive are creating a suite of optimization tools and a
| hosting platform for Unreal Engine developers to to target the
| browser using WebAssembly, with WebGPU and WebXR support on the
| way for UE4 and UE5. We've already got some demos online that
| are really impressive despite only being WebGL 2 (OpenGL ES
| 3.0) for the time being. With WebGPU, it'll enable desktop
| quality on par with what you'd except from Vulkan, Metal, or
| Direct 3D 12, except in Chrome, Safari, Edge, and Firefox.
|
| The future of gaming and the metaverse is cross-platform and
| free of walled gardens, with developers empowered to distribute
| directly to their end users online without a middleman
| required. The reinvention and subsequent golden age of high
| fidelity 3D browser games will be upon us sooner than most
| realize.
|
| Links for anyone interested:
|
| https://www.theimmersiveweb.com/
|
| Our Discord:
|
| https://discord.gg/zUSZ3T8
| winter_squirrel wrote:
| manuelabeledo wrote:
| > The future of gaming and the metaverse is cross-platform
| and free of walled gardens
|
| Given that you mentioned Unreal Engine, why the web and not
| native?
|
| I mean, this sounds like an awful lot of work to port
| something to the web, when it already runs in every platform.
| Guidii wrote:
| Perhaps because of the web's deployment model? Quickly
| getting from "interested in" to "running the game" might be
| a game-changer. (apologies for the unintentional pun)
| have_faith wrote:
| > free of walled gardens
|
| How will it reduce walled gardens?
| BlueTemplar wrote:
| Well, the hardest in cross-platform has always been designing
| for different input / output devices (which usually fails,
| better stick to a single platform and do it well).
|
| Another question : how, as a player, do you run a game like
| this offline, or run multiplayer when the game company
| servers have shut down ?
| jmrm wrote:
| The only part here that I'm a bit sceptic are the embedded
| electronic. Maybe I'm too into bare metal and RTOS instead of
| Yocto or other Linux-based development, but I don't see the
| advantages of using WASM here. By the other hand, I agree
| completely with the rest of the other deployment targets.
| tracker1 wrote:
| I wouldn't mind better isolation interfaces between my
| entertainment system and my engine performance options. Of
| course, this doesn't require WASM... also, the hardware
| horsepower (so to speak) for the computers you interact with
| are anemic to begin with, let alone the 2-5x impact of WASM
| on top of it.
| birdyrooster wrote:
| The future in the datacenter is unikernel virtual machines
| scheduled by kubernetes.
| tester34 wrote:
| Is WASM going to replace:
|
| Lua, JS and LLV IRM?
| BlueTemplar wrote:
| Isn't it an intermediating language ? Why would it replace
| them, it's not like a lot of people directly code in assembly
| when C is available...
| cpuguy83 wrote:
| Instead of, as an example, coding a plugin in lua, you code
| it in whatever you want and compile to wasm (that supports
| wasm as a compile target). In that sense it would be
| replacing lua.
| BlueTemplar wrote:
| But lua is typically used as an easy scripting language
| for non-programmers...
| _nalply wrote:
| No. I am not a clairvoyante but I think there will be
| possibilitites to compile to WASM. LLV IRM is a special case
| but transcompiling is not unimaginable.
| kortex wrote:
| No, no, and no. The only one remotely close in scope is LLVM-
| IR, and even then scope is pretty significantly different.
| LLVM-IR is a general purpose IR for native compilation. Wasm
| is deliberately small in scope and designed for sandboxing.
|
| Lua and JS are not even binary languages.
| singularity2001 wrote:
| > edge first database
|
| Sqlite was successfully ported to wasm, maybe something can
| grow out of that?
| infogulch wrote:
| This is the biggest question actually.
|
| Something like cockroachdb's serverless might fit too:
| https://www.cockroachlabs.com/blog/how-we-built-
| cockroachdb-...
| samwillis wrote:
| We are singing from the same song sheet.
|
| SQLite in the browser and at the edge is going to explode in
| popularity. A slightly unknown feature of SQLite is
| "sessions" which would allow you to build an eventually
| consistent system on top of SQLite.
|
| https://www.sqlite.org/sessionintro.html
|
| I can very much see SAAS type apps wheee each
| costumer/workplace has a SQLite db effectively deployed to
| the edge.
| throwaway81523 wrote:
| Write once run anywhere sounds like Java of the 1990s ;).
| 8bitbuddhist wrote:
| It's very similar for sure, but it's worth nothing how this
| is different. WASM is much more accessible as it doesn't
| require additional downloads or tooling. It also supports a
| wider range of languages. I can take my Qt desktop
| application written in C++, run it through emscripten, and
| have it running in Firefox or Chrome in just a few minutes.
| Instead of having to build and release binaries for Linux,
| Windows, Mac, and Android, I can make a single WASM build,
| host it on my website, and run it anywhere. It's honestly
| incredible
| pjmlp wrote:
| Just like the Common Language Runtime.
| dragonwriter wrote:
| Sure, its the JVM, but open from the start, native in major
| browsers, and at a time when a popular choice for desktop
| development is "wrap a browser in a layer providing access to
| OS services".
| brabel wrote:
| It's very similar. If Java had had a good sandbox model and
| not shipped with a large runtime available to all
| applications, from the beginning, there would be no reason
| for WASM to exist.
|
| WASM is like Java bytecode without access to the Java
| standard library (like, no `java.lang.String` or even
| `java.lang.Object`... just the primitives).
|
| But it has a mechanism to call "host" or "imported" functions
| and to use linear memory (an array of bytes which can be
| shared with other modules and the host), which is how it
| actually does anything useful.
|
| I can imagine a version of Java that works like this as well,
| actually, I wonder if there's ever been anything like that?
| ptx wrote:
| Once the GC proposal lands, letting the host and
| application interact through object graphs, won't that
| bring back most of the same perennial security problems
| that Java suffered from?
| monocasa wrote:
| Java's perennial security issues was that the sandboxing
| mechanism was implemented in Java in the same VM as it
| was trying to sandbox... then they added reflection. They
| couldn't plug all of the holes that could let you get a
| reference to the security management objects and go to
| town on them with reflection.
| PoignardAzur wrote:
| _> Once the GC proposal lands_
|
| "Once".
|
| That GC proposal isn't anywhere close to landing. It's
| making progress, but it's the "Zeno's paradox" kind of
| progress where the feature seems further away the more
| they work on it. I wouldn't be surprised at all if it
| still wasn't supported in browsers in 10 years.
| nkozyra wrote:
| It does, but so do interpreted languages and the many
| compiled languages with different compilation targets.
|
| It's less of a problem in 2021 than it was in 1995.
| justshowpost wrote:
| api wrote:
| There are a lot of security reasons to get away from compiled
| native code as well as convenience reasons. Something like
| Spectre/Meltdown could have been mitigated completely with a
| JIT upgrade.
|
| Then there's the huge advantage of encouraging more competition
| in the CPU market. Something like RISC-V would have a much
| better chance if you didn't have to recompile everything for
| it.
|
| I'm surprised native binary is still the standard. Back in the
| 1990s when I saw Java and then .NET I thought it would be dead
| by now outside of specialized high performance libraries for
| things like codecs and cryptography.
| kaba0 wrote:
| 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 wrote:
| As much as I hate it, I think economics will make WebGPU a
| thing the same way it did electron.
| tracker1 wrote:
| It could happen... I still remember how exciting VRML was in
| the 90's. Of course, I still have more of a wait and see
| approach to anything actually working out.
| codeflo wrote:
| 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.)
| j-pb wrote:
| > It's designed to be efficiently implemented on top of the
| vendor APIs, so platform vendors can't block it.
|
| Their choice of inventing their own shading language
| instead of using the ONE standard that the industry finally
| could agree on (SPIRV) makes me very pessimistic.
|
| Apple is purposefully crippling stuff to retain their App
| dominance yes, but Apple IS a major part of WebGPU. So it
| never had a chance and was doomed to fail from the very
| begining.
|
| Google even had a presentation titled "regaining developer
| trust" on this topic, but WebGPU continued to push WGSL
| nevertheless.
| krona wrote:
| SPIR-V is an intermediate representation and WSGL
| compiles to it. WSGL is (or will eventually be) a w3c
| specification.
|
| I fail to see where your point about trust fits in to
| that.
| j-pb wrote:
| Apple + Mozilla did a bait and switch on developers in a
| textbook case of: Embrace, Extend, Extinguish
|
| The original google proposal was to simply use SPIRV. A
| compromise was then settled for the intermediary language
| to be isomorphic to SPIRV, removing some of the warts and
| edges of it and make verification easier.
|
| However, Apple with the help of the Mozilla folk
| successfully managed to twist the semantics into
| something that is no longer easy to translate from and
| to.
|
| Game developers don't want to work with WSGL, the whole
| point of the new WASM and WASI ecosystem is to allow devs
| to bring their own tools.
|
| This is especially bad for something like a shader
| language, where you want to squeeze every bit of
| performance out of the hardware, often with hand rolled
| instructions. Having the browser run a mangled version of
| the SPIRV that you or your toolchain/engine e.t.c.
| produced is simply not acceptable.
| the_duke wrote:
| As the draft says [1]:
|
| > Trivially convertable to SPIR-V
|
| > Constructs are defined as normative references to their
| [SPIR-V] counterparts
|
| > All features in WGSL are directly translatable to
| [SPIR-V]
|
| > Features and semantics are exactly the ones of [SPIR-V]
|
| > Each item in this spec must provide the mapping to
| [SPIR-V] for the construct
|
| So WGSL is essentially just an alternative representation
| for SPIR-V.
|
| But I don't see how this compromises the viability of
| webgpu.
|
| [1] https://www.w3.org/TR/WGSL
| j-pb wrote:
| That was the original sales pitch which has been
| abandoned in favour of "Lets make a Rust-like language
| for shaders!".
|
| It's a textbook case of: Embrace, Extend, Extinguish
|
| Google tried to save it, but that proposal was rejected:
| https://docs.google.com/presentation/d/1ybmnmmzsZZTA0Y9aw
| TDU...
|
| The Proposal to work with both WGSL, was also not
| accepted because it would "weaken the position of WGSL".
|
| "But think of the children/open web!"
|
| Apple knows how to push the right buttons on the Mozilla
| folks so that they tag along: Rust, wEB-StAnDARds, not
| invented here.
|
| - SPIRV was done by an evil technological group, not an
| open and inclusive standard body. We would tie our
| standard to whatever the SPRIV says, that's not open web.
| The open web can only flourish if everything is text
| based! _cough_ WASM _cough_ Rust ist such a modern
| language! -
|
| It's similar to what happened to WebSQL, except this time
| it's much worse as it also ruins any hope that WASM might
| be able to replace all the other technological cruft.
| Playing the old guessing game of how the transpiler will
| mangle your SPIRV is simply not something that people
| want to go back to.
| the_duke wrote:
| I'm a bit confused.
|
| The draft was just updated two days ago.
|
| Are you saying that the direct mapping requirements I
| quoted above have been abandoned?
| j-pb wrote:
| > Are you saying that the direct mapping requirements I
| quoted above have been abandoned?
|
| Yes.
|
| See these quotes:
|
| Apple: "Having an isolated focus on SPIR-V is not a good
| perspective, we have MSL etc. to consider too"
|
| ...
|
| Apple: "Extreme A is no interaction with SPIRV?, extreme
| B is very tightly coupled to SPIRV, we should find a
| middle point"
|
| ...
|
| Google: "We take all targets into consideration. We can
| allow developers do runtime probing and maybe branch
| according to that. Optimization occurs in existence of
| uncertainty. Dealing with fuzziness is a fact of life and
| we should give the tools to developers to determine in
| runtime."
|
| From https://docs.google.com/document/d/15Pi1fYzr5F-aP92m
| osOLtRL4...
|
| See also:
|
| https://github.com/gpuweb/gpuweb/pull/599
|
| https://github.com/gpuweb/gpuweb/issues/582
|
| https://github.com/gpuweb/gpuweb/issues/566
|
| http://kvark.github.io/spirv/2021/05/01/spirv-
| horrors.html
|
| https://github.com/gpuweb/gpuweb/issues/847#issuecomment-
| 642...
|
| https://news.ycombinator.com/item?id=24858172
|
| The process has been very implementation driven, with
| Naga, the Rust tooling that does the whole conversion
| shenanigans, growing and changing its IR and semantics
| steadily. It's ironic that a group that is usually very
| adverse to having a single implementation of things is
| now pointing to Naga and arguing that we don't need an
| easy conversion step because we have all the compiler
| infrastructure build already.
|
| The group has slowly redefined "bijective" to mean
| "easily compilable", which would be pretty hilarious, if
| it weren't so sad.
| kaba0 wrote:
| Without much experience in the topic, why was the "de
| facto standard" SPIR-V was not chosen then instead? If
| they are so similar, is there any advantage of a new
| format?
| codeflo wrote:
| Here's a comment summarizing the official rationale: http
| s://github.com/gpuweb/gpuweb/issues/847#issuecomment-642.
| ..
|
| TBH, I don't find those arguments convincing, but then,
| WebGPU is largely a political compromise, not a technical
| one. In a politics-free zone, they'd have standardized a
| "WebVulkan", not made an entirely new thing. That would
| have been on the table, but Apple vetoed it. The same for
| a "Web-SPIR-V".
|
| However, I also don't think it's that big of a deal in
| the grand scheme of things. I'm glad we have a viable
| standard at all.
| BlueTemplar wrote:
| Microsoft is _definitely_ the core issue here : they are
| trying to unify XBOX and PC gaming, and are NOT supporting
| Vulkan on XBOX.
| astlouis44 wrote:
| WebGL 2.0 today runs on not just desktop browser but also
| through the web on Xbox, which has a Chromium-based Edge
| which can run browser games and will get turbocharged
| with near native performance with the arrival of WebGPU.
|
| So you now have a platform target with one codebase that
| developers can target PC/Mac/Linux, mobile/tablet, and
| one of the biggest console platforms. I'd say that's
| pretty powerful.
| yolo69420 wrote:
| vulkan runs everywhere except on apple shit, and that is on
| nobody but apple. they are actively working against open
| standards. the world is better off if you ignore them and
| their users.
| pjmlp wrote:
| No Vulkan for you on Playstation, XBox.
| kaba0 wrote:
| That's not true:
|
| https://news.ycombinator.com/item?id=30021878
| torginus wrote:
| I hope so. And for that matter, I hope that WebGPU makes it
| out of the browser as well. It's a modern API, based upon
| Metal, that has an execution model much closer to actual
| GPUs, much like Vulkan/DX12, while still handling some of the
| hairy scheduling/dependency issues for you, as well as
| lacking the incredible verbosity of the _modern_ APIs.
| nicoburns wrote:
| WebGPU is to WebGL as Vulkan, Metal, DX12 are to OpenGL, DX11
| and below. In that context I would expect WebGPU to be just
| as successful as WebGL has been.
| pjmlp wrote:
| Basically mostly 3D renderings for online shops, while most
| indie devs rather focused on mordern hardware on mobile
| platforms.
|
| Ah, and Google Maps.
| jokoon wrote:
| 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.
| alex_duf wrote:
| 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.
| marcos100 wrote:
| Wasm is not only for browsers. There is wasmer, for example.
|
| The author is saying that you will be able to replace docker (I
| think comparing to kubernetes is wrong) with wasm, because it
| can run code sandboxed.
|
| Another example is a plugin ecosystem using wasm. Your go
| program would be able to load plugins written in c, lua or any
| other language that compiles to wasm.
| anonporridge wrote:
| 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.
| jokoon wrote:
| And how would they do that?
| mhoad wrote:
| 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 wrote:
| 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-...
| dqpb wrote:
| The WASM/container comparison doesn't even make sense, let lone
| WASM/container-orchestrator.
| haolez wrote:
| Genuine question: outside of the web browser, what's the
| advantages of WebAssembly over the JVM or a similar VM?
| runlaszlorun wrote:
| 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 wrote:
| 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 wrote:
| Some WASM interpreter can run on MCU.
|
| https://github.com/bytecodealliance/wasm-micro-runtime
| tayo42 wrote:
| Shipping self contained modules, this whole things sounds like
| reinventing what the jvm is.
| shireboy wrote:
| 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 wrote:
| 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.
| rcarmo wrote:
| 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 wrote:
| 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.
| rob_c wrote:
| 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.
| _robbywashere wrote:
| 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.
| kokizzu2 wrote:
| 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
| gerash wrote:
| 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
| justshowpost wrote:
| ozten wrote:
| 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 wrote:
| 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 wrote:
| 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.
| wolframhempel wrote:
| 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 wrote:
| 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?
| immibis wrote:
| WASM also can't "run in any environment" since it relies on
| imports, and different environments will have different
| things available to import. The only way around that is by
| only defining very minimal behaviour... like it does on the
| web. But then you can't do anything useful with it by itself.
| hinkley wrote:
| I think we say 'run in any environment' when what we mean
| is 'recreate the environment on any machine'. And this is
| often more of a continuum than a black and white answer. I
| can get a lot of things done without low level access to
| the GPU, or printer, but I can't do everything.
| vbezhenar wrote:
| Docker supports Windows-native containers.
| chriswarbo wrote:
| 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.
| immibis wrote:
| Wait until you hear about ARM.
| fesc wrote:
| > as they include their own OS
|
| That is not required.
| pablok2 wrote:
| Anything that runs 1's and 0's will do!
| syrusakbary wrote:
| 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
|
| [2] https://news.ycombinator.com/item?id=26271806
| politelemon wrote:
| I predict an amusing PoC in a few years, implementing k8s in w9y.
| It will spark discussions about microfrontends.
| thrower123 wrote:
| 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.
| jabl wrote:
| 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.
| raesene9 wrote:
| 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 wrote:
| > 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 wrote:
| Serverless could have been the future. But it's too expensive
| and not worth it.
| cyberpunk wrote:
| 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)
| bsder wrote:
| > 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.
| tehbeard wrote:
| 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.
| PaulHoule wrote:
| It's like saying that beans are the new cars.
| FreeHugs wrote:
| 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.
| ridiculous_leke wrote:
| Off topic: I assume you have your own SaaS app. If yes, can you
| share more details about it?
| pjmlp wrote:
| Same here, it is kind of funny to see Java and .NET being re-
| invented by haters all the time.
|
| First they do containers to replicate application servers, and
| now WASM to replicate bytecode server side.
| ptrwis wrote:
| And were these application servers (like JavaEE) that bad?
| Separately deployed EJB modules can also be considered
| microservices, and everything was much easier to manage.
| pjmlp wrote:
| Not at all, I am still working with modern versions of
| them.
|
| In fact I consider Kubernetes much worse experience,
| regardless of how much hate Websphere and Co might get.
| chrisandchris wrote:
| If WebAssembly is the new k8s (in terms of complexity), I am
| going to do as much as with k8s with it: nothing.
| stavros wrote:
| 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 wrote:
| 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 wrote:
| 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.
| slingnow wrote:
| Wow, that sounds like such a simple process! It's
| definitely the "right way"!
|
| Never look back at working tech folks. That's today's
| lesson. If it works, don't just fix it -- remake it,
| rebrand it, and overcomplicate it!
| jack_riminton wrote:
| It sure does sound like the latest "next best thing"!
|
| I'll stick to Rails though thanks :)
| aenario wrote:
| I think your LAMP (Linux, Apache, MariaDB, Python) is a fancy
| new LAMP (Linux, Apache, MySQL, PHP).
| samwillis wrote:
| I'm a Django developer at hart and have been for 15 years. The
| dream I have that I hope WASM will provide is to package any
| app (Python, Ruby, Rust, Go, anything!) up into a single binary
| file that we can deploy anywhere, on any architecture (x86,
| arm). No more packaging nightmare, no more containers, just a
| single file that runs anywhere. Maybe it's wishful thinking but
| I hope it happens.
| rich_sasha wrote:
| Isn't this basically JVM?
|
| Jython is a thing.
| samwillis wrote:
| The parallels between WASM and the JVM are well known. But
| I like to think of it as WASM is building upon the
| knowledge gained from the JVM.
|
| With the JVM you had to reimplement your language to target
| it, or design a new one. WASM was planned from the start to
| be a target for existing compiler frameworks such as LLVM
| and GCC.
|
| With Jython you could not use extensions that were designed
| for CPython. With WASM you can. Take a look at Pyodide,
| they have ported most of the scientific Python stack to
| WASM, that's not possible with Jython.
|
| https://github.com/pyodide/pyodide
| pjmlp wrote:
| Just like IBM TIMI, TenDra, Amsterdam Compiler Toolkit,
| CLI.
|
| That is the thing with WebAssembly marketing, not being
| aware of bytecode formats history.
| immibis wrote:
| And yet WASM still has warts that make it impossible to
| simply transpile existing binary code onto it.
|
| Java, by the way, also isn't stopping you from storing
| all your data in one big ByteBuffer, which is how WASM
| handles memory.
| pjc50 wrote:
| Sort of - and the JVM has been a thing on webservers since
| WebSphere and Tomcat. But never quite achieved the ease of
| use. I'm not aware of a service you can just chuck a jar at
| and your webservice spins up on your (sub) domain?
|
| Jython has been a casualty of the 2 => 3 transition.
| 1337shadow wrote:
| It's PyInstaller:
| https://pyinstaller.readthedocs.io/en/stable/
|
| Or containers.
| manmal wrote:
| Containers are not architecture-agnostic. In theory they
| are not even kernel version agnostic, though Docker seems
| to work around that.
| dilyevsky wrote:
| "Containers" are basically Linux only and that means they
| can freeride off Linux's really stable userland api
| joconde wrote:
| PyInstaller is hackish though, I had to add tricks to
| setup.py by trial-and-error until I found why some config
| file or sub-module of a sub-package wasn't included when
| everything else was. It's also slow to launch, because it
| extracts the code into a temporary directory before
| importing python.dll, which then imports all the rest.
|
| Containers are fine for a server after installing the
| runtime, which is already one too many steps. There isn't a
| self-contained app format that can run without installing
| something else before starting it.
| jerryluc wrote:
| A project that's kind of an implementation of this idea:
| 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.
| kitd wrote:
| 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.
| kortex wrote:
| Yeah, I'm not seeing it, either. Kubernetes' scope is right in
| the name: control loops. K8s is basically a super powerful
| IFTTT engine: it looks at state, looks at spec, and figures out
| how to jigger the system until state matches spec. It has
| nothing a priori to do with containers, it just happened to be
| written in service of that space. You could use k8s to run your
| teakettle.
|
| It's like saying QEMU is the new Systemd; it doesn't even make
| sense, it's a category error.
| cpuguy83 wrote:
| Wasm is a compile target. You can use tools like wasmtime to
| handle isolation and linking in wasi (the system interface).
|
| In that sense, wasmtime is an alternative to runc for
| wasm/wasi.
|
| In no way is any of this a replacement for a high level tool
| like docker.
| x3ro wrote:
| 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
| almostdeadguy wrote:
| But to the point that K8s has "nothing a priori to do with
| containers" made by a sibling comment to yours, there's no
| reason for WASM to necessitate "the next Kubernetes". WASM is
| just a different workload type that could be orchestrated w/
| Kubernetes. I haven't looked too much into it, but I assume
| that's what projects like Krustlet are working on:
| https://krustlet.dev/
|
| I think that's kind of essential to understanding the role
| Kubernetes fulfills: it's an automation platform.
| kitd wrote:
| Yes, you're right. I missed that. A bit of a shame to leave
| it to the end though.
| ghostoftiber wrote:
| Whenever anyone does that they might as well simply state "I
| wrote this entire article and then realized I was wrong".
| Writing is a thinking exercise.
| dr_hooo wrote:
| Sounds more like clickbait an some [0]
|
| [0]https://en.wikipedia.org/wiki/Betteridge%27s_law_of_head
| line...
| keymone wrote:
| that is my impression too and i've honestly forced myself to
| mentally take a few steps back and consider that maybe i got
| something wrong / misinterpreted.
| lewisjoe wrote:
| You are right, and wrong. Yes we will need a kubernetes-like
| orchestrator to manage WASM instances. But what the author
| means in general is that WASM will change the game entirely,
| such that the industry's recent affair with Kubernetes will
| become irrelevant. And I agree.
| manmal wrote:
| I don't see how. Everything K8s does will still be needed.
| Switching from containers to lightweight VMs is not that big
| a step. Distribution becomes easier, but what really changes
| apart from that?
| Hokusai wrote:
| > 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 wrote:
| > 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.
| torginus wrote:
| 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.
| lewisjoe wrote:
| 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...
|
| 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.
| BlueTemplar wrote:
| But why using a browser in the first place ? It's not like your
| OS is incapable of running 100s of processes (with inter-
| process communications and all the security sophistications),
| without the additional weird abstraction of tabs and the
| browser quirks...
| KingMachiavelli wrote:
| Right... Chromium uses user namespaces as part of its own
| security model but I'm not sure how that extends to v8 or
| WASM runtimes. Where's the line between implementing a
| security model in a userspace VM and just providing an
| abstracting layer on top of OS features?
| immibis wrote:
| IDK either. It's like we have meta-platforms, or platform
| adapters. Platforms inside platforms.
| harpratap wrote:
| > 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?
| trhway wrote:
| > if WASM existed back in 2008, he wouldn't have created
| Docker!
|
| doubt it as there was JVM back then.
|
| >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.
|
| Now just add K8s on top to orchestrate it :) Somebody will just
| develop new WASM based container ...
| postalrat wrote:
| Is the JVM made to be isolated like WASM is?
| pjmlp wrote:
| Ah, but WASM is Java for the haters, so it sells much better
| at the bytecode shop.
| jason0597 wrote:
| I wonder why the Java haters chose WASM over Kotlin
| immibis wrote:
| "I wonder why the C++ haters chose ARM over Go" is a
| comparable sentence. I hope the error is clear.
| ptx wrote:
| Kotlin for WASM is in the works[1], so once that arrives
| they won't have to choose between them.
|
| [1] https://www.youtube.com/watch?v=-pqz9sKXatw
| vbezhenar wrote:
| When I'm reading about Kubernetes, it makes me tremble. Like
| you need three servers with 16 GB RAM each just for some
| management stuff.
|
| I have one server with 1 GB RAM. Can I start with that? And
| expand on more servers later if need arises.
| KronisLV wrote:
| Seconding K3s being a good option, supports most distros and
| is easy to set up in minutes: https://k3s.io/
|
| If you'd like to use a management UI instead of just the CLI,
| Portainer is also a wonderfully lightweight option:
| https://www.portainer.io/ (and also supports Docker Swarm, if
| you'd like even more lightweight container orchestration)
|
| That said, in my eyes the biggest problem with Kubernetes is
| that some distros by default reserve resources and thus
| disallow overcommit, which is fine from a stability
| perspective, but doesn't really work for overcommit
| scenarios.
|
| For example, with Docker Swarm, it's exceedingly easy to say:
| "Okay, this PostgreSQL instance can use anywhere from 0 to
| 256 MB of RAM, but no more than that" and with 1 GB of RAM i
| could easily run 8 of those instances if the average usage
| was half or less of this maximum limit - a risk that i'd
| sometimes like to take, when i know that the limits in place
| are more along the lines of controls so that the whole OS
| doesn't run into OOM errors.
|
| Of course, if you mess around with the YAML, i guess that's
| doable on some level as well.
|
| As a sidenote: most of the software that i run (Java, .NET,
| Ruby, Python, Node, Go, PHP) all is memory constrained most
| of the times, so when looking for server specs, i usually
| prioritized the memory the highest, CPU, storage and network
| speed all usually being a secondary concern. Sadly, in the
| current day and age, i'm not sure how far you could actually
| get with 1 GB or why even use container orchestration at that
| point. The smallest VPSes that i have come with 2 GB of RAM
| and even those are for smaller pages/proxies and such,
| whereas the majority have at least 4 GB (since GitLab and
| Nexus won't launch and work with much less) and my homelab
| servers have 16 GB, whereas my workstation has 24 GB at this
| point, because that's all that i can afford.
|
| Wirth's law be damned, i doubt that even OSes will work well
| with that much in the future, especially because of desktop
| software being infected with Electron and server software
| having JVM eat as much memory as you'll give it (though that
| also happens with MySQL or MariaDB). I don't care about
| "Unused RAM is wasted RAM" as much as others do, i just want
| to run more stuff on my servers and to have software that
| doesn't NEED the memory not take it.
| kastden wrote:
| I'd suggest trying out https://k3s.io/ then. Runs on pretty
| much anything and supports multiple nodes that can be added
| later. They have ripped out a lot of things you might not
| need (cloud drivers, etc). Despite that, it was easy to
| install things like storage drivers or Cilium for networking
| when I wanted that.
|
| I used k3sup to setup my cluster, but that was just for
| convenience.
| El_RIDO wrote:
| Yes, you can start with that. There is a k8s distro called
| k3s that runs fine even on 1GB Raspberry Pi 3.
|
| I have been running it on those for a while, but also on
| other SBCs. You can grow the single master by attaching one
| or more workers to it. The "pain" is mainly that you can't
| expand the single-master to a multi-master setup, so once you
| want to go beyond a single master, you have to re-install it
| all. On the other hand, with k8s you have all deployments,
| etc. in yaml files and you simply redeploy these on the new
| cluster.
|
| My remaining pain-point is persistent storage - it's simple
| to run complex setups with stateless containers or that can
| retrieve there data at initialization (i.e. a secondary name
| server that populates itself from the master at startup), but
| for classic databases I currently still have a manual step to
| import the DB dump once the service got (re)started/migrated.
|
| Sources: - https://k3s.io/ - https://www.jeffgeerling.com/blo
| g/2020/installing-k3s-kubern...
| cogman10 wrote:
| Where on earth are you getting that notion?
|
| K8s operates just fine on 1GB nodes. It's very low overhead.
|
| You can operate it on a single node cluster, but that's
| generally not recommended, not for performance reasons, but
| for redundancy.
|
| The reason larger nodes are recommended is that k8s is for
| fleets of applications. If you are only talking about a
| single service, then a k8s cluster is overkill.
|
| K8s is the cheapest way to run a fleet of microservices.
| mrweasel wrote:
| I believe you can get away with much less, but this is
| something that concerns me as well. We deal with customers
| that want Kubernetes, but the management plane uses more
| servers/VMs than is required to run their code.
|
| There is mini-Kubernetes implementation, but I don't know if
| they're any good for production.
|
| There seems to be a limit to how small you can go with
| Kubernetes in my mind, and most people never need to cross
| the line where they're large enough that Kubernetes makes
| sense. It's honestly a niche product, but right now it's
| being viewed as a catch all solution.
| guywhocodes wrote:
| Yes with 1GB you can run k3s.
| Bayart wrote:
| Yes you can, that's the point really. You can just start off
| on your own machine with something like Minikube [1] and
| deploy to GCP on a bunch of much larger nodes to see how it
| behaves. The overhead of Kubernetes itself isn't much, it's
| just a bunch of API daemons.
|
| For small scale development, plain docker/podman is better in
| my opinion.
|
| [1]: https://minikube.sigs.k8s.io/docs/start/
| immibis wrote:
| Why can't you run multiple Docker containers with inter-
| container communications and all the security sophistications
| on a single machine? You can do exactly that. I suspect you
| have different expectations from Docker and WASM, such as
| expecting to run heavy things in Docker and light things in
| WASM.
|
| Anyway, to make WASM useful as a server platform it will end up
| re-implementing the entire Linux kernel API.
| hinkley wrote:
| Doesn't Docker re-implement about 30% of the Linux kernel
| API?
| option_greek wrote:
| 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.
| Bayart wrote:
| My only real gripe with GCP is that every project is set up
| to use their premium networking tier by default.
| robertlagrant wrote:
| 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.
| marcos100 wrote:
| Yes, you can setup your own kubernetes if you want, using
| just ec2, but nobody wants to do it because it's easier to
| just pay.
|
| I think k8s actually saves you money, because it allows you
| to use your resources better.
| robertlagrant wrote:
| Yep - you can also just use a VPS or even some Raspberry
| Pis in your home.
| option_greek wrote:
| The ingress can be free with Nginx but not the inbound
| firewall rule that passes the traffic to Nginx. And
| 'coincidentally' it costs the same $ as using their load
| balancer which automatically has this rule applied.
| robertlagrant wrote:
| You're talking about a cloud provider's fees, not
| kubernetes.
| immibis wrote:
| It sounds like it's just setting up the load balancer for
| you behind the scenes? Kubernetes isn't a load balancing
| engine, to my knowledge. It just sets up containers and
| stuff.
| guywhocodes wrote:
| If there is anything nefarious in the design and rollout of
| k8s it's just to make it uncool to run something small.
|
| I've worked with it for a bunch of years now and run a
| cluster at home, but I do hate that it scales down so poorly.
| Is so much work to run a bare minimum, if not for SME-
| purposes but for local development. It's just starting to get
| acceptable.
| guywhocodes wrote:
| Docker was not the only container based system back then and we
| did have other projects for running arbitrary code in the
| browser. Were they as good as WASM? No but the browser wasn't
| as good either. Point is it's not just WASM that makes him feel
| that way today. It's pretty damn hard to roll back your mind 12
| years and then apply 12 years of innovation from the side and
| make accurate predictions of what you would have done
| differently.
|
| Just like "if we had internet in the 19th centry", it implies
| so much more.
| pjmlp wrote:
| Ironically the only WASM that is as good as Flash tooling in
| 2011, is Flash itself recompiled to WASM.
| hinkley wrote:
| I wonder if it makes sense to build up a WASM environment on a
| union filesystem (layers) as it mostly seems to in Docker.
| [deleted]
| TruthWillHurt wrote:
| WASM is like K8S in that 90% of projects don't need it.
___________________________________________________________________
(page generated 2022-01-21 23:02 UTC)