A truly resilient multi-cloud platform with wasmCloud and WebAssembly

Myself and senior software engineer Aayush Attri were invited to speak at the CNCF's Kubecon North America event at the end of last year on Wasm day. 

In the presentation, we demonstrated a PoC platform leveraging WebAssembly, wasmCloud and NATS messaging to provide self-healing clusters that span clouds while remaining unaware of underlying topology and vendor-specific products.

We show how developer productivity is improved by avoiding boilerplate and building highly focused, lightweight, reliable and secure services.

This talk explores this paradigm shift and demonstrates a declarative way to deploy distributed applications on a wasmCloud lattice that spans multiple cloud providers across geographic locations.

It also shows seamless failover (and recovery) between cloud providers when there is a server outage or a network partition.

Red Badger was engaged by one of Europe's largest banks to help understand what the future state architecture should look like. Multi-cloud is a must, and resilience and portability are highly desirable.

We believe such a platform looks like what the wasmCloud folks are doing. WebAssembly actors and native capabilities are all hosted in a resilient mesh (or lattice) on a NATS substrate.

Today, you could host this on Kubernetes and manage it with GitOps.

We built a PoC platform around this technology and believe this approach is a game-changer for the finance industry and beyond.

Register for our We Love WebAssembly (outside the browser) event

Join us and our friends from Cosmonic and SingleStore as we explore the enormous potential of WebAssembly and demonstrate its capabilities for software development, universal portability and enhanced security.

Are your platforms built for the future? 

If you're interested in what you've seen and want to find out how you can take advantage for your business, we'd be happy to talk to you about the potential of this silent revolution.

Presentation transcript:

Hi everyone! — we’re really excited to be at Cloud Native — North America — Wasm DAY — 2021! It’s a real honor to be selected to talk today — and we have some really exciting stuff packed into the next 20 minutes or so!

We want to talk about the use of WebAssembly server-side and how it’s driving a revolution in platform design.

Coupled with products like wasmCloud and NATS — WebAssembly is creating a new paradigm for Cloud Native, which — as new paradigms should — eliminates entire classes of problems that we struggle with today when building distributed applications.

But before we dive into all that, let’s introduce ourselves - I’m Stuart Harris, founder and Chief Scientist at Red Badger, and this is Aayush Attri, senior software engineer at Red Badger.

We’re a London-based consultancy that’s obsessed with helping organisations streamline their ability to continuously deliver digital products and services. We’re very honoured to be here and a big thank you to CNCF for organising this event today.

As a consultancy, we’ve felt the pain — over and over again — of building microservice applications with today’s architectures. It’s not straightforward, by any stretch of the imagination.

One of our clients — one of Europe’s largest banks — engaged us recently to describe to them what a future state platform architecture could look like.

They want to prepare themselves for a world where they can easily deploy workloads, securely and reliably, across on-premise and any cloud, without having to constantly adjust network topology to suit.

This is really refreshing — that large organisations are thinking ahead like this — but this thinking is driven by their pain: from working with today’s complexity.

We’ve built a proof-of-concept to show what such a platform might look like. It’s a really cool demo, which we’ll take you through in a few minutes. First though, some background.

It seems to me as though the last decade has been characterised by a rush to the cloud. Now that we’re there (well most of us), we’re rightly worried about having all our eggs in one basket, and we’ve realised that it's still far too complicated.

It’s better than filling out a form, and sending it to the IT department, but the burden of managing infrastructure is all too real.

I think the next decade will be characterised by a rush out of the cloud.

Well not out completely, but out enough to be independent of any one provider. And out enough to make good use of the edge, on-premise and Internet of Things.

If you’re in a regulated industry, like finance or healthcare, the regulator will insist that you have a “get-out plan”. But these plans are not real — you wouldn’t be able to execute them. At least not quickly. Or cheaply. They’re really just there to satisfy the regulator.

The cost of moving everything to another provider is going to be prohibitive.

Containers, and Kubernetes, have been an eye opener for our industry. It’s the first time that there has been a standard, consistent and uniform way to deploy our applications, regardless of which cloud provider we want to use.

But we’re still locked into cloud-provider specific services — AWS is famous for the number of services it keeps introducing. And every cloud provider-specific service we use locks us in further.

Kubernetes was the first step on this ladder. But what’s the next step?

It definitely needs to be multi-cloud (or maybe I should say multi-location) and to do that it needs to sit above the HTTP TCP/IP networking stack that dominates microservice configurations today.

But multi-cloud is not really a thing. Yet. Not transparently.

The best we can do, today, is to join discrete Kubernetes clusters together in a service mesh, using point-to-point connections between cloud providers.

And we can’t yet have workloads that are truly location independent.

The next step on the ladder out of the cloud (or lets say, above the cloud), is WebAssembly, running server-side, on one of the many runtimes we have now. And probably with a platform like wasmCloud.

