The cloud providers are splitting into a few camps.  On one side, you have
companies like Amazon that offer infrastructure as a service (IaaS), and Google
who offers platform as a service (PaaS).  PaaS offers rapid development,
and no server administration, but it locks you into a specific provider. 
Enter Engine Yard, a company that's enhancing Ruby on Rails to run on on top of
arbitrary IaaS.  In this interview Ezra Zygmuntowicz paints the picture.

• Defining platform as a service and the creation of Engine Yard
• Advancing cloud computing beyond buzzwords
• Opening cloud computing as a simple, provider-agnostic framework
• Operating system and programming language flexibility
• Providing flexible scalability of data stores
• Paradigm shifts created by cloud computing, including admin roles and rapid start-ups

Scott Swigart: Please take a moment to introduce yourself and your company.

Ezra Zygmuntowicz: I’m one of the founders of Engine Yard. We started life as a hosting company, and we’ve evolved into an open source company with a platform as a service cloud offering that we run on other people’s infrastructure.

I’ve been heavily involved in Ruby and in the Ruby on Rails open source community ever since Ruby on Rails first came out in 2004. Back then, I was webmaster for a newspaper–the Yakima Herald Republic in Yakima, Washington. I was looking for some kind of new language to redo their whole website, because it was kind of an old mess.

I was reading up on Python and Ruby, and when Ruby on Rails came out, I took it and ran with it, building one of the first commercial sites in Ruby on Rails. That site is still live and running there, and that’s how I got into the deployment and hosting sides of things.

Back in the early days, nobody knew anything about deploying Ruby on Rails applications. There just wasn’t much information available on it, and there weren’t many big sites doing it. I was the only tech person at the newspaper, and they bought me a couple servers and said, “You need to put this new Ruby on Rails site online and take the 250,000 hits a day we get at the old site right off the bat.”

That pushed me to start researching how to deploy and scale Ruby on Rails applications on an open source stack. In the community, I became one of the de facto deployment experts, and I wrote a book, Deploying Rails Applications for the Pragmatic Programmers.

The business partners that I started Engine Yard with had a consulting company called “Quality Humans” that was a Rails consulting shop. They had a couple of big clients, and they were trying to figure out how to deploy them. They took them to Rackspace, but Rackspace didn’t know anything about hosting Ruby back then, and Tom and Lance saw a business opportunity for building a high quality hosting platform for Rails applications.

They went looking for somebody to help them with that. They found me in the community, and we got together in early 2006 and started planning this platform for running Ruby applications.

We scrounged up our first $100,000 to get a few servers and our first data center in the summer of 2006. We started taking customers in September 2006, and it’s been a wild ride since then. We’ve grown from a tiny startup to 85 employees in 12 locations around the world, running quite a few very high-traffic Ruby on Rails applications. That’s where we are today.

Scott: How does open source fit into your business?

Along the way we’ve had to build all kinds of tools, and our whole stack is built on open source. We were active in a bunch of open source projects, and we have a number of projects ourselves. We have a project called “Rubinius,” which is a new virtual machine for running Ruby code that we’ve been developing for awhile.

We just hired the guys who run the JRuby project, which is a Ruby virtual machine built on the Java virtual machine so it runs on the JVM. They liked the idea of coming to work for a company focused on Ruby on Rails, so they ended up coming to work for us.

On top of that, we had an open source web framework called “Merb” that we wrote to create a sort of high performance version of Ruby on Rails, and that had quite a bit of success. It became more and more of a compelling product, and we realized that we were stealing some thunder from Ruby on Rails.

We had started our company to support Ruby on Rails, so we got together with the Rails core guys and we decided to merge the two projects. So, Merb and Rails have merged to become Rails 3, so it’s kind of a cool open source story.

The long view is that we kind of forked off to make some performance improvements and provide some different architecting approaches. That was successful, and now we’ve merged that back into the main line of Ruby on Rails to make it better. That’s the little story of how we got where we are today.

Scott: That’s an interesting history, and it I think it’s pretty unique to open source. It proceeds from the idea that a group of people can take a code base off into the wilderness, take it in a different direction to support a different use case or optimize it, and finally bring it back and fold it in.

We see a lot of open source projects go through iterations like that. For instance, between Apache 1 and Apache 2, there were lots of changes, and PHP has gone through similar evolutions. As you mentioned with Ruby, sometimes things go their separate ways, and they may stay separate, or they may converge back together.

