The Python Podcast.__init__

Share on social media:

[00:00:14] Unknown:

Hello, and welcome to podcast dot in it, the podcast about Python and the people who make it great. When you're ready to launch your next app or want to try a project you hear about on the show, you'll need somewhere to deploy it. So check out our friends over at Linode.   With their managed Kubernetes platform, it's easy to get started with the next generation of deployment and scaling powered by the battle tested Linode platform,   including simple pricing, node balancers, 40 gigabit networking, and dedicated CPU and GPU instances.   And now you can launch a managed MySQL, Postgres, or Mongo database cluster in minutes to keep your critical data safe with automated backups and failover.  

Go to python podcast.com/linode   today to get a $100 credit to try out their new database service. And don't forget to thank them for their continued support   of this show. Need to automate your Python code in the cloud? Want to avoid the hassle of setting up and maintaining infrastructure?   Shipyard is the premier orchestration platform built to help you quickly launch, monitor, and share Python workflows in a matter of minutes with 0 changes to your code. Shipyard provides powerful features like webhooks, error handling, monitoring, automatic containerization,   syncing with GitHub, and more. Plus, it comes with over 70 open source low code templates to help you quickly build solutions with the tools you already use.  

Go to python podcast.com/shipyard   today to get started automating with a free developer plan. Your host as usual is Tobias Macy. And today, I'm interviewing Matt Butcher about Fermion and the impact of WebAssembly on software architecture and deployment across language boundaries. So, Matt, could you start by introducing yourself?  

[00:01:43] Unknown:

Yeah. I'm Matt Butcher. I still have a hard time saying it, but I'm the CEO of Fermion. I've been a software developer for   decades. I don't wanna say how many, but these days, started a new company in November devoted to WebAssembly on the cloud, and that's what we've been working studiously on since then. And do you remember how you first got introduced to Python?   I do. So it was right around   the big.com   crash,   2001. It hit me in 2001.   Young, very, very young. I had just bought my first house. The market sort of tanked.   Everything went downhill fast. I didn't know what I was doing.  

I had to quickly   spike a sail on it on the house, move back in with my parents, and I was just   depressed.   I had been doing Java development up until then. Back in that time, Java was really cool and trendy. I'd been doing Java development. Had been doing Perl before that. I remember sitting around at my parents' house just with no passion left. Right? I'm just kind of   depressed.   And I thought, okay. I'm gonna just gonna kinda look around and see if there's anything new out there. It was like 6 in the morning, 1 morning, and I was reading slashdot.   That dates me right there. I was reading slashdot, and there was an article about Python, and I thought, oh, this Python thing   seems to be getting kinda popular.  

I should go look at it.   Before I realized it, hours had gone by, and I had been reading through the Python documents and writing some code. And after coming from Java and that kind of highly structured static type system,   everything just got refreshing and fun   and   really got me going again and and kind of reignited my passion for development. I I look back at that time and think in a way, that was 1 of those moments where if I hadn't found something to kind of reignite that passion, I wonder if I would have even stayed in technology. The job I had   at that time, you know, after losing my programming job and stuff like that, was doing, like, data entry. And I think if if nothing had rekindled that passion there, my life could have steered off in a very different direction. So in a way, you know,   Python, I credit with keeping me interested in technology, opening my mind to some different ways of doing programming, and really kinda   getting me going again.  



[00:03:55] Unknown:

And being in data entry, I can definitely imagine where Python would have been very useful to help, you know, streamline your job and say, no. I spent 8 hours doing this, but 6 of that, I was at the beach.  

[00:04:06] Unknown:

Yeah.   I was I was the only guy on that team who used VI as an editor to clean up stuff while I was doing data entry. Everybody else is like,   you just use Word. I'm like, I don't know how to use Word. I only know how to use VI.  

[00:04:21] Unknown:

I don't wanna touch the mouse. That slows me down.  

[00:04:24] Unknown:

Yeah. I mean, think of the microseconds I'm saving by not having to move my hand.   Exactly.  

[00:04:30] Unknown:

And so   from that time frame to where we are now with WebAssembly   and all of these new deployment methodologies and architectural patterns and   software eating the world.   It's definitely a very interesting time going from the year 20, 021, 001   to 2022.   And with WebAssembly   being sort of the hot new thing or 1 of the hot new things at least, I'm wondering for anybody who isn't familiar with what it is, can you give your elevator pitch for why it matters and why you're focusing your energy on investing in this ecosystem?  

[00:05:04] Unknown:

I think it was   probably around this time of year in 2015, kinda late summer, that   the Mozilla blog announced WebAssembly   as a kind of   group effort to build a runtime   for the browser and a byte code format for the browser that would allow   a variety of languages to be compiled to this bytecode format and then executed in the browser. So in a way, you know, kind of the original vision behind WebAssembly   was to to allow developers to use a language other than JavaScript and pick a language that made the most sense for the problem they were trying to solve. By design, it was designed to interoperate really well with JavaScript.   And so, you know, I spent a good 4, 5 years gaining traction in the browser world, and now all major browsers support it. But it wasn't until fairly recently   that people started looking at it and saying, actually, as a stand alone technology, I think WebAssembly is very promising. So you have begun now to see people move with that technology, take it out of the browser, and start doing some really interesting things with it.  



[00:06:05] Unknown:

As far as the support for Python in the WebAssembly ecosystem, I know it's not the most well supported language, but I also know that there has been some movement on that. And I'm wondering if you can give a summary of   the utility of Python in the WebAssembly ecosystem  

[00:06:22] Unknown:

and maybe how it compares with some of the other options that are out there. I am really excited about the language ecosystem as a whole for WebAssembly because at first,   we saw only a couple of languages really get ported right away. C was the target language to begin with. C and c plus plus moved fairly quickly.   Rust, which was, you know, also born out of Mozilla,   has, for a long time, had very, very, very good support for WebAssembly.   And then there were a number of other languages that started moving in that direction, but maybe a little more slowly and at measured pace. I think everybody was kind of waiting to see whether or not the runtime took off because it's a fairly major deal to port the language to a new byte code format.   And then sort of a couple of years ago, it seemed like that watershed moment was reached, and we started seeing not only   languages getting moved over quite rapidly, but also   new languages evolving that are directly WebAssembly related languages like AssemblyScript and Grain. So it's been really exciting for since about 2018 to the present, just watching the waterfall. Right? Python and Ruby are the 2 that I'm super excited about because the core language communities of both have kinda picked up WebAssembly   as a target and have over just like a 6 6 month, 8 month period at this point, just kinda slammed the foot down on the accelerator.  

So CPython's   WebAssembly support is very rapidly evolving. There's another community project run by SingleStore, which is a database company that uses WebAssembly   for user defined functions inside their database.   They also have a different shimming approach to doing Python inside of WebAssembly. So we've got basically 2 good choices to choose from at this point.   Both are still evolving.   In particular, the WASI support, the WebAssembly system interface support is evolving. So,   whereas the browser support is   pretty well locked in, the support for command line and cloud services and things like that, with CPython is just a little bit farther behind and very rapidly catching up.  

At Fermion, we have a language guide on our website,   and it's my pet project. It's my favorite thing to work on, and we've been kinda tracking very closely each incremental release of various runtimes and what they're supporting, and CPython's coming along quite quickly.  

[00:08:38] Unknown:

And I'm curious if you have any sense of the impact that things like the py o 3 bindings for Python support with Rust, but specific more specifically, the PyOxidizer   project of being able to   wrap   a Python   binary or a Python project in a sort of Rust format, how that has impacted the ability of being able to maybe piggyback on the Rust support for WebAssembly.  

[00:09:04] Unknown:

Yeah. I'm curious to see how some of these work out. Rust has really gained huge traction as a system programming language and, consequently,   a language to write run times for other languages.   And and we've seen it not just with Python, but with Ruby, and there's a Ruby and Rust   implementation coming along and other languages as well.   I think that those will kind of play out to be interesting projects, but I really think that   very likely, it'll be the core projects themselves that end up producing the most reliable run times and in part because that's where the heaviest concentration of expertise is.  

[00:09:41] Unknown:

In terms of what you're doing at Fermion,   can you give a bit of an overview about what you're building and some of the story behind how that came to be and why you wanted to days.   I  

[00:09:57] Unknown:

was a Drupal developer for a period of time and was days. I was a Drupal developer for a period of time and was kind of burning out of content management systems and wanted to get into something new. I joined HP Cloud right sort of at the big ascension point of the public cloud when everybody was doing public cloud and OpenStack had just sort of hit the scene and everybody was interested in that.   And I started as a Drupal developer and used that as an opportunity to sort of do 1 of those career transformations where I started learning more and more and more about virtual machines and switching over there, and really just absolutely fell in love with cloud technology. The way that it just, you know, fundamentally altered infrastructure   and the way we thought about deployment   and the way we thought about   the relationship between a piece of hardware and a piece of software. All that stuff was changing, and I was just absolutely loving it. Couldn't get enough of it. As I got going there, you know, branched out, worked on OpenStack development,   and then HP Cloud kind of peaked and then started to, you know, dissolve a little bit, and I thought,   oh, alright. Well, time to move along. Left and joined a startup that was doing IoT that I thought would have nothing to do with cloud services. Once more, kind of ended up this time in the container ecosystem,   then moved from there to Google, then left Google and went to a small startup in Boulder called DAIS. And   DAIS was just 100% in on the container ecosystem.  

And at the time, I was thinking, oh, well, containers are just gonna there's there's nobody's gonna even use virtual machines anymore. Right? The cloud architecture just fundamentally changed at this point. And so I just dove all in, worked on container technologies, worked on early, early Kubernetes,   worked this package manager for Kubernetes called Helm, and just really kind of steeped myself in the ecosystem.   And at dais, we kind of built up a team that was working on all these open source projects.   Along comes Microsoft and acquires DAIS,   and   we all got moved along into Azure.  

And this was like 1 of those sort of watershed   moments where   all of a sudden you see behind the curtain and you go,   oh, wow. All along, my viewpoint has been just way too simple.   And I saw that there was no 0 sum game between virtual machines and containers. They weren't really competing in any sense. They were lively,   thriving environments for both the usage on virtual machines was rising just as fast as the usage on containers, still is that way to this day,   and that changed my mindset.   And the group of developers that came over from day, as about half went on and built AKS, the other half became our open source team. And we went, okay. Well, with this new mindset, let's figure out what problems are out there to solve, and let's just go solve them. So we worked on container stuff. We worked on a bunch of Kubernetes stuff, but all along, we were keeping track of the problems we couldn't figure out how to solve.   So, ultra fast startup times was 1 that we just couldn't solve. Containers take seconds. Virtual machines take minutes. We were like, how do we get this down to sub millisecond?  

Cross platform and cross architecture has always been kind of a difficult situation for containers. You end up having to build multiple   copies of the same container,   often changing the Dockerfile and other artifacts like that just to get the libraries in there that you need in order to support, say, Arm or Windows or Linux, and the matrix kept getting more and more complicated, so we, you know, dropped that 1 on the list. And we just kept accumulating things on this list,   And at 1 point, we all got together. We were hanging out in an on-site after a day of long planning meetings, just kind of unwinding,   and we started talking about the list and going, well, what technologies out there   might check off some of these items on the list?  

We're unwinding. We're kind of bantering. Somebody says, well, what about web assembly? And I went,   isn't that a browser thing? He goes, hear me out. Hear me out. What if we took the WebAssembly runtime out of the browser   and put it in the cloud? And then we could get all the benefits of the browser. You know, the browser is designed with multi language well, WebAssembly itself was designed with multi language. Browser   is designed to handle multiple architectures, multiple OSes.   Nobody wants to wait for a web page to load, so speed is always forefront of everybody's mind. And as we start talking about this and he keeps enumerating these things, we're going, yeah. Yeah. That would be interesting.   So, you know, this is at Microsoft   late 2018.  

So we took our Fridays, and we started doing research on Fridays and playing around with things. That went on for a while. We had a lot of not very great experiments.   Come 2020, COVID hit, everybody was depressed, looking for something to work on, and we just all of a sudden, WebAssembly Fridays became WebAssembly Thursdays Fridays, then WebAssembly Wednesdays, Thursdays, and Fridays.   And we just kept diving into this technology, and the farther we got, the more enticing it got. And so by the end,   we started going, okay. Well, we've got, like, a Kubernetes runtime for web assembly now. We've got we built all these things, but we still think there's more potential.  

And that was about the time when we said, okay. It's time to leave kind of the constraints of Microsoft, go out, and really start on building the thing that we think is gonna be, you know, it's kind of the next wave of cloud computing, the next step in compute beyond virtual machines and containers.  

[00:15:12] Unknown:

There's definitely been a lot of movement   of WebAssembly   as a deployment target with different contexts. So   there are different CDNs that are using that as their edge compute target where you can, say, package up your function. We'll deploy it to our edge locations. You can run compute on the edge so that you don't have to wait for it to go back to a centralized server. There are projects like Red Panda, which is a Kafka alternative that has support for deploying WASM binaries for being able to do inline transformations of data as it's traversing the different topics in your Red Panda cluster.   There are numerous other ones that I won't bother mentioning.  

I'm wondering if you can just talk to   the overall state of the ecosystem for   WebAssembly as this deployment target beyond the browser and some of the   specific capabilities that you're targeting at Fermion for being able   to allow application developers to use this as their   basis for how to structure their applications?  

[00:16:14] Unknown:

Yeah. I think that what we're seeing is sort of 3,   you know, broad categories of use case for WebAssembly. The browser, of course, is always gonna be the first 1 that comes to mind because that was the 1 it was designed for.   And there, the role of WebAssembly is really evolving into   not necessarily replacing JavaScript in any way, shape, or form, but augmenting JavaScript for specialized tasks.   Adobe and Figma are good examples where   WebAssembly   in those contexts is used to allow developers to write highly optimized code in a language that is very good for said code and then link them back into JavaScript.   And I think that's always gonna kinda be the first category for WebAssembly.  

The second category is, as 1 of my friends remarked a couple of years ago, he said, you know, WebAssembly is the last plug in technology anybody's gonna need to learn.   Now I've been in computing long enough to know that there is no last of anything. Right? Somebody will always come up with something else that's better. But his core intuition, I think, is right in that a huge amount of WebAssembly's   value can come from using   WebAssembly   runtimes as an alternative to kind of the way we've been doing plug ins over the last several years, if not longer.   For example, you know, it was popular for a while to embed a Lua engine inside of an application and use that to write plug ins, and and, of course, that's only 1 of many examples. Right? But WebAssembly   provides   a way to drop a sort of language agnostic runtime   into   a host environment.  