Running on top of NATS, on top of Kubernetes (for now), on top of Cloud.

Today, Aayush and I want to talk about how these technologies are changing the game completely.

OK, it’s demo time - Aayush is gonna blow our socks off!

<DEMO 4m 30secs - 18m 30secs>

So what did we just see? — We saw “work” being transferred transparently between cloud providers (and back again) — totally seamless failover between different geographic locations.

This is amazing! And it’s made possible by ...

WebAssembly — for lightweight portable workloads

wasmCloud — for the application runtime and...

NATS — for location independence.

I am absolutely convinced that, in the next few years (or maybe even months), server-side WebAssembly runtimes will make significant inroads into platform design, subtly influencing software architecture on the way.

Because there’s another thing happening here — microservices, that today are delineated by network boundaries, will give way to much smaller, lighter Actors, compiled to WebAssembly that talk over (potentially global) messaging backplanes.

Importantly they’ll be freed from almost all of the boilerplate code that sucks up so much of our energy today. This is already happening.

This diagram shows this evolution. On top of Kubernetes we can layer Istio — to remove boilerplate for network-related concerns, such as traffic routing and role-based access control.

We can layer Dapr — which removes boilerplate for application-related concerns, like talking to a key-value store. These help us make our services smaller and more focused.

Then we have the paradigm shift, with WebAssembly and wasmCloud. This is where our services are now more like actors, sitting above the network layer and representing our pure core.

In the future, this may go even further — hosting immutable “functions” on platforms such as the upcoming unisonCloud.

Imagine a typical microservice today — say it’s built in Rust (good choice ;)) and placed in a Docker container, say Debian buster-slim.

That’s an operating system! — which we need because we want to talk to services over HTTP, so we need a networking stack. And we want to write a log to stand out.

We also want to talk to a database, so we need to pull in all the code to do that. Now we’re quite chunky. And we need direct access to a network and routes configured to allow us to reach the database, and for our consumers to reach us.

Maybe firewalls, or at least security groups and the like. We need our team to be DevOps capable so we can manage all this stuff. And before we know it, we’ve spent a lot of time not working on our core business value.

If we visualise the Onion Architecture (or Ports and Adapters, or Hexagonal Architecture, or Clean Architecture, or whatever we want to call it), we basically need to strip away all of the outer layers and just focus on our core business logic.

We want to push the side effects to the edge, so that we can keep the core pure, and therefore simple to test. And we want to iterate on this core quickly so we can deliver real value to our customers.

Dapr allows us to do this for microservices on Kubernetes.

WasmCloud allows us to do this even more. We now have Actors that consist of our core logic, which are compiled to WebAssembly that can run literally anywhere.

We can use WebAssembly to host anything, including wasmCloud itself — but in our demo we hosted wasmCloud in a container in Kubernetes.

The application runtime is built with Elixir/OTP, leveraging years of battle-testing, and it schedules capability providers and actors.

The actors talk to capability providers through a contract — declared with Amazon’s Smithy IDL — which is protocol and language independent. The capability providers are where the side effects are.

We build them once (or use a first-party provider out of the box). They’re just like frameworks of old, but independently scalable and resilient, AND ALSO language agnostic.

So wasmCloud has this concept of actors (compiled from any language into WebAssembly) that talk to the capability providers, which can be either first- or third-party.

Actors are scheduled to run on hosts that self-form into a self-healing lattice made from a NATS backplane.

NATS is amazing! It is the key to all this. A simple, yet incredibly powerful pub/sub-based messaging infrastructure, which is itself a platform for building platforms — that sounds familiar!

Any NATS infrastructure can be used, including NGS, the global communication system from Synadia. If a wasmCloud host can see a NATS leaf node, it can join a lattice.

Hosts (or nodes) can join and leave this self-healing lattice. Hosts are just compute that can be donated from anywhere — any cloud, on-prem, any edge or IoT device, even a web browser tab — wasmCloud itself has been compiled to WebAssembly and can run in a web page.

For the first time, as far as I’m aware, we can have truly global clusters, spread across geographical locations — all because of NATS and wasmCloud.

NATS flattens the wasmCloud lattice and elevates it above the network — allowing it to be independent of network topology — no more firewalls or perimeter based security models.

But NATS is even more secure, making extensive use of public key cryptography to provide a secure, multi-tenant substrate (or backplane) on top of which we can easily build globally distributed systems.

So what does a full platform look like? In a large enterprise, you might expect a single, global, multi-tenant NATS backplane to be the ceiling for the infrastructure team and the floor for the platform team.

WasmCloud becomes the ceiling for the platform team and the floor for the application teams. It provides a great developer experience for building modern distributed applications with high velocity and a core focus on building customer value.

Thank you for listening.