The Changelog: Software Development, Open Source - Phusion Passenger (aka Ruby Raptor) (Interview)

Episode Date: January 8, 2015

Adam and Jerod talk with Hong Lai, one of the co-founders of Phusion. His company recently got a lot of attention for their upcoming version of Phusion Passenger, which they decided to call Ruby Raptor in a clever marketing play to get people excited about Passenger again. It worked, and we invited Hongli on the show to talk about Passenger/Ruby Raptor, the challenges of marketing open source, and how to get the internet excited about your next version.

Welcome back everyone. This is the changelog and I'm your host Adam Stachowiak. This is episode 136. Jared and I had a great conversation with Hong Lee from Fuse and Passenger fame. We talked about Ruby Raptor and all sorts of fun stuff. Marketing open source, getting the crowd excited about your next version again and much, much more. We had some awesome sponsors for this show. Ninefold, TopTal, and

DaysWork. We'll tell you a bit more about TopTal and DaysWork later in the show but our friends at Ninefold operate a high performance platform for deploying and hosting Ruby on Rails apps. The platform is entirely built on Ninefold's own infrastructure with service in the U.S. and Asia Pacific. And with Ninefold, you don't need to sacrifice easy app deployment

and updates for performance. You get quantifiably superior performance compared to the competition with more economical scaling, enjoy great support, Thank you. 5 gig app server in the u.s for free month on month and all you gotta do is go to ninefold.com slash the changelog to learn more and now on to the show what's up everybody we are back this is jared with the changelog i'm here with adam hey adam say hi yo yo yo and we're here with hong lee from hello hong lee great to have you. Yes. Thank you, guys. Happy 2015 to everybody. Yeah, it's our first show

of the new year. We took a couple weeks off for Christmas and now we're back. We got Hong Lee on, talking about Passenger and specifically Raptor and some other fun stuff. Yeah, big Passenger user myself, Hong Lee, so thank you very much for your open source throughout the years.

For those of you who don't know, Passenger is a Ruby app server. And first launched, was it back in 2008? Yes, this is. And set out with the goal to make Ruby and Rails app deployments easier. It used to be a huge pain. You know, really fun and easy to write apps and then really, really hard and kind of disgusting to deploy them back in the day.

So Hongli, along with his partner Ning, set out to fix that problem and they've been working on and shipping Fusion Passenger ever since. Do you want to give us a bit of a backstory? Yes. As you said, Passenger was made to solve the Ruby deployment problem because it just sucked back then. If something went wrong, you often didn't know what went wrong. It's very hard to diagnose the problem. And you just had to perform a lot of steps. What we saw back then was that a lot of people came to Rails with the mindset of PHP.

In PHP, you can deploy an app just by dropping your PHP file somewhere, and then it just works. But back then with Ruby, you had to set up these app server clusters, and then you had these sockets, and you had to connect them to the web server, and lots of other stuff. And then we just thought, yeah, there's something wrong here. It should be a lot simpler, maybe like PHP. And it is with that vision that we made Passenger. So we went for the PHP-style uploaded Go model

and tried to implement an Apache module that sort of does something similar, but then for Ruby. And that's how Passenger started out. The philosophy behind Passenger started out. The philosophy behind Passenger was to make deployment as easy as possible, to require as least maintenance as possible. If the app server can do something for you, then it should. It should bother the human as less as possible so that the human can focus on the stuff that is really necessary. And this is the philosophy behind it.

And it also tries very hard to solve problems, keeps you out of the dark, to give good diagnosis of the problems instead of just swallowing all the error messages. That's why we have that error message base from Passenger. And this is kind of where it began. We just saw back at the time, a lot of people were complaining about how hard Ruby deployment was.

And then we saw an opportunity there to change things because we saw, like Zed Show had its mongrel. And then Thin came, and then a few others came, but they all followed the same model of having a simple app server that listens on a socket, and then you had to connect all of them to the web server. And lots of people just got confused by that very same model. We were the first one to come up with a completely different usage model.

And actually, even right now, we still are, because these days you have Puma and Unicorn, but what they fundamentally do is still following that old model. And we are the only one that tries to really integrate into the web server and through that way, eliminating a lot of the unnecessary setups,

so to say. Yeah, just going back to 2008, when you guys first started kicking off, I think, didn't you even call it Mod Rails way back in the day before it was called Passenger? Am I misremembering? Yes, we did. So you're really trying to position it as the PHP,

that same experience of, I can just drop my files into this public folder and Apache is going to process that and serve it. And so because you had mod.php, you guys decided mod.rails, used that really as a launching point. At some point, I guess that name didn't scale well. We're going to talk a little bit about marketing and positioning and stuff. When did you guys decide mod.ra Rails was not the best name and why?

Okay, so back then, the primary, well, let's say the primary way that people see Ruby is through Rails. Rails is what made Ruby big back then. So we wanted to associate with Rails as much as possible, and maybe even completely focus on Rails only, because back then you had these alternative frameworks, but they weren't really that popular. But then after a short while, Rack came, and that's an interface that allows multiple web frameworks to talk the same language, so to say, to the app server,

so that as an app server author, you only have to implement React and you can support multiple web frameworks, which is a very good thing. And we quickly saw that there's a lot of demand from the community to not support only Rails, but also other things. We also saw, hey, Rails itself is also going to jump on the rack bandwagon someday, so we should too. And then we came up with Mod Rails 1.2, and then we also decided, hey, we actually need a different name. We can call it Mod Rack, but let's face it, even back then, rack wasn't that popular.