Ezra: That’s a pretty cool open source story there, because it shows how open source is a new way of working on software. I think it’s a better way than closed source, because you can get so many more eyes on the problem.

Anybody can look at the code, and if they’ve got an itch, they can scratch it themselves and improve it to do what they want it to do. We were interested in being able to run these Ruby applications in the most efficient and resource-conscious way we could.

When we started building Merb out, it kind of took on a life of its own, eventually starting to look almost like a rival to the Rails project. Both projects basically have the same goals: to build a high-level, full stack that’s easy to get started with and that provides a very rapid application development platform.

It almost felt like we were fractioning the community a little bit by having Merb as an alternative to Ruby on Rails, and like we might be confusing people a little bit. There was starting to be a little bit of rivalry between the two camps, and I just didn’t think that was useful for the Ruby community at large to have this kind of chasm.

We got together with the Rail core guys and started recognizing that our views on most things weren’t so different. We started looking for ways that we could patch the two projects together and come out stronger on the other end.

Since then, we have been focusing all our work on Rails, and bringing the good parts and the performance focus we had in Merb into the new release of Rails, which is going to come out in a beta release sometime fairly soon. Because they’re fairly similar projects, there wasn’t any reason for them to be separate.

It was cool that everybody was able to get along and see that we’re all basically working toward the same goal, and we’ll be stronger if we combine efforts.

Scott: I guess Rails is sort of a platform as a service on top of cloud infrastructure. And since cloud’s the hot topic, let’s go ahead and stick the shovel in there. To start, how do you define that?

[laughter]

Ezra: Nobody knows what a cloud is these days. It’s kind of become a term for anything that runs on the Internet.

Scott: There are some people who are very serious about having a very strict definition, while others are kind of like, “Well, if we just put cloud on our marketing material, we’ll sell more. So let’s call what we’ve been doing for 10 years ‘cloud.’”

Ezra: Absolutely. To me, there are a couple of different kinds of clouds. First are the infrastructure as a service clouds, with the Amazon Web Services platform as the canonical example. That’s what I mainly think of when I hear the term “cloud,” because it’s what I feel the true definition of “cloud” is–an on-demand compute service where resources are disposable and scalable.

I would call something a cloud if it’s API addressable first and foremost. It has to have an API so it can be manipulated programmatically. It has to be able to scale up and scale down on demand, so if you need more server capacity, you just bring a few more servers up. If your load has gone down, you drop a few and you go back down. The business model is kind of metered, like the electrical grid, where you just plug in and pay by the hour.

Then there’s all kinds of other stuff that people are calling cloud. There’s higher level stuff, like platform as a service, which runs on top of infrastructure as a service, but it’s higher level and deals more with application services, rather than the low-level infrastructure.

Scott: What’s your own history with cloud computing?

Ezra: When we started Engine Yard back in 2006, we needed a platform to be able to build this Ruby platform as a service thing. This was before EC2 was out, and before people were calling things cloud, and before there was Amazon Web Services.

We built something in our own data center that looks a lot like EC2, based on Xen virtualization and Gentoo Linux. We still have our own customized version of Gentoo that we optimize for Ruby.

We built a private cloud ourselves, although that’s kind of a loaded term as well. It was a virtualized cluster platform that ran in our own data centers. We built our platform as a service on top of that. That’s higher level and deals with the application.

As time has gone on, the Amazon platform has gotten very compelling, and other clouds have popped up, so we have realized that the value that Engine Yard adds is not necessarily at the infrastructure as a service level. We don’t really give ourselves a big differentiation by racking hardware and running data centers. We can’t compete with somebody like Amazon on that scale, as far as racking and stacking servers.

We realized that our strong point is what happens after you have a VM online with network and compute and storage. Then you need to put an operating system on there and bring that up all the way up to the application. Then you need to monitor, scale and recover your application from failures. That’s more where we fit in, and that’s where our value is–in platform as a service.

Starting last year, we started taking everything that we’ve built, all our glue code, and all our open source stuff that we call our stack, and we started porting it to run on top of Amazon Web Services, rather than our own cloud. We’re kind of abstracting that, so that we can farm that out to Amazon or any of these other providers that have vCloud or other stuff popping up.

It’s not a super interesting business, racking and stacking servers, but the code and the platform that runs on top of that is a lot more interesting to us. So as a company, we’ve transitioned from the model where everything happens in our own data centers to a platform that runs out on the cloud in other people’s servers.

