WEBVTT 00:00.000 --> 00:13.200 All right, we're going to start again, please take a seat. 00:13.200 --> 00:28.600 If you want to talk about stuff, please go outside. 00:28.600 --> 00:32.600 So next up, we've got Claire's going to be talking about comparing Fuchsia components 00:32.600 --> 00:35.600 and then ex-containers. 00:35.600 --> 00:36.600 Hi, everyone. 00:36.600 --> 00:40.600 I'm just going to get started as people filter in and out. 00:40.600 --> 00:45.600 Yes, so I'm here to talk about Fuchsia components and learnings containers. 00:45.600 --> 00:47.600 I first about me, my name is Claire. 00:47.600 --> 00:54.600 I am a software engineer, and I am the tech lead of the component framework team on Fuchsia at Google. 00:54.600 --> 00:58.600 And at that out of the way, let's talk about what I'm talking about. 00:58.600 --> 01:00.600 So Fuchsia is a new operating system. 01:00.600 --> 01:02.600 We've been working on a Google. 01:02.600 --> 01:03.600 It's not Linux space. 01:03.600 --> 01:04.600 We have our own kernel. 01:04.600 --> 01:06.600 Everything's like new and custom. 01:06.600 --> 01:11.600 And it has a software sandboxing technology. 01:11.600 --> 01:14.600 You know, where we can distribute, like pieces of operating system 01:14.600 --> 01:18.600 and run them in a sandbox way that has a lot of similarities to some 01:18.600 --> 01:20.600 Linux container solutions like Docker. 01:20.600 --> 01:24.600 And I find the fact that these two things ended up being similar, really interesting. 01:24.600 --> 01:27.600 So the stock is going to be focusing on how they're similar and more importantly, 01:27.600 --> 01:29.600 all the ways they're not. 01:29.600 --> 01:31.600 Yeah, so Fuchsia. 01:31.600 --> 01:38.600 Before I get into that, I want to tell a quick story about how I ended up working on the component framework. 01:38.600 --> 01:44.600 So if we go back to 2015, I started working for a startup and San Francisco called CoreOS. 01:44.600 --> 01:50.600 And the project I initially worked on there was called Rocket. 01:50.600 --> 01:54.600 Rocket, RKT, was aiming to be an alternative to Docker. 01:54.600 --> 01:57.600 They wanted to do about the same things, provide about the same functionality. 01:57.600 --> 02:02.600 Just be an alternative for, you know, people to be able to choose what they're using. 02:02.600 --> 02:08.600 And just to kind of quickly go over, you know, our objective what we were going to do. 02:08.600 --> 02:10.600 Let's talk about what Docker does. 02:11.600 --> 02:13.600 Just kind of some of the basic functionality. 02:13.600 --> 02:16.600 It lets you build software packages, you know, like archives. 02:16.600 --> 02:19.600 They hold an executable to, like, actually run software. 02:19.600 --> 02:21.600 And all of it's dependent, like, run time dependencies. 02:21.600 --> 02:25.600 It's dynamic libraries and configuration files, those types of assets. 02:25.600 --> 02:30.600 And then those archives, those packages get stored on a server. 02:30.600 --> 02:34.600 And distributed to machines that actually want to run the code using the update framework. 02:34.600 --> 02:38.600 And these packages get stored in content, address storage. 02:38.600 --> 02:43.600 So we break them up into pieces and, you know, put them in this content address storage. 02:43.600 --> 02:46.600 It allows us to de-duplicate blocks across packages. 02:46.600 --> 02:52.600 So we can save on network and storage costs if two archives have the same pieces in them. 02:52.600 --> 02:56.600 And then, at runtime, we take those blocks out of content address storage. 02:56.600 --> 02:59.600 We ressembled them into a directory structure. 02:59.600 --> 03:05.600 And then we can launch name-space sandboxed processes using those executables. 03:05.600 --> 03:10.600 With that directory from the package as the roots of the process. 03:10.600 --> 03:13.600 Hopefully, this is familiar to a lot of you. 03:13.600 --> 03:17.600 Now, I wouldn't be surprised if most of you hadn't heard of rockets. 03:17.600 --> 03:19.600 This next slide's not as surprised. 03:19.600 --> 03:22.600 Rocket didn't end up lasting long-term. 03:22.600 --> 03:25.600 The project was officially spun down in 2020. 03:25.600 --> 03:28.600 But development really kind of petered out around 2017. 03:28.600 --> 03:33.600 And when, you know, I stopped looking at the rocket and turnly core lessons. 03:33.600 --> 03:34.600 And moved to other projects. 03:34.600 --> 03:36.600 It's fun and less interesting. 03:36.600 --> 03:40.600 So I looked around for other cool things happening in the space. 03:40.600 --> 03:42.600 And I learned a fuchsia at Google. 03:42.600 --> 03:43.600 And I wanted to work on it. 03:43.600 --> 03:46.600 So in 2018, I managed to join Google. 03:46.600 --> 03:48.600 And more than Google, I was working. 03:48.600 --> 03:52.600 I was put on what later become the component framework for fuchsia. 03:52.600 --> 03:57.600 And my new manager at Google was explaining, like, what the software's deck does. 03:57.600 --> 03:59.600 How it's supposed to work. 03:59.600 --> 04:03.600 You know, the basic objective of it, along with, you know, some of our partner teams. 04:03.600 --> 04:07.600 So we were going to build software packages, holding all the dependencies for an executable. 04:07.600 --> 04:10.600 It's like run a process and all the dynamic libraries and things it needs. 04:10.600 --> 04:13.600 We're going to distribute those using the update framework. 04:13.600 --> 04:15.600 So machines that want to run the software. 04:15.600 --> 04:19.600 Those, you know, packages get broken up into content and stored in content address storage. 04:19.600 --> 04:21.600 Did you duplicate labs? 04:21.600 --> 04:24.600 Though we reassemble those labs into a directory structure. 04:24.600 --> 04:27.600 And then launch sandbox software out of this. 04:28.600 --> 04:30.600 This is sound familiar. 04:30.600 --> 04:31.600 So I like asked around. 04:31.600 --> 04:35.600 Like, why does this look so similar to the Linux technology? 04:35.600 --> 04:40.600 And all the people working in the project, most of them came from, like, Android and Chrome. 04:40.600 --> 04:43.600 And, like, they knew of Docker, but they weren't, like, you know, ex-personant. 04:43.600 --> 04:48.600 And they had somehow stumbled upon a cleaner implementation of containers, 04:48.600 --> 04:51.600 except on an entirely new operating system. 04:51.600 --> 04:54.600 I found this really fascinating. 04:55.600 --> 04:57.600 But of course, the projects aren't identical. 04:57.600 --> 05:01.600 You know, this is very, like, broad strokes definition I just gave. 05:01.600 --> 05:04.600 And to kind of show the ways that are identical, 05:04.600 --> 05:08.600 I'm going to walk through some of the main ways that they diverge, 05:08.600 --> 05:13.600 the ways that, you know, are models and designs and functionality, 05:13.600 --> 05:15.600 are different between the two sides. 05:15.600 --> 05:19.600 And for this talk, I sat down and thought up, you know, like, where do these differences come from? 05:19.600 --> 05:23.600 What are some of the main things driving, you know, the fact that these aren't identical projects? 05:23.600 --> 05:26.600 And so some of those differences I came up with. 05:26.600 --> 05:28.600 Of course, Fuchsia is not Linux. 05:28.600 --> 05:32.600 We have a different kernel with different CIS calls, different functionality, 05:32.600 --> 05:33.600 different APIs available to us. 05:33.600 --> 05:36.600 And that, of course, changes what the project looks like and the functionality 05:36.600 --> 05:39.600 that we then offer to users of the component framework. 05:39.600 --> 05:42.600 I'll get into the second point more later. 05:42.600 --> 05:43.600 Kind of all these later. 05:43.600 --> 05:44.600 This is the agenda. 05:44.600 --> 05:47.600 One versus many hosts on Fuchsia were typically, 05:47.600 --> 05:52.600 a component typically is concerned with other components on the same machine. 05:52.600 --> 05:55.600 You can't necessarily make that assumption in the container world, 05:55.600 --> 05:57.600 like if you have a Kubernetes setup, for example, 05:57.600 --> 06:01.600 when you are talking to your PC to some other container that could be on the same machine 06:01.600 --> 06:04.600 that could be on the side of the data center that could be on the side of the planet. 06:04.600 --> 06:07.600 You know, such things are possible. 06:07.600 --> 06:10.600 And at the end of the day, we also accept different objectives, you know, 06:10.600 --> 06:14.600 what people typically try to do with containers versus what we're trying to do with components. 06:14.600 --> 06:17.600 Also, a disclaimer at this point in time, 06:17.600 --> 06:19.600 I, you know, was working in the Linux container space, 06:19.600 --> 06:23.600 but I haven't really looked at it in fact since 2018. 06:23.600 --> 06:26.600 So I'm mostly going to be talking to like the Docker type of, 06:26.600 --> 06:28.600 you know, Linux container, you know, 06:28.600 --> 06:30.600 those are the things like system-based systems, 06:30.600 --> 06:32.600 the end spawn, of course, and more. 06:32.600 --> 06:36.600 So just, when I say container, just so you can guys know what I'm talking about. 06:36.600 --> 06:38.600 Let's get into the first one. 06:38.600 --> 06:39.600 Fuchsia is not Linux. 06:39.600 --> 06:44.600 To kind of like show, I think one of the bigger differences between Fuchsia and Linux, 06:44.600 --> 06:46.600 I've made this slide. 06:46.600 --> 06:51.600 And it's kind of showing like what the kernel is responsible for, 06:51.600 --> 06:53.600 versus everything that lives in user space. 06:53.600 --> 06:57.600 You'll see here that the Fuchsia kernel is responsible for a lot less. 06:57.600 --> 06:59.600 Our kernel, our kernel is names are kind. 06:59.600 --> 07:01.600 It does not know what a user or a group is. 07:01.600 --> 07:03.600 It does not know about file systems. 07:03.600 --> 07:04.600 It does not run drivers. 07:04.600 --> 07:07.600 It does not know anything about networking, 07:07.600 --> 07:08.600 and so on and so forth. 07:08.600 --> 07:11.600 And all of that has been lifted up into user space. 07:11.600 --> 07:15.600 And the thing that manages user space is our component manager. 07:15.600 --> 07:19.600 In our stack, it fits into a more similar part of the system. 07:19.600 --> 07:23.600 This system does, you know, instead of Docker. 07:23.600 --> 07:29.600 And with a zircon or kernel, not doing as much. 07:29.600 --> 07:32.600 An important thing to ask, I guess, what does it do? 07:32.600 --> 07:36.600 The easiest answer that is it's a capability-based operating system. 07:36.600 --> 07:40.600 This is a security model and design model for how operating systems can be built. 07:40.600 --> 07:43.600 And to make sure we're all working with the same definition, 07:43.600 --> 07:46.600 I'm just going to quickly run this through the definition that 07:46.600 --> 07:49.600 Wikipedia gives us for capability. 07:49.600 --> 07:53.600 So capability is an affordable token. 07:53.600 --> 07:56.600 So it's like a token you have that other people, other processes, 07:56.600 --> 07:58.600 can't just easily copy. 07:58.600 --> 08:00.600 This token references an object. 08:00.600 --> 08:02.600 See, there's an object somewhere that using the token, 08:02.600 --> 08:04.600 you know, it'd be like points at it. 08:04.600 --> 08:08.600 The token has access rights that denote what you can do with that object. 08:08.600 --> 08:12.600 The token can be used to access the object. 08:12.600 --> 08:15.600 So if you have the token, you know, that's free and free and 08:15.600 --> 08:18.600 supermission to go and read or interact with. 08:18.600 --> 08:22.600 You know, whatever operations are possible on the object. 08:22.600 --> 08:25.600 And the token can be shared with other programs. 08:25.600 --> 08:27.600 So you could have a token, you could make a token, 08:27.600 --> 08:30.600 and then give it to your buddy process over there to do something with. 08:30.600 --> 08:33.600 And I know this is all really high level. 08:33.600 --> 08:36.600 So to tie it into something, there's a type of capability that 08:36.600 --> 08:38.600 all of you are already familiar with. 08:38.600 --> 08:41.600 Because file descriptors fit this definition perfectly. 08:41.600 --> 08:44.600 A file descriptor is a token, you know, like some, you know, 08:44.600 --> 08:46.600 number that is given to you by the kernel. 08:46.600 --> 08:49.600 It references an object in this case a file or directory of 08:49.600 --> 08:50.600 black device. 08:50.600 --> 08:51.600 It has access rights. 08:51.600 --> 08:53.600 You know, you can open a file to be read only. 08:53.600 --> 08:55.600 And then with that file descriptor, if you try to write call, 08:55.600 --> 08:57.600 that's going to fail. 08:57.600 --> 09:00.600 The file descriptor, yeah, can be used to access the object, of course. 09:00.600 --> 09:02.600 And a file descriptor can be shared with other programs. 09:02.600 --> 09:05.600 Using the send-in as Jesus call, you can send, you know, 09:05.600 --> 09:08.600 open a file descriptor and send them between processes. 09:08.600 --> 09:12.600 So to kind of understand what the fuchsia, what the zircon, 09:12.600 --> 09:14.600 like system call interface looks like, 09:14.600 --> 09:17.600 imagine if a process could only use file descriptors. 09:17.600 --> 09:20.600 And other types of system calls are not available. 09:20.600 --> 09:22.600 Imagine you like start a process. 09:22.600 --> 09:25.600 It is treated into an empty directory. 09:25.600 --> 09:28.600 So can't access anything by default that way using paths. 09:28.600 --> 09:32.600 And during process initializations, hand it open file descriptors 09:32.600 --> 09:34.600 to the handful of directories around the system. 09:34.600 --> 09:37.600 And then has to use those to reference and interact with the world. 09:37.600 --> 09:40.600 If it doesn't have a file descriptor to something, 09:40.600 --> 09:42.600 then it can't interact with it. 09:42.600 --> 09:46.600 It can't be named it because there's no strings or path-based operations. 09:46.600 --> 09:48.600 At least at the start of it. 09:48.600 --> 09:52.600 Everything is referencing an existing token that you can give in. 09:52.600 --> 09:58.600 And so to type back to fuchsia, you see here how a lot of stuff 09:58.600 --> 10:01.600 that the Linux kernel is responsible for has been moved into 10:01.600 --> 10:03.600 user space being run by components here. 10:03.600 --> 10:06.600 Because that's a user space that means you need a capability 10:06.600 --> 10:09.600 to be able to interact with all of these types of things. 10:09.600 --> 10:12.600 And we call capabilities on fuchsia handles. 10:12.600 --> 10:15.600 So you need a handle to interact with these things. 10:15.600 --> 10:20.600 And by default, a process on fuchsia, a new component, 10:20.600 --> 10:22.600 doesn't get access to any of this. 10:22.600 --> 10:25.600 A default component has a handle to its own process. 10:25.600 --> 10:28.600 So it can do system calls related to itself. 10:28.600 --> 10:29.600 A hand to its own job. 10:29.600 --> 10:32.600 A job is a type of container for processes. 10:32.600 --> 10:34.600 It's not that interesting for right now. 10:34.600 --> 10:36.600 And a handle to its package directory. 10:36.600 --> 10:39.600 So we can read dynamic libraries or configuration files, 10:39.600 --> 10:41.600 or stuff like that that's been bundled for it. 10:41.600 --> 10:44.600 A component, by default, with no other configuration, 10:44.600 --> 10:46.600 does not have any access to immutable storage. 10:46.600 --> 10:48.600 It does not have any access to the network. 10:48.600 --> 10:51.600 It cannot launch other processes. 10:51.600 --> 10:53.600 Other processes? 10:53.600 --> 10:55.600 By default, it doesn't even have the ability to embed logs. 10:55.600 --> 10:58.600 It can't even send strings off somewhere for you to see. 10:59.600 --> 11:01.600 It can interact with any other components, 11:01.600 --> 11:02.600 aside from a package provider. 11:02.600 --> 11:07.600 Because remember, file systems are also components. 11:07.600 --> 11:11.600 Yeah, and this means that most of the configuration knobs we have, 11:11.600 --> 11:14.600 available to developers, are about these capability handles, 11:14.600 --> 11:18.600 to noting which capability handles are needed as inputs to a component, 11:18.600 --> 11:21.600 and which capability handles are being created by component, 11:21.600 --> 11:23.600 and provided back to the system. 11:23.600 --> 11:26.600 So for an example, let's compare, I think, 11:26.600 --> 11:30.600 like kind of a basic developer flow for Docker and components. 11:30.600 --> 11:32.600 So we have just a Docker file here. 11:32.600 --> 11:35.600 I just ripped this off from their docs somewhere, 11:35.600 --> 11:37.600 and then a sample of component manifest. 11:37.600 --> 11:40.600 The component manifest, it's a JSON-5 file developers 11:40.600 --> 11:43.600 are expected to write them to note the inputs and outputs 11:43.600 --> 11:46.600 from their component along with some basic information, 11:46.600 --> 11:47.600 like how to run it. 11:47.600 --> 11:50.600 So, some of the key differences here. 11:50.600 --> 11:54.600 The component manifest does not say how to build the component, 11:54.600 --> 11:56.600 where the Docker file does. 11:56.600 --> 12:00.600 The Docker file, you know, kind of as a full-term key solution 12:00.600 --> 12:04.600 around like assembling, building, and running container. 12:04.600 --> 12:08.600 On Fuchsia, all of our building happens in an external build system, 12:08.600 --> 12:09.600 like Basel, for example. 12:09.600 --> 12:13.600 And the build system, you know, will package up the JSON-5 file, 12:13.600 --> 12:15.600 or an Ethereum, you know, 12:15.600 --> 12:18.600 print trends, like compilation processes, 12:18.600 --> 12:22.600 and put a binary blob based on it in the package. 12:23.600 --> 12:26.600 Both of them do note how to run the application. 12:26.600 --> 12:28.600 On the Fuchsia side, you know, 12:28.600 --> 12:30.600 here's a path to an executable inside the package. 12:30.600 --> 12:33.600 That's used to inflate a process. 12:33.600 --> 12:36.600 And on the Docker file, we're given a command to run, 12:36.600 --> 12:38.600 you know, in a shell-like environment, 12:38.600 --> 12:40.600 inside of the container. 12:40.600 --> 12:41.600 The component manifest, 12:41.600 --> 12:45.600 notably specifies that it needs permission to connect to a log server. 12:45.600 --> 12:47.600 If you should at logger.lux. 12:47.600 --> 12:51.600 That's our IPC protocol for sending logs. 12:51.600 --> 12:54.600 Containers by default can make any outbound network connections 12:54.600 --> 12:55.600 they want. 12:55.600 --> 12:56.600 Of course, you can configure this. 12:56.600 --> 12:59.600 But so Docker file isn't necessarily going to specify what 12:59.600 --> 13:02.600 network, you know, things that needs to be available to function. 13:02.600 --> 13:06.600 And both them specify that something is going to be provided 13:06.600 --> 13:08.600 available for connection. 13:08.600 --> 13:11.600 On the Docker side, it's just something is on port 3000. 13:11.600 --> 13:14.600 And the component manifest, there's a bit more details, 13:14.600 --> 13:16.600 where saying, you know, what type of handle here, 13:16.600 --> 13:21.600 and the IPC protocol. 13:21.600 --> 13:26.600 Like that definition, we're excited to speak over that protocol. 13:26.600 --> 13:30.600 Yes, that's one subject here. 13:30.600 --> 13:32.600 Another one is one host of many. 13:32.600 --> 13:37.600 It kind of comes down to the size of the universe for components versus containers. 13:37.600 --> 13:43.600 As I mentioned, components usually only care about other components on the same machine. 13:43.600 --> 13:47.600 They're all working together to make a single device function. 13:47.600 --> 13:52.600 Whereas containers, it's more common to have deployments compared to components 13:52.600 --> 13:54.600 where they can exist on different machines. 13:54.600 --> 13:56.600 You know, you might have, you know, failover. 13:56.600 --> 14:01.600 You might, you know, want to have a website where it's okay if one machine crashes. 14:01.600 --> 14:07.600 And this lens to different pressures on how these things work. 14:07.600 --> 14:12.600 And change is what's possible within these two sandboxing technologies. 14:13.600 --> 14:17.600 And one of the key things about components is our IPC thing, 14:17.600 --> 14:19.600 which you saw reference earlier. 14:19.600 --> 14:22.600 We call it fiddle, the Fuchsia interface definition language. 14:22.600 --> 14:27.600 It's kind of like the ERPC, you know, you write out a protocol like definition 14:27.600 --> 14:30.600 around like what functions are available, but other return types. 14:30.600 --> 14:34.600 But the reason why we came up with our own is that this allows us to natively 14:34.600 --> 14:39.600 reference and work with fuchsia specific concepts and functionalities. 14:39.600 --> 14:44.600 So as an example, here is a function in one of our fiddle calls. 14:44.600 --> 14:46.600 This is in our loader service. 14:46.600 --> 14:48.600 This is used during process initialization. 14:48.600 --> 14:52.600 When a process is started, it uses this to talk to whoever started the process 14:52.600 --> 14:57.600 and ask it for memory objects of the dynamic libraries that it means to, you know, 14:57.600 --> 15:01.600 do its linking and get up to being a functional, you know, process. 15:01.600 --> 15:04.600 So let's say we have process B that was started by process A. 15:04.600 --> 15:07.600 Process B sends the string object name when making this call. 15:07.600 --> 15:12.600 Process A returns a result code and actually a VMO, which is a virtual memory object. 15:12.600 --> 15:17.600 And that's the key bit here because these components are all in the same machine. 15:17.600 --> 15:20.600 They can rely on sharing machine local resources. 15:20.600 --> 15:26.600 It's very common, very trivial on Fuchsia to have shared memory between components that 15:26.600 --> 15:31.600 they negotiate over our IPC language, whereas in containers it's going to be more difficult 15:31.600 --> 15:35.600 to set up shared memory between two containers because you may even know if you have 15:35.600 --> 15:37.600 the same memory available. 15:37.600 --> 15:40.600 Of course, you can do stuff over the network, but there's different latency and, you know, 15:40.600 --> 15:44.600 speed expectations there compared to when you're on the same machine, 15:44.600 --> 15:46.600 sharing the same memory. 15:46.600 --> 15:50.600 Another big difference around the size of the universe is fault tolerance 15:50.600 --> 15:55.600 and how the software that runs in these things is expected to behave when problems show up. 15:55.600 --> 16:00.600 On the container side of things, if some container dies, you know, you're running along 16:00.600 --> 16:02.600 and you're using it, oh no, trashed. 16:02.600 --> 16:08.600 It's not that hard to just stand up a new container, update it CD or DNS or whatever 16:08.600 --> 16:13.600 to point to that, and everything can keep going, you know, can recover in a way. 16:13.600 --> 16:16.600 Compared to on components, one component dies. 16:16.600 --> 16:19.600 Typically other components that have a connection to it also die. 16:19.600 --> 16:23.600 It's very normal to be like, oh, if the connection breaks, if there's an issue with 16:23.600 --> 16:27.600 talking to this server, I'm dependent on just trashed. 16:27.600 --> 16:30.600 Let's just blow up the world. 16:30.600 --> 16:35.600 And this isn't to say that the system-based components is more fragile 16:35.600 --> 16:37.600 than the system-based on containers. 16:37.600 --> 16:41.600 The difference is that in the component world, things like talking to your file 16:41.600 --> 16:45.600 system are within the inter-components, like, communication. 16:45.600 --> 16:51.600 Containers, when they're talking to something else, like, there's more an assumption 16:51.600 --> 16:53.600 of the network, could you know, have a problem. 16:53.600 --> 16:55.600 The other thing could crash, but I need to be okay. 16:55.600 --> 16:59.600 Whereas on both systems, if your file system crashes, if EXT4 crashes on you, 16:59.600 --> 17:01.600 that machine is going down. 17:01.600 --> 17:03.600 Your container is not going to survive that. 17:03.600 --> 17:07.600 Whereas the component land, our framework is more, you know, 17:07.600 --> 17:09.600 we immediate those connections. 17:09.600 --> 17:12.600 We, you know, determine who's allowed to talk to the file system. 17:12.600 --> 17:20.600 So the, yeah, we aren't as resilient to handling one component crashes 17:20.600 --> 17:24.600 and having that out of effect on the components, because just the definitions here 17:24.600 --> 17:25.600 are different. 17:25.600 --> 17:27.600 The space we're working in is a little bit different. 17:27.600 --> 17:31.600 And this brings me to my last point, which is just that we have different objectives. 17:31.600 --> 17:35.600 What we're trying to do with components versus how containers are often used 17:35.600 --> 17:39.600 to, you know, build software and build solutions. 17:39.600 --> 17:42.600 I'm just going to wrap and fire through some of the small differences here. 17:42.600 --> 17:46.600 Commonly, containers have larger package sizes than components. 17:47.600 --> 17:49.600 It's very normal to bring in like a base OS image. 17:49.600 --> 17:50.600 You know, have like a shell. 17:50.600 --> 17:51.600 It'll have a package manager. 17:51.600 --> 17:57.600 And, you know, you run commands in there to, you know, set up your software to, you know, 17:57.600 --> 18:00.600 grab, grab dependencies and produce an archive that you can run. 18:00.600 --> 18:04.600 And then that base OS image, all the libraries that came with you might not use the package 18:04.600 --> 18:06.600 manager, all gets shipped with your application. 18:06.600 --> 18:11.600 Whereas, because our build system is external to the component framework, 18:11.600 --> 18:14.600 it assembles really minimal packages. 18:14.600 --> 18:17.600 We do not put a shell in a package for a component. 18:17.600 --> 18:21.600 If you need to shell into one, the tooling can provide a shell that will drop into that same 18:21.600 --> 18:24.600 namespace, sandbox environment. 18:24.600 --> 18:27.600 And also deployment is different. 18:27.600 --> 18:30.600 If you want to deploy a new container, you just knock or run it. 18:30.600 --> 18:33.600 Yeah, if you're using Kubernetes or Docker Compose, it can be more complicated, 18:33.600 --> 18:35.600 but things in between to run time. 18:35.600 --> 18:41.600 You can go and change, you know, like, like, system units if you want to, 18:41.600 --> 18:42.600 and, like, reload them. 18:42.600 --> 18:47.600 Whereas, on Fuchsia, pretty much all of the components that are going to run on the system 18:47.600 --> 18:50.600 are fixed at the time the operating system is built. 18:50.600 --> 18:53.600 There are small buckets that can have things dynamically launched with them, 18:53.600 --> 18:56.600 with really well-defined, like, limits on what they can access. 18:56.600 --> 19:02.600 But, by and large, adding a new component to Fuchsia requires, like, a full OTA of the device. 19:02.600 --> 19:06.600 Yeah, and this brings us to differences in deployment. 19:06.600 --> 19:12.600 We're typically running a single consumer device, where all components are working together 19:12.600 --> 19:17.600 for that singular purpose, whereas it's, you know, perfectly reasonable and container space 19:17.600 --> 19:19.600 to have a much more heterogeneous workload. 19:19.600 --> 19:22.600 You might have two different clients who want to run two different websites. 19:22.600 --> 19:23.600 They don't need to need to be aware of each other. 19:23.600 --> 19:28.600 We're going to co-locate them on your machine or something. 19:28.600 --> 19:32.600 And one of their big differences is how cross sandbox orchestration works, 19:32.600 --> 19:36.600 how you group together containers to get them to work together versus components. 19:36.600 --> 19:41.600 Typically, in container space, you need some other solution sitting on top of Docker, 19:41.600 --> 19:43.600 or whatever your containerization solution is. 19:43.600 --> 19:45.600 This is why Kubernetes exists. 19:45.600 --> 19:50.600 Docker compose can be thought of as a layer on top of the basic Docker containerization stuff, 19:50.600 --> 19:54.600 whereas the component framework itself carries the relationships between components 19:54.600 --> 19:56.600 and how they interact with each other. 19:56.600 --> 19:58.600 And this is kind of a big difference. 19:58.600 --> 20:01.600 Components are organized in a tree. 20:01.600 --> 20:04.600 Containers are a flat name space. 20:04.600 --> 20:07.600 You can run, you can add a container, you can remove container. 20:07.600 --> 20:09.600 It's just in the list of containers running. 20:09.600 --> 20:12.600 Whereas every component aside from the root has a parent component, 20:12.600 --> 20:14.600 it potentially children components. 20:14.600 --> 20:19.600 And let's pick on, this is an example of what Fuchsia actually looks like. 20:19.600 --> 20:21.600 It's missing a lot, of course. 20:21.600 --> 20:24.600 But let's pick on the network component via here. 20:24.600 --> 20:28.600 Then we're component from the perspective of the core component. 20:28.600 --> 20:30.600 It's just, you know, it's a node, everyone's staff. 20:30.600 --> 20:32.600 But if you go and look at the network component, 20:32.600 --> 20:34.600 it's actually made up of a handful of components. 20:34.600 --> 20:39.600 And that network component, when things are made available to it, 20:39.600 --> 20:41.600 when they're available and it's inputs, 20:41.600 --> 20:45.600 you can then make those available to whichever and any child it has. 20:45.600 --> 20:48.600 And likewise, anything available from one of its children, 20:48.600 --> 20:51.600 you can make available back to the parent of the network component. 20:51.600 --> 20:55.600 And it even makes it easy to keep things like, 20:55.600 --> 20:57.600 let's go up within here. 20:57.600 --> 21:01.600 If NetC of Gene needs to use something from the HCPD, 21:01.600 --> 21:03.600 all of that can exist within the network component. 21:03.600 --> 21:06.600 And the network component does not need to have that in its inputs or outputs, 21:06.600 --> 21:09.600 meaning that it's parent, the core component doesn't get to see 21:09.600 --> 21:11.600 or not interact with any of this. 21:11.600 --> 21:15.600 And this makes it easier to organize things 21:15.600 --> 21:18.600 and provides for better encapsulation. 21:18.600 --> 21:21.600 It means that if you have a component that's running and doing stuff, 21:21.600 --> 21:23.600 and you want to break it up into a handful of components, 21:23.600 --> 21:24.600 you can do that. 21:24.600 --> 21:27.600 And it works well within our system. 21:27.600 --> 21:30.600 And this also brings us another key thing. 21:30.600 --> 21:33.600 The network component exists for organization and, like, 21:33.600 --> 21:34.600 configuration and stuff. 21:34.600 --> 21:37.600 And you can know all of that statically in a manifest file. 21:37.600 --> 21:39.600 This means the network component does not have an executable. 21:39.600 --> 21:43.600 There's no running process for that component on our system. 21:43.600 --> 21:45.600 And this is another key difference from containers. 21:45.600 --> 21:48.600 It's trying to non-sensical to have a container with no process 21:48.600 --> 21:52.600 that's intended to run in it, whereas that's normal on Fuchsia. 21:52.600 --> 21:57.600 And this type of system, where the network component kind of have, 21:57.600 --> 22:01.600 you know, a handful of children, allows us to have all of that, 22:01.600 --> 22:05.600 you know, owned and scoped within and owned by a specific team on Fuchsia. 22:05.600 --> 22:08.600 So the network team can own the network component and whatever 22:08.600 --> 22:09.600 they want in there. 22:09.600 --> 22:13.600 And all of what's going on in there, the connections between those things, 22:13.600 --> 22:15.600 is invisible to the rest of the system. 22:15.600 --> 22:17.600 And not really bulletin to the rest of the system. 22:17.600 --> 22:21.600 So it makes it easy to kind of have their security boundaries as well, 22:21.600 --> 22:25.600 and that aligns with their organizational boundaries. 22:25.600 --> 22:27.600 Yeah, so there's a lot of differences. 22:27.600 --> 22:31.600 I listed that at some of them here for just like a summary slide. 22:31.600 --> 22:35.600 I find it fascinating that for such a different purpose, 22:35.600 --> 22:39.600 from engineers who didn't really come from ladies container land, 22:39.600 --> 22:43.600 they would build something that relies on some of the same building blocks. 22:43.600 --> 22:46.600 And I think the ways in which the two projects are different 22:46.600 --> 22:48.600 is also very interesting. 22:48.600 --> 22:51.600 Like for example, containers have way more nod than the ability 22:51.600 --> 22:53.600 to talk about network configuration than components do. 22:53.600 --> 22:55.600 A typical component is not talked to the network, 22:55.600 --> 22:58.600 but I wouldn't be surprised that something we need to do eventually. 22:58.600 --> 23:01.600 So there's, you know, learnings both ways I think that are potential. 23:01.600 --> 23:03.600 Anyway, that's my talk. 23:03.600 --> 23:05.600 We have time for questions now. 23:05.600 --> 23:15.600 All right, any questions? 23:15.600 --> 23:26.600 No, so my question was related to whether I was a difference 23:26.600 --> 23:28.600 with a component and an application. 23:28.600 --> 23:32.600 Because as part of the first point around how future 23:32.600 --> 23:36.600 is different from a container, you mentioned that components 23:36.600 --> 23:39.600 are set in style mode as I always build time. 23:39.600 --> 23:43.600 Does that mean all the applications that you want have to be set in style 23:43.600 --> 23:46.600 when you package OS for a particular machine? 23:46.600 --> 23:49.600 So if I want a new application, I need to effectively build the OS again. 23:49.600 --> 23:52.600 Or is there an ability to add something later? 23:52.600 --> 23:56.600 Yeah, so you've noticed I've been a little fast 23:56.600 --> 23:59.600 and lose with my definitions in this slide presentation. 23:59.600 --> 24:03.600 But so most components are fixed at built time, as I mentioned. 24:03.600 --> 24:05.600 But you're able to define these little boxes. 24:05.600 --> 24:07.600 You can put components in dynamically. 24:07.600 --> 24:10.600 And the way that that works is each component, you know, 24:10.600 --> 24:14.600 by their parent is, you know, given in the component manifest, 24:14.600 --> 24:18.600 the set of things that are the inputs and expected outputs of that component. 24:18.600 --> 24:20.600 Where you can say, I'm going to run the network component. 24:20.600 --> 24:21.600 You get all these things. 24:21.600 --> 24:22.600 I need these things from you. 24:22.600 --> 24:25.600 And the way these boxes work is very similar. 24:25.600 --> 24:27.600 You can set down this little box and be like, this box, 24:27.600 --> 24:31.600 and anything that's going to go into this box will get this limited set of access to, 24:31.600 --> 24:33.600 you know, these handles, you know, from those places. 24:33.600 --> 24:36.600 And then at runtime, you can watch things in those boxes 24:36.600 --> 24:39.600 that get access to those specific handles. 24:39.600 --> 24:41.600 They're specified statically up front. 24:41.600 --> 24:44.600 This means if you have specific types of things you want to run dynamically, 24:44.600 --> 24:48.600 like drivers, it's, you know, easy to have the little box, 24:48.600 --> 24:50.600 but, you know, the things that drivers might need. 24:50.600 --> 24:52.600 And there's there are some knobs for runtime configuration, 24:52.600 --> 24:54.600 about that are kind of limited. 24:54.600 --> 24:58.600 But this means that you need to have a specific box that fits the shape of what you want to run. 24:58.600 --> 25:01.600 So if you find a box that is sensible for user applications, 25:01.600 --> 25:03.600 there might have a lot of things available to it. 25:03.600 --> 25:05.600 You know, user applications tell you when to access the network, 25:05.600 --> 25:07.600 multiple storage and all this other stuff, 25:07.600 --> 25:11.600 whereas the box, again, for drivers or for file systems or, you know, 25:11.600 --> 25:14.600 for other types of things, just like developer tools, 25:14.600 --> 25:16.600 you're going to have different inputs available to them. 25:16.600 --> 25:18.600 So if you do want to go and run something dynamically like that, 25:18.600 --> 25:20.600 you need to specify the box for it up front, 25:20.600 --> 25:24.600 and, you know, make sure that that fits whatever applications 25:24.600 --> 25:26.600 you're going to want to run inside that box. 25:26.600 --> 25:28.600 Does that make sense? 25:30.600 --> 25:32.600 Anyone else? 25:32.600 --> 25:34.600 Oh yeah. 25:40.600 --> 25:42.600 Thank you for the talk. 25:42.600 --> 25:45.600 I actually watched this project for a while, 25:45.600 --> 25:46.600 and I was always wondering, like, 25:46.600 --> 25:48.600 what is this actually targeting? 25:48.600 --> 25:52.600 Because I haven't seen this operating system the while so far. 25:52.600 --> 25:54.600 When the concepts look really cool, 25:54.600 --> 25:58.600 and I would imagine there is several places where this could be used, 25:58.600 --> 26:00.600 but where is it actually used? 26:00.600 --> 26:02.600 Great question. 26:02.600 --> 26:05.600 I'm not allowed to talk about future plans around the project, 26:05.600 --> 26:07.600 but I can't talk about what has already happened. 26:07.600 --> 26:13.600 So we do today run on the type of project from this place. 26:13.600 --> 26:15.600 It's a Google Assistant with a screen on it. 26:15.600 --> 26:18.600 You can ask it things and it will show up on this screen what's happening. 26:18.600 --> 26:21.600 So all those devices now run Fuchsia. 26:21.600 --> 26:27.600 And it's a really interesting part of the project for that migration, 26:27.600 --> 26:31.600 but yeah, I don't know if that answers your question. 26:31.600 --> 26:33.600 There's a consumer device out there that runs our software, 26:33.600 --> 26:37.600 and I can't really talk about future plans around that. 26:37.600 --> 26:48.600 On your example, I always assumed they were just running Android device. 26:48.600 --> 26:52.600 So what's relationship with Fuchsia and Android? 26:52.600 --> 26:56.600 Android runs on top of the Linux operating system, 26:56.600 --> 26:59.600 and Fuchsia is separate from that. 26:59.600 --> 27:01.600 There's no formal relationship between them. 27:01.600 --> 27:04.600 If you have an Android phone, that's running on Linux, 27:04.600 --> 27:07.600 that's the stack that you're familiar with. 27:07.600 --> 27:10.600 Fuchsia is not in the same space right now. 27:14.600 --> 27:16.600 I think there was another question over here. 27:22.600 --> 27:26.600 You say that you resemble the files from a content address 27:26.600 --> 27:29.600 blobs to back to directories, do you copy them? 27:29.600 --> 27:31.600 Or do you do something else? 27:31.600 --> 27:33.600 No, we do something else. 27:33.600 --> 27:35.600 So we do a deduplication based on the file. 27:35.600 --> 27:37.600 Instead of Docker does it based on layers, 27:37.600 --> 27:40.600 really the commands in the Docker file. 27:40.600 --> 27:42.600 So we have what we call blobFS. 27:42.600 --> 27:45.600 Every file is stored in a content address way. 27:45.600 --> 27:48.600 And we have the manifest file that specifies for this package. 27:48.600 --> 27:51.600 We need this blob at this path, this blob at this path, and so on. 27:51.600 --> 27:54.600 And we have different files system implementation. 27:54.600 --> 27:57.600 So that speaks our IPC for the file system. 27:57.600 --> 28:01.600 The components speak the IPC for the file system to that thing. 28:01.600 --> 28:03.600 And that presents the actual file system view. 28:03.600 --> 28:06.600 You would expect the right paths and names and everything. 28:06.600 --> 28:08.600 And whenever it goes to read a file, that then gets 28:08.600 --> 28:11.600 forward to the correct blob in blobFS, 28:11.600 --> 28:16.600 using the cache of the expected content for that file. 28:16.600 --> 28:20.600 So this looks like BGR of the package. 28:20.600 --> 28:21.600 Yeah. 28:21.600 --> 28:22.600 Yeah. 28:22.600 --> 28:24.600 There's some similarities. 28:24.600 --> 28:26.600 All right. 28:26.600 --> 28:28.600 We are the time, but thanks a lot. 28:28.600 --> 28:29.600 Yep. 28:29.600 --> 28:30.600 Thanks everyone for coming.