It has a lot of promise but calling it mod rack it's just a little bit of a lame name it doesn't really sound good and marketing wise it's just not not not a good name and then we we needed a new name so then we thought okay um how about we call it passenger because it's in the same it is in the same category as rails so imagine that you are a passenger inside a train on top of some rails and all you have to do is to sit back relax and everything is taken care of for you you arrive at the destination without having doing doing much and that's the philosophy behind the name. I never connected the whole passenger onto a train, rails.

I never connected that analogy there. Unfortunately, I heard this recently from other people too, that they didn't connect names. Maybe we should make this clearer. I like it now that I hear it, but with the name

I just didn't. I was like, well, passenger, that sounds cool. Well, it now that I hear it, but with the name, I just didn't say, well, Passenger, that sounds cool. Well, it definitely scales better because over the years, you guys moved on to add, first of all, you added Nginx support, so you could deploy on Apache or Nginx. And then later on, you added support for not just Ruby apps, right? So now you can deploy Python,

Node.js. Is it completely polyglot, or is it specific ecosystems? It is specific ecosystems. We didn't want to fragment too much. If we support everything, then we just don't have any focus. And we want to focus on a few languages that are popular, but to give them really, really good experience. And we just can't do that if it supports everything. And then you guys took opportunity to build not just an open source project, but you're

actually building a business around Passenger. Or is it just one of your many products? Passenger is right now our primary product. Because as Fusion, we started also in 2008 when Passenger was launched. We saw Passenger as a way to start a company, to gain recognition in the company. Back then, our business model was to do consultancy, and we saw Passenger as a way to advertise ourselves, to advertise our consulting services. People would use Passenger, see that it's good,

and then they would come to Trust Fusion and come to us for consultancy. And this worked for a while. But unfortunately, it is not a really good scalable business model. So the problem is we could not monetize Passenger directly. We spent, even in the first version, months of work into Passenger. And we had

to earn all that money back through consultancy. And luckily, back then, we were still students. We were actually in the second year of our computer science study when we started Fusion. And then we had to do all this consultancy. But the problem with consultancy is we didn't get to study a lot. You cannot run a company and study at the same time. So as a result of Fusion, we actually had a study delay of about five years. So our bachelor is supposed to take three years, but then we graduated after about seven years, starting from when we started studying. But it was all worth it. Having said that, it still didn't scale.

And so for years, we had to worry about our next client, about getting the next project to generate income. So for a long time, we made a lot less money than we should have compared to when we were employed by another company as developers. And we lived in our student dorms and we also operated Fusion from home. We didn't have an office for a long time. Things actually became a lot better after we decided to do away the consultancy business model and started selling Passenger Enterprise. So you moved to an open source plus an enterprise, a closed source enterprise, or is it just like a license? How do

you guys actually manage the upgrade? Well, Passenger itself is open source and that is the core. Most features are in the open source version. And on top of that, we have Passenger Enterprise, which is a paid version with extra features such as rolling restarts, multi-threading, live debugging, etc. And we just charge a license fee per server per year or per server per month. That makes sense. Yes. And with that model, we were a lot more successful than consultancy or support. For a while, we have also tried to sell support, Red Hat style.

A lot of people say, hey, if you are open source and you want to make money, try selling support. We tried doing that, but it didn't work at all because Passenger is too good. That is seriously a problem.

Passenger is too good. Two people have problems. So nobody needed support. We couldn't make any money from that. You just need some more bugs. That's all you need. And then you got built-in support infrastructure. Be bad coders or something like that.

Yeah, we actually made jokes about that. But at the end of the day, we didn't want to do that. It hurts our pride as developers. And I'm only joking. Of course, you shouldn't do that. And as a longtime user, I can definitely be a testimonial to not needing support

because honestly, you set the thing up and you get it running and unless you have extreme usage or strange things that you're doing, it pretty much just works. So good job on writing stable and well-documented software. It's rare.

It's rare. It's rare these days. This path, though, Jared, that they're on, we've heard this story before where you've got an open source version. You've got an enterprise version of it or a pro version of it. And their story too, Hongli, your story for your commitment to Passenger, from a monetary standpoint, as a developer, you could have taken a position at a company and said, well, forget Passenger or we'll just kind of figure that out along the way and made more money. When you guys were making the decisions to kind of make the company and take the long haul, you stretched your education, you stretched your financial dollars to a degree. What were the conversations like between you two talking about Passenger and talking about the Enterprise Edition and talking about the direction the company could take?

How did you all come up with the decision to sort of stretch your education timeline and even stretch your dollars and not take the quick money path? How did you talk about that sacrifice, I guess, for the open source community? It is a very difficult one. It has not been an easy choice. The thing is, Ning and I, we have this dream of making our own company and become big with it. If you work for someone else, there's not a lot of freedom you have. If you don't have your own company, it is a lot safer, but it limits your freedom. And it is this freedom that appeals to us. It is also the potential that appeals to us.

And furthermore, back then, we were still young. And we thought, hey, starting this company is something that we can do without a lot of risk when we are young. When we are older and we are married, we have children, we have wives, we have responsibility to take care of them. And we can't just take all these risks. But when we are students, what's the worst that can happen? Maybe we go bankrupt and that sucks too. But it wouldn't be as bad as when you go bankrupt while having a family. So if we are to do that, we have to do it now.

