Fermyon Platform For Kubernetes Part 2: Enterprise Architectures and Patterns
Thorsten Hans & MacKenzie Adam
spin
wasm
kubernetes
webassembly
Welcome to part two of our Fermyon Platform For Kubernetes series. Last week, we introduced you to Fermyon Platform For Kubernetes and discussed the benefits that come with using the hyper-efficient platform to achieve up to 50x the density when compared to a traditional pod model.
That being said, we do need to think through what makes a workload a good fit for being modernized into a WebAssembly (Wasm) application. Let’s take a peek at some criteria to evaluate whether your application is a good fit, and then dive into some more specific workload patterns that thrive in this setup.
Workload Fit - Is Wasm Right For Me?
At its core, Fermyon Platform For Kubernetes is a tool for running Spin applications with stunning efficiency and performance on Kubernetes. Naturally, the first-order question to answer is, would my workload (or a subset of my workload) benefit from running as a Wasm application? Having had the opportunity to attend KubeCon EU this year, we can confidently say this question came up a lot on the conference floor. And for good reasons, too, the benefits of modernizing your application with Wasm are alluring:
- portability across operating systems and processing architectures without any rewrites or multi-arch builds
- cold start performance in the < 0.5 millisecond range
- application package sizes maxing out around 10 MB
- polyglot scenarios, such as the ability to compose your application using components written in different programming languages
With Spin, we work hard to deliver an excellent developer experience for writing, building, and running Wasm applications locally. However, at the time of writing this blog, there isn’t an automated migration solution available today, which means you’re looking at either greenfield applications or a rewrite of an existing application. Therefore, it’s important to consider whether your workload has the right characteristics to be run as a Wasm application.
- Is my workload event-driven? Spin applications are invoked via a trigger, similar to many Function as a Service (FaaS) offerings. If your workload is triggered by a queue (like Redis), HTTP call, or cronjob, you’re likely heading down the right path!
- Does my workload execute its task in under a minute or less? Spin applications run like jobs, completing the task before freeing up the host resources for other workloads to consume.
- Are the critical libraries and other programming language-specific dependencies I need to be supported by Wasm? Even in the past year alone, the Wasm community has made incredible advances in language support and developer tooling; however, there are still gaps that we’re working to address. It’s worthwhile to review Fermyon’s Wasm Language Support Matrix (which tracks support for compiling different languages to Wasm).
Missing something? Please let us know by opening an issue here (and tag your issue using the “wasm-languages” label).
Perhaps you have a workload that perfectly fits this criteria (such as the ZEISS Group’s order processing workload that saved 60% by migrating to SpinKube); however, let’s say you have a monolith you’d like to modernize. Your workload isn’t immediately ruled out - rewriting a small component as a Wasm application could be a great way to introduce cost savings and familiarize yourself with the technology. The relationship with Containers and Wasm isn’t an either/or conversation. These are complimentary products that can create synergy. For a more in-depth analysis, check out our comparison here.
📡 We affectionately refer to this architecture (rewriting small, event-driven components from a larger monolith) as satellites. Stay tuned for an upcoming blog post that will deep dive into this topic 🤔
If you’re curious about what the journey of rewriting an existing application to be SpinKube-compatible looks like, we highly recommend you check out Kai Walter’s, lead architect at ZEISS group, article where he shares the results of his performance and cost-saving analysis running their 10K order processing pipeline on SpinKube and Azure Kubernetes Service.
Enterprise Architectures and Patterns
Although Spin streamlines the experience of starting your Wasm journey, you may find yourself asking how one could use Spin and Wasm to implement real-world enterprise applications.
We heard questions like this a lot and created a collection of samples to illustrate how one could implement common enterprise architectures and patterns using Spin and Wasm.
https://github.com/fermyon/enterprise-architectures-and-patterns
In the following section, we’ll explore what you’ll find in the repository.
CRUD HTTP APIs
Spin is a superior framework for building serverless HTTP APIs. By leveraging SDK capabilities like the Router we can build real-world HTTP APIs with ease. The repository contains four CRUD (Create, Read, Update, Delete) implementations which illustrate how to build full-fledged HTTP CRUD APIs using either Rust, Go or JavaScript. As Spin provides different approaches for persisting data, the samples illustrate how to use SQLite, MySQL and PostgreSQL.
Command and Query Responsibility Segregation
Command and Query Responsibility Segregation (CQRS) is an architectural design pattern that separates the responsibility of handing commands (requests that mutate state) and queries (requests that read data). There are dedicated implementations of CQRS available in Rust and Go.
Publish-Subscribe
Publish-Subscribe (pub-sub) is a common messaging pattern for building distributed application architectures. The pub-sub sample, contains two distinct publishers (JavaScript & Rust) and two subscribers (Go and Rust).
Signed Webhooks
Webhooks are a common mechanism to integrate third-party applications. This sample illustrates how one could sign and verify webhook payloads. By signing and verifying webhook payloads, webhook consumers can ensure data has not been modified during transit. The Spin Apps of the Signed Webhooks sample are written in Rust and Python and use the Wasm Component Model to use a shared Wasm Component responsible for signing and verifying the signatures of webhook payloads.
Long Running Jobs over HTTP
There are situations in which you may want to perform data processing which takes longer than usual HTTP requests and could result in users receiving timeouts. By using the mqtt capabilities provided by Spin, you can move the time-consuming actions (or jobs) to a different (background) process. This sample illustrates how to create a corresponding API facade and offload time-intense compute to background workers (a Spin worker using the MQTT trigger or a native GoLang worker).
Transparent Caching
Implementing a transparent cache can reduce load from databases and increase overall application performance in distributed architectures. This sample illustrates how you can leverage a key-value store to implement transparent caching for your Spin App.
Content Negotiation
It’s a good practice to implement content negotiation when building HTTP-APIs. By implementing content negotiation you can make frontend and backend agree on format and structure of exchanged data. It enables interoperability between different systems by enabling them to communicate using various data formats, such as JSON, XML, or even HTML.
Cross-Origin Resource Sharing
Cross-Origin Resource Sharing (CORS) is a security measure in web browsers that controls access to resources from client-side code served from different domains. It’s important to implement CORS to prevent unauthorized access to sensitive data and APIs, thus enhancing the security of your HTTP APIs.
Load-Testing Spin Apps
You can use load testing to test the performance, breakpoint, and throughput of your Spin Apps. The sample shows how you can use open-source Grafana k6 to load-test your Spin Apps.
What’s next?
If any of those patterns inspired you, we highly recommend checking them out on GitHub. To see the entire collection, filter for “architecture” or “pattern” content types on Spin Up Hub.
To see a demo of Fermyon Platform for Kubernetes or discuss workload fit with the product team, reach out to us here.