And then because of the way the runtime is designed, it makes it possible for the host runtime to expose functions very easily into the WebAssembly   module.   And I think you see that with, like, Envoy proxy is my favorite example because I think they really knocked it out of the park. Proxying is a hard, hard job, and building an extension mechanism for a proxy is a hard, hard job. Plus, you're largely appealing to system engineers who are not gonna wanna use, you know, a super high level language   and who are not necessarily gonna wanna learn a new language in order to write their plug ins. So Envoy kinda develops this system where they can expose a lot of low level features into a WebAssembly runtime   and then allow plug in authors to really build whatever tickles their fancy. And they as a consequence, you know, they've had a very robust ecosystem developed around those plug ins. I think we'll see that model kind of play out everywhere. Then the third 1 is kind of the cloud side. I think you see this in Edge. Fermion is building it for public cloud style.  

And I think there,   what we're hoping to accomplish is that the isolation and security model for WebAssembly   is as strong, if not stronger, as containers and, you know, coming close to the strength level of virtual machines.   Consequently,   WebAssembly provides a safe environment   for a host to execute   what is essentially untrusted guest code. Right? Nobody audits every virtual machine that gets uploaded to Amazon. Nobody audits every container that gets uploaded into a Kubernetes cluster.   The assumption is that   the security model of the compute runtime will be sufficient to prevent   an attack from the guest code into the host. And WebAssembly   falls into that same pattern, has been designed from the ground up to fall into that same pattern,   and, consequently, it makes a good cloud runtime.  

So you see both Cloudflare and Fastly, you know, 2 of the most innovative   edge companies   around   have both already embraced WebAssembly and are doing edge compute with WebAssembly. In fact, Luke Wagner, who wrote WebAssembly,   works at Fastly. They have most of the core WebAssembly team now at Fastly.   That I think speaks volumes about this kind of third   area of cloud computing where WebAssembly can really kind of fit in, not because it's augmenting an existing program, which is what a plug in does, but because it enables web developers and microservice developers and machine learning developers   to build applications that can run-in   hosted   cloud runtimes.  



[00:20:15] Unknown:

1 of the things that I'm curious about   when running in a WebAssembly environment   is what types of constraints are being imposed beyond   what is the case for a container or a virtual machine environment, specifically thinking in terms of   things like file system access,   being able to support threading or multiprocess,   what types of constraints are imposed in terms of the   libraries or extension modules that you're able to incorporate into the code that you're writing.   And then as a secondary piece of that, the types of architectural   patterns that are   either encouraged or mandated   because of the ways that the application is compiled and deployed in that environment?  



[00:21:02] Unknown:

3 big things to unpack there. The first, with the security model,   capabilities based security is sort of built into the core of the WebAssembly   way of doing things. So in a capabilities based model,   the host tells the guest module what it's allowed to do   and exposes those kinds of features inside,   and then the host can turn on and off various features of that capability. So file system is a great example. Right?   Fundamental concept that if we can't do it, then the cloud computing is gonna be really, really hard.   But you don't wanna just give an application free rein over a file system. So the way that, say, Docker solves this problem is Docker says, okay. Well, I'm gonna   allocate a special file system that the container can access that is separated from the file system of the rest of the host. The way that WebAssembly handles this is saying, okay. So through WASI, the WebAssembly system interface,   we will give the guest module   the API bindings that make it appear that it's doing file operations. Yeah. Right? It can list the things in a directory. It can open a file. It can read and write that file, seek through the file, what whatnot. Right?  

But we leave it up to the host to determine what's actually happening there, and the host can do a number of things. The host can say,   sorry. Anytime you try and do any of those, you're gonna get a file system error. Or it can say, we're gonna bind a local file system or a chunk of a local file system into the web Assembly runtime, and we'll be able to manipulate local files. Or it can say, you know, all the way to the extreme of saying, yeah. Sure. Here's the thing that looks like a file system. Knock yourself out. In reality, it's just a chunk of memory or, you know, an interface to an object storage system sitting somewhere. And that capabilities model makes it possible for us as developers writing   applications in WebAssembly   to use the tools we're comfortable with. We use our regular old file operations in any language we want.  

While it gives the host runtime and the DevOps team running that the ability to say, okay. Well,   we don't trust guest modules, so we're gonna lock them down into this particular pattern, or we don't actually have any notion of file system on our service at all, so we're just gonna give errors. Basically,   fit the solution to the problem.   And I think that's really exciting and a good way of doing things. And what we're seeing with WASI, the WebAssembly System Interface, is that each new API that gets added   allows these kinds of toggles and switches   so that the author of the host runtime has a lot of freedom to do what they think is best. So that's 1. 2nd 1,   WebAssembly is not totally done. Right? Gotta be totally honest about the state of WebAssembly.  

The core model is done, and there are a whole bunch of extensions that are floating around, including,   you know, threading   and garbage collection for languages that would prefer to take advantage of a native garbage collector instead of implementing their own inside of WebAssembly,   and a host of others.   Networking in the WebAssembly system interface group is another 1, and each of those specifications   is sort of churning its way through the standards process.   So, you know, because of that,   there are features that just currently don't exist. Threading doesn't happen in WebAssembly   yet. There are a couple of proposals. I have a high amount of faith because I'm an optimist that it won't be too long until we start seeing those land in various run times.  

But there is a sense in which Fermion, you know, jumped in very early in the process and said, you know, it's more important to us to dive in now and build what we can and move a lot of these standards and things along to the best of our abilities along with Mozilla, Intel, you know, Amazon, whole bunch of other start ups, stuff like that, than to wait until after this is all done and miss the opportunity. Right? But we are early, and we know that. And, consequently,   there are certain things you just aren't gonna be able to do as efficiently in WebAssembly now, though in a year or year and a half,   that that list is gonna be very small, I think. So those 2 things really lead us into the 3rd. So if we're still at a point where things like threading aren't done and aren't part of the standard WebAssembly run times, then we need to think hard about what kinds of applications we wanna build with WebAssembly today   and and how we're gonna architect those. And you mentioned programming models and that's this, I think, is exactly where we wanna go with that. Right?  

What are good development models that we can use   that will not require threading in order to do big meaningful tasks,   and that will be able to work as we're still waiting for a few of these other kinds of extensions and capabilities to be completed.   And when we looked around and kinda asked ourselves that question,   1 of the things that kinda cropped up was that as we've talked to developers about   Lambda and some of these other ways of doing compute functions as a service, as a sort of general category,   some people just call this simply serverless,   what we were hearing from developers is that they liked the model.  

The idea of diving in straight into the business logic and just tackling the problem and not having to worry about standing up a web server first and configuring TLS first and all of that, that was a compelling thing. And furthermore, the the microservice architecture was a compelling thing, but that a lot of the tooling and paradigms kinda got in the way. With things like Lambda, people would say, the thing is, you know, I don't wanna be locked into 1 particular vendor, or I found it really, really hard to debug once my application was more complicated than a few hundred lines or a couple of different Lambda functions. And so we looked at that and went, okay. Alright.   Anytime you hear this from developers, this is a good thing. When they tell you what they like, then you say, okay. Alright. So all I have to do is figure out a good way to make this experience better.  