Scott: We’ve talked to a lot of people who are Amazon Web Services customers, and they’ve talked about use cases. Generally, it seems to be fairly good at existing applications.

For example, we talked to some guys who do web resources for the Indy 500. They’ve got an enormously elastic need. When there’s an event, they’re going to have a tremendous amount of traffic, but when there’s not an event, there’s very little traffic. And so they’ve got this need to spin up 100 servers, have them be up for a week or so, tear them down to a handful, and then spin them back up again.

We talked to other people who do diagnostic kind of stuff, and a lot of these show up as Amazon case studies, so if somebody wanted to go look, they could go get details on these. At any rate, this company runs their own internal grid for these analytical models, and when they’d get a particularly large data set from a customer, again, they have a very elastic need.

It worked pretty well for them to take their existing apps and just run them as is. They don’t need to maintain enough hardware for their peak load, and their internal servers now are just whatever they need for ongoing day to day operations. All the elasticity happens out in the cloud.

So that’s one kind of cloud, and then there are other kinds of clouds coming on line. Google’s been out there for awhile with App Engine. There’s also Windows Azure, where you’re coding to a certain kind of API, within a certain development framework, and you don’t even see machines. You just put your code up, and you don’t know or care whether it’s running on one box or 10 boxes or 100 boxes. It’s very request-response based.

And there you’re making a bet. With Amazon, you’re not making a bet on Windows or Linux or any of that stuff; you’re not even really making a long-term bet on Amazon as a cloud provider, unless you program to something like SQS. With somebody like Google or Microsoft, you’re making a bet not only on whether you want them as a cloud provider, but also on whether you really want to stick with that framework. If you’re using Google App Engine, then the only place it runs is on their framework. And the only place that framework is available is on their infrastructure.

Looking at that world, you might think that maybe there’s an opportunity for something that’s sort of in between. On one hand, maybe you could choose an infrastructure as a service provider, as a somewhat independent choice, and on the other hand, maybe you could choose the platform as a service framework, also independently. You could sort of mix and match the two.

Is that the kind of scenario that you are enabling?

Ezra: I think you hit the nail on the head about what we’re trying to do. I look at it like this. You’ve got raw AWS as the canonical example of the infrastructure as a service right now. But they hand you very low level building blocks. You get compute, you get network, you get some memory, get some storage.

You can choose Linux or Windows or whatever, but they hand you these big building blocks, and you still have to assemble those into something that can run your application, and scale, and be reliable at the application level, and so on. You still require quite a bit of system administration, and it’s not something that Joe Schmoe can just use out of the box.

Then there are the higher level things like Google App Engine, where Google has made a lot of decisions for you. As long as you can fit within their box, you don’t have to worry about servers anymore. You just twist the dials and scale up as needed and pay for what you use.

That’s really compelling to people, but it requires them to buy into the lock-in of this Google App Engine thing. You can’t run elsewhere, and you’re going to have to be able to color within their lines. There’s a definite limitation on what you can and cannot do there. You are betting the farm on that being the right way for you to architect things.

We’ve built this platform as a service that takes the low-level building blocks of something like Amazon or another infrastructure as a service provider, and we have done the research on how to assemble the best practices. We have figured out how to load balance a scalable application farm, a database with replication, and all this kind of stuff for you, and we’ve figured out how to work with elastic block storage, and snap-shotting, and all that kind of stuff.

We’ve taken that and wrapped it up into a nice little push button platform as a service, where it’s pretty much just as easy to get going as with App Engine or something. You tell us about your application code and click a few buttons, and we’ll build a whole cluster for you.

But it still looks like your old school Web 2.0 deployment. You’ve got your load balanced applications and your MySQL or Postgres databases. You get SSH access with root login on your boxes, so you can still login and see what’s going on, and it feels familiar to people.

Our platform as a service is kind of in the middle of that. You can still not really know what you’re doing and come and just click a few buttons, and get this full cluster and everything up and running, and then add capacity and remove capacity as your traffic goes up and down.

But there are no limitations as far as what you can run there. It’s just Linux. You have root access, so anything you have been running on Linux servers will still run on this platform and none of this color within the lines stuff, where you can’t do a certain thing on a platform because they don’t allow it.

Scott: Will it actually spin up and spin down nodes as demand increases and decreases?

