Video: Fermyon Behind the Curtains
Fermyon Staff
webassembly
fermyon
In a recent interview, David Flanagan sat down with Matt Butcher and Radu Matei to learn more about where Fermyon came from, what we’re trying to do, and why we’re passionate about WebAssembly.
Matt and Radu talk about everything from where the name came from (spoiler: physics) to what we hope to achieve from the component model. Below is a textual, and slightly re-ordered, account of the interview (with some added background information and links to resources) for your convenience. We hope you get a chance to enjoy this and we look forward to keeping in touch, as you embark on building applications using Fermyon Cloud.
Fermyon Cloud
Fermyon Cloud is a hosted platform where developers can deploy their Spin applications. It is designed to be the simplest way to run WebAssembly (Wasm) microservices in the cloud. Creating a frictionless experience for developers means that the Fermyon Cloud needs to take care of every operational aspect such as creating application endpoint URLs and taking care of application logs. Also, dealing with any obligatory tasks such as resource allocation, routing, security, certificates and so forth.
Developer Experience
The Fermyon Cloud exists to create the best Wasm developer experience. It strives to achieve this by allowing the developer to do what the developer does best; write their code and decide which libraries to use. With Fermyon Cloud the developer does not need to put any thought whatsoever into what operating system or architecture to use. Simply put, Fermyon Cloud creates an environment where it should be trivial and instant for any developer to deploy an application to the cloud.
Wasm
Fermyon Cloud passes on all of the benefits of Wasm to the user, including ultra-fast startup times, language neutrality, safe sandboxed execution, performance and more. In addition, developers can communicate between Fermyon Cloud and hosted storage solutions like Redis; to achieve persistent storage for their applications.
Wasm Binaries Are the Libraries
The Wasm specification describes a binary format (how things are supposed to be executed). The Wasm Component Model is an overarching layer which describes how 2 different Wasm modules can intercommunicate i.e. share non-trivial data types between them. Over and above both of these sits the Wasm System Interface (WASI). WASI describes how you can perform I/O operations between the aforementioned different components.
Costs, Flexibility, Efficiencies and Scaling
This new approach is deliberately designed to scale down, close to zero, and then respond and scale up when incoming loads are presented. There is real potential that is being realized through the rethinking of microservices and also thinking differently about serverless computing, threading and so forth. In this new scalable cloud architecture, it is increasingly possible to hot patch parts of a large system. This has advantages over more traditional applications whose monolithic designs and deployment strategies make upgrading less flexible, more complex and slower.
Over the last decade or so the evolution has gone from deploying applications on in-house physical machines to using Virtual Machine (VM) instances and containers in the cloud. Wasm, being the next technology to progress, will not be replacing VMs or containers. On the contrary, Wasm has proven to be complementary and, as a result, is adding more value to the cloud computing space. Technologists who use these existing technologies can now embrace Wasm to go ahead and build more advanced, lower cost, highly efficient and performant technologies that scale.
How Does Wasm Change How We Build Complex Applications?
The good news, is that most existing knowledge gained during the years of implementing VMs, containers and other cloud-based infrastructure i.e. designing orchestration and building microservices will be very useful in the world of Wasm. All of the general ideas will carry over to the extent that we will engage in the thriving market of VMs, containers and their tooling. Essentially, we are adding new necessary technology (Wasm) to achieve what we want.
Quip: “ … all of your Yaml knowledge is not going to come in useful in the Wasm ecosystem …“ 😆
From a design and implementation perspective, we are rethinking microservices, when using Wasm. For example, we can have as little as 0 microservices running (when there is no load) and then scale up to tens of thousands of microservice executions immediately. This is not the case with containers. What’s interesting is this new thinking solves existing problems in a few areas. Firstly, planning: with Wasm we no longer need to plan and predict application-load requirements. Instead of choosing the number of instances we need to run, we now have a scenario where sleeping microservices are only executed upon request. For example, there isn’t even an instance of a Wasm VM running unless an actual user request is in play. Speed: upon each request, the microservice (which runs in a Wasm VM instance) reaches its first instruction in under one millisecond, this sort of performance is perfect for the web (where a few seconds is too long, and well below a user’s expectations). Cost: from a business perspective we now know that we no longer need to run more infrastructure than we need. Aside from being cheap to execute anyway, we can also save money by actively processing requests in an environment of minimalistic idle infrastructure.
Nomad Is a Great Fit
Nomad is built to be able to handle and orchestrate different types of execution contexts i.e. containers, VMs, Java Virtual Machines (JVMs) and now Wasm. From our own development and deployment experience, saying that we are pleasantly surprised with how well Nomad has worked with Wasm, would be an understatement. Perhaps joyously shocked would be a better way of describing that things are just working! All while constantly scaling up, on modest cloud resources. We are continuously seeing remarkable performance numbers.
Fermyon Cloud - Open Beta
We are interested in learning about the types of workloads that you would like to run in the cloud. We are also curious to understand what types of features you want to see in such an environment. We would be absolutely thrilled if you tried out Fermyon Cloud today. You could kick things off by using our Quickstart procedure. Your honest feedback on everything, including our documentation, would be greatly appreciated. We have a specific Fermyon Cloud feedback repository, to help with this.
We hope you enjoy the video. Thanks for reading!