WebAssembly really fits this model extraordinarily   well   because we can   design for very small modules. Right? Which means they're very easy to move. They're very fast to start up, and   we can handle a lot of the external stuff, setting up the HTTP socket. So let's just talk for very quickly about an HTTP request and response. We can do this with all kinds of different things like queues in Kafka or cloud events or things like that, but let's talk just about HTTP.   So request comes in, and, you know, the web server has an open socket, you know, creates a new socket, you know, sends the data over to the processor. The processor does all this stuff, you know. And in a typical microservice, you're either writing all that code yourself or you're starting with a fairly large framework, like Django or something like that. Right? What if we kind of   focused in on just the request response handling piece of that and said, okay. The entry point to the application is I get a request, I send a response, and we move routing out of that, we move HTTP out of that, we move TLS out of that, and the host runtime handles all of that stuff. Then it starts to feel a little more like a function as a service style thing. And, you know, from the first line of code you're writing, you're saying, okay. I've got the data I expected from the user. Now, how do I work with that data?  

And then my response is just what I wanna send back to the user.   That model really kinda seems to resonate with people who have liked Lambda, but it also works very well with the WebAssembly model.   So   what we've seen is we've experimented with this is that, first of all, it makes it nice and easy to do language new neutral things. Right? Because there's a fairly small number of problems we need to solve for people. Get the request in, be able to take a response object back out and marshal it and send it back over HTTP.   And and what we've also noticed is then building microservices becomes very, very elegant and a lot of fun. Built this game called Finicky Whiskers. It's at finickywhiskers.com.  

And, basically, it shows off, like, a 7 microservice game about feeding your cat. And the microservices,   I mean, they're averaging, like, 40 or 50 lines of code   in this game because   all of the boilerplate's really been done for us. Right? So it's just a matter of handling particular logic in the game, and it works with Redis, and it's like taking messages from the web browser, sending them to Redis. Another web Assembly module is listening on a Redis channel, and it's handling those and sending information back to keep a scoreboard tallied up. It's just kind of a fun way to kinda explore what a microservice model based on functions as a service would look like. And I really feel like on the Cloud side and you'll see very similar trends in Cloudflare's latest announcement. Cloudflare   actually used this almost identical model to what we started with in their new WebAssembly WASI based service   because it works really well and because it enables developers to get the job done really fast without having to worry about a lot of boilerplate. So what I hear when I hear, like, Cloudflare is doing the same thing we are, is, you know, a strong validation that this particular model is resonating with developers and is really making sense for WebAssembly.  

So until we have threading, I think this stuff will work. Once we have threading,   I think, you know, once again, building fairly large multithreaded applications will be a thing that can be done in WebAssembly.   I'm actually kind of thinking that   it won't be the rule. It'll be the exception. I think this idea of being able to run small executable chunks is gonna end up being very compelling long term.  

[00:29:56] Unknown:

There   are lots of interesting things that I could imagine building to simplify or support the different architectural   patterns and paradigms that you would want to build in this, you know, truly microservice   world where, for for instance, because you don't have threading and multiprocessing, you wanna be able to have cooperative multitasking.   So you wanna be able to have things like transparent queue interfaces for message passing between these different actors and, you know, being able to have support for the actor model where this is similar to what Erlang will do. But rather than   throwing out all these ideas and suppositions,   why don't you tell me a bit about what it is that you're actually building it for me on to make this a pleasant experience for developers who are using   WASM as a build target and want to be able to actually build these services that are fast to start up, easy to manage, easy to debug.  

And then maybe as part of that, also talking about   what the role of these types of applications and services is in this broader context of cloud compute where we do still have containers and VMs and   when you want to write for WASM as your target and when you want to use it as a supplemental service or capability   on top of your existing VM or   containerized environment?  

[00:31:11] Unknown:

Yeah. So Fermion is building a couple of big things. The first is tooling for developers. The second is a host runtime where applications can be executed. So   step 1 for us, you know, for any good technology,   particularly a developer oriented technology, if you can't tell a really compelling developer   story,   nobody's gonna use it. Right? I think the Docker really underscored this very well because Docker understood that in order to get developers to use it, they needed a very simple way of executing   things things in containers, and they built a Dockerfile, and they built a really easy to use Docker CLI.   And, of course, since then, it's gotten more complex as more tooling came in. But if we rewind back to 2015,   the tooling that they were producing was developer oriented and was just absolutely stellar. And we looked at that and said, you know, for   WebAssembly,   we should have an advantage here because WebAssembly is innately sort of a developer oriented technology. It's a compile target. So, let's build a system that's gonna be delightful and fun to use for a developer.  

So, that tool is called SPIN,   and SPIN makes it easy to create new projects in a variety of different languages and then to compile and execute those, you know, locally to get what we always call the inner loop developer experience. Right? When your focus is on churning out code   and writing, testing, debugging,   and validating,   that's inner loop. Right? And so you're working hard on doing the day job is the way I like to think about it. And to me,   a tool that is strong in that particular area is gonna be very enticing to to developers. Right? Or at least it's enticing to me, and I think I'm kind of the average developer, maybe slightly subaverage.   And that's what we wanna build with SPIN. And it's focused on building microservices,   web applications, and, really, we're sort of branching out a little bit into machine learning at this point because those are 3 workloads that work very well with WebAssembly.  

The runtime profile is very well understood   and can be and the work can be divided into small chunks. So with a microservice, we understand because of the way the pattern works, the back end needs to be able to do this over here, that over there, and we start naturally kind of breaking down 1 large   job into a variety of discrete tasks. Web assembly works very, very well in that set of constraints. Web applications and machine learning really work very similarly in my mind.   So the second tool then is, well, once I've built something, I need a place to deploy it. Fermion, the platform,   is a full platform for executing these kinds of applications that you build with SPIN.  

And as a bunch of ex Kubernetes developers, right, most of the core engineering team had worked on Kubernetes as a day job for a while. We understood very well what it takes to spread loadout across multiple nodes in a cluster and how to operate a cluster, but we were getting frustrated with the complexity of Kubernetes.   So we wanted that same experience, but we wanted it for WebAssembly, and we wanted it to operate very, very fast and not require a lot of YAML and a lot of startup time and a lot of waiting around for health checks.   And so we started looking around after building Crestlet, which was a a WebAssembly runtime that ran inside of Kubernetes. We Gotta go back to the drawing board. We need to find a different way of orchestrating.  

And, you know, as every developer, we talked about building our own, but decided that was a lot of work and probably not what we should be focusing on.   And, you know, I remembered a talk I had heard years ago when HashiCorp introduced their Nomad orchestrator and how they were able to orchestrate Java VMs. And I thought, well, if you can orchestrate a Java VM, you can orchestrate a WebAssembly   virtual machine because they're similar in many ways, but the WebAssembly 1 is actually far more modest as far as what it requires.   So after spending 7 months building Kreslient, we decided to give Nomad a try, and in 2 days, had already surpassed the feature set we had with Kreslient,   and that just absolutely won us over. So the Fermion platform is powered by NoMAD as its orchestration service. So I'm writing an application with spin. I write an HTTP, you know, hello, world y kind of thing. I type in spin build, it builds the application.  