Ezra: We haven’t released that feature yet, but it’s something that we’re working on right now, and we hope to release it fairly shortly. Right now we can basically do that, but you would get alerts, and then you would have to make a manual decision to click a button to add or remove a node. We are working on adding the whole auto-scaling thing.

Auto scaling is really hard to do in a least common denominator type of way that works for everybody, because it can be so application specific. But we can kind of get away with it because we’re doing this platform that is all Ruby applications. They all have very similar needs and profiles in terms of how they work.

Scott: I don’t know your guys’ architecture, but one of the scenarios somebody mentioned to us was, “It’s not memory or CPU that I’m concerned with; I care about the queue length and the simple queuing service. And based on more queue items, I want to spin up more nodes.”

Ezra: Right. If you just build an auto scaling system that adds nodes when your load average goes above X, it’s never going to work that well. You’re either adding too many nodes all the time, or not keeping up, or whatever.

Scott: Or not adding them to the right tier.

Ezra: Exactly. That’s not super helpful, so what we’re trying to do is build something that takes load into account as one of the factors.

Like you said, maybe they’ve got a queue they’re listening to. If the disk goes above X, maybe they want to spin up two more nodes. Or maybe their application is processing X requests a second, and if they hit a certain threshold, they want to scale up or down in a specific way.

We’re trying to build in some general heuristics that are least common denominator, but still allow it to be a little more intelligent about what it does.

Scott: Amazon’s an infrastructure as a service, and VMware’s approach doesn’t look like they’re going to stand up five massive data centers in five places on the planet. It looks like they have more of a strategy of going after existing hosters and getting them to be vCloud partners. By being a vCloud partner, they’re going to have an API exposed to them that lets them programmatically control their instances, kind of like what they can do with AWS. They’re going to have a self-service provisioning portal, an admin console, and things like that.

Do you see the Rails stuff that you guys are working on down the line supporting this heterogeneous ecosystem of infrastructure as a service providers?

Ezra: That’s definitely something we’re targeting. We’ve been talking with VMware a lot lately about the vCloud stuff, and we had an early demo of our platform as a service working against vCloud that we demoed during the keynote at VMworld in Paris six months ago.

We’ve got the AWS thing down, and it’s working great. We’ve got lots of customers on there and customer rate is growing great. And right now we went GA with our platform at the end of September, so this first version is fairly feature complete.

Porting our system to work against vCloud would give us a bunch of bang for our buck, because that’s not going to tie us to just one infrastructure as a service provider. If we code to the vCloud API, there’s going to be 10 or 20 of these vCloud approved service providers that we can point our application at, and go to town. Then we know how to instantiate a cluster that would run your applications on AWS or on Terremark’s vCloud, or on Hosting.com’s vCloud, or any of these other places.

Scott: And that’s not the piece you are focused on, right? You’re focused on your framework, but like I said, you could envision a future where there’s a Rails cloud framework and a pile of hosts that people can choose from, and maybe some other Java cloud framework or PHP cloud framework or .NET cloud framework, or whatever, and they could mix and match.

In that scenario, if a given department prefers a certain language, there’s a cloud-based, auto scaling dynamic framework that supports that. That also provides a choice of development models and a choice of places to host it that can also be mixed and matched.

Today, I could run ASP.NET on Rackspace and run PHP on Hosting.com, but those are not really cloud frameworks, and those providers aren’t really in the path. The hosting providers haven’t really provided an elastic resource, and it’s been fairly static kinds of units that people have to buy in.

It seems like there’s a gravitational attraction toward the programming frameworks becoming better at cloud development and the traditional infrastructure providers becoming better at being cloud infrastructure providers.

Ezra: It makes a lot of sense. For example, with Google App Engine, you really have to code to their platform to run your app on there. Everything you write in your app has to take into account what they’ve done there, and how to use a different data store and everything.

But with our platform it’s just your typical Web 2.0 stack with your applications here, your memcache here, and your database here. It looks familiar to people, and they can run their existing applications on it but still take advantage of the scalability in the cloud.

If they get their application running against our platform on AWS, as soon as we add other back ends, they’re going to be able to click a button to deploy it out onto a different cloud without any changes in their code or anything.

We’ll take care of the differences in architecture underneath and still expose the same interface to the application developers. They can just worry about writing their code and let us take care of figuring out the best architecture for each different cloud.

