Distribute and Scale

Under Construction

🚧 This page is under active renovation for wasmCloud 1.0. Some details may not be aligned with v1.0 during the alpha period. 🚧

Scaling up 📈

WebAssembly can be easily scaled due to its small size, portability, and wasmtime's ability to efficiently instantiate multiple instances of a single WebAssembly component. We leverage these aspects to make it simple to scale your applications with wasmCloud. Components only use resources when they're actively processing requests, so you can specify the number of replicas you want to run and wasmCloud will automatically scale up and down to meet demand. Let's scale up our hello world application to 50 replicas by editing wadm.yaml:

yaml

apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
  name: hello
  annotations:
    # Make sure to bump the version so wadm knows to update the application
    version: v0.0.2
    description: "wasmCloud Hello World Example"
spec:
  components:
    - name: hello
      type: component
      properties:
        image: wasmcloud.azurecr.io/hello:0.1.7
      traits:
        - type: spreadscaler
          properties:
            # Update the scale to 50
            replicas: 50

Now your hello application is ready to deploy v0.0.2 with 50 replicas, meaning it can handle up to 50 concurrent incoming HTTP requests. Just run wash app deploy wadm.yaml again, wasmCloud will be configured to automatically scale your component based on incoming load. It's a little easier to visualize this in the wasmCloud dashboard, so let's take a look at that next.

Viewing the wasmCloud dashboard

To view the wasmCloud dashboard, you'll have to launch wash with the option --nats-websocket-port 4001. Go ahead and CTRL+c or wash down to stop your previous host, and then relaunch it with the new option:

bash

wash up --nats-websocket-port 4001

What will happen to my application?

Treat wasmCloud hosts as cattle, not pets. Stopping your host will stop all of the components running on it, and wadm will look for other available hosts to reschedule your application on. As soon as you launch your new host with the --nats-websocket-port option, your application will be rescheduled on it and work just as it did before.

Then, you can launch the wasmCloud dashboard using wash ui, which will launch the dashboard on http://localhost:3030. This is a great way to visualize what is running on your host, even multiple hosts that are connected to the same NATS server.

Log files

If you encounter any problems, the host log files may contain useful error messages, and it's good to know how to find them. The tabs below, organized by how you started the wasmCloud host, show you where to find logs:

Local

By default, logs from wash up are automatically output to your terminal. If you ran the command with the --detached flag, logs can be found in ~/.wash/downloads/wasmcloud.log

Docker

Logs from hosts running in Docker, if started with our docker compose, can be found by running docker logs wasmcloud.

Hello Universe

You've now built a simple microservice with wasmCloud that uses common capabilities (handle HTTP requests, interface with a key-value store) that many cloud native applications need. So, why wasmCloud? What makes this application that you built different from similar apps on other platforms? wasmCloud is an easy-to-use platform that's quick to get started with, which is essential for a great and intuitive developer experience, and this project extends far beyond "Hello World." This page emphasizes the intention behind the design of wasmCloud, and the benefits that follow after you've built your application.

Now that your microservice is running, consider what you may have to do to actually deploy that to production in the cloud. If you're building this application in a modern language and packaging it up into a container, you may have the following hurdles to consider before you even get to the point of writing your features in the first place:

info

The only time you need to recompile your application is if you want to add new functional logic. All of the below questions don't need to be considered until after you've already built your application with wasmCloud, and can be freely changed at runtime whenever needed.

1. What CPU architecture am I going to be deploying to? Do I need to build for x86, ARM, or both?
2. What operating system am I going to be deploying to? Do I need to support more than just Linux?
3. What cloud am I going to deploy to? What if I need to deploy to multiple clouds?
4. Do I need to be able to scale multiple instances of my application? How many? How will I handle communication between instances of my application?
5. Do I need to be able to distribute my application across multiple machines? How will I handle high availability or failover?

CPU Architecture and Operating System Support

wasmCloud applications compile to WebAssembly, which is a completely platform agnostic binary format. The wasmCloud runtime itself releases binaries for Linux, Mac, Windows, x86_64, and aarch64 machines.

Cloud Support

wasmCloud applications can be deployed to many cloud, edge, bare-metal, or on-prem machines due to the portability of Wasm and broad support of operating systems and architectures by Wasmtime, our WebAssembly runtime of choice. This means that you can deploy your application to any cloud provider, or even to your own datacenter, without having to worry about the underlying infrastructure.

Scaling

Each wasmCloud component is a self-contained unit of execution. This means that you can scale your application vertically by simply running more instances of your component. The wasmCloud runtime will automatically load balance requests across all instances of your component.

Distributed Deployment

wasmCloud applications can be distributed by running multiple instances of the wasmCloud runtime. Whether you're running a single instance of the runtime on a single machine, or multiple instances of the runtime across multiple machines, the wasmCloud runtime will automatically load balance requests across all instances of your application components. You do not need to configure load balancing, service discovery, or failover requirements for your application.

Runtime and Vendor Lock-In

The WebAssembly component you built in this tutorial can be deployed to any WebAssembly runtime that supports the WASI HTTP and Key-Value store interfaces. You can take that component and run it in wasmCloud's underlying runtime wasmtime, the ByteCode Alliance's jco NodeJS runtime, or even in the browser. Additionally, because we aren't compiling in vendor-specific code, you can use any implementation to satisfy your interfaces and choose that at runtime with wasmCloud.

Getting Involved

We appreciate you taking the time to go through this tutorial and take a look at what we're passionate about building at wasmCloud. We welcome all in our Slack and we would love for you to come and engage with our community, especially if you found the tutorial and the above points exciting! We hold weekly community meetings at 1pm EST on Wednesdays, and you can find the link to join the meeting on our community calendar or just tune into the livestream on YouTube. Lastly, if you're looking to contribute to wasmCloud, all of our projects are open source on GitHub and you can refer to our CONTRIBUTING.md.