I type in spin deploy, and it pushes that application   out into Fermion.   And what happens is the application gets packaged   and versioned,   and there's a web interface you can go in and, you know, take a look at how your package adds some environment variables or whatever, but it gets deployed out into a nomad scheduler that's gonna schedule it on your data plane to whatever nodes seem to be. Well, actually, in our case anymore, we've gotten to the point where we just deploy the WebAssembly module everywhere.   Because WebAssembly is so cheap, we don't have to keep it running all the time. We can shut it down by default,   and then as requests come in, the load balancer can say, okay. I'm gonna direct this load over to node 1. I'm gonna direct this node load over to node 2, and then we can pretty much instantly start up the WebAssembly service and execute it to completion and shut it down. So to contrast that with the model you see with Kubernetes and and sort of old style microservices,   if you want to run a web application in Kubernetes using containers,   what you tend to do is you build a full microservice that's an HTTP server all the way up through your business logic,   and then you package it up in a Docker container, you ship it off to Kubernetes,   and tell Kubernetes I need at least 3 instances of this to run because I need to make sure if 1 fails or if a node goes out, then that can be redirected. And if we hit a big load, then we've got at least 3 things to take care of that load. You know? If you trend on Hacker News, right, you've got at least enough to handle that load. Consequently, you're paying for   3 instances of your containers to run 100%   of the time, regardless of what the circumstances of the cluster and traffic are like. The way we built things with Fermion   is that by default,   none of your applications are up and running until requests come in. And then as requests come in, the runtime will start up brand new instance of your application,   and then hand it the request, fetch the response, send it back to the client, and then shut your application down. So at times when you have no load, you're scaled to 0. At times when, you know, you're trending   on Reddit or something,   you may have at any given time 100 or thousands of individual instances of your web service up and running.  

Fermion's   own website   runs on this same platform, and so we watch it and analyze what it looks like when, you know, there's no load versus when there's lots of load. And it's fascinating to see that the amount of throughput that we can handle is just orders of magnitude higher than what we used to be able to achieve on Kubernetes because we can what we call under provision, essentially. We can load more things into our cluster than we could technically run if they were all being accessed at the same time because we know they won't all be accessed at the same time.   And so, consequently,   we run the Fermion website and finicky whiskers and things like that on AWS   3 AWS T2 small instances.  

We couldn't even start Kubernetes clusters without going at least 2 node sizes up from there. So what we're excited about this is that it'll drive cost down. It drives energy efficiency way up, and it makes it actually easier to manage the cluster because we don't have to keep scaling out with the frequency we would have to scale out with Kubernetes and other things. So we can run, you know, tens of thousands of instances   in the same size pool that we would only be able to run dozens of instances in if we were using Kubernetes and containers as a technology.   That actually gets us though to the other half of your question,   which is then how do these things interact with other technologies?  

Because   going back to it, like, the first part where we were talking and I said, you know, we got to the point where we said there are no 0 sum games.   It doesn't have to be the case that WebAssembly   beats something else or defeats or, you know, renders it obsolete. Right? In fact, that would probably be a non goal for us because we know that there are some things that containers really do very, very well at. And 1 of those is running a long long, high availability persistent services,   like databases or like Redis or Kafka,   where you really don't wanna have to start up a Kafka queue for every request and then store the state on disk and then shut everything down and then start it back up and load everything back, that that would be inefficient.  

So, you know, that kind of workload is not currently in WebAssembly's   wheelhouse.   So with games like Finicky Whiskers, we said, okay. Well, we want a Redis instance, and we want the Redis to store the scoreboard and to handle the events so so that we can have a full PubSub experience there.   And so we ran Redis inside of a container. Just so happens, Nomad does an excellent job of running container workloads. So we can run them side by side with our WebAssembly workloads.   And we understand that the profile for running the container is a little bit different. Redis is always on and always up and always available, does not scale to 0, and we're okay with that because that's only a small piece of the overall architecture.   Then all the web assembly modules are, you know, spinning up and shutting down with great rapidity   while the Redis is just kinda chugging away there all the time,   and that has worked out really well for us. And as we've looked into building more and more sophisticated applications,   this is starting to look like the right way to write the kind of service that you were describing.  

If we need to, say, build large ETL pipelines where we wanna have something in the middle to handle fan ins and fan outs and things like that, we can run   our message queues, our key value storage, our relational databases   as longer running processes or as hosted services.   And then the   logical bits, the business logic, the application logic, the jobs in in ETL language, you know, these get encapsulated   inside of WebAssembly modules   sorry, the tasks in ETL.   We really like this way of doing things. It works well with the microservice architecture, works well with the way we see ML trending, actually works remarkably well for web applications where you can just mount different web assembly modules to different routes on your routing table.   And so we're really excited about that and think that this kinda interplay between   containers   and WebAssembly will, over the long term, lead to building faster but far more efficient   deployments of applications.  



[00:41:07] Unknown:

Continuing on your topic of being able to use this for   deconstructing a web application where you have 1 route per WebAssembly   module, for example,   what do you see as the evolution in tooling and frameworks for being able to do something like, I have a Django application. I want to turn this into that world where I have 1 module per route and being able to actually decompose an existing   application into a Wasm environment or   being able to just take your Django app and compile it and say, okay.   For each of these routes, I'm actually going to do some level of sort of bundling and tree shaking to minimize the overall package size that gets deployed and just some of the ways that you're seeing,   specifically, the Python ecosystem because, you know, that's the focus of the show, but in general, the general tooling support in terms of these libraries and frameworks to be able to   manage   the complexity of a full,   you know, rich application   while taking advantage of this   very efficient and   componentized   approach of being able to deploy the actual binaries?  



[00:42:14] Unknown:

I think I'll start by explaining just in 10 seconds or less sort of what the routing table for Finicky Whiskers looks like, and then be able to go from that and talk about where I think there's potential here and where I'm hoping   to see things go in the future.   So Finicky Whiskers, you start a game. It's a web application, so the first thing you end up doing is downloading a bunch of resources.   Then after that, you've got your little game there and there's a start button, and you click the start button. And when you click the start button, it starts a new game session.   And then you start clicking away to feed the cat whatever the cat wants, and you're clicking buttons. So in the WebAssembly world, just going with those 3 actions. Right? The mount table has   a wildcard path that handles all the file loading for the HTML, CSS, image files, JavaScript, stuff like that. So the first time you point the browser there and you start downloading things, there's a file server. It's essentially running using that WASI style file system and is pulling down files and serving them back to you over HTTP.  

Then the start button shows up, and you click on that. That goes to an endpoint called session. That's gonna start a new WebAssembly microservice that happens to be written in Ruby in this particular case. I should have rewritten it in Python for today's discussion.   And that generates a new session ID that starts the game and starts the timer for the game ticking down, and then you start clicking buttons in the game. And each button click is going out there and hitting a WebAssembly endpoint and starting up a new module.   And that module is handling just that 1 request. So, effectively, you've got at least 3 different WebAssembly modules that are handling each little chunk of   that application's overall functionality.  

So now let's contrast that with a Django app or any of these that tend to use a a routing table as a top level design element, which incidentally, I think is exactly the right model to use for stuff like this. You know? In this case, the HTTP re request comes in, and it's Python code that says, okay.   Here's the route that was requested. What does that match as far as the controller inside the application? What do what am I gonna call? Right? And then it executes the necessary functions or chunks of code and then returns the response back. All of that's happening in Python code and in spin, and in the Fermion platform, all of that happens outside of the host code and and in the runtime itself.   So we've got a nice strong parallel there. Now,   there are a couple different ways to approach getting from a to b. 1 is it is always gonna be possible to run an entire application inside of, you know, a a spin application. Right? So you can always do your routing internally,   which means   the easy way to transition for some people from   1 way of doing things to another way of doing things will simply be to rebuild their applications and run them inside of WebAssembly instead of running them inside of the the native host. And that I think is okay.  