Scott: One other facet is that if people want to run this framework internally, they can benefit from using the same framework internally and externally.

Is the stuff you guys are working on mainly a Linux thing, or could you see people running Rails 3 on Solaris? Does it work on Windows? What degree of choice do people have there?

Ezra: Rails does work on Windows and Solaris, but Ruby in general is kind of sub-par on Windows compared to Linux, and nobody really deploys production Ruby stuff on Windows unless they absolutely have to integrate with some .NET or other Windows-specific stuff.

Scott: As you look at the other choices that people have in that Linux ecosystem, a lot of times it’s Java, PHP, and a smattering of other things. And then there’s Rails, which has gained a lot of popularity in a relatively short period of time.

Popular conception seems to portray Java on one end as the strongly typed, object oriented, structured enterprise programming language and PHP on the other side that lends itself to learning in a weekend. Coming from a Microsoft background, I think of it like VB for the Web. There’s a very low barrier to entry, but the people with computer science degrees point at it as not real programming.

As a development framework in general, and then thinking about cloud development scenarios of the future, what do you think makes Rails a good fit?

Ezra: I think that Rails is really good at building a prototype and getting something out and usable to your customers very quickly. It makes some of these decisions for you in starting a new project.

If you’re starting a project in Java, you’ve got to sit down and figure out what application server you’re going to be using, what choice of frameworks, and which ORM, and which XML config files. You’ve got to piece that all together, and then spend a few days configuring it, so there’s friction to starting something new and just trying it out.

Rails has a really nice out of the box experience, where it makes all these decisions for you that are fairly sane. You can tweak them later if you need to, but it allows you to just jump the gun and get something started very quickly. And then there’s a whole slew of plug ins for doing social networking things, friend of a friend, or sending emails, or all this stuff just out of the box you can plug in with very little code.

One of the big advantages of Rails I see is that it allows you to take an idea and have something to show people in a week or two with a couple guys developing on it. That might take three or four months to get the same prototype in a Java system. It’s just very rapid development.

You can rapidly prototype a website, get it in front of your customer, and then iterate based on real customer feedback, rather than having these really long iterations where you get a bunch of specifications from a customer, and then you come back to them three months later.

Then the customer doesn’t like it, so they give you a bunch more specifications. Then you come back three months later, and maybe you’re kind of ships sailing past each other in the night, not really getting the feedback that you need.

With Rails, you could be showing stuff to your customer every day, or every couple of days, and then iterating based on their real time feedback. You can just be so much more productive with it, and I think that’s where its big advantage is.

As your app grows up and becomes more complex, Rails can support that too. And it has tunables and other options so you can get in there to make it really scale. There are good stories for the stack and the way to scale it now.

One of the other big advantages is that Rails enforces a directory structure, the way the app’s laid out, and the testing frameworks and so forth. That means you can hire a Rails developer, and they’re going to be able to find his way around pretty easily. There’s not going to be a month or two of learning how you customize J2EE or whatever. So there’s this shared knowledge between all Rails apps that allows you to get programmers up to speed much quicker.

Scott: When you compare it to PHP on the other end, is the difference the model of your controller paradigm, or what? Because people think of PHP as being a very rapid way to stand something up and prototype it.

Ezra: You can also rapidly prototype stuff in PHP, but when you do and then it gets successful, you’re probably going to have to rewrite it entirely because it’s probably a spaghetti mess. With Rails, you could rapidly prototype something, and then if that prototype is successful, you’re built on a very solid foundation where you can keep scaling that project and keep it maintainable as you add developers and stuff.

Scott: With things like Google and Google App Engine and Bigtable, it seems that the popular approach to scale a website is by using a traditional kind of relational database back end. It could be MySQL, PostgreSQL, Oracle, SQL Server, take your pick.

But if you really want to scale infinitely from the beginning, you’ve got to build on top of one of these distributed, shared databases, whether that’s SimpleDB or Bigtable or whatever. Talk to me about the options that you have at the data layer.

Ezra: There’s this whole no SQL movement going on, where people are exploring other databases, because they’ve outgrown MySQL or PostgreSQL. The reality is that I think there’s a little bit too much hype around that stuff right now.

Most people will never outgrow MySQL or PostgreSQL, even though we have a lot of people who come to us saying that they’re going to be the next Google or Twitter, so they have to be able to scale huge.