And that's it. That's the most important thing. Are you guys married and have kids now? No. No, I have a girlfriend, but Ning is still single. And so I suppose for a while, it's not... Well, we are doing a lot better now that we have launched Passenger Enterprise.

Well, that's good to hear so let's talk about raptor a little bit because this is pretty interesting in fact this was the reason why you came back across our radar as i said long time user but you kind of settle in with a tool and you just don't think about it very much but over the years passenger has slowly gotten better i'll i say slowly it's probably moved fast But it's gotten better and better. You've gotten four versions out. As I said, you added support for Nginx. You added these different things.

I'm sure it got faster, better error reporting, and so on. But I think it's safe to say that in the community's eyes, it got a little boring, I guess. At least in your guys' eyes, at the way you thought it was being received. Especially in the Ruby community, we're kind of all about the new hotness and developers in general. I think it's amplified in the Ruby and JavaScript communities.

And new app servers were coming out. I think it was Puma perhaps the most recent. Slightly different models, so you had multi-processed and you had some multi-threaded models. Benchmarks would be released. Passenger may or may not fare very well. And then in November of this year,

this news starts coming out about a brand new Ruby app server named Raptor, which was just blowing away all benchmarks. A few prominent bloggers wrote about it. Ruby Inside, Peter Cooper, friend of the show, who I was a bit curious when I saw his post because he kind of has slowed down. Ruby Inside is not exactly something he's writing on

on a regular basis. I think he's doing his newsletters now. And out came this Ruby Inside post about how he got the inside tip on Raptor and got to use it in beta and could confirm these benchmarks where it's outperforming all the usual suspects, Unicorn, Puma, Torquebox, by up to 4x. Somebody else, I think, blogged about it,

Fabio Akita, perhaps, wrote about it. And all this buzz started happening about this new app server named Raptor. Everybody wanted to know, where is this thing? Who's writing it? When's it coming out? A little less than a month later, I think it was like mid-November, we find out Raptor is

Fusion Passenger 5. Where did this marketing idea come from? Okay, so it is, as you said, over the years we have improved Passenger a lot, but then it got a little bit boring in the community's eyes. So this is also related to Passenger Enterprise a little,

because after we launched Passenger Enterprise two years ago, the development of the open source version has increased a lot. So Passenger Enterprise came right before Passenger 4, and in Passenger 4 there were just these tremendous improvements in the open source version. The Enterprise version funds the development of the open source version. And during consultancy time, we just couldn't spend a lot of time on development of Passenger because we had to do consultancy.

But despite all these improvements, it is, as you say, it got a little bit boring in the community's eyes. We just saw that, okay, we can come up with improvements and these are facts and that's okay. But the perception is also important.

Even if you really become better than Puma and Unicorn and certain features, and which I believe we actually have, then if people don't perceive it that way, it still doesn't help you. So then we had to come up with an idea to change people's perception. And if we were to try that, then there are a few options we can choose from. We can either spend a lot of time

blogging about things, trying to talk to people, trying to spread the word, and we can advertise. But all of that takes a lot of time, a lot of resources, and then you still wouldn't reach a lot of people. Because after visiting some conferences, it has really sunk into me that a lot of people had kind of closed their mind from passenger. No matter what good news we come from, no matter how we improve passenger, a lot of people just didn't listen to passenger news anymore.

You can't reach them anymore, no matter the facts. And that made us a little bit sad. People were talking about Unicorn, and then we improved upon Unicorn. We saw, hey, this is the Unicorn feature. How do we improve it? Okay, we improved it.

Hey, here's a new release with improved out-of-band garbage collection or with even better rolling restart. And then a lot of people just wouldn't listen. So then we realized, okay, apparently a lot of people in the community would only listen to new things. And if we use the name passenger, a lot of people would not listen by default.

And we had to think out of the box. Like advertising costs too much money. And we are a small team. We are with four people right now. We also have other projects going on. So we cannot spend too much time on talking to people and blogging. It just doesn't scale. So then we had to use unconventional marketing tactics.

And then we thought, hey, wouldn't it be fun if we were to launch something that appears to be a new project, and then it kicks everything else out of the water, including ourselves. And then we'll just pretend like, hey, Fusion is totally defeated by these new guys. And then at the end of the day, hey, it's actually just us. So it was kind of...

That's awesome. It's a good idea. Yeah, so it kind of started as a joke, but then we thought, hey, this might actually be a good idea. It would be a good laugh and it would have a lot of effects. So then we went with this campaign. Yeah, and you guys went all out. So you had your own website, rubyraptor.org,

a radically new Ruby web server. You tapped into your friend network and you got Peter and Fabio to play along, obviously, and kind of stir up buzz on your behalf. You had kind of this future announcement, I think it was like November 10th or whatever the date was, that the team behind Raptor will be revealed and all this intrigue. And then you announced that it's Fusion Passenger 5. Tell us about the reception. Was it good? Was it bad?

What were people thinking? There's a lot of good reception. There's naturally also some bad reception. A lot of people were surprised that it's us. Most of them didn't expect it. Some of it already figured out by looking up the DNS entry. But most of the people were just surprised that it is us. A lot of people were also pleasantly surprised