We've done that on a number of occasions ourselves, and I think it's positive first step.   But what I'm hoping is that there will be the second step where developers of these kinds of frameworks say,   we can really streamline this. And for each different kind of web application infrastructure, we can say, as you pointed out, you know, you can do a little bit of analysis   at build time, do a little bit of tree shaking, do a little bit of strategic compiling, and the next thing you know, you have   9 WebAssembly modules, 1 for each route that you've declared on your routing table, and then you just export the routing table out to the post run time and allow that to take care of it. I'm really hopeful that we start to see some tooling like that. The 3rd approach is the 1 that we are often the most guilty of taking, which is we, as engineers, as a whole, are the most guilty of taking, which is, well, I'll just, you know, invent something new that'll work in this particular way, and I think that we'll probably see some application frameworks that   are what we might consider, like, web assembly first. Right? Where they are designed specifically with the WebAssembly way of doing things in mind and   don't have any necessarily analog in the pre   WebAssembly world.  

All 3 of them I think are promising ways, but that second 1 that excites me. Right? Some clever developers are going to be able to figure out a way to take existing applications   and move them into the WebAssembly world in a way that feels really, really strongly   familiar to the developer,   but takes advantage of all those big features of WebAssembly that in route 1 just don't happen. Right? So I think it's the right blend of the 2. That said,   to my knowledge,   nobody has yet really started working hard on that second route. I'm aware of efforts on the first and I'm aware of efforts on the third. Right? I'm aware of people just compile myself included, compiling applications to WebAssembly and running them as is and saying,   it's bigger and it's less elegant, but it gets the job done today. And I'm aware of people doing you know, trying to think through what would a framework look like if it was WebAssembly first, but it's that second category of figuring out ways to   meet the developer where they're familiar  

[00:46:57] Unknown:

and then build something that's really runs according to the WebAssembly model. That's what I think is promising and exciting for the future. Yeah. I'm definitely curious how things like the Zappa library and things like Chalice that are already built for the Lambda deployment target of being able to run-in those types of serverless environments, how those will be able to map to this WebAssembly target, and   what are the concrete differences between   deploying to Lambda specifically or some of these fast platforms   and saying, no. We're actually going to take that function and compile it to WebAssembly   and deploy it that way so it runs sort of natively and idiomatically for that target.  



[00:47:37] Unknown:

Yeah. That I think we'll see that happen, I think, fairly quickly because   there's at least enough common ground between   the way you write a Lambda HTTP handler function and the way you write a spin HTTP handler function.   It won't be too long before we see that. And we've seen a number of good strong   FaaS architectures that are   designed   to, in the back end,   accommodate the differences between   cloud offerings, and those I think will look at this and say, oh, well, this is just 1 more thing to plug in. The APIs will be a little different, but what I think is gonna happen is that the back end services that WebAssembly will be able to provide will be far more   robust, and robust is the wrong word. We'll see more. Right? We'll see simply,   quantitatively,   more back end services that are supported because   everybody can very easily extend this environment. It's not necessarily like Lambda where   at the end of the day, you are kind of stuck with what Amazon wants to give you on that day. But I think this will go more the way of, like, open FaaS, where you see a much more thriving community being able to plug in different back end services   and handle different kinds of event types.  

Spin, for example, is designed to allow you to write pluggable event handlers, so you can trigger   the invocation of a WebAssembly module based on different events.   And that I think too is a flexibility point that many FaaS style solutions haven't been able to do, and I think that we'll see kind of   a blurring for a little while as the 2 sort of begin to merge together, and then I think you'll see kind of native support for WebAssembly on the back end. That's what I hope. That's what I hope.  

[00:49:09] Unknown:

As far as the SPIN platform,   it is the core of what you're providing in the hosted firm ion environment.   I'm wondering if you can just talk to your thinking of   building and releasing SPIN as this open source project and the overall governance strategy   around how to make sure that this project   stands on its own and is sustainable   over the long run, and then what you see as the boundaries between what lives in the open source and what belongs in your managed offering?  

[00:49:40] Unknown:

I think ecosystem building is actually just as much fun as software development.   And if you think hard about how you can build a good solid community around   a technology, a broad technology, and then how to build a, like, sub community around   your own open source projects and things like that, I think you can really achieve something bigger than just,   you know, success for a company, right, or success for a small group of individuals.   I love the way that you can look out on the landscape and see, here's the Python community. It's a really big community. Here inside the Python community is the community around Django. Here's 1 around machine learning, which is a slightly smaller than Python as a whole community, but then has a whole bunch of subcommunities inside of it. If you take a look in this SPIN repo, you'll see   a folder called SIPs, which is Spin Improvement Proposals. You will never guess what the inspiration behind SIPS was. Right? The Python community has really done an extraordinary job. Again, Python community as a whole of creating a big giant space where other smaller spaces can kind of form, and then inside of those spaces, even smaller spaces can form, and each of those sort of thrive together.  

An ecosystem, I think, is the perfect word to describe that. On the Cloud side, you see something very similar with, like, CNCF, which originally was a very Kubernetes oriented organization and has grown to kind of include   vast swaths of open source cloud development.   And open source there meaning, you know, big open source projects where there's plenty of room for individuals to contribute, where there's plenty of room for   established   companies to, you know, talk about their proprietary things. It's just an ecosystem. Once again, it's very broad.   I really like those ways of functioning. I think there's a role for standards bodies for things that need to be   agreed upon and implemented broadly, which is why I love the fact that WebAssembly is a w 3 specification.  

But I also think there's a big need for   community where we can discuss how we wanna run things together, how we want   to steer   the direction of standards as they pertain to running on the Cloud or as they pertain to handling   machine learning workloads and things like that. With WebAssembly,   there is the bytecode alliance is a is sort of a, I guess,   foundation slash consortium   is the right way to describe them, where they have a notion of membership that's strong and has to do with organizations and things like that, but they're not limited to that kind of notion like a consortium is. It's really about building an ecosystem and encouraging individual developers to, when they get passionate about something, pursue that inside of the WebAssembly domain, experiment with things. And, consequently,   I think bytecode alliance is likely to become sort of the locus for ecosystem   that you see with, like, CNCF in the container world.  

For us as Fermion then, that raises a really interesting question for any startup. Right? Which is, well, at the end of the day, it would be good to be able to pay everybody's salaries reliably off into the indefinite future, so we need to make money, but at the same time, we're a bunch of open source developers who have done this for decades.   To to us,   contributing as much as possible to open source is a big deal. So CLI tool is 100% open source. The Fermion platform is 100% open source, and we have engineers on staff that we pay to contribute upstream into core WebAssembly technologies.   And in that way, we think we are playing a part, maybe small, but playing a part in building that big ecosystem around web assembly and doing so intentionally.  

