We provide a fully-managed PaaS to support and scale your complete multi-component Wasm applications to run and communicate from anywhere to anywhere.
We believe we are on the cusp of the next epoch of cloud, server and edge computing. Furthermore, we have seen developers move their workloads from hardware to VMs and onto containers.
Next comes WebAssembly (Wasm).
Wasm is smaller than containers, starts instantly, and removes the need to handle OS layers or instance configurations. Wasm is the future of server, cloud edge-based computing all in one.
At Cosmonic we believe that you need more than just a runtime for a server or an edge. As Docker found, just running a single component alone is not enough. Applications need to be fully-distributed, scaled and orchestrated anywhere they are running. They need robust, self-forming and healing mesh networks to provide secure and reliable communication from any datacenter, cloud or edge.
At Cosmonic we believe that, as applications have evolved, so should our approach to their component parts. In a world of tiny (but mighty), distributed applications, developers want to remove tight-coupling of business logic and non-functional requirements (like HTTP servers or key-value stores). We know developers don’t want to have to re-implement the same core components in each of their applications across a distributed mesh of services. They want to loosely-couple their applications and enable only the capabilities they need when they need them.
Sound good? We think so. We would love for you to give Cosmonic a try to see how we are fixing these challenges for the next generation of the applications.
How we make networking amazing
Networking is hard for microservices, and a lot of the time developers are investing time here hen it should just work for them. We wanted to fix that. Cosmonic is based on the CNCF Sandbox project wasmCloud that leverages the messaging broker NATS. This powers Cosmonic to provide simple and secure messaging, made for developers and operators, who want to spend more time developing modern applications and services than worrying about a distributed communication system.
This gives us a bunch of quite cool features:
- Location transparency (which in turn means we don’t need service discovery)
- Decentralized security - a NATS server can be compromised and lose zero keys
- Strong multitenancy with cryptographically secure topic import/export
- Built-in distributed key-value store
- Built-in distributed blob store
- Flexible client-programmable streams (JetStream)
The outcome of this is that it lets us provide you with a simple, self-healing mesh network, which we call your constellation. The network has a flat topology providing an isolated network that allows all of your services to communicate securely. You have full control over the ingress points into your application with Cosmonic’s wormholes (yes, we like space things!).
How can you run anywhere
We love WebAssembly outside the browser. WebAssembly offers a platform-agnostic, deny-by-default sandbox for executing code with near-native performance. In a world where applications are composed almost entirely of open source libraries, tight control over the security of third-party code is essential to prevent vulnerabilities. Using Wasm allows the developer to design applications for any platform, from the browser to the cloud to the edge, without investing countless hours in complex deployment and management strategies.
Cosmonic lets us run on any host from a Raspberry Pi, cloud VM or even embedded on a boat! Our runtime can authenticate and add any host into your constellation in moments, enabling you to run your code and connect to the services you need, from anywhere to anywhere. Cosmonic gives you a single control plane to manage and scale your applications.
Write less code using contract-driven development
Many software products operate with a capability-based model for security. Browsers ask for the capability to access your location, mobile phones ask for the capability to connect to Bluetooth devices, and your favorite SaaS provider asks for the capability to read your email address. At Cosmonic, we believe software development can be more secure and flexible by embracing this capability-based model during the development of applications.
Regular Wasm modules operate in a completely isolated sandbox, with no access to the operating system, I/O, networking, etc. They can take numbers in and give numbers out. In functional programming circles, we might call this type of code "pure" because it produces no side effects. But how are we supposed to write any meaningful code after implementing the add function? We use abstractions called interfaces.
These interfaces let us define the capabilities we want to use when we want to use them (just like you can in mobile phones for Bluetooth). They give our code access to things like key-value stores, HTTP servers, HTTP clients, message brokers, and much more, at runtime rather than at compile time. By decoupling capabilities from your code, we can swap them out at runtime if we want, removing hard dependencies on services and avoiding vendor lock-in.
This means we don’t need to re-write everything every time; we can simply rely on our contracts to provide what we need 🎉
Leveling it all up with components
The WebAssembly (Wasm) Component Model is the realization of a vision of a software ecosystem that is not just based around a portable unit of compute, but something entirely new – composable, interoperable, and platform-virtualizable Wasm modules.
Components let us snap together pieces of code that communicate via interfaces (in our contract driven development). A component doesn't have a compile-time dependency on the actual implementation of another component, it only knows how to communicate across the contract boundary. More importantly, the fulfillment of that contract can be either another component or the host itself.
The big thing that comes with components, beyond just our contract driven development, is that they are language agnostic. When we want to reuse a library, your Rust developer colleague is only too happy to share their library, but Rustaceans code in Rust so their link sends us to a crate. What’s the solution? With components everything just builds to a Wasm module removing the language dependency, so whether your components are in JavaScript, Rust or Go, they can all be used as components.
We believe components make the promises of Wasm real.
One manifest to rule them all (well OAM at least..)
We did it! We avoided introducing another standard!!
Rather than creating our own manifest for defining applications, we looked at what is out there and already great. That is why we settled on the Open Application Model (OAM). Focused on application rather than container or orchestrator, the Open Application Model [OAM] brings modular, extensible and portable design for modeling application deployment with higher level, yet consistent, APIs.
This is the key to enable simple, yet robust, application delivery using declarative deployments that can be run by a developer locally or shipped to production using your CI/CD system.