because they were skeptical before, but then they found out, hey, it's Fusion. So then they thought, okay, these guys have some reputation. It's probably good stuff. And there were also some people who feel deceived. Some people compared it to switch and bait. Well, I suppose I can also understand their feelings because we had hidden our identity.

At the same time, we didn't really, other than hiding our identity for about a month, we didn't really say anything that isn't true. Like all the things that we advertise about, they are real. The performance improvements are real, and they are even open source. So everything that we introduced in Raptor is in the open source version. It is public. The code is out there. But there are a lot of meta users for Passenger 5 now. And we got a lot of feedback. There are some bugs that need to be ironed out. And we hope to release Passenger 5 release candidate in about a month.

First of all, I think that's pretty awesome that somebody actually went out and checked the DNS records and tried to figure out who this is. That showed how much interest you guys built. And I think quoting here from your blog post where you kind of do the reveal that it's just Passenger 5,

is that this Raptor approach that you said over the past month has produced more subscribers to our newsletter than we have been able to accomplish over the past six years through the Fusion to our newsletter than we have been able to accomplish over the past six years through the Fusion Passenger moniker. He says, you say, we still have a hard time comprehending this, but there's no denying the numbers. We, the community, seem to like shiny new things.

Yes, that is true. We were just a little bit sad that people would not judge us for our facts, for the things that we really are but had to judge us by how shiny we are so to say and i'm not saying this is a bad thing this is just how things are and i can also understand it a little bit as a developer myself i am also attracted to shiny new things but i just want people to treat us fairly and based on our merits. And as long as people had this idea of passenger from three years ago and thought that passenger had stood still for a few years, there's no way to win them from that. Except when we introduce something to completely change the perception, to let them refresh their perception, so to say.

All right, let's pause the show for a minute, give a shout out to a sponsor. I want to talk to you about TopTile. We've been working with them for the last year, and it's just been a great time working with them. We thought it would make some sense to circle back and talk to some of our listeners who have applied with TopTile and have been accepted because only about two to three percent of the engineers who apply make it past their strict elite engineer process.

And that person is Daniel Elzon, a longtime fan and listener of the changelog. He is now living the dream as an elite engineer at TopTal. And I say living the dream because he's now able to have 100% control of the types of projects and technologies he's working on as well as the rate he wants to charge. Daniel earns 100% of his income as a TopTile engineer, and he wanted me to pass on his seal of approval, so to speak, of the TopTile experience. And for those of you out there who are freelancing or would like to test out freelancing or even

try out a no-risk freelance-like project while you maintain your full-time position, you've got to check out TopTile. If you think you have what it takes, head to TopTile.com to get started. Tell them the changelog sent you. And now back to the show. Let's talk about those beta users you mentioned. How many beta users do you have of Fusion or Passenger 5

codenamed Raptor? How many they are exact, I don't't know we don't have any statistics for that okay let's maybe talk about then what I'm trying to get at here is the perceived changed perception of you right so these

judging on your merits this new version out there that's much faster four times faster than competitors all that good stuff what's the feedback from those people you know these are obviously out there that's much faster, four times faster than competitors, all that good stuff. What's the feedback from those people? You know, these are obviously people who are using your latest, greatest, best version of it that was the shiny new object that turned out to be the same really awesome object, but just a shiny new cover on it.

Well, it's actually not just a shiny new cover because there actually are a lot of new improvements. So it's something I can talk about that a little bit later. It includes this rewritten HTTP engine that makes things faster. And there is integrated caching support. And there's also a lot of internal changes in terms of being able to improve the feasibility of your applications behavior. But what we have focused on mostly is the bug reports. We really value stability. So there were surprisingly few bug reports actually. There were about five bug reports that we deemed critical, like they were called

crashes and we have fixed most of them. And after this phase is over, we can release a version that is kind of usable for testing and production. You mentioned that... Sorry, what was your question again?

I'm trying to figure out what the... Jared's over there jumping. This is the first time, by the way, y'all, we laughed a couple times during this show that may have seemed unusual laughs. But we got our video on on this call. We don't usually do video during our Skype calls, but we can all see each other. So I'm seeing Jared kind of antsy over there to ask some sort of question. But the thing I'm trying to drive here is I'm trying to figure out what you said was that the perception had changed about passenger because you weren't shiny and new right and what i'm trying to figure out is of the new people that began using the latest passenger 5 aka raptor that's four times faster

than x and all that good stuff what is their feedback about you know using this new version that's got the new http server that you just talked about there? What has been the feedback about their usage of it? Because we talked about the bait and switch for a bit there, but just trying to figure out the perception. How has the perception changed? A lot of people, they perceive Passenger as faster now. But we do have to say it is faster in benchmarks, but that does not mean that it is faster in real-world scenarios.

And that's a big disclaimer. So the number of people who have noticed an increase in actual production performance, they are very limited because in actual production environments, the time spent in the application is a very significant part of the overall time and the app server is a very tiny part. Having said that, one of the major features in Passenger 5 is this turbo caching thing.

Turbo caching is an integrated cache in Passenger that would cache your responses and send back a reply on the HTTP level. And it can completely offload your application to Passenger itself, which is written in C++ and does very fast. And this is the primary way that we provide