They might lose a lot of time by trying different options, whereas they’d be better off just starting with a SQL database and getting something out there fast. Then, as they hit the ceiling, they can move portions of that out into some kind of key value store or something else.

We have support for a couple different key value stores on our cloud. You can use Redis, or Toyko Cabinet and Tokyo Tyrant. We have out of the box support for those two. We also like MongoDB a lot. And also MySQL with as many replicas as you want.

The progression usually starts with the thing on MySQL server and a couple app servers, and as I scale those up, I might add a slave or two to the MySQL server and do read-only queries against the slaves and scale down my reads.

As I start to swamp that master database with my write capacity, I might move certain features out into a memcache or a Tokyo Tyrant tier where I don’t need as sophisticated data access patterns and ad hoc queries; I just need raw speed and scalability of storing a ton of data.

If you have some app that really just screams out, “I don’t need a database, I just need a key value store,” you might start with one of those from the beginning. Still, you’re going to want to keep your customer and your transactions–anything to do with money–in a SQL database with the proper constraints and stuff.

But there is quite a bit of stuff, especially in web pages. You can store rendered HTML template fragments in a memcache or a Tokyo Tyrant, because they might be pretty expensive to pull all the data and build a template, and then you might cache the result of that.

The idea is basically to scale MySQL up as far as you can go and then start taking features and pushing them off into a key value store to take a load off of the database, and to have a system where you’ve got a relational database augmented by key value stores, and you’re using them each for what they’re really good at.

Scott: That ties into another thought I had. As some sites have gotten really popular, they have crashed under their load, so they pushed all their images and static data into S3. The page would just have a bunch of image tags, and it would pull the images from Amazon S3. They would off-load a ton of bandwidth from their servers, and the user wouldn’t really see any difference.

There were a bunch of case studies around that, which told the story of how Amazon S3 saved some sites when they got popular, because they were able to off-load most their bandwidth, without really off-loading any of their processing.

Like you said, Google really forces you to color within their lines, with a limited choice of programming languages, no relational data store, and not really great support for a background process. It’s still sort of under the constraints of a request and a response.

People have taken the part that won’t fit in those lines and stuck that over on Amazon, and they just call out to it from the Google App Engine code, or those kinds of things. People I’ve talked to who have programmed on Google App Engine have said that data store is the paradigm shift.

That’s the hardest thing to wrap your head around if you’re used to programming against a relational database, which everybody is. Paradigm shifts are hard. It took 20 years to go from procedural programming to object oriented programming.

Ezra: I think those things are definitely in the future for a lot of apps and a lot of programmers, but like you said, they are paradigm shifts, and a lot of people just aren’t ready to make that shift yet. Cloud computing is pretty young still, and everybody is still trying to figure out how it’s going to work, what they’re going to use it for.

There’s another good five years here where people need to move their legacy applications to the cloud, or they want a cloud environment that looks similar to their on-premises stuff, but they might not be ready to make the jump to the full-on Google App Engine style.

I think something like what we’ve built will be more compelling for the next several years. It takes advantage of the elasticity of cloud, and the programming capability of the APIs and stuff, but it still kind of looks like your traditional infrastructure.

Scott: It might be compelling for a lot more than the next five years. At the end of the day, free is really nice, and it is going to attract a lot of customers. But, the corollary is that those providers are not necessarily going to make a lot of money off of those customers, because they were attracted by something that’s free.

You can kind of democratize and commoditize a certain kind of lower end of the hosting space, but I look at you guys, and I think, OK, there’s a framework that I could run. I could run it internally. I could in the future run it on a variety of external partners, whether it’s Google, or vCloud or whoever. It’s one of the frameworks I could choose.

Tell me if this is part of your pitch, but I could see companies that are looking at this saying, “Well yes, but you’re a small company, you’re a start up, we don’t really want to bet on you.” Is this a place where open source helps, since you’re able to tell them that they’re not really betting on you but rather on the longevity of an open source project?

Ezra: I think that one of the strengths of our software is that it is built entirely of open source components. We have a lot of proprietary stuff that ties it all together, but at the end of the day, the stuff running your app is Linux, nginx, Rails, MySQL, memcache, and a bunch of other stuff that’s all open source.

If we went out of business or you didn’t want to host with those anymore, you’re not locked in. You can pick up your app and go elsewhere, and be able to put something together that looks close enough where you’re not going to have to rewrite your code. That helps, because you don’t get locked in when you use our platform like you would with App Engine or something.

