For this episode, we talked with Matt Butcher, CEO at Fermyon Technologies, about distributed computing, the long-term promise of WebAssembly, and the HR mix-up that switched his career from lawn care to computer programming.
Fermyon offers serverless cloud computing. Spin is their developer tool for building WebAssembly microservices and web applications; check it out on GitHub.
Like past podcast guest David Hsu of Retool (and yours truly), Matt earned a degree in the humanities before deciding to prioritize his “side gig” in tech.
Follow Fermyon on GitHub. Matt is on LinkedIn.
Shoutout to Lifeboat badge winner keineahnung2345 for saving Hamming distance between two strings in Python from the dustbin of time.
[intro music plays]
Ben Popper Listen to Season 2 of Crossing the Enterprise Chasm, hosted by WorkOS founder, Michael Grinich. Learn how top startups move upmarket and start selling to enterprises with features like single sign-on, directory sync, audit logs, and more. Visit workos.com/podcast. Make your app enterprise-ready today.
BP Hello, everybody. Welcome back to the Stack Overflow Podcast, a place to talk all things software and technology. I am your host, Ben Popper, Director of Content here at Stack Overflow, joined as I often am by my colleague and collaborator, the Editor of our blog and facilitator of our newsletter, Ryan Donovan. Hey, Ryan.
Ryan Donovan I think my title gets longer every time.
BP I have to come up with something new to say about you every time so we're going to keep adding to your nomenclatures. Today our guest will be Matt Butcher, who is the CEO of Fermyon, and he's going to talk a little bit about his journey into technology, how he got to know WebAssembly and why he's decided to work with that and build some stuff for the future. So Matt, welcome to the program.
Matt Butcher Thanks, it’s great to be here.
BP So tell us a little bit about yourself. How'd you get into the world of software and technology and what first brought you to WebAssembly?
MB So when I was 16 I got a job, my first summer internship style of job, and I went to the job interview and they asked me questions like, “Do you own steel-toed boots?” “Can you operate light machinery?” And I said, “Yes, yes.” They hired me but I neglected to ask, being a naive 16 year old, what I was going to be doing. So I came to my first day of work wearing my flannel shirt and my steel-toed boots and I walked in the door and the receptionist says, “What's your name?” I said, “Matt.” She said, “Let me show you to your new job.” So she ushers me into a server room and sits me down at a desk and introduces me to Bob, my new manager, and then says, “I’ve got to run. I’ve got to stay on the front desk,” and she sort of vanished. Bob says, “Well, let me get you started here. I'm about to go on vacation. Here's a stack of programming books for you to get going with and here's a Unix workstation. I'll check back in in a couple of weeks.” This is 1995, okay? So he says, “I think you should start experimenting with this new technology called,” and he used the air quote thing, “the World Wide Web.” So he gave me a book on HTML 1.0, a book on Pearl, and a book on CGI programming and he took off and went on vacation. And so I learned Pearl, HTML, LiveScript, the precursor to JavaScript, kind of these first technologies and played around with it. And when Bob came back I showed him a little website I built and he said, “Hey, this is great,” and we started working on some early, early web development. A couple months into this job I got called upstairs to the room of the person who had hired me and she said, “Ah, yeah, we seem to have made a little mistake. You were actually hired to mow the lawn.” She said, “It just so happened we hired two people named Matt and got them confused and the other Matt never showed up and so we just assumed you were the right person until it came to our attention that the last names didn't match up.” So that was how I got into programming, completely on accident, but once I started I was hooked.
BP Very nice.
RD Beats mowing the lawn, huh?
MB Oh, yeah. I mean, imagine where my career would be now if I had stuck with that job.
BP And so what did that company do? Did you end up building lots of websites for them and did those go into use with their consumers or their clients?
MB So it was actually a municipal utilities company so they did the electric, power, water for Colorado Springs, Colorado, and they were trying to build an intranet essentially to try and build a sort of internal way of communicating between teams. And so we did a lot of stuff with cameras and the ability to monitor the water supply in places with cameras. It was very fun. And to your question, in a way we were building experiments that kind of instantly went into production because there was nothing that they were replacing and no expectations around how they had to perform or what they did or what their uptime was. It was a great, great experience because we just got to try all these new exciting technologies and see them in use and get very quick feedback from a distinct class of user. People who were doing operations on waterworks at 2 AM would say, “Well, the camera went down for 45 minutes. Anything we can do about that?”
RD So do you want to talk about how you got from there into WebAssembly?
MB Yeah, so that kind of got me interested in programming more or less as a sort of side gig. I know I'm at least the second person on this podcast who is a philosopher. I actually have a PhD in Philosophy and taught academic philosophy, but all along the way software development was sort of my side passion then became sort of my overriding passion. I ended up working in content management systems. That got me into HP Cloud which got me interested in cloud computing which got me into virtual machines. And then from there I just kind of said, “All right, philosophy was fun and all, but philosophy should be the side project and software development should really be the thing I focus on for my career.” And I never think I've made the wrong decision. I mean, I liked teaching but the speed at which we can work here and the fact that we're in that kind of historical inflection point in which a few decades ago the idea of the computer was new. Rewind a few decades before that and everything was R&D. In our lifetime we've seen this thing go from toothpicks and marshmallows to the point where we have these amazing artifices of computational strength that have resulted in things like cloud computing and things that are unfathomable to my grandparents and what they would've experienced during their lifetime. And philosophy's nice and all, but this is something historically amazing that we get to be a part of, and so I love that about this career.
BP Very cool. Yes, it was David from Retool who said he was a dual major in Software and Philosophy, and I chided him for trying to do something where he could actually make money. But I guess you're a dual major, so it can be forgiven.
MB I have no excuse. I was philosophy all the way.
BP Tell us about some of the early things that you might have worked on with WebAssembly as the technology, and as you saw it evolving, what made you feel like it would be a good fit for this new world we live in full of microservices and containers, code as infrastructure, serverless. This is a very different world from what we were doing even five years ago.
MB Yeah, I mean for me, the HP Cloud moment when I switched from content management systems into the early cloud ended up being sort of a really deeply formative experience to me, where I got this glimpse into the way that suddenly we didn't have to run our own data centers, that suddenly the operating system could be packaged up and I could lease somebody else's hardware and push my operating system out there and they would deal with all the hardware problems and the uptime issues and all of that. That was a mental sea change for me and the way I thought about things. So at HP, I ended up running the Platform as a Service team and HP Cloud. I left from there and ended up doing platform as a service for a container company called Dais that was really, really early on the container technology. While I was only like four-six months into working there, Google released this project that none of us could pronounce at the time, Kubernetes, and we started looking at that and going, “Oh, okay.” So containers plus Kubernetes, this again sort of reshapes the way we think about distributing and deploying software and what distributed computing is really starting to look like, and I think that's the big story. Cloud is a set of baby steps toward really true distributed computing, and Kubernetes was one of those steps. That company, Dais, got acquired by Microsoft and I spent five years at Microsoft right while the container ecosystem was booming and they already had a good virtual machine set of technologies and service fabric, and the Xbox server side is all running on top of this platform. And I got to look behind the curtains and that was just a mind blowing experience. And I worked at Google too. The scale at which these kind of hyperscalers can actually work is mind boggling. The numbers don't make sense to me. The number of physical machines we had, I still can't quite wrap my head around it in terms of the number of rows and rows of blinky lights that actually turns out to be in reality. When you try and visualize numbers that big in terms of the things you have seen it's like, “Whoa, whoa.” And because we got this view behind the curtain, we also got this kind of glimpse into what their pain points were. And it became evident to us that the number of servers being racked was just astronomical, and yet at the same time, what we were hearing from the teams on Azure Compute and Azure Functions and places like that is that a lot of these servers are just idle most of the time. They're sitting 80% idle, and we can't use them because it's a customer workload that's sitting 80% idle, or it's in a queue where it has to be ready to go from 80% idle to 100% utilized in a couple of milliseconds, but there's all this time that was just being essentially wasted. We were consuming electricity that we were not technically really using wisely. And believe it or not, that's what got us into WebAssembly. My team started looking at this problem and saying, “Ah, what's the root of this problem? What are the actual core computing problems that are causing us to consume this much electricity and this much hardware but with such poor returns on investment?” And part of it was that you're going to get a little bit of wastage in any process, but as we dug a little deeper we said, “Okay, so part of this is that it's expensive to shut things down and start them up.” So if you think about a virtual machine, a virtual machine may take a few minutes to start up. You think about a container, a container is going to take a dozen seconds or more to start up. So that means that we can't necessarily autoscale at the speed we really need to if we want to say, “All right, we're going to get really lean. We're going to run the fewest possible instances of something.” And we couldn't do it because the cost of starting those things back up again was beyond the amount of time that a user is willing to wait. And when you scale this and when you think, “Okay, Thanksgiving winds down and nobody's really doing anything because they're all watching football and then suddenly everybody goes shopping,” now you go from fairly low utilization to very, very, highest of the year utilization. You can't autoscale quickly enough to meet that demand if every little unit that you're autoscaling up is taking minutes to start up or even seconds to start up. So this got us obsessed with the question of, “How do we scale to zero and scale up to tens of thousands nearly instantly?” And the kind of bottom line for us was that we had two kinds of compute available to us. We've got virtual machines and we've got containers, and we can't figure out how to do it well with either without eating into the wastage problem and just saying, “Well, the solution is we prewarm all these things and they sit around waiting.” That got us saying, “Well, okay, we understand cloud really well. We understand the necessity to have a really strong security isolation model, which is the core of what makes these compute engines like containers and virtual machines successful, but there's got to be another technology out there. There's got to be a third kind of compute that will handle just this case. It doesn't have to solve all the cases virtual machines and containers do, but we really want something that's going to be able to scale from zero to tens of thousands and back again nearly instantly. How close to instantly can we get?” We looked around at a number of technologies and I'm sure there are technologies out there that came close to fitting the bill. We tried some really kind of wild experiments with how fast we could get virtual machines and things like that. But among the experimentation we started looking at this browser-based technology called WebAssembly and it looked really promising so we spent some time playing with that. This is probably a good point for me to say, “Whoa, whoa, whoa. Let's talk about what WebAssembly is before I dive into why I was solving a problem.” WebAssembly was a browser technology. It was intended to solve a very specific problem in the browser. Mozilla released it in around 2015. When they released it they made this great commitment: “We've seen attempts to solve this problem before. They failed. Why? Well, our hypothesis is that they failed because they weren't done by standards bodies and they weren't agreed upon by all the browser makers.” So what were they doing? They were trying to come up with a way to run non-JavaScript languages in the browser in parallel with JavaScript and make it so that JavaScript could draw on the strengths of code written in different languages but in a way that wasn't going to threaten the browser security model or anything like that. So they need a highly sandboxed runtime. I kind of joke, it's been done before. In fact, early in the web we tried it with Java applets. We saw Silverlight, we saw Flash, we saw attempts to inject other languages like VBScript into the browser, and all of these things had kind of failed time after time. And Mozilla's theory was, “Well, the reason why is because in each of those cases, it was an attempt by an individual vendor to make a sort of soup to nuts platform that did both the UI and all the processing, and yet still the vendor could kind of keep their arms wrapped around it and prevent anybody else from sort of encroaching on their space.” So they said, “All right, well we'll do two things. We'll focus first and foremost on the binary format and execution, and second of all, we'll focus on doing this through a standards body.” So the end result of this is a binary format. You can think of it like, “What do I compile my stuff to? Well, I compile it to an ELF binary or to a Windows binary or a Mac binary. Okay, we could compile it to this third format, WebAssembly, and then every browser will know how to execute this WebAssembly binary instruction set and then we start working with language vendors and saying, ‘Can you support this as a compile target?’” And so the Mozilla developers joined with the Chrome and Safari, and at the time, IE developers, and they all worked together and implemented the standard sort of uniformly across the major browser vendors and it worked fairly well, except not a lot of people knew what to do with this technology. I mean, we saw some huge successes. Figma is an excellent example of a company that said, “Hey, we can write better code in C++, a higher performance, number crunching code that's going to help our graphics libraries work better and compile it to WebAssembly and then tie it all together with JavaScript.” And so in some ways, Figma has become sort of the poster child for appropriate use of WebAssembly inside of a browser. And we can kind of pause the story there and say, “Okay, well in some ways then, this was a massively successful project. They got all the major browser vendors to use it. They actually started to get the language ecosystem going. C support was first, Rust support was next.” Right now I track the top 20 languages according to Redmonk and try and keep track of how many languages can now run inside of WebAssembly. And I think right now of the 20 it's 17, and the outliers are Cascading Style Sheets, which I don't think will ever make it there, Objective-C, which I think if any of us tried hard enough we'd be able to get it to work, and it's unclear whether we can do PowerShell yet. So we're talking about Java: check, JavaScript: check, Python: check, Ruby: check. All the major languages, and particularly Rust, Go, C, those languages have enjoyed really good support for a very long time.
RD So I'm curious, this is compiling to a binary format, but it's being sort of interpreted and produced on various different operating systems, different hardware. How is it different than virtual machines?
MB Okay, well, we can turn virtual machine into two kinds. We've got the operating system virtual machine like what we're used to using on AWS or in VMware. We also have language virtual machines like Java or .NET CLR. WebAssembly is in the tradition of those language virtual machines. The way that Luke Wagner, one of the core developers of the original WebAssembly specification, described it to me at one point, he said, “You know, Java has been around for 20 some years and we have learned a lot of really good lessons from Java about how to do JIT compiling, how to run more efficiently.” When I started WebAssembly he said it was like getting to start on top of 20 years of learning that the old team didn't have when they started. And I'm thinking about that and we in technology have this tendency to want to say each time we make a technological innovation, “Everything is new. The world is new. We've created something new and it's going to blow away everything that was old.” We want to tell these big grand narratives, and part of that is because we are in, like we talked about at the beginning, this ecosystem, this technology that's growing very, very rapidly and new is a virtue in our system. But really, WebAssembly is sort of yet another evolution of the kinds of patterns that programming language and language virtual machine runtime developers have been discovering and innovating in since Java and before. CLR is another, the .NET runtime is another great example of this. That said, there are a couple of virtues that WebAssembly has that make it uniquely suited to this, and I'll really just hit one. That's the security model. The Java virtual machine was built with the idea that you as a developer should be able to write code that can access the file system and you shouldn't have to know what operating system the file system was on, but you should be able to drop down there and read and write files and maybe manage the process table and do whatever you need, open network sockets and things like that. And that should be the sort of default posture of the virtual machine. WebAssembly started with the opposite security posture because it was for the browser, which is, “Hey, you should be able to run your binary here, but with all the guardrails on.” By default, you as the binary author don't get to make any decisions about what you're dealing with when it comes to file system, process table, environment variable, stuff like that, because we need to make sure that nobody downloads some nefarious code into their browser’s WebAssembly runtime and accidentally roots their system. So that security model incidentally, going to the other virtual machine model, operating system virtual machines have run using essentially that same kind of model, as have containers for the most part. And so that security model is what first raised our eyebrows and made us say, “Wait a minute. This is a candidate for a third kind of cloud computing.”
BP Interesting, yeah. You mentioned how many languages it now supports. I was doing a little research before this on Wikipedia and there it says it's up to 40, including all the most popular ones. And then getting towards what you were saying about its applicability to the cloud, there's a quote in here from Solomon Hykes, a co-founder of Docker, who wrote, “If this existed, WebAssembly, in 2008, we wouldn't have needed to create Docker. That's how important it is. WebAssembly on the server is the future of computing.” So expound on that a little bit where you see its role in this area.
MB Everybody should also read the tweet that Solomon said right after that one where he partly walks it back and says, “I see a future in which Docker and WebAssembly work together.” And I think his core intuition was right. A lot of the pain points that led to the creation of Docker really were related to the same problem space that WebAssembly was addressing, and the two streams didn't cross until years and years down the road. But again, I think Docker is great for these long running processes like databases. It works really well in a number of these cases. I think the intuition Solomon hit there was that there's more potential for WebAssembly to run in the same kinds of operating system contexts that containers and virtual machines run on, and that certainly is where we've gone for us. It's those areas where you need to be able to scale down to zero and up to tens of thousands, because another one of the real virtues of WebAssembly is it was built to be fast, and by that we're talking about seconds to start up a container. Even if we're talking about Lambda functions which are one of the fastest things you can do on AWS, we're talking about 2-300 milliseconds to start them up. With WebAssembly and our experimentation and if you play around with the Fermyon tools, you'll see this cold startup time at around one to two milliseconds. So we've really managed to get way down and that's really what we're excited about because that's the solution to the problem that we set out to solve– how do we manage this burdensome scaling problem that over time is going to mean lower cost for people who are using cloud and much less energy consumption for the people who are running clouds.
BP Right, right. I think I see what you're saying. We've had this conversation a few times recently, and Ryan and I just worked on a piece together about people who are migrating back from public cloud to private cloud or on-prem, and the question is always, “These days, how do you balance the cost of being in these large multifaceted cloud environments with the speed and reliability that your customers demand?” So I think what you're trying to say is that maybe here you can get a bit of the best of both worlds. If you are a big e-commerce company, you're not burning cycles and blowing up the climate for no reason. And then when you do want to, a couple milliseconds later, the customer can see how much that shirt is going to cost and choose to purchase it or not?
MB Yeah, exactly. The repatriation story is interesting, but the other answer is if we can cut cost and cut energy consumption down, then we're accomplishing that same kind of thing that those who have been saying, “Let's go back to our own data centers,” have been after as well.
RD It sounds like it runs almost like native code. So what's the ultimate implication? Is this going to be faster than serverless? Is this going to be the next way that you get as close to your user as possible?
MB I think the big narrative for me is, how do we do distributed computing well? And we're taking our baby steps toward this, and I think the baby step that WebAssembly is getting us to is if we can figure out a way to do the kind of serverless style workload ultra fast and make that really, really affordable and really, really performant, and then we can do it on a binary format that doesn't care about the architecture or the operating system, suddenly we have a compute unit that we can start moving around. We've talked about it with microservices, we didn't achieve it with microservices. Now suddenly we're in an environment where potentially over the long term the same executable can run in anything from a web browser to a server somewhere in a data center to maybe your watch or an IOT device or something like that. That's where I think the long term promise of WebAssembly is. But the step toward that for us, the baby step we're taking now is saying, if we can build a faster, easier to work with serverless functions platform à la Lambda or Azure Functions or something like that, we're taking the right step in the right direction. So that's been our focus for the last year and will continue to be our focus for this year.
BP Very cool.
[music plays]
BP All right, everybody. We want to say thanks for listening. As always this time of the show, we want to shout out someone who came onto Stack Overflow and helped spread a little knowledge around the community. A Lifeboat Badge was awarded to keineahnung2345 for providing an answer to the question, “How do I find the hamming distance between two strings in Python?” Thank you keine, and congrats on your badge. I am Ben Popper. I'm the Director of Content here at Stack Overflow. You can always find me on Twitter @BenPopper. If you have ideas for the program, suggestions, questions, email us: podcast@stackoverflow.com. And if you like the show, do us a big favor and leave us a rating and a review. It really helps.
RD I'm Ryan Donovan. I edit the blog here at Stack Overflow. You can find the blog at stackoverflow.blog. And if you want to connect with me, you can reach out on Twitter. I'm @RThorDonovan.
MB I am Matt, the CEO of Fermyon. The easiest place to get in touch with me is @TechnoSophos on Twitter. Because I'm a philosopher and I like Greek words.
BP And if developers are listening and want to demo or play around, they should just go to your website? Can they try stuff there for free?
MB Website for us is fermyon.com. We've got a blog there that goes back and forth between deeply technical stuff and really kind of high-level more vision-y kind of stuff. If you want to try Fermyon out for yourself, the Spin open source project is probably the place to go, and that's at github.com/fermyon/spin, or you can find it at fermyon.com.
BP Very cool. All right, everybody. Thanks for listening, and we will talk to you soon.
[outro music plays]