Check, one, two, hello.
Hello.
Hi.
Where's Malte?
Hi.
Nice to meet you.
Okay.
Sorry.
Just like one of my hacker friends that has been working with me on the project.
I've actually never met him in person, so nice to meet you.
Anyway, today we're going to be talking about Aura or Aode, however you want to pronounce
it, is fine, which we're temporarily calling a distributed systems runtime, and that's
the name that has caused the least amount of friction over the past few months.
Okay.
So, my least favorite slide, my slide about me, so I'm an engineer, I work at GitHub,
I helpkeepgithub.com online, sorry about the Shaw thing last week.
Yeah.
So, I keep a lot of systems online, some of you may or may not use them, all of you hopefully
have good opinions of them, and then if you want to follow me on the Fediverse, there's
where you can follow me.
So I'll do overview and context, so if you want to go to the GitHub repo, you can grab
a photo of this or just remember it, the link to the slides are there right now, I just
forced push to main like two seconds ago, so you can go and you can see the slides and
there's like links to everything there that I'll be going over today.
So if you want to grab that, go ahead and grab that.
Okay.
So, we're going to start off, I'll do a little bit of context, I'll answer the question,
what is Aura, what does it do, and then we'll spend the last two thirds of the presentation
talking about Rust and why we decided to use Rust for the project and some reports about
how it's going so far and some of my experience as well.
Okay.
So, just show of hands, who here has heard of Aura before?
Oh, God.
Okay.
Well, thank you for following my project, that makes me very happy but also a little
terrified.
So anyway, Aura, it's an open source Rust project and it's aimed at simplifying node
management at scale.
And so, when I talk about it, I usually say it's basically a generic execution engine
for containers, VMs, and processes.
The really quick pitch that I'll give on Aura is all of these things, containers, VMs,
hypervisors, and basic process management is all that I do at GitHub and all that I
have done in my career for the past 10 years.
And I have used a plethora of tools to do this and I was tired of learning and managing
all these different tools and so I hope that this will be the last tool I ever have to
work on in my career.
So I wrote a thesis about the project and I'm trying hard to continually reevaluate this
thesis and basically it says that by bringing some deliberate runtime controls to a node,
we can unlock a new generation of higher order distributed systems.
And what I mean by that is, in my experience, a lot of the things we do on a node are organic
and grew over the past 30 years or so.
And this is more of a deliberate set of what do we need in the enterprise and what do we
need at a bare minimum on the node.
And I think that if we get that right, we're actually going to have a much more interesting
conversations in the coming decades.
So I also believe that simplifying the execution stack will foster and secure observable systems
while reducing complexity and risk.
And complexity, if you have ever ran Kubernetes, is the name of the game.
Cool.
So I'll be talking about these things called nodes today.
So node is a keyword.
And when I say node, pretty much always in life, but very specifically in this talk,
what I mean is a single compute unit in a set.
So this would be one or more computers that we're trying to group together and manage
as a set of computers.
So when we do one thing to a node, the sort of assumption here is you want to go and
do this twice or three times or 10,000 times sometimes or so on.
So when we say node, I want you to think of a set of computers or an array of computers.
OK.
So what does Aura do?
So the thesis here is this is going to be a central control for every runtime process
on a node.
So whether you're running PID 1 or a container or a virtual machine, the hope is that all
of this can be funneled through the Aura binary at runtime, and Aura will have the ability
to not only manage it, but also observe it and control it and start it and stop it.
And who knows?
Maybe even one day debug it if I'm very lucky.
It runs as a minimal in its system.
So this is important.
A lot of folks want to compare Aura to system D. And the more I think about it, the more
I think that I really believe Aura and system D have different goals.
Aura doesn't really want to become a desktop manager.
In fact, it kind of wants to be the opposite of that.
It wants to be as lightweight and as minimal as possible.
In a perfect world, there would be no user space on an Aura system because we wouldn't
actually want users touching a single computer.
Remember, we're managing sets of computers.
And so the hope here is that we can make this as lightweight as possible.
Additionally, we want this thing to have a remote API.
So the idea of a single person sitting at a desk and operating on a single node is kind
of irrelevant here.
So everything that we do on the node, whether it's scheduling another process like a bash
shell or it's scheduling a container, should all come through this remote API.
And we're going to learn more about this API in Rust specifically later on in the talk.
Also it runs on Linux.
Right now it's tightly coupled to the Linux kernel.
So what doesn't it do?
So it doesn't do generic desktop support.
So that's just completely out of scope.
I don't want to deal with your Bluetooth drivers.
I don't want to deal with your sound drivers.
I don't want to manage your desktop interface.
I don't care.
In a perfect world, this hooks up to network and that's about the most advanced user interface
we're going to have to one of these nodes in a set.
Additionally, higher order scheduling is out of scope.
So when we talk about enterprise management, whether it's some sort of orchestration system
like Kubernetes or not, a lot of those discussions very quickly go into the scheduling discussion.
There was a really good article, I think it was yesterday or the day before on Hacker
News that came out of fly.io about their orchestrator experience with Nomad.
I see somebody shaking their head.
Yeah, you read the article.
It was a great article.
And maybe we can find a link to it and put it in the video or something for folks.
But that conversation was very much about how do we make scheduling decisions with available
resources today.
And that is pretty much all I do at my day job at GitHub and that's all I've been doing
managing Kubernetes for the past five or six years.
And so while I'm very interested in having that conversation, my hope is that by simplifying
the node, we can make those scheduling conversations easier in the future.
And what I mean by that is that we will have less to say about what we actually do on a
node and we can effectively make nodes boring.
So it doesn't run on Darwin and it doesn't run on Windows.
Like I said, we're tightly coupled to the Linux kernel, which if you haven't pieced
it together yet, is why Rust is very exciting for the project.
Okay, so again in summary, where did Aura come from?
It came with challenges with complexity at scale, so we just want the node to be boring.
And it became, there was this desire to simplify and secure the stack.
So I do deeply believe that with simple systems come secure systems.
Every hack that I've been a part of in the industry has usually started with some sort
of disparate and unknown fragmented attack surface that somebody's been able to exploit
and do some sort of lateral movement once they're into the system.
So if we can simplify that and we can just make the conversation involve less moving
pieces, my hope is that we can actually secure the stack.
I also want there to be a stronger node API.
So who here has ever debugged the KubeLit API before?
Who here even knows what this is?
Okay, so we have a handful of people.
So the KubeLit is a Kubernetes version of we're going to go run an agent on a node.
It does have an API, last I checked it was undocumented and it was tightly coupled with
the Kubernetes control plane.
We hope to break that.
We hope to just have a generic API that you could use to run a single process remotely
or you could schedule millions of processes remotely and we want that to be a very strong
and thoughtful API.
One of the big lessons of running large distributed systems at scale is that the bigger you get,
the less trust that you can have in the people working on your systems.
So as I've grown either like my small mastodon server that's grown into a medium sized mastodon
server or even dealing with thousands of nodes at scale.
One of the lessons that I've noticed is that all workloads tend to this untrusted banality.
So the bigger you get, the less you can trust a single workload.
And even if these workloads are on the same team as you, you really want to start looking
at them as an isolation zone that you don't want to trust too much from the centralized
control plane perspective.
So we started off ORA with a few guiding principles.
Number one, I want it to be boring.
So we're targeting a single binary.
We want this binary to be polymorphic in nature.
Who here is familiar with Busybox?
Great.
Yeah, Busybox.
It's a good binary in my opinion.
I really like what it does.
There's a switch on R0 and it basically behaves like however you call it.
So we're trying to get some similar functionality into the ORA binary as well.
And we also want this thing to be lightweight and have a very strong scope and be as low
risk as possible.
Additionally, we wanted this thing to be attainable.
We wanted to play nice with others.
So I knew that I wanted this to fit in neatly with Kubernetes.
I knew I wanted this to fit in neatly with Linux.
And I knew I wanted pretty much everyone in this room to feel realistically like they
could be running this thing on their laptops one day as the project grows.
And so in order to do that, the API was going to be the majority of what we were talking
about as we began developing the project.
And ultimately, I wanted it to be functional.
I don't want it to subserve the needs of a corporation.
I don't want it to serve the needs of a higher order control plane.
I literally just want a standard library for executing processes in containers and VMs
at scale.
What we do with that is out of scope.
I just want it to work first and foremost.
So ultimately, I want boring systems.
And if you see in the background here, there's all of these like subtle distributed system
propaganda notes that you can go look at if you want to look at the slides later.
So ultimately, I wanted the thing to be safe.
So when we're looking at tenant security, one of the questions I ask is, how do we make
it easy to do the right thing?
And I think that comes from the underlying infrastructure.
And in our case, Aura is the underlying infrastructure.
And we intended to build a very strong project here that would unlock this sort of safe paradigm
that we could give a team a binary, and they would be able to run their applications on
top of it.
And we wouldn't really have to worry about anybody sneaking out of their container or
accessing any parts of the systems.
We didn't want them to access.
So tenant security is a strong motivator for this as well.
OK.
So about six months ago on Twitch, which I do a Twitch stream.
You should maybe follow me if you want to learn more about the project.
But I started to write this paper.
And it was mostly as some bro in chat was like, yo, why don't you just go rebuild system
D?
And I was just like, maybe I will.
And so anyway, I ended up writing this paper.
And so, well, here we are.
And so the paper really grew.
And it started to answer a bunch of questions about, why should we go write it and go?
No, no, no.
We should go write it in C, because C is going to be the most common language that will interface
neatly with the kernel, and we can do EVPF probes and so on.
No, no, no, no.
We should go write it in Rust.
You can go look, there's a Google doc, and it's just got all these comments of people
from all over the internet, all over the industry, arguing about what we should do.
And eventually, we settled on, we want a lightweight node, Damon, and thus became the Aura runtime
project.
OK.
So this is where we shift from the conceptual, what is Aura?
How did we get here?
What problems does it solve?
And we start to get a little deeper into the code.
So when we originally started the project, we started writing it in Go, the Go programming
language.
And there's two kind of predecessor projects that later turned into Aura, which is written
in Rust.
This first one that we call Aura Legacy, which up until about five, well, I guess 15 minutes
ago now, but right before I walked into the room, this was a private GitHub repo, and
I've gone ahead and actually opened it up.
So if you want to go see the original code in Go, there's some really interesting things
in there.
We did some libp2p bit torrent style routing between nodes, where you can build a nest of
nodes and things.
But you can really see where this runtime, Damon, started and some of the original concepts
that we were tinkering around with.
Ultimately, though, we ran into a lot of the same problems that I ran into in Kubernetes,
which was I needed to start recreating these objects, and I needed to start reading some
config, whether that be YAML, JSON, or something similar, and then marshal that onto a struct
in memory, and then go and do arbitrary things with that, in our case, schedule a pod.
And one of the things that was kind of outstanding in the back of my mind was, what about access
to libc?
I knew as soon as we started scheduling containers and DMs, we absolutely were going to need
native access to libc.
Additionally, there's this project called NAML, which is basically Turing Complete Kubernetes
Config, it's written in Go, and it just uses the Go SDK, and that was yet another way of
sort of validating this idea of we need to start making our system stronger and building
stronger interfaces for teams to manage different parts of the stack.
So those are the two sort of precursors to the Aura runtime as it exists today.
That of course, writing it in Go came with some challenges.
The big one here is obviously native access to libc.
We were going to be creating C groups against the Linux kernel.
We definitely wanted to use the clone3 system call, and the container runtimes of today
had some assumptions about how we were going to be executing the clone3 system call that,
of course, I had to disagree with because, hi, have you met me?
I have to disagree with everything.
And we also wanted to implement some ptrace functionality as well.
So obviously, Go was going to give us some challenges here when it came to using CGo,
so Rust became very exciting and definitely got a lot of attention very quickly as we
were writing the Go side of things.
We also wanted ebpf for networking.
I personally want it for security and maybe for some other interesting service mesh ideas,
but I do think that having ebpf for networking as a non-negotiable, we're definitely going
to want to simplify what Kubernetes refers to as kubeproxy that we can now invent our
own name and hopefully simplify that layer, but I digress.
We also wanted some access to native virtualization library, so all the KBM stuff is written in
C. And if you go look at the Firecracker code base, that is also written in Rust that vendors
the KBM bindings.
And so we knew we would want to access these three components, and all three of these are
going to be problematic with Go.
Update as of about an hour ago, I went to the state of the Go room across the hall here.
Did anybody else go to the Go talk this morning?
Yeah, we got three or four hands up here, so this kind of pissed me off.
Go has unwrapped now as of 1.2.0, and they also freaking have.clone.
And I was just like, bro, get off our keywords, this is totally like, this is our thing.
So anyway, it's really exciting to see Go taking these concepts a little more seriously,
and if you've ever written Rust before, who here has written unwrap in Rust?
Put your hands down, we're not supposed to do that, I don't know what we're supposed
to use now, I just get so much shit on my Twitch stream every time I write unwrap, but
yes, we do have unwrap and clone in Go now, which is just a strong indicator that we're
likely doing something right with Rust.
So anyway, I made the decision to move to Rust, and I didn't know very much about Rust
when I made the decision, and I literally just started out the main function and said,
we'll figure it out as we go, and I ordered the Rust book and just jumped in and started
to write code with the hope of accessing kernel constructs and C groups and EBPF probes.
So what could possibly go wrong here?
Okay, so how are we doing on time, by the way, we're 15 minutes in, okay, cool.
So Rust to help us solve the YAML problem, I suspect we're all familiar with feeding
YAML to machines, we've all done this before at some point in our lifetime, okay.
So this is a thing I do a lot working in large distributed systems, and I work with people
who do this a lot, and if we do it so much, we've tried to get really good at doing it,
and that I think, that's an interesting discussion.
So in my opinion, so warning, Chris Nova opinions here, in my opinion, all config ultimately
is going to drift towards Turing completion.
So I see this C++ templates, anybody, anybody C++ templates, okay, Helm charts, customizing
Kubernetes, any of the templating rendering languages that you see in web dev and front
end work, there's all kinds of interesting Python libraries that will allow you to interpolate
your config and so on.
In my opinion, a good balance is kind of something like bash that is Turing complete, but it
just comes with some strong guarantees.
And so I knew very quickly that I didn't want to be feeding YAML to Aura.
I definitely didn't want to recreate this idea of we're going to have to manage a thousand
pieces of YAML because we have a thousand different nodes.
So I wanted to explore more about what are some options that we have here, so we're not
just feeding YAML to machines anymore.
So thus became this really interesting project of mine, we'll see if this pans out, which
is this binary called AuraScript.
So AuraScript is a, it's a Rust binary, we have it compiling with Muzzle today, and embeds
all of the connection logic for a single machine.
And so we'll talk more about the semantics of AuraScript in a second.
But ultimately what you need to understand to kind of get the initial motivation here
is that this aims to be an alternative to managing YAML at scale.
So I found this really fascinating type script runtime called Dino.
Have folks heard of Dino before?
Can I swear in here?
I, FN, love Dino.
I'm sorry, I really like this project.
If you want a good example of like, hey, I just want to see a really successful Rust
project that has a really strong community, I would encourage you to just go look at the
Dino project.
I think their code is beautiful, I think what it does is beautiful, I think the way that
they manage the project is beautiful, it's just a really good quality project and it
solves a problem for us with Aura.
And so Dino is basically, it's a runtime for type script and it's written in Rust.
And the way the project is set up, that you can go and you can add your own custom interpreted
logic and you can build fancy things into the binary and you can do things with the
type script interpretation at runtime, which is precisely what we needed to do with Aura.
So here is the model now.
So instead of feeding YAML to a single node, we now have this higher order set of libraries
that we can statically compile into a binary and we can interpret it directly on a machine.
So in order for you to interface with an Aura node or a set of nodes, all you need is one
binary, mtls config and then whatever type script you want to write.
And this is an alternative to like any of the Nomad command line tools or the Mesos
command line tools or the Kubernetes, kubectl, kubectl command line tool.
And now you can just write it all directly in type script.
So this is actually a concrete example of what would be, what system D would call a
unit file, what Kubernetes would call a manifest and what Aura just calls a freaking type script
file because we don't have fancy names for our stuff yet.
So you can see here at the top, we basically contact the Aura standard library.
We get a new client and then we can allocate this thing called a cell.
A cell is basically an abstraction for a C group.
We cordon off a section of the system and we say like we want to use a certain percentage
of the available CPUs on a node and I want it to only let processes run.
In this case for 0.4 seconds and then we'll use the kernel to just kill the process if
it runs longer than that.
And so the first thing we would do is we would allocate that which is an improvement over
Kubernetes as it exists today because we can allocate resources before we actually start
anything in that area and then we can go ahead and actually start whatever we want.
And so you can see I simplified the example just for today but it's just, it's remote
command injection as a service.
So this whole talk was just basically like how to go and run a bash command in on a server.
And so now you can express your commands and similar primitives that you would see in other
run times directly in TypeScript.
The interesting thing here is TypeScript is just natively more expressive than a lot of
the Amble things that we see today.
In this case we can actually do math but I'm sure you can imagine you can do other things
as well.
You can access logic, loops, if statements, there's if branching and so on.
And so we were able to actually solve some of these like templatey rendering style problems
by just doing things natively in a well known and easy to understand language such as TypeScript.
So patterns started to emerge.
So Rust gave us the ability to generate the TypeScript binary with all of the magic behind
the scenes MTLS security config that we wanted.
And so now the conversation was a little more like this which is how do I manage a small
set of TypeScript and it's much more flexible and you can start to actually express things
the way that we used to and just express things statically and then you can have all of your
Turing complete logical components below and you can mix and match these however you want.
So in addition to addressing the YAML problem with Dino and TypeScript, Rust also helped
us to solve the sidecar problem and by us, I mean this is our hope as we operate our
mastodon servers and our various other ridiculous side projects that we operate both in my basement
and in a colo in Germany.
So talking about sidecars, who here knows what a sidecar is, show of hands, okay most
folks do.
Okay, so a sidecar that is always available with the same features as a host.
So this is going to sound a little bit weird and the slide is going to look a little bit
weird but just bear with me as we kind of like unpack what's actually going on here.
What we want that I don't think we're talking about is that sentence.
I actually think what we want is we want a sidecar to sit along our applications that
does literally the exact same things we have to do on a given host whenever we're managing
these workloads at scale.
As I began looking into writing sidecars at the host level, I began drilling deeper and
deeper into the C programming language as I was writing this in Rust and just made the
connection that memory safety was going to be key because we're going to be running these
demons right alongside of your workload.
And so unpacking the need to do this really helps you understand why we shifted over to
Rust.
So again, another Chris Nova opinion, any sufficiently mature infrastructure service
will evolve into a sidecar.
So if you have done any sort of structured logging, in my opinion, if you will continue
to build structured logging and you'll continue to ship logs, that will eventually turn into
a sidecar that you're going to want to go run beside your app so you have this transparent
logging experience.
You can rinse and repeat that paradigm for pretty much anything, secrets, authentication
data, and so on.
And so I started to see these patterns kind of surface.
And very specifically, I started to look at how would I solve these with Rust?
And as it turns out, the Rust ecosystem had a plethora of pleasant surprises for me as
I started to explore what putting some of these features into a binary would look like.
Logging was boring because we could just use Tokyo Streams, Auth N and Auth Z was boring
because all I had to do was just use the Rust-derived primitives to just start applying Auth Z to
each of our units in the source code.
Identity was boring because I didn't even get to fight with open SSL anymore.
We just had to use Rust TLS and that was easy.
And so the network was also easy because we had native access to Linux and Lib C so we
could just very boringly schedule a Linux device and we got a Linux device and it was
pretty straightforward.
So we were able to create this at the node and now my question was how do we bring this
into the workload level at scale?
And I think this is where most of the conversations you start talking about things like Istio and
service meshes and structured logging and so forth.
And I actually think that we can simplify that conversation too.
And so what we were able to do with Aura is we just spawned the root daemon and use that
as the new PID one in any of our nested isolation zones.
And when I say spawn, I very directly mean like we literally read the byte code from
the kernel and we build an image at runtime with the byte for byte, the same byte code
that's running on the host and then we can just go and execute whatever we want against
the same API as the original host runs and all of this is memory safe.
So I can put this right next to your application in the same namespaces running in a container
or running in a virtual machine and there's a relatively low risk of any sort of binary
exploitation at scale.
So here's a model of what that looks like.
So on the left big side here we have the Aura host daemon and on the right we have the three
types of isolation zones that you can run with the daemon.
You have a cell sandbox which is effectively a C group, a pod sandbox which is a group of
containers running in unique Linux namespaces and a virtual machine which is effectively
a container with a kernel and some virtualization technology.
All of this is possible with Rust natively and all of this was made possible by spawning
the binary and creating these nested isolation zones at runtime.
Additionally Rust was able to help solve the untrusted workload problem because of the
memory safety and that Rust offers and because of this really interesting model that we have
right here.
So this is a zoomed in model that might look familiar if you've ever done any container
escapes before and in this model basically what we're saying is we're replacing any sort
of like pause or initialization sequence in an isolation zone with the same daemon we
run on the host.
So I think the Rust binary for Aura right now is about 40 megabytes and we can just
copy that into a container and run that alongside your application.
So it's a relatively small application, runtime that will sit right alongside of your app
so managing memory from MTLS and RID.
So as I'm writing Rust one of the things I notice is I start paying attention to memory
management more every time I try to clone something or the freaking borrow checker yells
at me that kind of like is a small like grim reminder of my roots as a C developer.
This is an interesting takeaway the only memory that we need to share that multiple parts
of the system have access to in this entire model whether we're creating containers or
VMs is the shared MTLS config.
So this is the only bit of shared memory that we really have to manage and Rust very clearly
called that out and to be a candidate I don't think I would be able to as be as comfortable
with this model if I was doing this in something like go.
So Rust was able to help us solve the maintainability problem so somebody say Rust macros.
So we have a really brilliant guy future highway who helps us work on the project and future
highway is our resident macro guy.
Does everybody here have a macro guy in your team?
Because you should.
He has made things a lot simpler for us.
So one of the things we struggled with go in Kubernetes specifically was like how do
we generate objects with unique logic.
Rust macros were a solution to this for us.
So if you've ever looked at the Kubernetes code base you can see we've created these
things called CRDs that started out as third party resources and we've built this entire
bespoke API machinery system that basically is a glorified macro system that allows us
to generate go in the project.
So we're allowed to use Rust macros now and it's a very simple model in the code base.
We basically have a combinatorics problem where we're able to map the different primitives
to the different logical systems that are unique to us and we can generate our source
code as needed.
And so our source code ends up looking like this which I think we've successfully achieved
boring for a low level run time.
This is a fairly straightforward call and then we can be confident that the code it
generates is unique to the project and encapsulates all of our concerns as maintainers.
So really the whole conversation now is just the proto conversation.
Everything can be generated by Rust macros.
The whole project really is pretty much on autogen at this point.
You can just go introduce a new field in the API and then you can spit out a new client,
it'll plumb itself into the run time, it'll plumb itself into the AuraScript library and
everything is given to us for free just because of macros in Rust.
And so this is our code path and the way that we're able to take advantage of macros.
We do a lot of manual work, we fight with the borough checker, we make some improvements
and then we get done and we encapsulate it into a macro and we can simplify our code
path by just replacing all of that with a macro after we've been done.
And so this is the Aura project as it exists today, which again I'm very stoked to say
that this is a very boring exercise.
So a quick update and then I'll be done with my talk here.
There's a few components, all of which are written in Rust here.
Number one, the AuraD daemon is the main static binary that's written in Rust and compiled
with Muzzle.
So we can ship that without any of the shared objects on the host directly into an isolation
zone.
AER is a completely generated from Proto Client.
So this is exciting, we can actually call a GRPC API directly from the client, we don't
have to do any of the run time plumbing.
So if we add a bool to the Proto file, we get dash dash bool directly in the client
compiled for free without typing a single line of code.
So this is a very exciting primitive for us, so we can just begin to have API conversations
and not necessarily care about the internals of the program anymore.
AuraScript is completely generated and we have this exciting project down here, which
is AE, which is an alternative command line client written in Go.
So ultimately the lesson here is Rust was able to help us solve the boring problem.
We have a very complicated, very obscure piece of technology that is you don't really have
to do much to work on it anymore.
Most of it's on autopilot at this point and most of the conversations are very philosophical
in nature and not necessarily about how to implement things in the software.
So takeaways about the project, Aura is completely stateless, so you can restart a node and it's
basically empty until you push config to it, which means all of our systems are declarative
like NixOS now and you can just pass things like TypeScript or JSON to them and it makes
it easy to manage things like containers.
Next we have some to-dos for the project and I would encourage you all to get involved
and if you want to see a demo of all this, I'll be out here in the hallway after the
talk and you can come and you can track me down and I'm happy to give you a demo.
So anyway, I think we have a few minutes for questions and five minutes for questions,
so I'll take questions and if you want to get involved, here's how to get involved and
I'm Chris Nova, please clap.
You mentioned the size of the binary being, does it work?
You mentioned the size of the binary being 40 megabytes, is that with size optimization
or no?
Sorry, say that again?
Is the size of the binary at 40 megabytes with size optimization applied already or
no?
No, that's completely unoptimized, that is like just straight out of the compiler without
any aftermarket tuning.
Amazing talk, quick question.
So if I want to have just enough Linux to like pixie boot into this thing, like do
you guys have any templates because it feels like a shame to run it on something like
RHEL, like I just need like enough of Linux to just pixie boot into that?
Yeah, so the question is basically can we pixie boot this and then you mentioned RHEL.
Where we're going, we don't need Red Hat, so I guess what I would say is in theory all
you need to run is static Linux kernel and Aura and a network connection and some MTLS
config, and so everything else at that point, all of your packages, your services, your
daemons are passed to it via the API.
Hi, you mentioned that you use a lot of macros.
I've also run into problems where, you know, you have a combinatorial explosion of templates
in C++ speak or something like that.
What are your thoughts on generics for generating some of this rather than macros in order to
be a bit more type safe, I suppose?
Personally, I got a little drunk with generics, I'm not going to lie.
When I first moved over from Go, because I was just so excited about it, the reason
I like macros is because we can add logic to them.
So we have, like to give you an example, we have containers and we have VMs.
So we'll have a section of the macro dedicated just to VMs that manages the kernel.
And that's irrelevant to the container systems in the project because containers run on the
host kernel.
And so we can embed those small branches directly into the macro code so that macros generate
slightly different outputs based off of the inputs that are given to them.
So for Aura, when you're dealing with similar systems of code that have small nuances like
we are, macros really, in my opinion, are the way to go.
Did I answer your question?
Looks like.
A simple question, so can I actually give the configuration instead of like Aura script
or TypeScript just in Rust?
Yeah, of course.
So we have this Rust client here, it's basically a Rust SDK.
And then we have a tool called AER, which takes it a step further and it's automatically
generated with macros.
And it's a compiled binary that you can just use from the command line.
So you can just type commands directly into it and it will run against the server on the
back end.
Do you think code is Rust?
Yeah, there's also an SDK.
So you could write your own Rust code and it's GRPC.
So you could generate, you could write it in Go or in WeDo and you could write it in Python
or Ruby or realistically anything, any client you want.
Hi.
I was wondering when you talk about the remote API, have you considered a future direction
to make this a unicolonel?
A unicolonel.
Yeah.
I have a slide for this.
So I added like a bunch of like FAQ slides to the end because I knew that we were going
to get all these good questions.
The answer is it depends, hold on, let's see if I can't find it.
You guys get to see.
There it is.
It depends.
What does unicolonel mean to you?
I think the most minimal system we could do would be a Linux kernel as it exists today,
like good old fashioned stock Linux giant make file to hold nine yards.
And then the ORID daemon and that would be the minimal system.
Anything else you would need to pass to it at runtime?
I think we have time for about one more question.
So you said it doesn't do any higher order scheduling.
I guess I'm kind of curious what, if you want to do things like resilience or steering
or if the job dies, bring something back up, what are people typically using with Aura?
So Aura is still very new.
I think that my hope for the project is kind of like the same hope I had with my book,
solve the lower layer first and then that is going to open the door for higher order
conversations in the future.
My hope is that there's a whole ecosystem of schedulers.
You change your scheduler, you change your socks, well maybe not that often, but the
point would be that that's very specific to the needs of the current organization that's
working on it.
And I would hope that we can still use the Kubernetes scheduler or the Nomad scheduler
to schedule jobs on Aura.
I know there's also some machine learning folks who have some data resiliency problems
that are interested in Aura right now and plan on using some weird global mesh that will
do a peer-to-peer network around the world, kind of like BitTorrent, and then they intend
to use Aura for that.
So I think there's some opportunities there.
The project itself won't ever have an opinion on a scheduler.
Maybe I personally will start another project to do that in the future or something, but
this is the scope for now.
So that's all the time we have.
Okay.
Can we hear it again?