We are here at Ruby Conf 2006, and we are going to talk with Ezra Zygmuntowicz. Why don't you tell our viewers a little bit about yourself and what you clame to fame is?

My name is Ezra Zygmuntowicz, and I have been doing Ruby programming for about 4 years, and Rails for a little over 2, ever since it first came out. I built one of the first largest Rails sites for the newspaper called Yakima Herald Republic, and it's one of the top 20 projects on the Rails website, and made quite a few open source contributions to Rails and Ruby over the last couple of years. Other than that, before I got back into programming around 2000, for all the ‘90s I ran a glass blowing school and studio in Bellingham, Washington. Really different than programming but I've always been interested in computers, I had my first Mac 128k when I was 7 years old, and I did all my own PHP and MySQL stuff for my glass blowing business, for online presence and everything; then got out of the glass blowing business, went back to school and have been programming ever since.

You have some exciting stuff going on with a company called Engine Yard, right?

Right now we have a start up, Tom Mornini, Lance Walley and I have a start up called Engine Yard, and it's being incubated at Quality Humans, which is a Rails and Perl staffing company. Engine Yard is the next generation Rails hosting services, fully targeted at the higher-end Rails applications. We support Ruby applications too but nothing else, that's all we host. And it's all based on cluster redundant technology, everything is built on top of Xen and there's two more of every single piece of hardware in the whole system, so that everything is fully redundant.

What is Xen?

Xen is a server virtualization technology, that allows you to run one Linux kernel basically that is your dom zero or your hypervisor, that runs directly on the hardware, and then you can run any number of user virtual machines on top of that, so you can basically partition one physical box into ten or twenty virtual machines.

What sets apart Engine Yard's offerings from other virtual private hosts?

Other virtual private hosts are offering just a virtual private host, you get your VPS, you get access on it and you handle setting it up yourself, you do everything yourself, and you don't get any redundancy out of that. If your server goes down you are down. In our offer we are building everything around Xen, and our offering is called a slice. With one slice you get one Xen VPS like the other guys give you, but you also get a section of the cluster database server, section of the cluster mail server, cluster's version, redundant hardware low balancers, storage area network, and all that stuff. If you buy your VPS from a normal other provider you need to run the database, your mail server, your Apache, your Mongrels, everything else in one virtual machine, and most VPS places get very small memory so they run out of space pretty quick. But what we do is make sure your virtual machine only runs your Rails application in Mongrels and everything else is on different machines in our cluster, and it's like a mini EC2 for Rails. EC2 being the Amazon classic compute cloud thing. We want people to think of us more as a Rails hosting utility than like a hosting company. The way we got things set up is you can start with one slice but the general recommendations is 3 slices: 2 for production and one for staging, as you need 2 to be fully redundant, because they would be on two different physical machines.

Is it catching on? This is a pretty good idea.

Yes, it's catching on, we already have got around 30 people on there and a big waiting list for more, we are building stuff up, and right now I'm working on the control panel. You can go on http://engineyard.com and check out the blog where I posted some screencast movies there, and the control panel is pretty slick.

How long have you had this in works?

We've been working on it since February, designing the system and so on, we actually got a little bit of funding and got hardware in July, and now our cluster hardware and technologies are all done and set up and I'm just about to finish up the control panel in the next couple of weeks.

Does Rails scale?

Yes, Rails scales just like everything else scale. There's a couple of ways to look at it. People think PHP is easy to deploy because you copy the directory up to a server and run it. That's true but then you face the same issues when you want to expend it to more than one server. You have to synchronize your static files across servers, the database is always a bottleneck, and the cool thing about Rails is that it's such a unified environment where everybody's project fits the same layout, so it allows us to do a lot of automation. With other frameworks or PHP everybody does their own different thing, so it's hard to automate stuff. But Rails scales like any other shared nothing-type technology, especially when done correctly. What we are selling at Engine Yard is you can start small and as you get more and more traffic, or you get dugg or slashdotted, when you first sign up, and you can sign up only for a slice, you can say "I'm willing to go up to ten slices if I get dugg or somebody mentions me on a TV show or something" and as your traffic gets hit we automatically boot a whole other of virtual machines, duplicate your Rails environment that will join your cluster.

Are you saying that it is possible to do this because Rails applications follow conventions ?

Yes that's right. Rails is opinionated software. Engine Yard is opinionated deployment. We lock you down to a certain thing but you accept our handcuffs and you don't have to do anything. You build your application, we handle everything else. We are all about support too. You don't have to know anything about this, I've spent the last couple of years learning how to deploy Rails applications and I'm almost done with my Rails deployment book for the pragmatic programmers I've been around the block with all the different options and I've explored every type of webserver out there, and we've done all the research and I feel this is a really good platform.

