Building Serverless Ruby Bots
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
Title |
| |
Title of Series | ||
Number of Parts | 66 | |
Author | ||
Contributors | ||
License | CC Attribution 3.0 Unported: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
Identifiers | 10.5446/46577 (DOI) | |
Publisher | ||
Release Date | ||
Language |
Content Metadata
Subject Area | ||
Genre | ||
Abstract |
|
00:00
BuildingVideoconferencingMusical ensembleTelecommunicationPresentation of a groupRobotMultiplication signJSONXML
00:31
Multiplication signElectronic mailing listComputing platformXML
01:09
Electronic mailing listRobotWeb pageEmailNeuroinformatikContent (media)Scripting languageTask (computing)ParsingGroup actionXML
02:07
Lambda calculusFormal languageJava appletService (economics)WeightScheduling (computing)ParsingCorrelation and dependenceRegular graphWrapper (data mining)Regulärer Ausdruck <Textverarbeitung>ParsingPort scannerFibonacci numberPersonal computerServer (computing)Scripting languageNeuroinformatikData structureMultiplication signEmailPort scannerLine (geometry)Revision controlRobotProgramming languagePoint (geometry)Regulärer Ausdruck <Textverarbeitung>Inheritance (object-oriented programming)ImplementationVirtual machineRun time (program lifecycle phase)Lambda calculusComputer fileCodeWeb pageGoodness of fitParsingElectronic mailing listElement (mathematics)Computing platformScheduling (computing)Repository (publishing)ParsingBinary fileBoilerplate (text)Social classUniform resource locatorWrapper (data mining)Projective planeMultiplicationMobile appSoftware developerJava appletPortable communications deviceWindowBinary codeMicrocontrollerInterpreter (computing)MathematicsCartesian coordinate systemGroup actionMaxima and minimaLibrary (computing)Canonical ensembleTwitterFormal languageCross-platformGastropod shellVotingFunctional (mathematics)Common Language InfrastructureGodMereologyService (economics)Computer programmingSquare numberCausalityXML
11:12
Context awarenessLambda calculusWrapper (data mining)Function (mathematics)Gateway (telecommunications)FluxSet (mathematics)CodeMachine codeInformationRun time (program lifecycle phase)MIDIBuildingMobile appCloningJava appletNumberMetric systemParsingVirtual machineWrapper (data mining)CodeRobotConfiguration spaceComputer fileBinary fileCompilation albumFunctional (mathematics)Run time (program lifecycle phase)Java appletImplementationBitDifferent (Kate Ryan album)Mobile appSemiconductor memoryBuildingTerm (mathematics)CASE <Informatik>Lambda calculusAbstractionIntegrated development environmentLetterpress printingWeightSoftware repositoryLibrary (computing)Rule of inferenceSource codeEvent horizon1 (number)Well-formed formulaFlow separationTask (computing)Computer programmingData storage deviceEmailOperating systemProjective planeScheduling (computing)Revision controlRegulärer Ausdruck <Textverarbeitung>Equivalence relationComputing platformMetric systemCuboidNumberCartesian coordinate systemError messageWindowLine (geometry)SubsetVariable (mathematics)Gastropod shellDirection (geometry)Level (video gaming)Binary codePlanningOperator (mathematics)XML
20:00
Context awarenessCodeCloud computingRun time (program lifecycle phase)BitComputer animationXML
20:35
MIDILambda calculusMultitier architectureIntegrated development environmentLibrary (computing)Compilation albumAbstract syntax treeJava appletCore dumpRobotArithmetic progression2 (number)Self-organizationProcess (computing)Semiconductor memorySource codeLibrary (computing)Exterior algebraSystem callRevision controlFormal languageJava appletINTEGRALCompilation albumMultiplication signSimilarity (geometry)Software frameworkNumberNeuroinformatikCASE <Informatik>Point (geometry)Different (Kate Ryan album)Level (video gaming)Computer configurationCausalityBeta functionRun time (program lifecycle phase)Functional (mathematics)NP-hardMetric systemSummierbarkeitBitProjective planeError messageCartesian coordinate systemProduct (business)Virtual machineIntegrated development environmentComputing platformXML
27:01
Point cloudJava appletEvent horizonGroup actionText editorMathematicsoutputBuildingSoftware frameworkArchitectureLambda calculusFunction (mathematics)Mobile WebGoogolInternet service providerPlug-in (computing)Game controllerPrice indexVolumenvisualisierungHand fanAreaVector potentialMoment of inertiaTemplate (C++)Point cloudAreaInternet service providerText editorComputing platformMultiplicationSoftware frameworkBoilerplate (text)Open setComputer configurationFunctional (mathematics)Run time (program lifecycle phase)Computer fileConfiguration spacePlug-in (computing)1 (number)Term (mathematics)AuthorizationSystem callServer (computing)CausalityProjective planeRouter (computing)Cartesian coordinate systemFlow separationMenu (computing)Context awarenessDigitizingProof theoryError messageElectronic signatureOpen sourceLambda calculus
32:18
Uniform resource locatorSoftware developerMultiplicationPosition operatorXML
32:53
Coma BerenicesXMLComputer animation
Transcript: English(auto-generated)
00:01
Thank you for coming to my presentation.
00:21
Today, I want to talk about building serverless Ruby bots. So, some time ago, I was looking for an apartment to rent in the center of Zagreb. For those of you that don't know, Zagreb is the capital city of Croatia, which is a country located in Central Europe. If you want to rent apartments in Croatia,
00:42
you check out listings on an online classified platform that's called Nushkalo. Nushkalo is basically the same thing as Craigslist you have here in the US. I had a problem while trying to find an apartment. I had a hard time forcing myself to check out the classifieds each day, multiple times.
01:02
Well, you probably all know this, but the good apartments usually get rented out within an hour or two. So to tackle my problem, I decided to build a small bot that would scrape that webpage with all the listings every five minutes and shoot me an email when a new apartment comes around.
01:21
This technique was actually really successful because I was basically always the first one to call the advertisers, and I managed to find an apartment fairly quickly. So, the technical background of the bot was really simple. I used a couple of gems. I used HTTP party to fetch the content of the webpage.
01:40
I used the yoga gem, which is an HTML parser, really similar to Nokogiri, but I don't know, better. Then I used the action mailer gem to shoot myself an email. I wrapped it up all in a rake task and invoked that rake task with the whenever gem. And the script ran on my local computer,
02:02
and that was good enough for me. If I'm not on my computer, I rarely check my emails. After some time, I decided to reuse the script, and I wanted to run it consistently every five minutes, no matter if my computer is on or off, so I had to move it from my personal computer to a server. However, I didn't fancy the idea of renting a server
02:22
just to run a simple Ruby script. Enter serverless. I knew at that point that the ideal infrastructure for what I need would be a serverless one, a place where I could just put my function on and run it periodically without taking care of servers. Thankfully, Amazon, Microsoft, Google, IBM,
02:43
and many other vendors provide the infrastructure for this. It's usually called serverless or FOSS, Function as a Service. And I wanted to try out the most used FOSS and the pioneer in the area, so I tried AWS Lambda. AWS Lambda lets you run code without provisioning or managing servers.
03:02
You upload your code in a zip file, you set some triggers to run it, and that's it. You're up and running in a couple of minutes. It executes your code only when needed, it scales automatically, and you pay only for the compute time you consume. Now Lambda's got support for multiple languages such as Python, Java, Node.js, C Sharp,
03:22
but it has one problem. It doesn't support Ruby. So the AWS team asked the public more than three years ago on Twitter whether they should first support Ruby or Golang, and unfortunately for us, the vote was 54% for Golang and 46% for Ruby.
03:43
And then more than two years later, this tweet came out announcing Golang support. It took them a while to add it, basically like over two years. And so I would guess that Ruby support isn't that near at all. There have been some rumors about it, but there are no official announcements.
04:03
So no Ruby. I wanted to stick to Ruby and try it out on Lambda. Although there isn't any official support for Ruby on AWS Lambda, you can run JavaScript, Java, or Python and invoke shell commands. And since we can invoke shell commands, that means we can wrap our Ruby script
04:22
and package it up and run it on AWS Lambda. So there are at least three, but actually more ways to package Ruby and run it on AWS Lambda, and I tried these three. Traveling Ruby, mRuby, and JRuby. So let's introduce each of them.
04:40
So Traveling Ruby. If you ever wanted to distribute a CLI built into Ruby, your end users would have to have Ruby installed or, God forbid, have a Ruby version manager installed or something like that. And they would have to install Bundler and they would have to install all of the gems. And then if you do an update,
05:01
they would probably have to do some parts of that again. Traveling Ruby is a project that tackles the problem of distributing CLI apps. Traveling Ruby is a project by devs from Fusion that support portable Ruby binaries that can run on any Linux distro OS6 or Windows. It allows Ruby app developers to distribute a single package
05:22
to end users without the end users needing to install Ruby or any of the gems. Now mRuby is something totally different. mRuby is an interpreter for the Ruby programming language with the attention of being lightweight and easily embeddable for various microcontrollers and IoT devices.
05:40
It's created by maths and its first letter might stand for either maths or minimal or embeddable, however contrived that might be. So mRuby hands out various ways to run Ruby code and they're easily packaged in an executable binary that can be run on any Linux distro OS6 or Windows,
06:01
so it's not a problem to run it on Lambda. And then JRuby, unlike our canonical Ruby implementation, JRuby runs on the JVM, the Java virtual machine. It provides a way for us to embed Ruby into any Java application and have two-way access between Java and Ruby code.
06:21
And since AWS Lambda supports Java, it's possible to run JRuby on it. So I wanted to try all the Rubies and basically check out how they perform. Since we have three totally different implementations, I decided to write a minimalistic bot that has all of its code in a single file with minimum dependencies,
06:41
basically depending only on the standard library. So the first thing I had to do was shrink the code base. I had a bunch of gems in, oh, five, and I needed to get rid of them. So a gem file looked like this. I easily got rid of HTTP party because I could just use net HTTP.
07:01
It's good enough. And I got rid of action mailer, again using net HTTP, just because I used Mailgun and Mailgun has an API which you can just ping over HTTP. Then I got rid of whenever and rake because Lambdas got its own scheduler and the only one I couldn't get rid of was the Oga gem.
07:25
So since the webpage that I was getting the data from didn't have a JSON API or anything like that, you could say it has an HTML API, I had to parse that HTML somehow and JRuby and Traveling Ruby have an Okegiri and Oga
07:42
which you can use, but mRuby on the other side, that's so much. So I went on and tried to find a HTML parser in mRuby and didn't manage to. What I did eventually was post a question on the official mRuby repository asking whether there's some HTML parser in mRuby
08:01
and who answered, actually Matz. And he said, you have three ways to tackle this. If it's really simple, you may use regular expressions. I was kinda like, yeah, well, I don't wanna use regular expressions for parsing HTML that I could go, it's a slippery slope.
08:20
Then the second one was porting a simple Ruby HTML parser which unfortunately I didn't find because most of the HTML parsers that are in Ruby actually have C-level dependencies. So I don't know, it would be really hard to do that. And the third one, the hardest one, is to write a wrapper over libxml
08:42
which is the hardest one and which would basically mean re-implementing nokogiri in some way in mRuby. So I looked at how the listings look like, how the HTML looks like. I saw that each listing has a time element with a datetime attribute
09:01
and against all of my beliefs, I said, okay, regular expressions it is. So let's look at what the Ruby bot code looks like. It's really simple. So I had a simple class called new apartments that would get a URL to scrape off of which would basically be a URL that says
09:21
I want apartments in this region, it has to have this square footage, it has to be under this price, so on and so on. I shoot out an HTTP request, scan whether there's, and scan whether there's any new apartments that have been published in the last five minutes.
09:40
And I had a simple class that was just shooting an email and I glued it all together by basically calling if there are any new apartments by the search URL called the mailgun emailer. And that's 60 lines of code, super simple. So let's start with the first implementation. Implementing the bot with traveling Ruby
10:01
or the packaged MRI runtimes. So what do you need when you wanna use traveling Ruby, what do you need to do is actually download the runtimes first. You have to download the runtimes for each platform that you're gonna run your bot on. So I had to download for two platforms, an OS6 for my OS6 machine, my dev machine, and Linux for running it on AWS Lambda.
10:23
We can easily curl that down from an S3 repository provided by Fusion. Then you just pull it down and once you delete the zip files and unpackage it, your boilerplate bot code would look like this. Or if we expand it, we can see that each of those
10:42
platform dependent folders has a bin folder inside of it and a Ruby script that's used for running whereas basically the Ruby runtime is. So if I copy over my bot code to a file called main RB, the structure would look something like this. And if I wanted to execute the bot
11:02
with the Ruby that's installed in my machine, I would just do this. And if I wanted to invoke it with the Ruby that I pulled off of the S3, I would just do this and just check whether everything's working. And everything worked perfectly fine from the beginning.
11:23
So that's not all that you need to do to upload the bot to AWS Lambda. You actually have to, since Lambda unfortunately does not accept direct shell commands, you need to create a wrapper over it to execute it. Actually, I didn't write this wrapper.
11:41
Similar ones can be found online. What it basically does is spawns the child process, executing that shell command, and that's it. And after that, you need to zip it all up or package it all up in a zip file to upload it to AWS Lambda. And then what you need to do is package three things,
12:01
the runtime, the source code, the main RB file, and the JavaScript wrapper. And after that, you have to go to the AWS Sandman panel, and there are five easy steps to follow and just to configure your AWS Lambda serverless function. So creating a function, you have to just name it, select a runtime.
12:21
Then after that, you have to select a trigger. There's several ones to choose from, like the API gateway, so you can ping your serverless bot, but we'll choose the CloudWatch events scheduler that enables us to run our bot periodically. Then we need to create a rule for the trigger,
12:41
which is basically we'll just name it and run it for one minute or five minutes or whatever, and upload the bot code in a zip file. And the last thing you need to do is set a handler. So what's a handler? You have to explicitly tell Lambda to look into your zip file, check for a file,
13:01
and check for the method that's in, and invoke it that way. And that's it. We can now harvest the benefits of our Ruby bot, and we can get our email whenever a new apartment shows around. So implementing the bot with mRuby. This one was interesting. So there are two ways to build apps with mRuby.
13:22
You can download the mRuby source directly from GitHub, or you can use the mRuby CLI, which is a platform for building native command line applications for Linux, OS X, and Windows. So I decided I didn't want another level of abstraction and wanted to get a little bit deep down,
13:41
so I said I'm going to build it from the mRuby source. So what I did was clone the mRuby repo. Once I cloned it, I got a bunch of files, but these three are most interesting. I got a empty bin folder, a build config file, which acts as a gem file or a gem spec, and a mini rake file.
14:01
And this mini rake file, once you invoke it, all of a sudden your bin folder is not empty anymore. It has an mRuby file and a MIRB file. What it does is it actually creates runtimes based on the build config and your operating system, and creates an mRuby file, which is the equivalent of Ruby,
14:21
and a MIRB, which is mRuby's IRB. Now, if I were to just create a simple hello world file, and if I wanted to invoke it with mRuby, I would just do bin mRuby hello world rb, and that's it, that works. But, so I copied the code over to,
14:42
or the bot code over to the main rb file, and I all of a sudden got undefined method required for main, so that was like the error on the first line. And mRuby doesn't support the require method because it works kind of differently. So remember how I said in the intro how mRuby is lightweight?
15:02
Well, it really is, it doesn't, it's meant for embedded systems, and it doesn't come with everything included, so some of the things that you might have in the standard library, you would have to add mRuby gems for it. So, I had a couple of issues I had to find. Replacement for net HTTP,
15:23
mRuby doesn't have out of box support for environment variables, or even for regular expressions. So, I had to add to our build config file all of those dependencies. I easily found them, and I had to recompile my binaries
15:40
with the mini rake command. And that kind of worked, I had to do some tweaks, like custom parse, like I had to build a custom parser for dates and stuff like that, but after 15 minutes, it worked on my machine. So, executing the code with this
16:00
would send an email to myself. So that was great. And now, I had to upload it to AWS Lambda, which means I had to do cross-compilation because I'm running on OS 6, and Lambda's running on Linux. Now, I basically just recompiled it on a Linux machine,
16:21
and zipped it all up the same way as I did with the traveling Ruby, and that's it. It worked perfectly. The remaining instructions are basically the same as if I was uploading a traveling Ruby. And now, implementing the bot with JRuby. So, there's several ways.
16:41
I think the most easiest way that I found was there's an AWS Lambda JRuby repository, which already has a pre-packaged formula for building Ruby functions on AWS Lambda with JRuby. So, once you clone it, you're gonna see you have a couple of things in it.
17:02
It's gonna be a lib folder with a JRuby jar, which has the JRuby runtime. You're gonna have a source folder where you can put all of your main.rb files, and you're gonna have a gradle task to compile all of that together into a zip file. So, if I were to paste my code into that main.rb file,
17:22
and just build the project with the simple gradle command, I would get a zip file. Just one thing to note. I had some trouble doing this. I tried doing it on my OS X machine. I guess I maybe had different versions of Java or something like that.
17:40
I ended up actually compiling all of that or building all of that on a Linux machine as well. And now, the only difference between uploading the previous bots is that we're going to use Java 8 instead of Node.js, and that's it. Although there isn't any official support for Ruby, we managed to run three different versions,
18:03
or three different implementations of Ruby on top of AWS Lambda. That's great. So let's talk a bit about metrics and numbers and compare these three approaches and code size, memory consumption, and speed. And afterwards, I'll explain Lambda's pricing.
18:22
So, as expected, the least code size we got was with mRuby, and that's no surprise at all. However, all three are okay in terms of not exceeding Lambda's restrictions on the code size per function, which is 50 megabytes. Then the memory consumption, I was kind of surprised
18:44
that mRuby had a larger memory footprint, but your mileage may vary, definitely. This was my case. I'd also expect the memory consumption of jRuby to be the highest, however, I didn't expect something simple like this to be 150 megabytes.
19:03
The only thing here is with jRuby is that it goes over the basic billing plan, so the 128 megabyte model, so you would have to opt in for a more expensive plan. And I even had issues running it on anything
19:23
that's below 448 megabytes, so I'm not sure what the issue is here. And then execution time, and I'm gonna explain what the cold start is and what a warmup is. So mRuby is not supposed to be faster than regular Ruby, and our numbers actually prove it.
19:42
And jRuby, when you first try to execute it, is a lot slower than the two, and that's no surprise at all. Even a simple print hello world program in jRuby can take up to five seconds, simply because of the long warmup the JVM needs.
20:00
Let's talk a bit about cold start. So when your code is triggered for the first time, a cloud provider initializes a new container, and it needs to basically warm up, it needs to do all the work. And on subsequent calls, it reuses the same container unless like roughly four hours passed,
20:24
or something like that. What it basically does is it shoves the runtime in a request context that's, and it reuses it on subsequent requests. So after it's warmed up, traveling Ruby and mRuby have about the same
20:42
execution time as they did on a cold start. However, jRuby outperforms them really well. It performs it in 1.2 milliseconds, sorry, 1.2 seconds. And as said, your mileage may vary. These are my numbers.
21:01
I have two IO calls, one to scrape the webpage, one to shoot an email, and so it really may vary for other cases. So why do these metrics even matter? So AWS Lambda's pricing. AWS Lambda's pricing is a two-tier pricing.
21:23
It basically looks at it at two levels. First one is the number of requests or the number of times your function was called, and the other one is the sum of durations of our functions took to execute, and the memory allocated expressed in gigabyte seconds. So on a free tier, you get one million requests
21:42
and 400,000 gigabyte seconds per month. With one million times per month, we could roughly run this function every three seconds. And the 400,000 gigabyte seconds per month might be kind of confusing. Basically what it is is the memory size
22:03
multiplied by the amount of seconds your functions take to execute. Let me show you an example. If you have a serverless function that has allocated 128 megabytes for it and it runs for four seconds, it's going to consume 0.5 gigabyte seconds.
22:24
So if we ran the bot every minute, and this is kind of roughly for all three the same, we would spend around 20,000 gigabyte seconds. JRuby outperforms NRuby and Traveling Ruby on subsequent requests. However, it does allocate more memory,
22:41
so it kind of comes up to the same thing. So if our bot spends 20,000, sorry, yeah, 20,000 gigabyte seconds, that's basically nothing. We have 400,000 of those on a free tier, and that's a really good bargain. So choosing the right Ruby for the job.
23:03
Traveling Ruby is really cool. It has low memory consumption, well-known environment. However, the support is not great. There has been some activity lately, but there hasn't been no active maintaining or releases of new versions, and there's a discussion on their GitHub repo,
23:20
what's gonna be with the future of it. And then mRuby is really cool because it has low memory consumption. It's lightweight. However, the library support isn't that great. I had to try four different HTTP libraries and each of them had their own problems, especially with HTTPS. One point I resorted to just curling stuff,
23:43
so that's kind of a problem. And cross-compilation, you have to do that initially, but, oh, sorry, not initially. You have to do that every time you change your code, but there's the mRuby CLI, which should take care of all of that for you, so you can give that a try.
24:01
And then jRuby, the simple packaging with an asterisk, because once you get it right, it's really simple, but it's kind of hard to get it right, at least for me it was, because I had to switch machines. Some Java, as I said, some Java version wasn't really working great on my computer.
24:20
So, yeah, and it's got fast execution, which is really great after the warmup it takes. However, it has high memory consumption, and one thing that I didn't like that I had kind of a hard time debugging is if I get Java errors, I, yeah, basically don't know what to do. So it was a lot of trial and error.
24:43
So I talked about AWS Lambda, and I talked about these three Ruby versions. So let's talk a bit about some alternatives. There's Ruby Packer, which is a project that compiles a whole application into one executable.
25:00
I haven't used it myself. However, as much as I know, some companies do use it in production. And then there's Ruby Snap, which is used for packaging and distributing apps. It's worked on by Hiroshi from the Ruby core team. It's only used for Linux, and it's still a work in progress,
25:21
but if you want to see it, it's in the main organization, in the main Ruby core organization on GitHub. You can check the source out. You can check the source out there. So I talked a lot about Lambda, so let's mention some alternatives to that.
25:41
There's Azure Functions, which have a similar language support, or even now, even more language is supported. However, not that many integrations as Lambda has, and it has a pending feature request on their GitHub to support Ruby. However, it's not even in the experimental stage
26:00
on their platform, so I'm not sure when it's gonna be there. And then there's Google Cloud Functions, which just came out of beta a couple of months ago, but they, however, only support Node.js and Python. And then there are options to run Ruby with Docker on some of these serverless platforms
26:20
using a Kubernetes framework called Kubeless, which is a serverless framework built on top of Kubernetes. However, to be honest, that is not the simplicity I would look for when trying to run a serverless function. So you can definitely say there are various different options.
26:42
It's really interesting. However, none of them really seem ideal. You could argue most of them are really hacky. Yeah, none of them is really, really that good. So that all kind of changed about a month ago to about two months ago when Apache OpenWhisk,
27:03
an open source serverless platform, announced that they are coming with Ruby support. And that's great, but to be honest, I wasn't that hyped about it at first because I was like, okay, it's an open source serverless platform, which means that I would have to host my serverless function
27:22
and take care of servers for my serverless thing and kind of didn't make sense to me. I think I found out really quickly after that is that IBM Cloud Functions are actually built on top of Apache OpenWhisk, which makes IBM Cloud Functions, or IBM,
27:41
the first provider to support Ruby on their serverless platform, which is great. When you wanna create a serverless function, you get a drop-down menu and you can select Ruby 2.5 on there, which is really great. They're really up to date with that.
28:00
And they even offer an inline editor with syntax highlighting. They could have some improvements. It's really early on. If you do a syntax error or whatever, it just yells out, we couldn't run Ruby, and that's it. So, but I can guess that those improvements
28:20
are gonna come soon. And another great thing that came, I think, last week is the serverless framework support. So the serverless framework is the most popular serverless framework for building serverless applications on top of AWS Lambda, Apache OpenWhisk,
28:44
Azure Functions, and basically all of these major providers. So what you can do is run serverless create with a template, OpenWhisk Ruby, and I think this template option should land this week in and generate some boilerplate for your serverless function.
29:01
It gets a couple of files. The two main ones are the handler RB, which you can put your Ruby function in, and a serverless YAML file, which is just a configuration file where you have to say what the plugins are, what the runtime is, how to invoke it, and that's it. In a couple of minutes, you just have to do serverless deploy,
29:21
and it's on IBM Cloud Functions, which is really great. And support like this is great in terms of when maybe AWS Lambda and other major providers start supporting Ruby. Then there's a JETs framework, which was announced a couple of months ago.
29:40
It's a serverless framework for Ruby. I thought it was kind of new, but the author only announced that I think in August or September, but it actually has more than 2,200 commits, which is kind of like a huge Ruby project. And what it does is you can generate an application
30:01
which really looks like Rails in some ways, like you have a router and you have a controller, and each of those routes maps to a separate Lambda function, and the author even fixed some of the warmups, so subsequent calls should be pretty efficient,
30:21
because he's basically shoving the Ruby runtime into the request contacts from AWS Lambda. And then the last thing that is really cool, which also came about like a month or something ago, is FastRubyIO, which is a hobby project created by Paulo Arruda. He basically built a serverless platform
30:40
on his DigitalOcean account, and a Ruby CLI, so you can just generate a Ruby serverless function and deploy it in a couple of minutes. Note, this is a hobby project. As much as I understand, this is on the author's DigitalOcean. He might have some ways to expand that, but there are currently no ways to access your functions
31:02
or a dashboard or something like that, but it's a really, really cool proof of concept. So, in conclusion, this was a really fun experiment for me to try multiple flavors of Ruby. I'm glad that I had the opportunity to show you that you can run Ruby on any of these serverless providers,
31:20
no matter if they actually support Ruby or not, and this doesn't have to only affect serverless. If you have maybe some platform that doesn't have Ruby, maybe these are some of your ways you can do that. However, personally, I think this is far from perfect, and we're not there yet, but hopefully we will be soon.
31:41
IBM's move is a great move forward, and there's a lot of new things happening in the serverless area related to Ruby, especially in the last couple of months, and hopefully this will push all the other major providers to go forward with supporting Ruby. If you wanna see all the major providers supporting Ruby,
32:02
there's an open petition on serverlessruby.org that has almost 1,500 signatures. You just log in with your GitHub, and the purpose is to get all of these big vendors to support Ruby. That's all, folks. My name is Damer Svertan.
32:21
As much as you understood from the beginning of my presentation, I come from Croatia, and that's where I lived up until six months ago. Since then, I moved to the San Francisco Bay area, where I started to work for Netflix. Netflix is currently hiring Ruby developers on multiple positions, and if you're interested in hearing more about it,
32:43
please feel free to catch me after the talk, or just visit this URL. That's it, thank you.