to really improve the performance of your application, even though the application takes up a large amount of time, of the entire processing time. So just to be clear, is this the kind of cache mechanism that a Varnish would do, or that you would do with Nginx, perhaps, this turbo caching? Or is it something that just doesn't exist at all outside of the passenger space? Well, right now it is an HTTP cache, so it is on the same level as Farnesh or Nginx. Having said that, we are working on something new. We are working on an extension to this mechanism to introduce a new kind of cache. With this cache that we have right now, we have noticed

from feedback from people that it is of limited usefulness. A lot of apps are not cacheable on the HTTP side, on the HTTP level. Some of them are, but those are mostly static websites. So if you have an app that, for example, has a login button that displays your username, then it is already not cacheable on the HTTP level. So what we are going to introduce in the near future, and we are also going to blog about this, is to introduce a variation of the HTTP cache

that allows you to cache these sorts of apps as well. Because we have seen, even though a lot of apps are not cacheable technically, there are a lot of parts in the app that are cacheable. And which version of the cache you should serve, in a lot of cases, it depends only on whether the user is logged in or not. So caches like Farnish, they have problems with caching pages that have cookies, pages where the content depends on the logged-in user. But there are large classes of applications that have a lot of anonymous traffic. For example, think about marketplaces or news sites, maybe even something

like Twitter, where a lot of anonymous people browse the tweets or even YouTube. And we thought, okay, what if we can come up with a new mechanism that would allow you to cache the content based on a cookie that specifies which user is logged in? If we can do that, then you can share the cached response for all the anonymous users. And that would be able to increase your traffic, I mean, increase your performance tremendously. For all anonymous traffic, you can completely offload your application

and serve directly from passenger. And I think there's a real use case there that would be really useful for passenger to provide. So it's like a per-user cache, but one user is the anonymous user, which actually represents N numbers of people who are not signed in. Almost.

There is an anonymous user cache, but we can also extend this. I mean, we can also generalize this concept to a level where you can cache based on user classes. For example, if you are talking about a user forum like Discourse or PHP or something, then what you actually want to cache, the cached version that you want to send to the client is based not on who the user is, but on what permission level the user has. So then you can, for example, define user classes of normal users and moderators.

And then you can send out one version for all normal users and one version for all moderators. And suppose that you also make some small changes in the application to make it sort of like a single page app. So then you would load your user details only once. And for all subsequent page loads, you would use AJAX. But then that version does not need to query any specific user-specific information.

They only need to know what class the user belongs to, what permission level. And if you use that, then you can have these small numbers of cache levels that each one has a very large cardinality. That would make things really a lot more cacheable than

would be possible with normal HTTP caches. And I think this would be a real innovation in the HTTP-level caching systems. Yeah. No, that's exciting, and definitely keep us in the loop on as you guys develop that out.

Let's talk about what's in Passenger 5 that makes it so fast, even if these aren't for the synthetic benchmarks. It seems like you guys have some innovations that have happened here. One of these is the hybrid IO model where it appears to do multi-process, multi-thread, and evented in certain cases.

Can you talk to that? So the hybrid model is not so much for performance as in raw benchmark performance, but it is more for safety and security. The main idea behind that hybrid model is to protect your server from so-called slow clients. And so slow clients, they can include users who are all modern, but they don't really exist nowadays.

Users who are on mobile networks, they just have high latency. So what happens if you have a lot of slow clients, it's like having a lot a lot of people standing in front of your door and then your normal visitors they can't enter because of all these people standing there uh just standing still and not doing anything and and the only way to really solve that is by having an offended surfer on some level that would have a virtually infinitely large door, so to say. And that is what the passenger core is. It has a server that is built using the evented style,

so that's the same style as Nginx and Snow.js. It would use operating system-level primitives to be able to handle lots of clients, and it would shield the application from these slow clients it would put them in nicely ordered queues where where each request and response is very fast and so your application doesn't have to worry about that you don't have to worry about people using a denial of service attack to to block your server like this this doesn't protect you from all denial of service attacks, of course, but it protects you from certain classes.

And the reason why we made it hybrid is to get a little bit of extra performance out of this. The problem with the normal evented style is that you cannot use multiple cores. One evented server only runs on a single CPU core. But then we invented a mechanism to make sure that each CPU core runs its own event loop. And then we have this load balancer to distribute new clients equally in a round-robin fashion over each core. And that's how we can leverage multiple CPU cores better.

So some of this work sometimes is taken off by an Nginx or HAProxy. Is it your guys' best practice once Fusion Passenger 5 is out of beta to serve it directly, like have it listed on port 80 and 443? Or would you still put it behind some sort of proxy? You should put it behind some sort of proxy. So what we did is writing an entirely new HTTP engine that is not only safe, but also very fast. But the downside of this, of being very fast,

is that we had to sacrifice some features. There are just some features this HTTP engine would never have and that Nginx would have. And one important thing is, for example, G-step compression. G-step compression is very important if you have mobile clients. But we're never going to support that because it would just complicate our code. It would probably also make things slower by making the architecture more complex.

So we have made an explicit decision. If you need features, just put Nginx in front of it. There's nothing wrong with putting Nginx in front of it. You would notice that in benchmarks it would probably get slower, but you're not going to notice it in production. So what else about this is new? It looks like you have written your own HTTP server for this version.

What you say is twice as fast as Nginx. How did you accomplish that? Well, mainly by doing less than Nginx. Nginx is fast, but it's not as fast as it theoretically can be because it has these sorts of features. So our HTTP server is very bare bones. We only recommend putting it

