WebAssembly runs in a language virtual machine that is similar in many respects to the JVM (Java’s runtime) or the CLR (.NET’s runtime). But a key difference in WebAssembly’s architecture (built, as it was, for the browser) is that by default the runtime does not trust the code that it executes.
Late last year, a hack against a prominent open source Java library rocked the software world. A vulnerability in a logging system allowed attackers to execute arbitrary commands on the host. The recent Log4j attack provides an opportunity to talk about that characteristic and see why WebAssembly is resistant to this kind of attack. But I end with a warning that WebAssembly’s security model is only as good as its runtime security, and a troubling tendency to insecurely expose underlying host facilities to WebAssembly modules could undermine WebAssembly’s security model.
In the last few years, Docker Containers have been the most popular technology on the cloud side. Now, WebAssembly is arising as a new cloud technology. How does it compare to Docker Containers? Previously, we covered what WebAssembly is, and briefly touched on Docker. In this article, we explore the similarities and differences in more detail. We conclude that each has its place, but that WebAssembly opens some enticing possibilities.
Microservices are serving us well in many ways. But in some ways, we can do better. Having learned a bit from Functions as a Service, containers, and now WebAssembly, we can rethink some of our assumptions and perhaps devise a better way for creating microservices.
In our first blog post, we talked about how we envision a new iteration of microservices. Then we introduced our CMS system, which in many ways exemplifies our approach to microservices. Last week we answered the question, How should we think about WebAssembly?, discussing why WebAssembly is a promising cloud technology. Here, we spell out the problems with microservices v1, and pave the way for a microsevices v2.
All those things are, to some degree, sensible ways of looking at WebAssembly. However, it might help to take a bird’s eye view of the technology and understand its essential properties. And from there, these other assessments will begin to make sense. Once we’ve covered the essential characteristics of WebAssembly, we’ll circle back to Fermyon’s stance that WebAssembly is the enabling technology behind the next wave of cloud compute.
Earlier this week, demos began to circulate of LibreOffice (using the QT graphical toolkit) compiled to WebAssembly and running in the browser. This comes after Thorsten Behrens of Allotropia gave an interview announcing WebAssembly support in LibreOffice . The stories trended to the top of Hacker News. And this came hot on the heels of the Fosdem session explaining WebAssembly for LibreOffice. Why all the fuss?
Fermyon is proud to introduce our new lightweight WebAssembly (Wasm) content management system (CMS): Bartholomew. As we mentioned in our first blog post, the entire Fermyon.com website is served from WebAssembly modules. In this post, we talk about Bartholomew, our CMS system.
Bartholomew offers a feature set that should be familiar to users of popular static site generators like Hugo. However, Bartholomew is not a static site generator. Built into a lightweight WebAssembly module, it processes page requests individually on demand.
Hello World! We’re Fermyon Technologies, and we are building the third wave of cloud compute with WebAssembly.
Take a look at the cloud compute landscape. Virtual Machines (VMs) are the heavyweight contender, the first big entrants into the field. But cloud compute did not stop there. Along came containers. Those of us on board in the early days believed that containers would unseat VMs and become the way compute was done in the cloud. Happily, we were wrong and not wrong. Containers were wildly successful, but they did not replace VMs. In fact, VM consumption has gone up alongside container usage.
For several years, we worked on container technologies. As part of Deis, and then DeisLabs at Microsoft, we explored the container landscape. And we are proud of the things we built and the community with whom we built them: Helm, Brigade, the Kubernetes VS Code extension, Open Service Mesh, CNAB, and others. But along the journey we discovered some of the limitations of containers. And that got us asking a new question.
Along with VMs and containers, is there a third wave of cloud compute?