And then, you know, our plan is to say, okay. Well, can we host something? Can we provide a hosted solution that will allow developers to very easily deploy their applications without having to go   through the rigor of creating an Amazon account, setting up some virtual machines, installing this whole Fermion platform onto those virtual machines, and then managing that off into the future. And that I think is where we'll try and solve the problem of paying our paychecks.   Our hope is that those 2 are so compatible, and we've seen that playbook run repeatedly with lots of different companies, large and small, where we put a lot of effort into open source, we put a lot of effort into community building, and still we manage to carve out a good product space.   I think that's   the most promising way for a startup like ours to still participate in ecosystem building and pay paychecks.  

All that said, I'm really optimistic about the way open source in general has really kinda gotten the hang of ecosystem building, And I think WebAssembly will be able to learn a lot from   how the Python community evolved, how the node community evolved, how CNCF evolved, and things like that.  

[00:54:10] Unknown:

In terms   of the systems and applications   and projects that you've seen built   with the SPIN and Fermion platform? What are some of the most interesting or innovative or unexpected ways that you've seen it applied?  

[00:54:25] Unknown:

For the most part, the easy starting place that everybody has chosen has been blogs. And so, largely, we thought, okay, well, this will make sense. We'll see people doing blogs. And then people start showing up   and dropping, like, Postgres integration.   And I'm going, well, okay. So somebody's not creating a blog with this. And then, you know, key value storage integration for the thing they're working on.   And for a while, we're looking around going, what exactly are people doing? We don't know. We just get these funny little hints with PRs that get open against spin.   And then we start seeing things like, at KubeCon, Microsoft is demoing spin   in their own stuff, and we're going, oh, well, that's interesting. And in Bill, when they're trying to, again, replumb   spin into Kubernetes at a lower level to be able to do things like sidecars running with containers.  

That was really interesting. We didn't see it coming as we were kind of seeing things drop. And then HashiCorp took spin and took our finicky whiskers game and integrated it into Minecraft.   And so we started seeing videos of people playing   our finicky whiskers game inside of a Minecraft environment where, you know, instead of pressing the button to feed the cat whatever the cat food of choice was at the moment, they're in Minecraft throwing food at a cat. And it was like, you know, these are things we never really imagined   anybody doing. We started seeing what they were doing and thought, oh, this is just fun to watch. Right? It is fun to see   your own assumptions   about what people would build come back wrong,   but at the same time, see these people excited because they were able to build things with your software that were outside of the realm of what you had envisioned.  

We still don't know,   you know, what else people are working on, and we're we're kinda eager to see as these new projects emerge,   what kinds of problem spaces people are applying to. We know a lot of it is web applications, and that's exciting because that's 1 of our targets, and microservices, again, 1 of our targets. But we're starting to wonder if we're gonna start seeing some really interesting demos that are well outside of what we had anticipated people building. In your own experience  

[00:56:23] Unknown:

of   building   the SPIN framework and the Fermion platform   and digging further into this WASM ecosystem, what are some of the most interesting or unexpected or challenging lessons that you've learned in the process of building and growing this business and community?  

[00:56:39] Unknown:

The hardest lesson   for me is always related to patience.   I am a naturally impatient   person.   The WebAssembly ecosystem,   that has led to 2 kind of distinct conclusions. 1 has been,   I have learned that   to be patient as some of these specifications evolve is going to end up being better. Right? There were early attempts where I'm like, let's just, you know, shove through a spec that gets this kind of bare minimum   way of doing networking done.   And then realized now, you know, in hindsight, if that had worked out, then we'd have a mountain full of issues that we'd have to solve.   And just being patient and let people who have   spent substantial parts of their career working on low level post 6 e networking   stuff, you know, steer the ship on that.  

But a second part of the patience lesson, I think, has been to get innovative while you're being patient and say, okay.   If I have to wait for a standards body, and and we all know standards bodies tend to move at a slow and methodical pace,   what kinds of problems can we carve off that we can solve today and solve really well today? And that was part of the thing that initially got us saying, okay, well, we're not gonna be able to spin up an entire web server compiled to WebAssembly because the   threading is not there and the sockets is not there.   What can we build instead of that? And that forces you to say, okay. Well, what do developers say they like to do? What do developers say they enjoy more than the competing alternatives? And that it was what essentially drove us toward looking at functions as a service, which I admit I was highly dismissive of when Lambda first released. And then even as the community picked up, I thought, this is not gonna take off. People aren't gonna like being constrained to what to just this kind of business logic you view, and instead,   when we talked to developers, what we heard was the opposite.  

And we looked at that pattern and said, well, that's something we can build today while patiently awaiting for other stuff to happen in the future.   I think the last lesson learned in doing a startup in general, and particularly for us as a bunch of ex Microsoft people, right,   is that at Microsoft, it was very easy to just throw an idea out there and have everybody kinda say, oh, well, Microsoft is doing this, so this must be a thing. And, honestly, we got a little sloppy because we didn't have to do a lot of diligence behind the scenes. We didn't have to run a lot of experimentation   to validate that our way of doing things was right. In a sense,   we could   draw on our quote, unquote expert opinion and then just drop software out there.  

Doing a startup has really forced us to take a step back and say, okay. We have to   be honest about our limitations,   honest about what we are trying to do, and then ask a lot of questions from a lot of different people about what they want to do and whether our assumptions are actually playing out in any way. And it honestly,   it has turned out to be just a really, really good practice to get into.   And I feel ashamed to admit that it wasn't anything I did before, or in a lot of cases, I just the fact that I had the opinion seemed to be enough justification for me to tell people, this is how you should do stuff. But as a whole, as a team, as Fermion has gotten started and we have gotten really good at asking questions of other people,   in some cases, we have found that people will say, yes. Your opinions are our opinions. And in other cases, we found that they say, well, what if you just turn it a little bit to the left and try it this way? And we say, oh, 0, well, that's we hadn't thought about that. That's really great. And in other cases, they've said, no. This is not the way we do things, and   that feedback has probably proven to be 1 of the most valuable pieces of feedback because as a start up, we can't afford to make mistakes. Right? Monetarily   cannot afford to make mistakes.  

So that kind   of relearning   or maybe learning for the first time how to be honest, open, and then accept a lot of feedback from the community has been a really good lesson for us  

[01:00:26] Unknown:

to learn. For people who are interested and excited about these capabilities of having these easily   deployed and easily managed and fast to start   up modules and   units of software,   what are the cases where Fermion and the Spin platform are the wrong choice, and maybe they're better off just going and building another Django app and deploying it in a container?  

[01:00:50] Unknown:

I like how you followed up my commitment to honesty by asking the hardest question here.   And right now, WebAssembly is early as a technology.   Right? And right now, WebAssembly in the cloud is early as a technology.   My view of this is that the right set of applications you wanna be thinking about playing around with are those kinds of new greenfield applications where you're starting from scratch. You don't have any assumptions that you really need to carry with you as far as what the structure of the application or what frameworks you need to use, what those kinds of things are, and build some web applications, some microservices,   play around with machine learning. Spin is the right platform to try this out on. Right?  

Particularly   right now as Python support is evolving,   If you're interested in getting started, you're going to have to accept the fact that things are changing very rapidly in the Python to WebAssembly space.   That is fun if you're a pioneering kind of spirit, and it's really frustrating if you're just trying to get the job done.   So right now, my feeling is it's early, and if you're the kind of person who likes pioneering,   now is the time to jump in and try some of those first basic things, and then start pushing the limits and see what you wanna be able to do and what you can do. In an open source world, you can jump in and contribute.   I would say, you know, shy away from big complicated applications.  