in your local network for internal communications, but not directly on the internet. If you want to put it directly on the internet, you should put Nginx in front of it. And Nginx has these configuration options that makes it internally very flexible. From a C programmer standpoint, we would say that Nginx internally has a lot of indirect branches, and that means it has pointers everywhere that points to different functions,

and that doesn't really help with CPU branch target prediction or CPU branch prediction. There's a lot of safety checks inside Nginx to check for all sorts of stuff. Nginx has its own IO layer to handle disk IO and just all sorts of stuff that we don't have. For our HTTP engine, we just focus on the complete bare minimum

that is necessary for a web server. And that's how we made it fast. But in real production scenarios, the difference is tiny. You are probably not going to notice it. All right, let's pause the show for just a minute. Give a shout out to a sponsor. I want to talk to you about Days Work.

Days Work is a new way to track time and send in voices for freelancers and small companies. It was designed and built by a small company who was bummed out by other time trackers. So if you're a freelancer tracking time or you work in a small company, you should definitely check this sponsor out. And as a designer, one of the things I like most about it is they allow you to visualize the effort that you make every day on a readable and interactive timeline this helps make sure you don't forget any of the time you have in a day and make sure you fill in all the time that you've you've spent on clients and also know which clients you're spending the most time on which is super important you can control who can see and manage financials with the admin and non-admin roles they allow you to give every member of your team their own account so there's no limits whatsoever

it even has international support so you can choose your currency a 12 or 24 o'clock and preferred number formatting day's work is by far the simplest and easiest way to organize your clients and keep track of your business this time and And right now, you can sign up for a free trial for 30 days. No credit cards required, so you've got nothing to lose. And since a fellow 5x5 host helped create Days Work, they're offering a special discount for 5x5 listeners. Here's the URL. You need to go to dayswork.co slash join slash changelog. Again, that URL is dayswork.co slash join slash changelog.

Go to that URL, get 20% off both monthly and yearly plans right now. Once again, that URL is dayswork.co slash join slash changelog. And now back to the show. I'm reading through some of the list of your guys' optimizations, avoiding dynamic memory allocations. Looks like you're taking advantage of the Node.js HTTP parser. Anything else in the internals that really stands out that you'd like to talk about?

I think our blog post covers pretty much all the important stuff. Cool. So we'll definitely link out to those on the show notes. It looks like the first one is how we made Raptor up to four times faster than Unicorn. And then there's a follow-up post about pointer tagging, turbo caching, and other things. So yeah, we can just link out to those

and our listeners can go and read. Yeah, but the main thing is that we borrowed a lot of things from Node.js, from Nginx. They're all just really brilliant. They have done a fantastic job and we have just borrowed the best parts from them. We couldn't have done this without them.

That's the beauty of open source, right? You pull together all the best ideas, the best implementations and... It's not the first time you heard that. Yeah, it's a winning pattern. It is a winning pattern. Look what others are doing and repeat it. It makes sense. So let's shift gears a little bit and tell us about your guys'

new project, which you're calling Traveling Ruby. What's this? Okay, Traveling Ruby is about being able to distribute your Ruby apps to users. So if you are a Windows programmer and you have programs in Delphi, then you would know the beauty of being able to make a single executable

that users can just use. If you have ever used Windows and then you have this.NET app or Java app, then I'm sure you would have run into ridiculous situations where they say, hey, you have to install.NET Framework 5.1 first or Java 5 first before you can use the app. And that just discourages users. And then in Unix land, it's even worse. If your app is not packaged by a package manager, and even if it is, then it's probably out of date, then your users are out of luck. They have to compile your app from source. And in case of Ruby, they have to install Ruby. They have to use Ruby gems to install your gems.

And that's just not nice to users. As a user, you just want to be able to use the app and you want it to immediately work without having to take all these sorts of sidesteps. This is also the reason why a lot of people are flocking to Go now because Go can just create a single executable that works everywhere. And it is with this vision that we have created Traveling Ruby. We have these tools that we want to write in Ruby because we love Ruby as a language. But distributing this app to users, it's just a pain if users have to install Ruby and have to use Ruby gems first. It's going to scare them away. We want to keep on using Ruby.

We don't want to switch to Go. And so we came up with this idea of traveling Ruby, of just distributing Ruby binaries along with your application. And the good thing with this approach is that you don't have to set up a fleet of VMs to cross-compile your application for multiple different operating systems. If you had to set up these VMs, then as a developer, you would lose a lot of time. It's just slow. You just don't want to do this. It makes the entire experience not enjoyable. And we want to keep that enjoyable for developers. That's really important. So with Travelling Ruby, the idea is really simple. You take the binaries that we pre-built, you drop them in a tarball, you make three versions of them, each one with platform-specific binaries,

and then you are done. As a developer, you don't have to learn these complicated steps to make RPM or depth, and then each one for all the 20 different Linux distributions, it would just work. It saves you a lot of time. Wow. So what's the status of this project? Just getting started, or is there stuff out there

where people can get involved? It just started, but it's usable and it's actually already being used. For example, the Cloud Foundry project, they have this tool called Bosch. And Bosch is some kind of release engineering tool. I'm not entirely sure what it is, but one of the main problems they've had for a long time is that a lot of their users are not Ruby guys. They just want to use Bosch, but then they are told, hey, they have to install Ruby. And then the developers of this tool just saw that a lot of people struggle with installing Ruby and struggle with installing the dependencies. So then they

