 Okay, up next we've got a love letter to isolation with Kelly Shortridge. Kelly is a senior principal engineer at Fastly and lead author of security chaos engineering. Please join me in welcoming her to the stage. Thank you very much. Thank you so much for having me and welcome to a love letter to isolation. I know that this is probably the first love letter you've seen at like a nerd conference. So get excited. It really is just me like expressing my profuse affection for the technology that is isolation. Obviously, tying it to wasn't. So I actually think isolation is kind of the unsung hero of modern computing. I think without it, we actually couldn't build many of the systems that we depend on today. It's really a core design element for how we sustain resilience against failures, whether that's, you know, the performance variety that you care about on the history side or whether that's cyber attacks as well. But I really think we don't actually love isolation the way that we should. I think we take it for granted. I think we often overlook it when we're thinking about software security and security architecture. We just don't invest in it as much as we should. I think isolation deserves more than this. Like they're a high value partner. We gotta like invest more effort, right? I also think our machines deserve more than this too. So this is all about how do we deepen our relationship with isolation? How do we harness its potential in computing as much as we can? This is why this talk is a love letter to isolation to really appreciate it for the gift that it is for software resilience and security. It's kind of a love letter, you know, to usher in this next big step, this big milestone in our relationship. And I think that big milestone is WebAssembly and especially the component model. So let's start our love letter with an ode to isolation's importance in complex systems, no matter whether it's software or otherwise. So not everyone realizes this, but life actually literally emerged due to isolation. Like all life relies on a membrane partially severing the organism or living being from its environment. So I love the quote by a biophysicist, Harold Morowitz, who said, the necessity of thermodynamically isolating a subsystem is an irreducible condition of life. Isolation really represents a selective barrier that ideally lets good things in and keeps bad things out from the external world. Reduces the contagion effect, which with COVID, we're all very familiar with that now. One failure, one thing cascades to the rest of the system, right? And in nature, we often see that this partial isolation is very layered that exists in both the micro and the macro world. And I like to think nature was actually the original architect of nested isolation well, well, well before we conceived the transistor. So we've observed isolation across literally every scale in biology, right? Like from proteins and genes to cells to organs to ecosystems. And so much again depends on a component separating itself to some degree from its external surroundings and other components. So like we have skulls here that protect our brain from its external environment. And even other components within our body, right? Like the blood-brain barrier. And then our brain cells have their own isolation too. Also things like axolotls, lizards, geckos, iguanas. If you don't know, they can regrow their limbs if they fall off. Again, it's just showing how like this isolation means that one component that fails, it doesn't cascade to the rest of the system. And it enables adaptation. We even see this in other areas of technology like humanity's relationship with nature. So as Dutch Elm disease ravaged North America and also elsewhere, Alberta, which is a province in Canada actually decided to isolate its Elm forests from the outside world. It means today it actually has the largest population of Elm trees in the whole world. And for thousands of years humans have grown crops within post-isolation to ensure their resilience of failures. So like this picture here, beautiful orchard, very low-res JPEG. It shows the orchard system in the John Ware National Historic Site. And here what's interesting is they actually planted the crops as modular units of species blocks. So it means they're not just more efficient for things like irrigation, but it's building resilience into the system, like ensuring that leaves frost damage doesn't actually affect the rest of the crops. It doesn't cascade everywhere. And speaking of modularity, like again, this orchard really reflects that modular architecture, right? And that's a really nice segue to talk about modularity here as a kind of macro category. Isolation is really the modularity of super power, right? When you hear modularity for like systems architecture, think about isolations like the super power to turbo charge it. Now modularity is the system property reflecting the degree to which system components, which are usually pretty dense. They connected in a network can be decoupled into separate clusters. For a more formal definition, modularity complex systems is a property that allows structure their functionally distinct parts to retain autonomy during a period of stress and allows for easier recovery from loss. So what we see in biological systems is that modularity directly enhances the vulnerability because modularity keeps systems adaptable. Like again, the world is constantly changing around us, right? So having decoupled components that can change independently keeps the system flexible enough to keep up with an ever-changing environment. And less components can fail independently. You don't really have modularity in the resilient sense. You maybe could have it in like an organizational sense where you can like, split up how you organize the system and build it. But with respect to failures and tolerating those failures, you don't really have modularity unless you're designing for it. And software modularity doesn't emerge naturally like it does in biological evolution, right? This is why we often see those like all hands-on deck kind of incidents that affect the whole company, right? Because we don't have this modularity. So modularity, it enables inner-ved evolution which gives the ability to make like small quick changes just like we wanna do in like DevOps and Agile world rather than investing in like a bunch of big bang changes at once, right? So you can think of modularity's ability for the system to almost like, save a bunch of its work and still change just like little by little. And this is possible because modules allow for basic encapsulation and separation of concerns which is gonna be really important when we start talking about the component model. We can change one module without changing all of the others. And this also creates a local boundary upon which we can introduce isolation. And this allows us to break things down to smaller components which means when done right, modularity minimizes incident impact because it keeps everything separate, right? If your system's architecture is modular, failures and small components can snowball or avalanche into very large impacts and lead to those cascading failures. How many of you have heard the ASOP's fable maybe for when you were a kid of the oak and the reeds, anyone? You have, thank you Tristan, you have. So in it, the oak is actually kind of mean. The oak locks the reeds because they don't stay mighty and upright, right? They don't resist the wind like the oak does. The oak thinks they're like a big deal. The reeds reply though, the winds do not harm us. We bow before them and so we do not break. But you and your pride and your strength have so far resisted their blows but the end is coming. I don't want us to spoil it for you if you decide to read it but you can guess what happens when the hurricane comes, right? Like who survives? This is a fundamental lesson about resilience, right? We can't prevent failure from happening. We can prepare for it. We can use strategies like modularity to remain adaptive to make sure we can recover gracefully from failure. We can bend like the reed. Humanity has understood this for a while in other areas of technology. Like, I don't know if anyone else is from New York City but I worked in this huge skyscraper in Midtown East and whenever there is a lot of wind like during Hurricane Sandy many years ago it would just like shake like crazy. It was very unsettling to be in but that's actually by design. It's resilient by design, right? We don't really have this in software though, right? When real world systems bend most of our software systems actually break and software system parts are actually quite brittle. They can crack easily. And software just isn't as forgiving to like crashes and exceptions and attacks. That's why isolation has been kind of the fundamental driver of all the major improvements to software resilience. In fact, I actually think isolation is a really great example of just how lucky we are to work with computers, right? I look, my research a lot about again other complex systems domains let me tell you like weak and isolated failures to handle unexpected interactions but you can't do that in most physical systems. Like talk to someone working in a nuclear reactor like a petrochemical plant or a mine they just can't do it but we can. So I think we need to leverage this blessing to its greatest effect. Again, this is, we need to give this some love, right? Because we have a unique opportunity. Now I also like to think true love means you know your lover better than anyone else and feeding all the words and whatever. So I say this with love that software isolation is kind of the weaker but cheaper and more flexible cousin of physical isolation. Again, I think that isolation is a core kind of part of what makes computers usable. Our systems have really like lost them because we've used isolation. Like anyone remember the blue screen of death or windows doesn't really happen as much anymore. I see some dots, right? That was like win 32 programs like stomping all over the kernel. Like we don't tolerate programs that behave like this, right? Especially if they're in production. So we're especially today like in production we have such complicated software systems, right? We need confidence that failures won't cascade especially like a multi-tenant environment. Whether that's due to like malicious tenants or just like the normal crashiness of computers. So isolation allows us to wrap specific software components in a membrane, right? It's a form of almost like decentralized response to failures because resilience has then spread across the population just like it still has a membrane. It ensures that when something goes wrong in one component it's effects don't leak out to the other components. But adding in each kind of like layer or dimension of isolation is a really hard fought battle most of the time. Some of it's actually social. So like windows 98 towards 6p that was a great upheaval in software for sure. Multi-user was a great upheaval. Site isolation, another great upheaval. Coloed to cloud, another great upheaval. With each way we got more effective isolation through greater flexibility and ease of use. And each wave made software more reliable and expanded its capabilities. So process isolation is one example. Like the invention of processes, they're great. Well, it depends if you think computers are a mistake but mostly they're great, right? It lets us perform compound tasks or more than one task at a time with a computer. But they came with the hazard that if one process failed then it could disrupt the others or corrupt the others. Process isolation fixed that, right? Computing is much more resilient to broken programs as a result. Like if your Excel crashes it doesn't mean that word crashes either. But process isolation doesn't occur costs which we're gonna talk about. Especially overhead when processes have to talk to each other over a network, right? Like RPC. Then there's user isolation. So that meant multiple people could share a computer in a way that was safer, right? Like in case the other person like deleted their files. That was the case when we had multi-user permissionless systems. But now we kind of take user isolation for granted, right? We just assume it's there by default. We can create even now like specific cloud accounts for a specific resource with fine-grain permissions that allow even more granular isolation. App-insight isolation, that's what allows us to like do online banking or shopping or like messaging our doctors without fear that our details are gonna be leaked or stolen. Or like in my case like we don't worry that like the app we used to devour no videos of like adorable babies, no leopards. Like if that crashes it's not gonna cause the rest of the phone to crash or other apps to crash. And like virtual machines and networks like cloud computing enabled all of those services to move online cheaply. Obviously with the components that data won't be intercepted. Relatedly, network isolation enabled a lot of this, right? So we developed plans. We developed bridges to segment those lands in like the late 1980s. With HTTP we started to separate things between client and server. We started segmenting traffic between different subnets with routers. Then by the early 1990s we started implementing VLANs, right? For logical separation, not just physical. Now we have different availability zones, logical isolation with things like VPCs. Some of you maybe hear work for the browsers. So a lot of the biggest innovation I think we've seen in isolation is because of the browser vendors. So they kind of understand in a lot of ways they're the new OS for users. And this overlaps a lot with like site isolation and process isolation where browsers ensure that each site you load is isolated at the process level. One that made you surprised is I actually kind of think cryptography is a form of self-isolation because if we think about like encrypted connections the virtual isolated tunnel, right? It's kind of separating you from the untrusted physical outside world and it's the same thing with like an encrypted disk, right? They're separating the data from its untrusted external environment. All of this supports modularity, right? Supports the independent failure of multiple parts and various parts. Now nature discovered that this isolation is a critical part of the survival of complex life forms. We've kind of like painstakingly discovered this over the past few decades for our complex software systems. So I think we should embrace even more isolation and deepen our innovation in it. So how do we deepen this love affair, right? I believe WASM and especially the component model is the next big step in this love affair with isolation. So WASM I think is kind of the latest in long history of technologies that are trying to provide like the same isolation that we have today with lower costs and more convenience. As I mentioned again, like isolation is often pretty expensive to implement, especially in terms of program overhead. Developers, you know as I like to say they have hot girls shift to do. So they try to avoid adding isolation or they find it inconvenient to add it into their systems. So let's start with what WASM offers today. It's probably refresher for most of you. The existing isolation model WASM lets you build services and programs that are completely isolated from the underlying system, right? The WASM sandbox means that programs don't have access to the host environment nor the underlying resources. So we can see how it looks here, right? The classic model involves, is it here like one minute memory per workload and protects the runtime, the host runtime from like out of bounds memory access and other attempts to like escape the sandbox. WASM also offers the capability safe model, which means all interactions with the host runtime are explicitly granted by the program developer. So the developer actually has to explicitly define or grant any functionality resources the program needs. And it does all of this with very little overhead. So WASM's existing isolation model, big improvement in the general context of like the software ecosystem. What was in safety guarantees today are to protect the host, not to protect the guests. It still means libraries and other components of the program present hazards. Like if they get wonky or they get attacked, it affects everything within the sandbox still. If we think of a workload as kind of like a workflow, sequence of steps with different components, the individual components within that workflow can still mess with each other even if they can't mess up the underlying host. And also the sandboxing today isn't the easiest to set up but I'll get back to DX later. So this means we can do a lot more to solve for like the strong isolation by default world. And the bytecode alliance, hopefully already has an answer to this which is the component model. So WASM is building a future where you don't have to compromise on isolation whether in terms of effort or overhead. You'll just get it by default as a developer and that's really powerful. Because again, developers want isolation to kind of be a concern that's handled by like a layer underneath where they're working. Similar to like observability or log collection, right? But to date, no one's been able to make isolation like invisible to developers as much as like logging or observability is. But I think with the WASM component model maybe we can actually get there. Okay, so what is the component model? I think there's a talk earlier about this but how does it specifically improve upon WASM's existing isolation model? So the component model adds the same safety benefits we talked about but between components instead. So components only interact with each other in ways they explicitly grant. The component model therefore not only isolates programs from the underlying hosts it also isolates libraries within the program from each other. So the component model isolates individual components within that like workload as a workflow by providing a separate memory for each component. So remember one of the downsides for existing process isolation is the overhead. So having to communicate over a network in terms of overhead is really expensive. Like it's slow basically. Communicating with function calls much faster and also thriftier. So the component model really allows engineers to like decompose their app into a modular architecture, wrap the resulting components in a lightweight sandbox to achieve looser coupling with importantly near native speeds. We can see how this looks here on the right side. Any corruption like the zipper image magic components can't cascade to the rest of the app. So I've got this nice little graph right there. Like image magic is actually a really great example of like smelly C code that's really difficult to extract or replace. So this is a big deal, right? The memory isn't shared and sharing only happens at the boundaries of each component. And these boundaries enforce what's called a shared nothing model. So each component instance has its own linear memories tables and globals and it doesn't share it with any other components, right? So components expose an external API which is the only way that components can interact with each other. So it does allow us access to like any particular components memory and tables. Again, this is huge. So all in all, the Rebson thing component model gives us the ability to like stitch isolated units together in a really transparent and performant way. This is why my colleague, Fastly Luke Wagner refers to the WASM component model as modularity without the microservices. And I agree, like you gain use coupling, right? Both in terms of memory isolation and even language choice that microservices offers, you get all of those benefits. But you also maintain the efficiency of modular monoliths in terms of cross-module calls and also with much lower memory overhead relative to containers. So we're forced to deal with like the bulk in overhead like awkwardness of network RPCs just to gain isolation. We gain isolation through like a simple FFI call which is facilitated by binding generation. How many of you know what binding generation is? Okay, quite a few of you, but for those who aren't aware, so binding generation is basically like automatically generated code that translates between the structure of one language to another and to allow programs to interact with things in a different language. And it's that binding, that automatic binding generation that creates another kind of like juicy carrot for developers to adopt the component model which is the ability to use libraries from other ecosystems. It means we can realize the ambitious vision of fully thought applications without it being like a total mess. Composability and performance benefits that we just talked about mean that wasm like let's be real, like kind of right now it's a bunch of us weirdos who are like really into wasm really into like security or isolation or jamming like C into the browsers. But this could mean that wasm through the component model actually becomes the more productive and safe way to build and assemble programs. The component model again means we work with portable, lightweight and component modules that connect to each other in a standard way. That's already awesome for performance, developer velocity. But those same characteristics actually enable some of the most powerful and also frankly like coolest security outcomes that I've seen across my whole career when I started out in cybersecurity. I think it actually gets us to that nested isolation that we see in nature get really powerful. Being able to split components arbitrarily and recursively to like a near infinite depth is honestly like to me it's mind blowing, right? Like we can bend full systems with our own complex and isolated sandboxes inside a wasm program and then embed that in another sandbox if we wanted to. That's not something we can do with technologies today, right? Like Kubernetes can be great. We can't just embed like a complete Kubernetes cluster containing some system we want to stand shade and communicate with, right? But the component model grants us this ability which is a game changer. The component model also enables wasm run times to implement stronger temporal isolation, not just spatial or logical, right? So again, existing wasm model already enables a strong degree of ephemerality. So that's the ability to limit the lifespan of a workload and like a kill and restart model or I think what wasm time calls disposable instances. So in this model we can actually instantiate a new wasm instance per task like a request in Fastly's compute platform. Then we can nuke it once the task is finished which gives us inter-task isolation. But the component model empowers this ephemerality even more. So if you were building an underlying host or runtime you can create component instances on demand destroying them once they complete their task like after a request response pair or connection session batch job or like a transaction, right? And since each component then is closer to like a single purpose sort of function it makes it much easier to bind its lifespan to specific functionality. And this is great for both reliability and certainly security. So it's hard to state how transformative this is for cybersecurity so I wanna dig into it a little bit. From a cybersecurity perspective all of this is huge in like solving the supply chain security problem which is the new like buggy person for the cybersecurity community. It's that concern that now is somewhere in our software supply chain or our dependency tree will allow attackers to breach or disrupt our systems. Developers write their app's dependencies as separate components which run as separate instances. They can now isolate failures between them, right? So whether an attacker targets like a vulnerable dependency with an exploit or tampers the dependencies code like a way upstream we now have protection against their compromise attempts. So though the attacker will succeed in compromising the dependencies instance state but now they have to do much more additional work. A sandbox escape which is really hard to access anything else in the instance. And ephemerality means they may need to re-exploit the component over and over and over to do whatever they wanna do which makes the work even harder. The Wasm component model layers in the existing capabilities sake model into this paradigm, right? So a developer can define the specific capabilities each dependency as component requires and that reduces the proverbial attack service like the opportunities that are present for attackers. Now further restricts what the attacker can do even if they gain access to a component that's very in line with like principle of lease privilege. These properties obviously benefit resilience beyond cyber attacks as well. So if a dependency experiences like performance failure the app can still stay up and the components can be killed and restarted if it's wonky, right? And restricting capabilities per dependency means there are fewer surprises and just unintended behaviors that can ruin our day in production too. And this extends beneath the app itself. So the component runtime implements host functionalities, Wasm components. It's beautiful for nested isolation kind of like isolation all the way down and sort of turtles all the way down and it further reduces performance and security hazards which I kind of think is closer to zero trust than a lot of the like cyber security tools that tell them is zero trust today. From the perspective of a resilient runtime provider kind of like vastly it means we can densely pack services together, right? Even adversarial ones and we can do that in a safer way. And platform providers have leveraged a new component model to do what I call the airlock approach menu book. Like you can leak components out the airlock on behalf of developers when something goes wrong. That way again, failure one component doesn't degrade the rest of the system. Platforms can also offer full observability between cross component messages or they can migrate components around and scale them independently in response to advanced too. So I kind of think it's like the app platform of our hopes and dreams. Related to that it's actually, I think it gets us closer to the ancient dream of software integrated circuits or six. It's in a safer way than I think even its progenitors could have ever imagined. But I think it would be like pretty sick. Ha ha, me here all night. So Brad Cox who invented effective C believed reusable components would actually revolutionize the software industry just very much in the same way that like interchangeable parts created the industrial revolution, right? This vision wasn't fully realized before Cox's death but I believe that the WASM component model can get us there. It means that we can sustain resilience by design which is what we want. We don't want developers to have to think about it. We can do that through modular name isolation. We can also enable like a really powerful new paradigm for how we build software at the same time. But to realize this opportunity for the to be the future of software development like we have to have developers use it right. To be honest, the dev experience right now with WASM is not the greatest, it needs to get better. Like developers, I like to include myself and among them we're kind of cobbled, get easily distracted by like new shinies, whatever's on hacker news. So that means as a call to action, like we have to treat DX as a core problem just as much as we treat like security or resilience. We have to be solving for DX if we want this to succeed. Okay, so now we can right off into the sunset with isolation as our dear lover. That's my mic, I apologize. So isolation, it's the key to modern life. It's the key to life itself. It's the ability for an entity to provide that kind of like partially separated, that barrier like to partially separate itself from this external environment. And that's a core neighbor of resilience. It's what allows life to evolve. Our thinking machines really wouldn't be so useful if we didn't have isolation, whether that's process isolation, user network isolation or even cryptography. Isolation is how we ensure complex software systems thrive like to ensure that things can fail independently. And every new dimension of isolation in software as I mentioned is an upheaval. And I think the Wasm Component Model is this next upheaval. It's the next big milestone in this love affair with isolation. It gets us closer than ever to the nested isolation that's so powerful in nature. We can realize resilience and security by design in a way that's invisible to developers. I'm really excited. I think all of you here hopefully were part of this like great revolution that's happening. And I also feel honored to be a part of it in my very small way. So with that, thank you very much. If you enjoyed this, you might enjoy my new book. It's all about like has stuff on modularity isolation, how to do resilience by design. That, thank you so much for your time and attention. Kelly, what an amazing talk. Might have time for one or two quick questions. Oh, hey, right there honey. Me personally, this was a very beautiful presentation. I had a question but I'll ask it at a personal time because it's like a lot, it's a lot. But I just wanted to state that you had a wonderful presentation and I loved it. Thank you. I also have, I'm guessing none of you have read my book yet but I have chaos kitty stickers. It's like the mascot for security chaos engineering. So if you find me, you can get stickers too or ask your question. Hello. Thank you for the talk, really cool stuff. I'm interested in taking the idea of S-bomb to like the next level and the idea of the strong typed interactions. Seems like we are pretty close to having Walsum apps generate all of these sort of allowed ways of interaction that can be thrown into a manifest and then evaluated. Do you know of anything in this area that's already happening or what's the like current state? Am I allowed to curse? Fuck S-bombs. I think they're pretty useless. They're just like what tens of thousands of lines like JSON blobs and like what do you do with them? It's like cool, like how do we know if this is actionable? How do we know if they can aggregate this? My thing is like with isolation, you don't really have to worry about it because like the impact is contained. So I kind of view it as like S-bombs are trying to solve a problem in a very consulting way. So yes, I agree. What's the way with the component model? Yes, you're getting into again like almost like allow listing the very specific things that each individual program can do. But at that point, why do you need all of the JSON blobs to know what's in this so great? I think there's a rule in which you can gain again like observability and visibility into this stuff. But to me, this is a much more kind of actionable thing when you have that isolation kind of ingrained. It's the answer to like, okay, so what do we do now with these JSON blobs? Like we're doing things. So to me, it's almost like solving the problem that S-bombs is trying to get to, but before S-bombs or at least once the component model is in there. That's my spicy take, so. Kelly, on your spicy take, would it be fair to say that the biggest difference between WebAssembly and containers is that containers satisfy their S-bombs at compile time, whereas WebAssembly gives us the opportunity to satisfy it at runtime. We always get the latest version. Yeah, I think that's fair, yeah. I hadn't thought of it that way, but I think that's, yeah, that's a fair comparison to make. And I think that's what we want, right? Because rendering is what makes us funny, and that's also what attackers point, so, yeah. All right, phenomenal talk. We're gonna break folks. Please join me in thanking Kelly.