WebAssembly is not quite mature enough in Python to be able to move a lot of those things over. In some cases, not even mature enough in Rust or c, the languages that had WebAssembly support for a long time. We need to wait for some of those proposals to make their way into implementations and then into the core runtimes, like threading,   like a garbage collection for many languages.   Those kinds of things as they come along will make it easier to write large scale applications. But for now, my advice is kinda stay with those small microservacy   or small in scope web applications and build those.  

Finally,   I still think that there's a lot to be said for combining the container and WebAssembly ecosystems together and leverage containers that do things like database support or like Redis support and use those and don't try and   mold everything into WebAssembly binaries yet. It's a good way to kinda step in incrementally into the WebAssembly   ecosystem while still taking advantage of a host of really, really spectacular tools that exist in the in the existing other ecosystems.  

[01:03:07] Unknown:

As you continue   to build and iterate on SPIN and Fermion, what are some of the things you have planned for the near to medium term or any projects you're excited to dig into or just any evolutions in the WASM ecosystem that you're paying particular attention to?  

[01:03:24] Unknown:

I think for us with SPIN, the most exciting thing right now is the new support for data services that that are dropping into SPIN on just about a daily basis at this point. We started with the basics, and, I mean, the basics. We have environment variables, reading files, you know,   accessing the clock, very, very basic kinds of features like that, the random number generator.   And those are not terribly   fun things for the developer. Right? We just expect those to be there, and it was good that we had those out in the first release,   all largely due to the support in WASI.  

But now we're starting to see some really interesting features drop in to connect databases, which, believe it or not, is very hard problem to solve in   any isolation   model. Right? You wanna make sure you do it very carefully.   Lo and behold, community members contributed, and it's looking awesome.   And object storage is another 1 that in the Cloud world, you really need object storage. Starting to see that drop in, and then, you know, what I think we'll see is   1 after another, different core services drop in. That answer right there should give you a good idea of how early we are in this ecosystem. Right? The relational database support is just now being added.   But the pace at which these things are being added now is really exciting for us because it validates that this is a very promising model that people   are so bought into at this point that they're willing to spend their Saturdays   writing database Postgres support. Right?  

On the standards body side, there's a lot of work happening on networking.   That, of course, very strong. Right   now, Spin has support for outbound HTTP,   and then anything else, like, when we add Postgres support, that's largely mediated through the host run time. At some point, we'll have full socket support inside of WebAssembly with that whole capability security model, and that'll change the kinds of applications we can write. So we're eager about those kinds of specifications moving through, though, again, patient as they do.   On the core WebAssembly runtime, the 2 big ones for us are garbage collection, because both of those mean   many languages that are really suffering to try and build WebAssembly support will suddenly have a fast track to get it in there. Kotlin, for example,   is waiting for the memory management aspect. Python,   I know Christian Heim's the 1 who did the original port, has very much found it frustrating that   Python is built with multithreading in mind, which is great, but it's very frustrating when you're trying to take that part out. And so he's really looking forward to that as 1 of the big specifications. And, consequently,   I am looking forward to that because he's done some amazing work on this stuff so far. So those are big ones for me.  



[01:05:59] Unknown:

Are there any other aspects of the work that you're doing at Fermion and on the SPIN platform and the overall ecosystem of WebAssembly   and in particular for Python developers that we didn't discuss yet that you'd like to cover before we close out the show?  

[01:06:14] Unknown:

I mean, the number 1 thing to me is that given where we are in this ecosystem, given how early we are, you know, people who have that kind of pioneering approach to technology can make a huge impact.   None of us at Fermion are actually at the level of expertise in Python where we feel like we can contribute a whole lot there. So this is that kind of opportunity where I like to say to people, if you're passionate about this and if you like doing the kind of experimental   work that can be frustrating for many people, There's a huge space right now for Python developers to be able to say, hey, here's a blog post explaining very easily how to get this done. Here's a blog post showing how to build an application.   Here are some early application frameworks to take advantage of some of these core web assembly features. I think there's just like this huge, what I like to call blank spaces. Right? There are these huge blank spaces right now   where somebody can make a fairly modest contribution   code lengthwise and a huge contribution   as far as steering the ship for making it easier for other people to do things. I love ecosystems when they hit when they're in this blank space space. Right? The container ecosystem was so much fun. Even if you go back to, like, my opening story. Right?  

Python in 2, 000 1, 2002 was a young, young language, and the people that I, you know, watched on the mailing list going, hey. I'm interested in this technology, turned out to be the people who are maintainers of core libraries, and then moved on into really shaping the entire ecosystem. Once again, there's this kind of moment where if you wanna be a pioneer, there's this huge space to shape an ecosystem that   10, 15 years down the road, people will look back and say, wow. This person wrote the first library for x in Python and WebAssembly. And that's a really exciting time for any ecosystem, I think. Absolutely. Yeah. It's  

[01:07:57] Unknown:

definitely amazing the level of impact you can have for the amount of effort that's invested when you're in these early stages of these environments.  

[01:08:06] Unknown:

Yeah. Absolutely.  

[01:08:08] Unknown:

Well, for anybody who wants to get in touch with you and follow along with the work that you're doing, I'll have you add your preferred contact information to the show notes. And with that, I'll move us into the picks. This week, I'm going to choose a movie that I watched over the weekend called Thor Love and Thunder. It easily made it into my top 10 movies. It is amazing. Even if you don't really like the Marvel movies, it is amazing. Just hilarious,   well executed.  

[01:08:31] Unknown:

It was great. So I'm not gonna give anything away, but it was great. So with that, I'll pass it to you, Matt. What do you have for pics this week? Add on to that 1 because I had such a fun time at that movie and have jokingly been telling everybody it was the best Guns N' Roses music video I've ever seen. It was awesome. I laughed start to finish. Mine's, I guess, a more sober pick. I've been reading the Remembrance of Earth's Past series by Cixin Liu. I'm probably completely mispronouncing   that name, but it's a sci fi trilogy that starts with a book called the 3 body problem. I'm I'm now at the 3rd book in the trilogy called death's end.   And this is the kind of book   that I sit in bed and read it until I literally cannot keep my eyes open a millisecond longer. And then I dream about it all night and then have to read it the next day and go, now what did I dream, and what was real? A fantastic trilogy of books, though. Yeah. I've heard a lot of good things about that. I've actually got the first 1 of the series on my bookshelf, so I'll have to raise that higher up the stack.  



[01:09:28] Unknown:

Alright. Well, thank you very much for taking the time today to join me and share the work that you're doing on Fermion and your overall perspective on the WebAssembly ecosystem. It's definitely a very exciting and evolving space, so it's great to see people like you and your team investing in making it more   viable for different use cases beyond just the browser. So I appreciate all of the time and energy that you're all putting into that, and I hope you enjoy the rest of your day. Thanks so much for having me. This is a lot of fun.   Thank you for listening. Don't forget to check out our other shows, the Data Engineering Podcast, which covers the latest on modern data management, and the Machine Learning Podcast, which helps you go from idea to production with machine learning. Visit the site at pythonpodcast.com   to subscribe to the show, sign up for the mailing list, and read the show notes. And if you learned something or tried out a project from the show, then tell us about it. Email hostspythonpodcast.com   with your story. And to help other people find the show, please leave a review on Apple Podcasts and tell your friends and  

[01:10:30] Unknown:

coworkers.