Rethinking Microservices
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.
How to Think About WebAssembly (Amid the Hype)
WebAssembly (also called Wasm) is certainly the subject of much hype right now. But what is it? Is it the JavaScript Killer? Is it a new programming language for the web? Is it (as we like to say) the next wave of cloud compute? We’ve heard it called many things: a better eBPF, the alternative to RISC V, a competitor to Java (or Flash), a performance booster for browsers, a replacement for Docker.
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.
Why LibreOffice in WebAssembly is a Big Deal
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?
For us at Fermyon, we see LibreOffice’s move as a strong indicator that WebAssembly is now poised to enter the practices of mainstream developers. And while Fermyon is focused primarily on the cloud side of things, we do think that (just as with JavaScript and Node.js) both sides of the network connection will benefit from pervasive use of WebAssembly.
Introducing Bartholomew
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 is built as a Wagi application, and will run inside of Hippo or inside of Krustlet if you have the Wagi extension. At Fermyon, we run ours using Hippo deploying to a Nomad cluster.
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
Hello World! We’re Fermyon Technologies, and we are building the third wave of cloud compute with WebAssembly.
Three Waves
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?