have used Travelling Ruby to provide a single package, self-contained, contains everything that they need to run Bosch. And it's been great. All their user installation problems have been solved by this. It sounds a lot like, I guess not a lot like, but to a degree like containerization, Docker, sort of self-contained distributables that make it easy to kind of move these applications or, yeah, I guess in this case applications too, around. The build system actually uses Docker and Make.

Can you talk a bit about the build system for those that are going to be building traveling Ruby binaries? Yes, so the problem with building binaries, especially for Linux, is that there are so many Linux distributions. So because of all kinds of technical reasons, it's very hard to build a Linux binary that works on all Linux distributions. So what people traditionally have done is they rebuild the binary once for every distribution. And this is just nuts if you have to take care

of all the 20 different variations plus all the different platforms. But there is a way to build binaries that works on every Linux. It just takes a lot of expertise to do it. And it just so happens that I've had a few years of experience with researching

this kind of stuff and building portable binaries. So then we have a very tightly controlled build environment that we use to build a tightly controlled Ruby binary that happens to run on all Linux distributions by limiting the number of glibc symbols that they use, by statically linking certain libraries,

and so forth. Nice. So do you have a call to action for Traveling Ruby besides use this tool? Is it highly under development or is it about wrapped up? Looking for help, looking for bug reports. What are you looking for here? Well, it is kind of wrapped up for us because we initially developed Traveling Ruby

because it is a tool that we need for a future tool that we are going to build in Ruby. So right now, Travelling Ruby already does everything we want it to do. We have heard from some people in the community, they want Windows support, but it's not something that we want to bother with. I was going to ask you about that. I was going to ask you about that because it seemed to read me that you're talking about not supporting it right now for obvious reasons. For obvious reasons for you because talking about not supporting it right now for obvious reasons. Yeah.

For obvious reasons for you because you don't need it. Yeah, so I do have a call of action. Please help us with Windows support. Please contribute. There you go. Yeah, it should be very easy. Like the Ruby installer project, they already provide Ruby binaries. So I imagine that it would only be a matter of extracting the binaries they have

and repackaging it in a format, but then you still have native extensions, you have these gems like MySQL, and they usually already ship Windows binaries, but some of them are quite out of date because the maintainer couldn't keep up.

And so I'm asking listeners to please help them, in particular the MySQL 2 gem author. They need help with keeping their binaries up to date. They have these GitHub issues open in which they ask for help. Please go there, read what they say, and just give them a hand if you care about Windows support. So you mentioned a future tool that you guys are working on. Anything you want to tease there?

Anything in the pipeline you want to talk about? Yes, and this is about the future of Passenger. So Passenger, for the longest time, has focused a lot on making deployment easy, but only in a limited scope. So Passenger handles transaction management. It handles process management, spawning of your processes, and so forth. But there's a lot of things that it doesn't do.

For example, it doesn't manage the rest of your servers. It doesn't set up your server. If you look at something like Heroku, then it's much more of a complete solution. And we actually have a vision of building something on the order of heroku so the vision is that you can easily deploy your application to any infrastructure so not just an aws but for for example also on premise or digital ocean or on Linode with about the same ease of use that Heroku has

or something that approaches it. And this tool is something that we are still working on. It's currently in prototype phase. We do not yet know what it is going to be called, but you would just be able to tell the tool, hey, I'm on DigitalOcean. Here are my credentials. I need Ruby 2.1.

Go nuts. And then the tool would just spawn the service for you, deploy your app, and then you are done. And then on every app release, you would just use that tool, and then you are done, and you don't have to do anything else. And this is much more of a complete solution than Passenger. But of course, internally, it would use Passenger as the app server. And I think...

So when can I use this thing? You don't have to answer that. It would take a while. I don't think I can answer this yet. It's still very much in a prototype phase. Well, that's very exciting. And if you're looking for a name, I hear the name Raptor is available.

No, the name Raptor is not available. That reminds me, did you guys ever consider renaming to Raptor? I know it's just a codename and you're now discarding it, but did you ever think, well, ever consider renaming to Raptor? I know it's just a codename and you're now discarding it, but did you ever think, well, what if we just go with Raptor? We can't do that for trademark reasons. Oh, Jurassic Park.

Who's trademarking Raptor? Do you know? Or you're saying because you have passengers? Ford. Ford's got it trademarked. Ford the truck. They got the Raptor version of the truck. There you go. There are all sorts of parties who have trademarked Raptor.

And also there's actually already a gem named Raptor, but it's completely unrelated to us. It's a web framework that happens to be also called Raptor. So the gem name is already used. completely unrelated to us. It's a web framework that happens to be also called Raptor. So the gem name is already used. We cannot use that. Well, never mind then. I was mostly just kidding anyways. One last question and then we'll wrap here.

Passenger 5 is in beta 2. Is there a schedule for public release of Passen passenger five when you'll be getting out of beta the release date depends on the amount of bug reports that come in and how many of them are critical but as things are right now i expect that beta 3 would come out maybe somewhere next week and that would solve all the critical bugs and then there would only be minor bugs left. And so somewhere past next week, we would be able to release a release

candidate. And probably Passenger 5 Final would be out at the beginning of February. Nice. Well, man, thanks for joining us. We do have one question we usually wrap with here, which we didn't give you much of a heads up on,