Scott: We’re getting near the end of our allotted time, so is there something interesting I didn’t ask about?

Ezra: I think we’ve covered the main points. The whole thing is a paradigm shift, since there are still a lot of people that I call “the server huggers,” who really like racking and stacking servers. They like seeing all those blinking lights, and they like having direct control over the servers and being able to choose the hardware down to every last card. Those guys are having a bit of a harder time with this transition.

I think the whole transition to cloud computing is really going to come to a head and force a merger between typical operations guys and developers. Since the infrastructure is programmable via API, developers are enabled with the power to control the infrastructure without having to call the systems guy every time they need a new server.

I think that your traditional operations guys are going to have to learn to become developers, and I think your traditional developers are going to have to learn more about operations, so that they can play within this new environment that can be totally programmable. I think that’s going to be one of the big paradigm shifts here.

Scott: It’s also interesting that you mentioned that in order to start out, you had to scrape together $100,000 and put together a small data center. Today, the distance between an idea and a product in the market is getting smaller.

That’s due in large part to the work that companies like you, Amazon, and Google are doing. The start up money that somebody needs to take an idea and run with it is far less, and if that notion doesn’t work, fail fast and try something else.

It seems that these technologies are just letting people try things out and spend a lot less time doing the market opportunity analysis and writing the business plan, and instead just trying stuff.

Ezra: The whole switch from Capex to Opex is a real game changer, and you’re right that it is largely cloud-enabled. If a couple of guys at a university have an idea that needs a couple hundred servers to run, in the old days, they would have to have a lot of money to buy a hundred servers and rack them up and get them available.

With the cloud, you can boot a hundred servers and play with them for a few days and shut it off by just spending 100 bucks or something. Being able to that easily try out an idea and see if it’s feasible or not is a game changer.

That flexibility is really compounded by things like Rails, which are enabling really rapid development of these sites. It gives a lot more power to individuals, and smaller teams these days can build pretty complicated products very fast and then scale them very easily.

That’s huge, I think. That’s one of the biggest things that this whole cloud trend is changing. All these open source technologies, along with the infrastructure on demand really does allow people to just try big ideas and then fail fast. Like you said, if it’s not going to work, they’re not going to be out a lot of money.

Scott: It also enables departments within a 150,000 person company to be really entrepreneurial and really experiment with things. The boss could practically try out an idea with his credit card, and the budget could go on an expense report.

Departments can go outside of traditional IT because they’ve got a budget and for things that are below a certain threshold, they don’t need approval. They can have a hosted CRM system or mail accounts or all kinds of things, including their own servers in the cloud that their IT department doesn’t even know about. They’re completely off the radar.

On one hand, IT cringes at that, but on the other hand, companies want risk taking, especially if there isn’t even really that much risk with this kind of entrepreneurial spirit, because it’s just hard to predict what’s going to work.

Ezra: There’s a big push for agile development. Test-driven development, Scrum, Agile, and all this kind of stuff has really changed the way people write software. They do rapid iterations and they test and they get stuff done very fast.

I see this whole space we’re in as enabling agility and deployment as well, because it used to be that maybe your development team is rapidly iterating and coming up with new features and all this stuff, but then there’s this big brick wall to get it deployed. They had to hand it to the ops guys and order servers and wait.

It was a big ordeal to get stuff deployed, but this new approach totally wipes that out and allows you not only to rapidly develop your product but also continuously deploy it and rapidly have it online and visible. It tears down that last wall of having your product go from idea to actually being out alive in the world and doing something useful.

Scott: I was just reading “Information Week” and there was a CIO saying, “One of the reasons I’m going with a hosted solution is my people never have to perform an upgrade. They never have to upgrade the CRM system. They never have to upgrade the mail system. Those used to be big projects that took lots of planning and lots of experimentation, and I will never have to devote staff to doing an upgrade. And at the same time, we feel safer making customizations because there’s a little bit more of a feeling that that fast provider isn’t going to break everybody’s customizations, because they’ve built the sandbox that we can customize within.”

And so they’ve got better visibility into what people are doing and not doing because it isn’t the case anymore that just anybody could be doing anything. They built the sandbox up fairly incrementally in terms of customers wanting to be able to do X, so we let them do X. Well, now they know they can do that, so if they’re upgrading their infrastructure, they’re able to take that into account.

I guess we are out of time. Thanks for talking with me today.

Ezra: Thank you.