This week on Cloud Out Loud, Danish Khan interviews Tom Mornini, co-founder of this fine conglomeration of hardworking people that we call Engine Yard. His profound passion for Ruby on Rails really comes through when he speaks about the evolution of Engine Yard as a necessary reaction to the explosive growth of the community. Danish: Hi, Tom. Could you introduce yourself?
Tom: I’m incredibly humbled to be a founder of \"Engine Yard\":http://www.engineyard.com/, which has grown so quickly beyond our imagination when we started. I’ve been in programming, I have a very technical orientation. I’m the CTO here at Engine Yard, and I’ve been in tech since I was twelve years old, in 1978. I guess I just gave away my tender age.
Danish: What is your role at Engine Yard and how has it evolved? Have things changed with the company’s growth?
Tom: It’s changed really dramatically, and it’s been kind of a roller-coaster of sorts. It’s had its incredibly exciting parts, and it’s absolutely terrifying parts. When we started, Lance and I were interested in having a product-based business. We had a human talent consulting service called \"Quality Humans inc\":http://www.qualityhumans.com/. Then we stared into Rails, and what we realized that Rails was really tremendous and was going to have a gigantic impact on IT. The missing piece though, was simplified and really high-quality deployment expertise. That’s how we got started. I think people might find it interesting that one of our primary goals in starting EY was to create a company large enough that we could support ourselves and our families and have group health care. Sometimes the very simplest of thoughts can lead to really exciting times and changes in your life.
One of the things my Dad taught me is that when you go into a small business, the person working the hardest is inevitably the owner. As I’ve grown older and gotten more and more curious about such things, I’ve actually made a point to go over and ask the person who’s during the worst job, the guy in the independent gas station spraying down the pavement at 2 in the morning. It’s usually the owner.
Especially in a company in a high-growth opportunity like Engine Yard was in, I think a lot of our employees worked incredibly hard behind our real hard work and willingness to roll up our sleeves and get in there and do that front-line work. If you exert yourself that way and provide leadership by example, people will follow. If you work hard, and ceaselessly and tirelessly, everybody will fall into place. All of the employees at Engine Yard show that on a day-to-day basis, and have since the beginning. We have absolutely tireless, dedicated people working here and I love every one of them for the effort they put in.
What happens is, you can’t lead effectively that way for very long. You get burned out, and more importantly, you get too involved in day-to-day decisions, and you can’t steer the company if you’re in the boat. It’s been very very difficult for me to transition to more of a guidance and keeper of Engine Yard culture. I think it is important—a lot of what got us here was a few very specific thoughts, and as a company grows big it’s important that it not lose its roots. But it’s also a very, very difficult transition growing from a company of 5 to fifteen employees. There are stages along the way that are very, very tricky and that’s why we’ve brought in management to help us, because frankly, we didn’t know how to run a company with more than thirty employees in it.
Danish: I know people say that when you bring in management, that the culture of a company changes. But when I first came to work here and someone pointed you out as the founder, I said, “that guy in the t-shirt and shorts, eating that burrito over there?” How did you maintain the casual, start-up culture around even after bringing in management?
Tom: Well, there are people here including early employees who would say that actually I did a pretty crappy job of it. This is something I’ve spent a lot of time thinking about and the answer is pretty complex. The simplified answer is that the culture of a true start-up--an idea alone, creating the first product, getting the first customers—it’s chaos. And it’s managed, focused, crazy, beautiful chaos, but it doesn’t scale well. Things start unwinding pretty quickly until you get systems in place. Lance and I have started a lot of business, and we knew a lot of the things we had done right in the past and a lot of things we had done wrong in the past . With that in mind, we tried to fix some of the things we had done wrong and keep all of the things we had done right. But what we had never done is run a big company where you have to get a hundred people aligned on a common theme, and really greatly increase the pressure at the tip of the sphere. It’s hard for five people to become unfocused. It’s extremely easy for a hundred people to become unfocused. For years I’ve heard big companies with this concept of “focus, focus, focus, focus,” and I’ve never appreciated it as well as I do today. I encourage everyone who’s listening who is running a small company not to slip into something that I certainly slipped into at Engine Yard—Having a long-term vision is good, but you can’t resolve it all at once. One of the things John Dillon, our new CEO, has taught me is that there are a lot of things to do and we need to do them one at a time, until we’re really good at them, at which point we can maybe start doing things two at a time. It seems crazy that with millions of dollars of funding and a hundred people here that we can’t do more than one thing at a time, but it’s the reality. Big, billion-dollar company usually only have three or four things they do at one time. And I think a lot of start-ups, because there’s so much to do, can get disoriented that way and think they have a hundred things that are critical right now. So, lots of things to do, do them fast, do them one at a time, and rinse repeat is really super fundamental.
Danish: A lot of people ask me why there is no Engine Yard for other languages, like Java. What’s your take on that?
Tom: People have asked me that for years and years now, and I’ve seen it on Twitter. It’s very clear that something kind of special is in the water that the Ruby community drinks from in terms of Cloud adoption and that sort of thing. I’m now kind of paid to think about these kinds of things, and now that I don’t have my head down in the weeds, I can actually spend some calm time contemplating such things. The simplest answer, which is probably the right answer, is that in the past, application development was so torturous and slow that if it took two weeks to requisition a server and configure it to run your application and then run it, that wasn’t a big part of the application development process. I think what David at \"37Signals\":http://37signals.com/, the creator of Rails—who I pay continuous homage to for giving us this unbelievable gift of Ruby on Rails—I think David and Matz combined will be remembered as the Henry Ford of modern software development. In the past, every application was a bespoke, custom coach, manufactured for the owner. Ruby on Rails is more of an assembly line. It simplifies the enormous complexities of application development with extraordinarily consistent and beautiful, common answers that work better than anything I’ve ever seen individually designed. Now we have a situation where a couple of developers can write an application in a couple of days, and that application doesn’t even need to be trivial. It’s unbelievable what the guys at the \"48-hour Rails event do\":http://railsrumble.com/. It’s unbelievable the kinds of applications that they’re building in 48 hours with a couple of people. That I think is why Rails is so far ahead in the Cloud space, because if you can build something in 48 hours then you can’t spend a couple of weeks deploying it, right? It was an absolute requirement that we exist. There’s no other way it could have happened—it was purely evolutionary.
Danish: What got you and Lance to decide, “we’re going to do it on Rails,” even though Rails was a new language among other game-changing languages. What really got you guys to decide to use it?
Tom: At the time, I was working among Fortune 50 companies, as a consultant to an enterprise software development tools company. We were modernizing their software development processes. I was shocked at how far behind open source, modern techniques these enterprise companies were. Working at those environment taught me a couple of things: the world is really quite large. There is a class of customers that has business problems that need solving that aren’t entirely associated with the lowest cost. Fortune 50 companies have stacks of money. They use that money as a tool or weapon to get things done. They are more than happy to spend money to solve problems. And I saw them spending gargantuan sums of money, to put ridiculous products into production, vs what was available in the open source world. So that, to me, immediately screamed “Gigantic Opportunity.” I couldn’t believe how big the market was, I couldn’t believe how easily they wrote really large checks. To people that are into technology, that are into programming, that have an engineer mentality, one of the prime aesthetics in engineering is efficiency: You want something that exactly matches your specs at the lowest possible cost. That almost is the definition of engineering. Because of that, I have noticed that engineers have a crazy kind of cost-benefit analysis: they will spend an enormous amount of their own time to save a penny, because that is the aesthetic. That could be the difference between being the cheapest way, and not the cheapest way. The cost-benefit is way off.
So I saw these companies with big problems—billion dollar problems—that were willing to spend a lot of money to solve them, who weren’t really concerned with the efficiency of that. Right about this time, I was kind of burnt out on this gig, and a buddy of mine, Aaron Frye, sent me this very innocuous email that said, “Hey Tom, I’ve heard about this new thing Ruby on Rails, and I’d like your input on it.” I had heard about it as well, as a distant echo, in the newsgroups and stuff I read at the time. I Googled Ruby on Rails and saw the \"famous fifteen minute video\":http://www.youtube.com/watch?v=Gzj723LkRJY. I was quite impressed. It was something very different. David was a tremendous salesperson on that thing. I went to Amazon, and there was the great book by Pragmatic Programmers Group, Dave Thomas, \"Agile Web Development with Rails\":http://pragprog.com/titles/rails2/agile-web-development-with-rails. It was available for pre-order, not yet for shipping, so I ordered it and then I totally forgot about it. As soon as I ordered it it left my mind in a way that few things ever have. A few weeks later, I came home and there was an Amazon package on the doorstep. I picked it up and threw it on my wife’s pile, because I knew for a fact that I was waiting for nothing. I had totally forgotten about it. A few hours later, she came in and said, “Did you order this?” and it was the Agile Development with Rails book. I was really excited, because I was bored to tears and tired of traveling, so I was like, “Yeeha, I get to learn something new,” which is one of my favorite things in the world to do.
I sat down and started reading this thing, and I could not believe—Ruby on Rails addressed every concern that I was running into on a day-to-day basis and that these companies were writing these gigantic checks to fix. It solved them in a way that was simple, that was unified, that could be repeated across applications forever. So I was enthralled, to say the least. At the time, Lance and I had started another business, which was a horrible failure. We had an application written in Perl, which I’m actually quite a big Perl fan, or was back in the 90s. There’s good Perl and bad Perl and this was the worst of Perl, the worst of a lot of things. I decided that the best way to learn would be to rewrite this application in Ruby on Rails. I was on the way to Washington DC, where we had a consulting gig, and I took the red-eye from Sacramento to Washington DC, and when I got on the airplane I had my laptop all configured to run Rails, and when I got to DC, I had about 85% of the application recreated on a five hour flight. Lance was in DC already. We had a corporate apartment there. It was about 7:30am when I got to the apartment. Lance was up making coffee and breakfast when I walked in the front door—I was completely manic. I said, “Lance, Lance, Lance! This thing is completely unbelievable. Let me show you what I did!” He couldn’t believe it either. I said, “We have to be in the Ruby on Rails business. Buy the keywords, put it on Quality Humans: we are now consulting in Ruby on Rails.” And Lance, being the unbelievably great business partner that he is, and the hardest working guy I know, just made it happen in a few hours. The phone just started ringing. So there was already at that time, about five years ago, this enormous, pent-up demand for Ruby on Rails developers. It wasn’t that there were so many people clamoring for it, it was that there were so few people who knew how to do it and were willing to do it professionally. So, that got us really excited, because there’s nothing like having an idea and having other people agree to pay you money to do it. That’s a very fun feeling. So we started doing that consulting, and what we found was that it completely transformed our consulting business. We had used to have a hard time getting projects done and customers happy with the code. The whole world has suffered this in software development for decades. It’s the problem in software: We can’t get it done fast enough and it never turns out quite the way we want it to. That problem just ceased to exist and the next problem was, “Where are we going to run it?” There were no experts on running your own stack, the stack at the time was extraordinarily complex. It used no technology that anybody else used. The Ruby on Rails community were a bunch of crazy maniacs. They didn’t use Windows, which, at the time, was unheard of; they didn’t use Apache, which at the time was unheard of; they used this crazy language, Ruby, which was developed in Japanese and half the documentation was in Japanese. I mean, it was just a crazy-house compared to the norm, which I am really comfortable with. I don’t like being in that normal group. So I just felt an immediate kinship toward the community, I loved the people who showed up at conventions, the people there were bright and were tired of the status quo. They were tired of the problems they’d had developing software and they’d found a solution. So we decided that we needed to make deployment really easy, and that formed Engine Yard. So, you set the question up like, “you started Engine Yard, what language did you choose to support?” That was totally backward. We were all about Ruby on Rails. We saw pain in Ruby on Rails deployment, and we solved that problem.
I didn’t feel like there was even any decision to make. The decisions all appeared to be right in front of us ready to knock down. The hardest parts were getting the right people, getting the message across and all that. It really didn’t feel like we were trying to create something. It felt like a rip had opened in the space-time continuum and we were just sucked into it.
Danish: We have some questions from your Twitter followers. The first one is: do you expect to have a two hundred million dollar buy-out from Salesforce anytime soon?
Tom: Obviously that’s in reference to the recent \"Heroku\":http://www.salesforce.com/ acquisition. We’re good friends with \"Heroku\":http://heroku.com/, they’re here in San Francisco as well, we knew them before. I remember the first time I met them, they came into our office in San Francisco before they even had an office, I think. A lot of people have set us up as enemies, but internally we’ve always felt that we would eventually probably have to go after each other--after we both helped take down Java.
We really, clearly understood that our product were different, they had different ideals, that each would attract its own customers—the real enemy is not Heroku vs Engine Yard--the real enemy is Java vs Ruby. I think we’re both winners with the Heroku acquisition, because it’s very clear now that that Ruby on Rails is headed deep, deep into the enterprise. Salesforce has announced that, VMware has announced Ruby on Rails support with their OpenPass platform at RubyConf X in New Orleans this year. Nothing could make us happier. The other thing that’s really clear is that everything’s for sale. If someone offered me the right price today, I’d sell you my shoes. That said, when we partnered with Benchmark, Benchmark surprised Lance and I by saying something that was very contrary to what we understood the VC world to be about. They said they believed that there is room in the future for an independent public company in the Ruby on Rails space. That’s what we’re trying to build here. We’ve never been in a race to sell Engine Yard. It’s just that simple. What we’re trying to do here is to build a very big, very cool company that can change the world one developer at a time and take the Java shackles off of their wrists and set them free with Ruby on Rails.
Danish: Last question: Any plans for other cloud providers or open-stack technologies?
Tom: Yes. \"AppCloud\":http://www.engineyard.com/products/appcloud, our primary product, takes your apps and deploys them on the AWS infrastructure. We absolutely have rather carefully designed the product so that when the time is right, we will be able to take the customers’ applications and deploy them onto various different back-ends. And perhaps just as importantly, we are eager for customers to be able to push a button and move from one provider to another. I think that is a slightly harder problem than some people make it out to be. The technology of doing it is pretty straightforward, but getting all the pieces right so the application continues to perform properly—what components can be hosted externally as a service, what things must be low-latency connected to the application itself—getting all those pieces right and making that migration smooth and easy is very important. So it’s absolutely part of our planning, certainly no product announcements today. What customers should know is that these decisions will be made based on what cloud platforms they want to deploy their Engine Yard apps stack on top of. We are not going to be trying to pick winners and losers in the cloud space or anything like that. Wherever customers want to go is where we want to be.
