[NCLUG] Some developments in Rust.

Brian Sturgill bsturgill at ataman.com
Sun May 31 19:18:17 MDT 2020


Containers and WASM programs are actually very similar. Containers use
hardware and WASM uses software to provide isolation and an abstract
interface to an OS and hardware. WASM translates to native code, but is
carefully checked to avoid things like buffer overruns, etc. WASM has an
extra layer to get to allowed access to OS and Hardware. It is therefore
slower for some types of programs.

But consider the case of small services, or micro services. Even 10
containers uses quite a chunk of a system. You could easily run 1000 under
WASM.

Admin load is much smaller too... networking with several containers over
multiple physical interfaces gets complicated fast. Such problems just
don't exist under WASM.

WASM also let's you more easily control what sorts of things the services
have access to.

One will likely see a lot of edge computing solutions using WASM. The
approach is more amenable to embedded processors.

No doubt both are needed, but WASM is welcome relief to someone that just
needs to run isolated services. In time it should be simple enough for
normal users to do it.

On Sun, May 31, 2020 at 4:55 PM Bob Proulx <bob at proulx.com> wrote:

> ...
> > The reason is interesting... modern container approaches are rather heavy
> > weight. WASM, designed to run independent programs in a single browser,
> is
> > a good lightweight alternative to a container.
>
> Is that really apples to apples?  Running server side processes in
> containers is one thing.  Distributing processes to client browsers is
> a different thing.  There are good uses for both but they are
> different things.
>
> I have been enjoying some of the educational simulations which get
> distributed locally to my browser.  That's great.  And it saves the
> load on the server.  I am the one watching the simulation unfold so
> that works great.  It is good that it is my electricity that is being
> used.
> ...
> _______________________________________________


Brian
-- 

Brian


More information about the NCLUG mailing list