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?