but I'm sure you'll handle it just fine. And that is, who is your programming hero? Who's my programming hero? Feel free to pick a couple. It's hard to narrow it down. Zed Shaw, author of Mongrel. He's a really brilliant guy. I think Zed Shaw is underappreciated by the community.

I'm sure a lot of people know him from his rants. And a lot of people think he's a jerk. But in reality, he is really a nice guy. He's the nicest guy you have ever met, if you know him. Is he? Yes, yes. In real life, he's really nice.

Totally not like his internet persona. And he's really experienced in a lot of things. I have learned a lot from him. Yeah, it seems like he had, like you said, the mongrel author. Mongrel itself fell out of favor years back, but the parser in there continues in use probably today in many Ruby app servers. Did Passenger use it, or does it still?

No, Passenger does not use it. Okay. For all kinds of reasons. That's right, you're using the Node.js parser. Yes. Yeah, it's funny. We had Zed Shaw on episode 34, so that's like forever ago in our history.

September 8th, 2010, we had him on the show. Cool. Way back when. Wynn had a conversation with him about, well, as Wynn says, his non-rock star alter ego was on the show. Talking about Mongrel 2, high-performance websites, guitar, and the show so talking about mongrel 2 high performance websites guitar

and the software community and ponzi schemes so that was a good show yeah zed shaw i think i think you're right though i mean he's known for his rants but i think he's what i've always appreciated most about zed aside from his really awesome code is that he seems like a really real person. He tells it like it is. He doesn't fluff it by any means where some people are a little bit more rounded off the edges. He's a bit more sharp in that regard. He's also really good at bringing the troll that's inside of us out. Out of the inner troll.

Yes. He can really extract that inner troll out of the greater programming community on a regular basis any other programming heroes you want to give a shout out to? it's really hard I regularly read hacker news and I think wow those guys

are really smart when I read those articles but I can't really recall any names I just think that if there are heroes, I don't know them personally, but there are a lot of people out there in the world that are a lot smarter than I am and I just have to keep learning.

Yeah. Well, if you come up with any names, we'll link them in the show notes for sure. It's all good, man. Hongli, thanks so much for joining us and sharing both your marketing and technical prowess with Passenger, aka Raptor. I got a chuckle out of it myself.

I was excited when it was just Passenger. I say just Passenger 5 because as a Passenger user, now all I got to do is upgrade, right? All I got to do is hit the old upgrade button. Thanks so much for your open source over the years, and thanks for joining us. Yeah, I think to add to Jared's note there, I think the marketing take was genius in my opinion. I sure hope any sort of lashback from the community on the bait-and-switch idea that you mentioned doesn't come back to you harshly because I think that you made a bet. All we can do is test things, right?

Test the waters on how things can be released. And I think you proved that shiny objects are attractable. You grew your newsletter list quite well and you grew better support for it. And you've reopened new eyes to passenger through this. And now we just have to fulfill our promise of being better. We have to keep up with releasing new features and just making it better. Yeah.

And I can imagine that brought some more demand to the Enterprise Edition as well. But that is it for this show. Hung Lee, so much gratitude for you to come on the show and you and your team making the sacrifice to stick with it and elongate your studies and then also your financial benefits to come along with working and stuff like that. I know that it isn't always easy to see that, but on behalf of the Open Source community, I know that Jared and I want to thank you on their behalf because I know that many of us out there use Passenger, and we appreciate your sacrifice and your work in open source for sure. Along with that, we do want to mention a couple sponsors for this show that helped make the change all possible, specifically an awesome Ruby host out of Australia, Ninefold. Good friends of ours have been waiting for an awesome Ruby show to come on the changelog so we can mention them but Ninefold

is super awesome we'll put a link in the show notes about a particular deal that they're offering changelog only listeners also our good friends over at TopTel love love of TopTel and also Dave's work for time tracking brand new tool out there getting a lot of press sensible

time tracking we'll tell you a bit more about that in the show notes as well but again thanks for coming on the show and let's everybody say goodbye goodbye goodbye bye All right, everybody. You thought the show was over. The show is not over. We have one more thing. Yes, one more thing to mention. I just can't believe it.

We've got an admin panel that's being mentioned. Hanli, why don't you take it over? Tell us what's happening here with this admin panel for Passenger. Yes, so this admin panel would be a very useful tool for displaying your requests, displaying your processes, and would just make it a lot easier to see what's going on on the application and passenger level. And then you can kind of monitor your CPU and memory usage with that,

and the admin panel could be used to watch your logs, to detect problems, and so forth. And it would be just a lot nicer compared to using the command line. I'm sitting here looking at some mock-ups you had here. So you can see processes. So for active processes, you can see your logs. You can see all sorts of different things. When is this going to be available?

Is this coming later? Is this soon? Is this in process? We have not started working on it yet. It's currently on the concept level. We have just made mock-ups. The thing that we are prioritizing right now is to get Passenger 5.0 out to make it stable,

and then we focus on the new features. Okay, so we're talking about mid-this year then? 2015? I believe so. I think mid-this year you can expect a first version of this. Gotcha. And we'll have you back on the Change Log. You get to come back and tell the listeners

about this new fresh hotness. People love new fresh hotness, as they've heard in this show, right? So that's what we'll do. All right. Thanks for telling us about this awesome admin panel. We can't wait to hear about it. Thank you.