You've been doing Ruby for 4 years. How has the Ruby community changed in 4 years?

It's gotten a lot bigger. There has been a huge influx of people because of Rails. It has an interesting dynamic, especially lately, there's a huge influx since it gets so much attention, there's money being thrown around, lots of corporations coming in; there's JRuby with Sun behind it, so a really bright future for Ruby. There are 6 different people implementing virtual machines and the Ruby community is very friendly. There's been a little worse signal to noise ratio because of the huge influx of people into Rails, but it's still a really friendly community compared to some other communities.

You come from a PHP background. What are the challenges for people coming from PHP to Rails?

With PHP even when people do object oriented PHP it's a little more closer to procedural, using objects to encapsulate a bunch of functions, and it's not that rigid. With PHP code you look at a number of different stuff and everybody does something their own different way. It's not as structured. A lot of people coming from PHP aren't familiar with MVC paradigm that Rails uses, that's something they have to pick up on. Ruby itself is a really interesting language, it's deceptively simple at surface especially with Rails, will all the custom macros, the little helpers and everything, it seams like you are learning a dialect that does everything for you but there's so much under the hood in Ruby that I recommend anybody coming into Rails to really focus on learning Ruby itself, because Ruby is what makes Rails possible, and Rails is fairly simple, Ruby goes really deep.

Put on your prediction glasses and look into the future a little bit. Where are we a year from now?

It's hard to say; I love Rails but I have a feeling there's going to be some other Ruby frameworks that people are going to be happy with. And Rails is going in the right direction, they are trying to shave some features and slim down the core, move stuff down in the plug-ins which I think is really good because Rails is pretty huge right now, the framework size, but I predict a lot of that stuff is going to be worked out. About a year from now we are supposed to have a stable release of Ruby 1.9 with the YARV virtual machine which should speed things up significantly. I personally would really like to see Rails get thread safe but that's whole other project, it's a big undertaking.

Thread safe meaning that you could run it on a system with native threading?

Not necessarily that, but meaning that for example right now most people use Mongrel for deployment. The way Mongrel works right now is by a big mutex around the dispatch to Rails, so it has to serialize it one at a time. If Rails was thread safe, it could handle multiple at once, so you could get a lot more performance and a lot more concurrency out of one Mongrel than without having to go to the multi-processes to handle all this.

What's the challenge behind making that happen?

It just hasn't been a priority. Rails is really complex, it seams simple on the surface but there's some really amazing code underneath that people have written.

Do you think that the feeling is that it is good enough?

I think the feeling is that it is good enough and I won't be upset if it doesn't ever happen, but I'd like to see some work done on it.

As someone who needs to know about these things based on what you are telling us about Engine Yard, is Rails good enough?

Yes

You have clients, you have people that are scaling, that are getting dugg...

Yes we have people. We had a person yesterday and it was the first time we got to put the scale on top of the ...we have a client that is soft-launched. I can't say their name, but they are in alpha. Actually, they are http://kongregate.com/ and they got "techcrunched" and we noticed it before they did, because I subscribed to the techcrunch feed and I was able to up their capacity as they started to get a lot of traffic from that, I was able to update their capacity before anything happened and they were able to use the whole techcrunch traffic.

How much memory got eaten up? Because Ruby-based stuff is a memory hog?

The way we are doing things at Engine Yard is Ruby applications vary so widely in how much memory they use, and some use a little and some use a lot, we are not setting a hard memory limit on the slices you get. Your virtual machine is guaranteed to run 5 Mongrels with your application regardless of how much memory your application takes to run 5 Mongrels. You buy slices in increments of 5 Mongrels and the rest of the cluster scales with you. So we were able to bump them up a few slices and handle the tag crunch which was quite a bit of traffic. And in the benchmarking and testing we've done, the setup we have is optimal for Rails. We built a full custom Gentoo image just for Rails, that's all optimized just to run Mongrel and Ruby applications.

Is it something that you keep as a competitive advantage?

Actually once we get a little more time on our hands, and get the control panel done and get our clients on the cluster we are going to release an Engine Yard Gentoo distro that people will be able to use and probably we'll offer it as a xen image or VMWare virtual player so people can have an exact duplicate of their Engine Yard environment on their local machine so they can develop there and deploy it and to be sure it's the same thing. We are going to release this soon.

Good to hear you are still making lots of contribution to the community. Thanks for spending some time with us. We're looking forward to a lot more in the future.

Thank you!