[MUSIC PLAYING]
AMJAD MASAD: Today I want to talk about how we brought--
what everyone is hearing about today
with serverless, how we brought that model to cloud IDEs.
And, essentially, we didn't do it on purpose.
We almost did it accidentally.
So what Repl.it is, before I get into the serverless stuff, is--
our mission is to bring programming to more people.
We want to be able to support any device, any computer
out there.
Anyone who has a computer should be able to code.
Coding should be as easy as opening a new tab.
That's sort of like what we do.
And from there we kind of get progressively more advanced.
And I'll show you some of the stuff
that you can do with the platform.
So it is essentially an online IDE
for more than 50 programming languages.
Zero setup, you can just start immediately.
And it's becoming also a platform
for hosting code and hosting apps.
And on top of that, we have a very friendly, open community
for people who are getting started with programming,
and even advanced programmers as well.
So I'll give a quick demo.
So the getting started experience
is that you basically pick a programming language.
I'm just going to pick Node.js here.
You name it.
So let's say, devzone.
Create a REPL.
And you're immediately booted up with an interactive programming
environment.
You see a big, green Run button.
And that kind of invites you to just start coding and start
doing something.
On the right, we have the REPL.
And you can sort of--
it's like an interactive REPL.
You can define variables.
You can console.log variables, and do anything
you can do with a REPL.
But it gets a little bit more interesting when, say,
you want to require--
let's say you copied some code from the internet
and had the library Lodash.
Repl.it will automatically detect that
and will start installing the package.
So that's something we do to just make
programming a lot easier.
And so I can use any--
you immediately get really good autocomplete as well.
So you don't have to set up any LSP or anything like that,
we just do it for you.
And I can run that.
Where it gets really interesting is
that let's say I want to get a server running.
So I can do something like import Express JS.
So I can go to our package manager and import Express.
Let me just zoom that in.
The moment I hit Add, it will create a package.json for me
and will start installing Express.
By the time I go back to the editor,
Express is already available for me.
I can require that.
I can start Express app.
I have an app.
And say on root, we're going to just say "Hello, world."
And someone shout a port for me.
Any port.
8080, I heard.
So any port would work.
The IDE will detect that you're trying to do web programming
and will open up a web view.
And now we have a website hosted at devzone.amasad.repl.
And it just-- it's cut off on your side
here but it just says, "Hello, world."
And that's, like, hosted forever.
You can come back to it any time.
I could also open a shell.
And I could inspect my files from the shell.
And now you might be starting to think
that this is running on a VM, that there's like a VM
powering this on the back end and you
can do whatever you want on it.
However, it's not.
What we do, all of this is running in a container.
I'm going to just use Chrome DevTools to put it offline.
So I'm going to put it offline.
It stopped loading.
Now put it online again.
Everything went back to the same state.
And what has happened there is we
either spun down the container, or if we spun down
the container then we're going to start a new container,
we're going to bring all the existing state,
and there's going to be sort of a negotiation
protocol between the IDE and the container.
Like, here's my state.
I have a shell open.
I have a window that I'm programming a website open.
And we reconstruct the state in a matter of milliseconds.
We copy the files into the container
and we spin everything back up.
And this use case is not only viable for, like,
web programming.
You could also do native application programming.
So here's like the famous pygame--
the famous sort of pygame game framework.
And I'm just going to run one of their examples.
And we're going to stream down VNC and start
playing games in the browser.
And let me go back to the presentation now.
So let me walk you through a little bit of history
of how we built this.
And then I'll go into a little bit more detail on the back end
and how we built our, like, fake VM via serverless model.
So what we want is we want a sandbox to execute code in.
We want to execute unsafe code that was given by our users.
And it needs to have access to system resources.
Anything that you can do beyond the simple case of practicing
a program, you have to actually use system resources.
Network, file system, etc.
It should work everywhere.
Should be cross-browser.
And it should load fast, and should be extremely cheap.
Right now, today, Repl.it has more than a million
monthly active programmers writing code on our platform.
If we were to give a VM to everyone, like, say, Google
Shell or some of these VMs with an online editor,
it's going to be very, very costly.
And most of our users don't have the money
to actually pay for that.
So our first pass, we're like, OK.
Since we want this cheap, what we're going to do
is we're going to actually compile all the languages
to JavaScript.
We're going to use Wasm.js and we're
going to emulate this [INAUDIBLE] layer on the client
to make it work on your browser.
We ran into a lot of problems.
It had a huge bundle size.
We had a 15 megabyte JavaScript bundle
for like Python and all the kind of Unix interfaces.
And you know if you're someone with a Chromebook
somewhere with a really bad connection
and you're downloading this much JavaScript,
you're going to run out of memory just trying
to parse the JavaScript.
And it also didn't have access to real system resources,
no matter how much we tried to fake it.
So now we moved it to the back end.
But that was two--
that was almost three years ago.
And serverless wasn't really a thing.
Like, it started becoming a thing,
but it wasn't even on our minds.
So we had to make something that was cheap enough
that we could run.
So it should feel like a VM.
But a VM is actually very costly, right?
So what we did, we're like, all right, we're gonna do it,
we're going to make it run on on-demand containers.
Containers should be ephemeral.
Any time we take out a set of computing--
anytime you're idle in the IDE we should
be able to take your container from you
and only bring it back when you're actually executing code
or you're doing something in the IDE.
It shouldn't run on preemptable Google Compute Engine or AWS
spot instances.
Basically you want to run it as cheaply as possible.
Preemptable compute is 80% cheaper.
So how do we do that?
And again, it's this ephemeral model.
It should have reproducible state.
So let's say we're on GCP preemptable They
take one of our instances and your coding
on that in a container inside that instances.
We should be able to reconstruct the state
and should not basically feel that there was a change.
And it should scale up and down according to demand.
So here's the architecture that we came up with.
So we started building this before Kubernetes was
the phenomena that it is today.
Maybe if we built it today, we'd start with Kubernetes.
But when we started, we're like, OK,
we're going to have these virtual machine instances.
Inside them we're going to have Docker.
We wrote our own container manager orchestration system.
We're going to have the files live on GCS.
We're going to have some kind of state and redis and etcd.
And we're going to have a Docker image registry.
And then we're going to have a proxy that actually, whenever
a request comes in, finds the container
and connects you to the right container.
So when we start a REPL, which is what we call a project,
a REPL is basically a union of a Docker image,
a GCS state in terms of files, and some kind of internal state
about who the user is, and authorizations,
and what collaborators they have,
and different things like that.
So that's kind of the high level over overview of our back end.
To dig deep a little bit onto the components,
Conman is our container manager.
You can think of it as something like Kubernetes or Docker
Swarm.
It figures out what needs to run, where it needs to run,
and creates the containers for those things to run.
Pid1 is a program that we inject into the container.
And pid1 is basically the inits program that we use.
Pid1 knows how to talk our protocol.
And it's responsible for reproducing the state when
you get a new container.
So when you get a new container, we
inject this program at runtime that we call pid1.
It gets run.
And now it's negotiating the state with the client
in order to reproduce it to the best of its ability.
And then Container Registry, we like
to support a lot of languages, a lot of environments.
So for every environment we create a new container.
And we're constantly updating these containers.
Fixing bugs, releasing security issues.
So we use Google Container Registry to be able to do that.
And storage, that was like a no brainer to use GCS for storage.
For the proxy, you saw me how when I started a web server,
it just understood that I want to serve some external traffic.
And what we do is we add some state or redis,
and then our proxy knows where to send the traffic.
We get a cert from Let's Encrypt,
and we give you HTTPS on the fly.
And, finally, the state where I mentioned it,
it lives on redis and the other places.
[MUSIC PLAYING]