 Hello everyone. Welcome to the first normal talk of the day by RubyConf putting me in this slot. They demonstrated two things one that they don't understand what I do in the evenings and two they give me a chance to give you guys a little advice on the whole rest of the conference. So those of you that do know me know that me that I am extremely logical. So I will point out two things to you. One is when you are sitting in the chairs it is recommended that you sit inward next to the people in the middle so that when people come in then they can sit on the edges and not have to stand in the back or on the sides or what have you. So just I would say throughout the rest of the conference try to do that because normally I come in to talks late and then I'm sitting on the side and then I have to stand the whole time and then my talk is next and then I've been standing for an hour and a half. So keep that in mind. The second thing is and I want you to try this maybe you've never done it before but you come to these conferences you fly across the world you fly from Europe from Asia or maybe just from the United States from the other side of the United States where things are so different but you come here to watch presentations you don't come here to work on your website or to chat with your friends or to be in the IRC back channel making fun of me so just once pull out a pad of paper and a pen and as you watch the presentations write down ideas that you have while you're watching them and I promise you that you'll have a completely different experience for the whole conference if you do that because I used to open my laptop when people were talking and start working and studies show over and over that humans cannot multitask we really really suck at it So if you're working you're not listening and if you're not listening then why are you even here? That's all I'm gonna say about that My name is Tom Preston Werner. I co-founded github two years ago and Since then it's been amazing. How many of you have used it? Oh You're gonna raise your okay. I was gonna save the hand raising for a moment from now, but you can do it now Unicorn yes, let me tell you a little story about the unicorn the reason that the unicorn came into being is because the unicorn means Stuff is really really wrong. So when you see the unicorn instead of the octocat it means Stuff is bad. He came about when we moved off of engine yard on to our chartered architecture, etc He tells us when the unicorns are not even Processing or doing anything. So that's why we have a unicorn now This talk is called Bert and Ernie scaling your Ruby site with Erlang however before I jump into that I'm gonna do a little bit of a derailment to something else that I feel is very important it needs to be talked about in our community in all Programming communities and that is that I believe that NIH syndrome or not invented here syndrome is a myth I get this thrown at me every once in a while Specifically because of what we're talking about today the Bert and Ernie stuff But when I hear it it makes me a little sad for the person that just said it So let me let me demonstrate By making everyone in the room raise their hands by asking you a question How many people here on a regular basis use light bulbs? Okay, everyone except the Amish people in the room How many people here use Transistors, how many people here use Ruby? How many people here use engine X for the sake of the video that was basically everyone in the room every single time So let me ask you then Let me ask you then If we use all of these things what was so wrong with the counterparts what's so wrong with candles Why did Edison not improve the candle my by making a better wick he went a completely different route Why did the guys the three guys that invented the transistor the solid-state transistor? Why didn't they just make vacuum tubes smaller? Why did Matt's invent Ruby? Why does he was so wrong with PHP and Pearl coming come on right? Just added a class system the PHP and you're done the point the point being is that Sometimes new things do need to be invented and I think that when people say NIH syndrome What they're really missing is the opportunity that these new things can bring to bear So let me tell you a story about when I was a kid. This is not me When I was a kid I used to play outside a lot I grew up in Iowa and We had a lot of rain and a lot of dirt and those are basically the things that I played with because there was nothing else in Iowa no offense But I would go out as a kid and I would play in the dirt in the mud and my friend Tim and I we would be playing in the front yard Coming up with concoctions and putting grass in them and I remember very specifically that once I said After I'd created my grass and mud creation. I have created the cure for cancer This was the cure for cancer. All you had to do was eat it But the point of this story is as little kids. We're always inventing things. We're always creating things in our minds We're always looking for the next big thing. We want to be special. We want to be important We want to invent things. So what is it that when we get older? We now start saying you created something new that looks like something that I'm using NIH. Why do we do that? I? Think comes down to different types of programmers So I think there's maybe three categorizations of programmers The first ones are the people who just work their day jobs. They're making websites They're writing bank software They're just doing it and then when they go home they play video games or they they do whatever right, but they go home They're not programming. It's just a it's just a job to them. They don't love programming. They do it for a paycheck We call those Java programmers the second type is The kind of programmer that uses everything that's available to them to create awesome software But it's more customer-centric. It's they're building websites for clients. You're building tools for people to use But you're not really distributing those you're just you're crafting them They're very nice pieces of software, but you're really just using what's available and creating something for yourself or to sell Or something of that nature And I would call those types of programmers craftsmen the people that rely on what's already there They like what's there they're using it and not really producing things for other people to use those are craftsmen craftsmen are great A lot of us are craftsmen My friend who's a computer programmer just took up woodworking and he's becoming a craftsman of wood I think that's really that's really enjoyable. That's a great thing to do. There's nothing wrong with this however What I think is more important is the third class of programmer which would be the inventor the person that is not Satisfied with what is already there the person that has to go out and create something new every single day Those would be the inventors So inventions I think are not always incremental It's not just make a better wick for a candle. It requires jumps jumps of understanding and So just improving something that already exists sometimes isn't enough you have to take a logical step outside of what is already there and try Something completely new and maybe it'll fail and maybe it's actually a stupid idea But maybe it's genius think about this Think about the future every sci-fi movie you've ever seen put it in your head think about all the awesome cool stuff Think about Star Trek. They got tri-quarters. They got spaceships. There's a giant canyon in Iowa But think about that and think of all the devices and inventions that they have in the future that we don't have right now There is a mathematical theorem of which I forget the name But it essentially states that if you have two points on a continuous function Then you are guaranteed that that path will go through the midpoint on the y-axis between them very it seems very intuitive So think about down here as the present Think about that think about that as the president and the future is up here and all along here are all the inventions that have to be made In order for us to get to the future If that's true if there are so many of these things Then I would suggest that each one of us should be creating that one right there create one in the middle All of these things need to be created and they can't all just be improved from what already exists Sometimes you have to create something new So you might wonder how do you go about doing this? How do you go about inventing things? Maybe it's not really something that you're used to maybe you're a craftsman and you haven't invented a lot of stuff lately So what is the process by which you create new things? Well step zero not really a true step in this process read the fucking manual so that you don't invent something That's already been created Maybe you just misunderstand it Maybe it already does exist, but you're ignorant of it so be careful while you're inventing things Make sure that you're not just replicating something that someone's already done make sure there's some New truth some new thing in there step one do not Accept what already exists. I'm a very picky person when I use software if there's something wrong with it. I get Angry Maybe not angry, but disappointed or finicky. I just it doesn't make me feel good to use it There's a lot of software out there like this the API is weird or it doesn't do thing X or Y that I need and a lot of people would say well Why not just use it and maybe add a little on top and that'll be perfect a lot of these things aren't that way So step number one is Don't just accept it Don't accept the things that are wrong in your world Think about them write them down on your little pad of paper every time you think of something That's annoying when you're on an airplane and something's annoying write it down and then invent something to fix it Every time something annoys you is an opportunity for you to invent something new that fixes that problem step number two when you are Thinking these things these things that annoy you or whatever Recognize that you're probably not the only one that has that feeling If there's anything that I've learned from the open source that I've done It's that if I solve a problem for myself. I'm probably solving it for someone else And that helps me go forward on a project For instance, I created a project called God. That's a process monitoring framework I created that because I didn't like monitor I didn't like the syntax of the configuration files. I didn't like the way it was managed I didn't like a zillion things about it never worked for me I couldn't get it to run on one of the servers that I was running all of these little things Added up and I said well, maybe there's a better way to do this. Maybe I can do this completely differently Maybe I can do this in Ruby with a better syntax. That's just Ruby for the configuration file where I can actually use loops and things What a concept but these Are the kinds of things to think about and it turns out a lot of people have these similar types of frustrations And so a lot of people use God to manage their servers And it turned out that that was a good project similarly something like chronic which I wrote which is a time parsing library There was nothing there that did what I needed there was date that parsed But you can only give that a very strict set of things to do So I said well, maybe something new needs to be done and I didn't even look Very much at what existed because I wanted to just blank slate it I wanted to say I don't care the approaches that anyone else is taking This is a case where sometimes reading the manual is Something not to do you have to be careful. You have to choose those carefully and say I want to do this my way without Relying on what other people have done the approaches that they've done. This was also learning experience for me to do this But to give it a new approach a Completely new implementation for date parsing that you can use in Ruby and just pass it natural language So pay attention to the things That you don't like and realize that a lot of people probably don't like them either And the third thing is Spend some time thinking I was just on an airplane a lot over the last 14 days in Europe When you're on a flight you can do several things you can watch a movie you can read a book You can sleep but what I like to do is just sit there and think with my eyes closed And a pen in hand and a little napkin that they give you in front of me Just think about things when ideas come to me I write them on that little napkin and then when I get home I pull out that napkin I say hey look at all these little things I thought about actually I was thinking about some of the things for this presentation on the way home I Wrote them on a napkin and now they're in this presentation So take some time to just think about things think about the things that annoy you think about the things That could be the things that need inventing that don't exist yet and then To choose the ones that are relevant It should be almost obvious to you which ones are relevant They should just feel right use your intuition if something that you're thinking about feels awesome to you Then it probably is sometimes it's not sometimes we're a little eccentric and we're weird sometimes It's oh sometimes that's not true, but often I find for me at least That that's almost always true so it feels right Give it a shot and see what happens Okay, so now that we know how to invent things going to talk about inventing the new GitHub or specifically the new backend for github that runs the site right now Maybe you're on github right now because you didn't pay attention to me and you're actually working if you are You are using all of the stuff that I'm about to talk about So as many of you know, we recently moved off of engineer to rack space We did this primarily because we needed more flexibility in the hardware that we could run We are now running 17 hardware machines that run github So let me explain the problem that we had The problem is essentially this this is what the site looked like on engineer in a much simplified view We had a load balancer that distributed requests to several front ends Those front ends would then use the library that I wrote called grit That is a git binding for Ruby. It uses grit to communicate to the shared file system So every server every front end Had access to what looked like a local disk. It was actually GFS red hat GFS We're in this shared file system All of the front end machines would connect to that system the problem with this is When you start connecting a lot of machines to GFS like we did and you start just pummeling it with IO Like we are doing just insane amounts of IO always reading off disk to get information about the git repositories If there's any problem at all in GFS if there's a locking problem Or if one of the machines goes down and the fencing isn't right the fencing is what takes of Server out of the lock pool for GFS when things go wrong, then you're totally and completely screwed Because everything in that whole system relies on that shared file system So when anything goes wrong throughout the whole system the entire site goes down and this is bad. We do not like this So when we moved to rack space we decided that we would eliminate shared file systems We would get rid of them completely and we would move to some sort of federated or charter disk system So essentially what we want is something looks like this load balancer sends requests to a number of front ends Which now make Calls somehow to get the information from the git repositories to many different file servers And this as you'll realize is the fundamental principle of scaling Cheaply which is take one thing and turn it into many things This is how we spend a little amount of money and get a lot amount of scale Because these are just these file servers. You can just be commodity machines each one of these costs something like six hundred dollars a month at Rackspace and it has 1.8 terabytes of storage that's rated for 0.9 Terabytes of storage on each one of these and they still cost very very little in the grand scheme of things So how do we do this? How do we say? Here's front ends here's back ends or file servers whatever you want to call them And how do we get the front ends to talk to those file servers in an intelligent way? How does that happen? Because before it was just all local disk access. It was easy use grit repositories there call it a day But now something has to happen where the information from your repositories has to travel over the wire to the front end Instead of information back and forth. So there's two problems. There's two problems here. One of them is How does each machine? How's each front end machine figure out which back end machine to talk to? Because your repository could be on any one of these four file servers completely arbitrary So what we did is we introduced a routing proxy that all of the front ends connect to directly and Then from there It's redirected to a specific machine. We do that using a project called proxy machine that I wrote Fragments that you can go to to check this out. This uses event machine So it's super super fast event machine if you haven't used it is probably the most amazing piece of software in the world It means you can write fast Servers in Ruby because all of the event stuff is written in C plus plus I guess but The idea behind proxy machine is that you can use a little snippet of Ruby to become a router For this proxy so front end connects to the proxy Proxy takes whatever is in there Extracts a piece of that information. This is what we would call layer 7 or content aware routing It looks at it inspects the request it figures out what user you're talking about It does a look up we use Redis for a routing table and the information about where your repository is stored is in Redis pulls that out figures out where Your repository is and then just establishes a straight proxy with the final file server At that point stuff just goes back and forth like normal and you're done Everything is in C plus plus it never touches Ruby again at that point. So it's extremely extremely fast and very very stable the second problem is What What is going over the wire? What are the bits that are crossing this chasm? How do we do that? We decided to use a very simple approach that worked with this architecture, which is a very simple RPC So that the front ends can just make a call to the back end and say give me information about something by doing this we maintain Kind of a single picture of our application a very simple serialized Traceable stack through the whole system through this you could use something like a MQP for this we decided not to I don't think it's a specifically appropriate choice for this application Particularly because we're often transferring megabytes of data over that wire. We don't want to store that somewhere We'd rather it not be stored anywhere and just be immediately returned to the caller and because we're using Ruby everything is Generally serialized anyway. It's not a whole lot of parallelism per process So this solution fits pretty well So it came time to choose an RPC mechanism, there's about a billion of these out there things like thrift and protocol buffers Corba json RPC, etc. etc. and list goes on and on When I was looking at thrift and protocol buffers those were kind of the first things that I looked at I'd use thrift a little bit before at power set where I used to work the main problem here is IDLs or interface definition languages. These are the Specifications that you write to say here's the calls I'm gonna make and here's the schemas of those calls and you express in intimate detail your complete knowledge of this whole RPC mechanism that Then forward every developer on your team will have to have intimate knowledge of and modify every time any of these calls ever changes So as you can see from my vitriol, I'm not a huge fan of IDLs. I don't think they are appropriate for my needs or for the needs of many small businesses of teams that are small enough to where You're using agile practices You're using things like unit tests Basically doing things the Ruby way. I don't think that's something that's necessary Maybe for giant companies where things are talking to everything else and every department has to know kind of what things they can use Maybe these IDLs are actually useful, but they're not useful to me The other thing that I don't like in a lot of RPC mechanisms is code generation You take these IDL files and you plug them into some Program and on the other side comes just thousands of lines of stub code For your RPC calls and then you call them just like you would normal Code in your application and then magically things go over the wire and you're done The problem with this is one that every time your IDL changes you have to Generate this code if you're using a static or a compiled language now. You have to compile this code It's a lot of steps And sometimes this generated code is pretty bad because you have the authors of these systems writing these Generators for languages that they don't even really know One example would be the Erlang bindings for thrift were some of the most horrible code on the planet This is now perhaps remedied But it's a lot of extra work that someone has to do to write these generators to make this code The machines wrote the do stuff and hide stuff from you and makes things magical. I don't like any of that I don't like that whole process Because what I want to do as a programmer is make a call to something that exists on the back end And if it's there it works and if it doesn't it throws an exception just like every other day in my programming life And Ruby if I want to call a class or if I want to call a method on a class I call it and if it's there it works and if it's not it throws an error So I started looking at JSON I like JSON JSON is really nice. I especially like the concept of taking a piece of a language a Notation in this case take that and just rip it right out of the language that it's from and say hey everyone Whatever language you're using now you can use this For inter-process communications. I think that's a cool idea because it's something that already exists It's already been shown to be useful a lot of people use it It makes things in certain languages super super easy Target languages like JavaScript if you're consuming JSON and JavaScript It's ridiculously simple to use it So I was thinking about this on an airplane perhaps I don't remember and I was thinking about the work that I did on a project called ear electricity which allowed you to Kind of glue together Ruby and Erlang you could make a Ruby program that would act like an Erlang node and send it messages and respond to it But you could write all of that in Ruby. So it was really nice for those things that you wanted to write really fast And you didn't need the high concurrency kinds of things that Erlang gave you use Erlang for the high concurrency server type stuff That makes all that threading nonsense go away And then you use Ruby for your application kinds of code where you actually need to get stuff done So I started thinking There is something in Erlang Let me take a minute. How many of you have written Erlang before ever? Quite a few maybe That's awesome. I had the pleasure of meeting all three of the guys from the Erlang movie Joe Mike and Robert and They're all amazing people. I Met Joe Armstrong at the Erlang Users conference in Stockholm about a week ago. He is one of the most animated intelligent and Awesome people I've probably ever met this guy is is truly very very intelligent. It was it was truly a pleasure to meet him I'm a big believer in Erlang. I've been using it for More than two years now maybe two and a half years How many of you were actually at the Ruby conference where they showed the Erlang movie as a joke? Guess who the jokes on it's on Ruby Because Erlang can do things that Ruby can't even dream of You can write servers In Erlang that put Ruby to shame now things like event machine mitigate that a little bit That machine is really really nice if you want to write servers in Ruby You better damn well be using event machine because if you're trying to use threads and some sort of server with Ruby Just give up just throw that code away and start over with an event machine. I promise you you won't regret it But if you're writing really sophisticated servers that need to do all kinds of crazy stuff and Have really heavy concurrency and and take just ridiculous numbers of connections Give Erlang a shot. It makes dealing with multiple paths through your system and spawning up functions Doing the kinds of things like forking off a process for each connection Makes that stuff really really easy So I was thinking Erlang okay Erlang has something that it calls the external term format And that is a serialization that it uses to do certain kinds of communication between nodes and other types of things This is a very simple serialization. It just takes each of its known types It has little identifiers for them. It looks something like this So you have a small array on the top that would be an Erlang syntax Called a term in Erlang when you Serialize this using the external term format. You can use the call in Erlang is called term to binary And then you put in the term in there and it spits out a binary these little these two angle braces here That's the the binary syntax. So in Erlang this is a binary It essentially looks like this. It's very simple the 131 is like a magic number the 107 says hey You're about to get a a small array 03 says the size of the array and then 123 is the content. So it's very simple That's essentially what the protocol or the serialization looks like It supports all of the types Basically of Erlang which are these things like integers and atoms and it even has references and ports You can even serialize functions in Erlang and pass them around So I was looking at this. I wrote a C version of the decoder and electricity to make the process of decoding The external term format a lot faster for electricity since we were using it I used it with Dave Ferram on a project called fused. It was a a server an Erlang server front-end for Rails applications used yaws or milky web to do that So I was thinking I Have this RPC situation I don't like a lot of the RPC things that are out there Jason RPC has problems where it doesn't have first-class binary Serialization you have to convert everything to base 64 and that's just conversions and dealing with Unicode and all that is just a huge pain in the ass so I Wanted a binary serialization and yet the binary serializations like thrift and protocol buffers I felt really lacking because of things that I already mentioned. So I said what if What if I took that idea from Jason where you rip something out of a language and say hey everybody use this and applied it to Erlang What if I took The external term format and I reduced the types that it supported To just the ones that were common across all languages to remove things like The functions in the end and the PIDs and the references and all that stuff that things like Ruby and JavaScript have no idea What the hell those things are just remove them, but keep the rest of the protocol the serialization protocol exactly the same What if I did that made a little specification around that and gave it a clever name and said hey everybody use this So that's how Bert came into being for his binary Erlang term Much like Jason. It's like a name right it's name like I guess Bert is a name all this way pretty uncommon Got Jason. You've got Bert now So here is an invention that I have something that I thought might be useful. I think This is something that is really useful in general to a lot of people a binary serialization That's an extraction from an existing language Already proved to be useful as really rich types and can be used for all kinds of serialization and transport things So let me talk about Bert for a little bit here are the simple data types in Erlang syntax You've got these guys in splotes atoms tuples bitless lists and binaries and on top of that I Said well, these aren't really Complete I would like to be able to send things. I would like to be able to serialize things in different languages like Hashes for instance here. We have nil There's actually a nil in the extra format that's specified But it is just the empty array and so disambiguate for other languages We wrap it in these complex type each complex type starts with the atom Bert To say hey, this is about to be complex type So that's the only reserved word in all of the Bert serialization And then we say you can have nils Booleans are just true or false dictionaries look like this You can serialize times and because I'm a little insane you can even serialize regular questions So again, this is exactly what the external term format looked like. It's no different. It's completely the same But now this I would name a Bert if you look at it with a certain pair of glasses In the Bert style, I would call this a Bert because the two are compatible Just the Bert is a subset of external term format So how do we send these Burt's over the wire while we send them with burps of course burps our binary Erlang packets It is simply just the Bert with a four-byte header that represents the length in this specific ordering So zero zero seven and then seven bytes of stuff very simple There's four bytes always four bytes that allows you to send quite a bit of information over the wire before you hit the cap And if you're sending that much stuff over the wire, then you probably shouldn't be using this stuff So now that we have a serialization for data And a way to send them over the wire. How do we use this to solve the RPC needs that we had? We do that with Bert RPC Bert RPC is a super simple RPC Formalization that we now use on github. I'll go over real quick in the first Place here in the tuple You have either call or cast in this case. It's call that says I want a response from this call Then you say here's a module. So in Bert RPC, you can have separate different modules So maybe one module that does communications for one system and another one for a different system Just to keep things apart if it was just a function you'd have only one namespace this having a module Give you two namespaces because the next item is the function name that you're calling and Then the next item is an array of arguments if the if there are no arguments and that would simply just be an empty array and From this you're always going to get a response If it is a successful response the first item will be reply in the tuple and the next item will be whatever term It is that was sent back in this case the addition of one and two is three The other thing you might get back from this call is an error Go error message. So we say error This is a server type error of this error code And this was the name of the exception and here was the message of the exception and here's the stack trace of The exception so you will get either reply or an error back We talked about the burps in RPC everything is transferred as a burp a burp is just The bird RPC burp is is simply just a normal burp, but you're using The term that represents the RPC call figuring out how long it is and prefixing it with the correct header So if you look at how that looks on the wire, it looks kind of like this Make this call It converts to this bite sequence that goes over the wire And then you get this bite sequence back and that represents this in the Erlang syntax Similar to calls is the cast the cast just says this is like a call. It is no different than a call except I Want the server to? Accept the request and then immediately send back no reply just the atom no reply in a tuple That's all it's going to send back and then on its side It's going to queue that up and process that whenever it's ready and whatever it would have responded just throw it away I don't care. We use this a lot in github to isolate Systems that could possibly fail and cause trouble like reporting exceptions We have something we call fail bot, which is a server that accepts RPC These bird RPC requests as casts and says report this exception And then that the server descends the response the no reply response back and then all of the HTTP Posting all the failures that could possibly go along with that are completely isolated in a separate system You can use the cast for things like that so a module function arguments and no reply back done For advanced things in bird RPC We have informational burps Which can do advanced things like this is the kind of what they look like Things like streaming you want to stream stuff over the wire like big files You can do that with bird RPC. There's a specification for that. It looks like this first you send an info burp This is info. This is going to be a stream. There are no arguments for this specific Informational burp you make your normal call and say hey, I'm going to send you a file called a dot jpeg and Then you send n bytes you send an n header which says I'm going to send you n number of bytes You follow that by the actual bytes When those are read Then you do that over again header content header content and when you're completely done Then you just send a four byte zero header So just zeros all the way across for four bytes and the response comes back like normal You can do this in reverse or streaming replies. That would be downloading stuff looks exactly the same Visually it looks a little bit like this. You say here's my normal bird RPC burp This would be the info and the normal one And then you've got your header and your bytes and your header and your bytes and your zero bytes when you're done Other features of bird RPC are things like asynchronous casts with callbacks So you can say I want this to be a cast But I want a response to go to another server somewhere else and by sending an informational burp with the callback information Then your server can then make a bird RPC request back to that callback address with the response that you would have normally gotten But you do it asynchronously. It's out of band There's also some advanced caching stuff. I don't have a lot of time left So I will allow you to look at that but there's expiration based caching and also validation casting Which is like the expiration the normal TTL stuff in HTTP as well as the e-tag stuff It allows you to handle complicated validation really elegantly so the philosophy of these systems is simplicity To write a bird RPC client or server is really quite trivial because the specification is so small There's no code generation. There's no IDLs I mean you could write them but the philosophy is not to the philosophy is to say use bird RPC Just like you write normal code. So simple simplicity plus Functionality what is the most amount of functionality for them with the most amount of simplicity that we can create? And I would call that bird RPC So let's look quickly at some implementations of these. This is exactly what we use on github The one I wrote is called Ernie Ernie is a bird RPC server. This is a complete specification. This is a complete code file for an Ernie server This gives you full RPC functionality on the server side you say require Ernie There's a module named calc and a function named add it takes two parameters Those are a and b add those together and whatever that happens to be returning. That's all it is Six lines of code you run this with this command here You say Ernie demonize it run it on port 9 9 9 9 Spawn 10 Ruby processes that are running that handler and Then balance between them or you could run 10 20 or 30 or a hundred of these whatever is suitable for your specific task Dash H says use this handler the calc Rb file that you just saw there is a and I'll show you that in a second How that actually runs? There is a Burt implementation called Burt it looks like this you just say Burt that encodes some Ruby value and that returns the binary and an Erlang syntax is the second one there Encode an array it looks like that encode a tuple There's a little syntax for tuple where you just Prefix an array with a T and that tells the Burt serializer to turn that into a tuple instead of an array That looks like that and then encoding things like times that takes a little more space But it looks like that Burt RPC implementation so you fire up that Ernie server you want to call it and get data back Well, that looks like this Burt RPC service new Here's the host It could be local hosts or whatever the name of the host is the port It's running on and to call this and this is where you see the simplicity of the system and no co-generation and no IDL You just say SVC dot call that could be a dot cast if you wanted to cast it SVC dot call or dot cast Calc That's the module name add that's the function name and the two parameters and guess what you get your response back That goes over the wire with Burt RPC using Ernie and Burt We've got like 12 lines of code for a full Burt RPC server client relationship extremely robust using All of this code I'm going to demo this real quick running out of time. However, I really want to show you this because it's awesome There is there is Erlang so here's how it works So this is so the thing with Ernie is Ernie is a hybrid system Ernie is Part what the so here's Ernie This is how we started up so Ernie is a hybrid system Ernie is a Ruby gem You just do gem install Ernie and you've got it you've got your Ernie binary, but that Ernie is actually Erlang so what it does is I created a way to package up Erlang applications into a Ruby gem and then it just uses the normal compilation stuff But instead of compiling some C extension. It's compiling Erlang now. You've got an Erlang server That's doing all the balancing and whatnot and then Ruby Handlers that it will balance between for all your calls You start like this this says Run this run eight of these Believe it or not that was actually successful And then you call it like this, so I got this loaded already you say SBC call There's a This is the this is the handler you got the function add it looks like exactly like that and you've got this log file You can also specify you can also specify a log file In Ernie, so it'll spew that out. Let me drag this over This is So if we run this command and we say give me call that test out bytes and all that does is just generate that many bytes And then send it back over the wire if you call that okay, you got x comes back right really fast Wow RPC If we look at the log it looks like this so we can see that that actually ran I return This is this is what it received. This is what it sent back Everything is awesome So real quickly This log file line up this guy So that loads that guy back up and then if we find This is a little this is this called event. This is a little benchmarker. I wrote for RPC This is gonna say this says make 5,000 calls using four Four processes in Erlang. This is a little Erlang benchmarker It's gonna run that and then it's gonna give us some stats about how fast it ran So here we go. It did 5,000 requests at 2476 requests per second through that process Tada I'm really out of time. So I'm gonna blast through these super super fast This is how many requests that github has done through this whole process so far since the launch 626 million actually probably like 640 million now. I did this number yesterday There's a bunch of implementations in a bunch of languages if you want to help if you like this stuff and you want to help write an implementation of Burt serializer or Burt RPC client or server in your favorite language That is the best way that you could possibly help this There's a mailing list where we can talk about for 2.0 and the things that are gonna change There's gonna be some new stuff that I'm gonna add and maybe deprecate some stuff This is the URL you go to Burt dash RPC org To find out all that information The architecture stuff that I talked about was very very very basic if you want a more Specific covering of that just go to Google search for github fast And you'll find the article that I wrote about how we made github fast and now that you've seen all this and you're stoked Go invent something new. Thank you