Hi, everyone. My name's Andy Glover and my guests this. time are Mark Gaydos, who is the Senior Vice President of Marketing,

Transcription

1 GLOVER: Hi, everyone. My name's Andy Glover and my guests this time are Mark Gaydos, who is the Senior Vice President of Marketing, and Bill Platt, who is Vice President of Operations for EngineYard. If you're not familiar with EngineYard, EngineYard is a cloud provider, a Platform as a Service (PaaS) provider, who has been the wonderful world of the cloud for many, many years. They started out in the Ruby community and have since expanded to include PHP, Node and probably some others that I'm not even aware of. So Bill and Mark, thank you very much for joining us today. GAYDOS: Thanks, Andy. Thanks for having us. GLOVER: There are lots of acronyms when it comes to the cloud -- Platform as a Service, Infrastructure as a Service. I thought it would be helpful for you all to talk about what in your minds, what is a Platform as a Service? GAYDOS: Okay. Well, Andy, this is Mark. Let me take that question. So there are a lot of technologies out there that are out in the cloud. And your most basic is what is often referred to as Infrastructure as a Service, where a company is providing hardware, networking, sort of the underlying storage and all that sort of hardware and networking you expect in order to run an application. On top of that, you need additional services, web application servers, database services, a lot of additional components that are necessary for a professional application to be run. And so,

2 Infrastructure as a Service providers are also in the cloud. But they only take care of that bottom layer, the sort of what you'd think of as the data center, the networking, the hardware. For the Platform as a Service, you not only get that infrastructure, you also get all the components that run on top of the infrastructure that are necessary to support a commercial grade application, right? And there are a lot of different components, and they need to be secure, they need to be hardened, they need to be scalable. And so with a Platform as a Service, you're getting the whole platform instead of just the infrastructure. You're getting to run your applications in the cloud. But with a Platform as a Service like EngineYard we're providing the entire stack -- not just the lower level, but the entire stack. And that way as an organization, your responsibility is to develop the application, and then you can run it right on top of the EngineYard Platform as a Service. And this way, we're taking care of everything there. And again, as I said, for an organization that wants to use Platform as a Service, they can now just focus on the application, which is really where they provide value. They really provide value to whoever their constituents are, whether they're customers or partners or employees. Whoever is using that application, real differentiating value comes from using the application and that's where our company wants to focus its expertise and its differentiation. It isn't that the platform isn't important; of course it's important,

3 we want it to run. But that's where a team of professionals like EngineYard provide a Platform as a Service to harden that, to constantly be monitoring it and keeping it secure and taken care of, because that's our expertise, it's where we provide value. For an organization where they provide value is in that application and when they use the Platform as a Service, you get the benefits of being able to focus more on your application, you get more time to focus on your application, and you get all the expertise of the team that runs in the EngineYard space thousands of production applications across the world on a daily basis. GLOVER: Well, so you talk about Infrastructure as a Service and as you kind of move up the stack you get the Platform as a Service. And certainly EngineYard is not the only Platform as a Service provider out there. You talked about the differentiators. You alluded to security, scalability. If I'm looking at Platforms as a Service, what are the key things I should look at? What are the differentiators that will differentiate Company A from Company B from Company C -- i.e., EngineYard from the other PaaSs out there. What should I be looking for? GAYDOS: Really there are probably three main things you should look at, Andy, if you're going to evaluate a Platform as a Service. First you want, if you're developing a professional app, an application that's either business critical or a, your Web 2.0

4 company, and that application is your entire presence to your customers, you want that platform to be bulletproof. You want it to be commercial grade. You want literally hundreds, if not thousands, of other companies using it because you want that robust capability, you want somebody who's taking care of the entire platform, you want technology that is proven and really hardened and secure. The organization s taking care of all the components from top to bottom so that you can depend on it. It s commercial grade. The second thing I would say is you want access to that environment. Just because you're using the platform doesn't mean you want to lose control, and so you want to be able to get access to that environment. And some Platforms as a Service -- this is a big differentiator. A lot are more opaque, meaning, you stick your application and you don't really have access to the platform. You just put it behind the curtain, and you're counting on the vendor to take care of it. With a Platform as a Service like EngineYard, having access to the environment, being able to modify able to change it, maybe just having the transparency to go and see what's happening is a critical thing for any kind of commercial grade application and a big differentiator of a lot of the Platforms as a Services out there. And the third thing to look for in a platform provider is deep expertise in the language which is important to you. As you mentioned at the beginning of the podcast, we support Ruby, PHP, Node.js. But I

5 sometimes joke that there are Platform as a Service vendors who seem to support more languages than they have employees. For a company like EngineYard, this is very important for us. We believe we need to have deep expertise within our organization, in our engineering organization, in our support organization. Our support guys are engineers. They know how to create production applications and platforms. Having deep expertise behind you so that we re identifying problems before you even know about them, we know how to architect the apps. We know how to run the apps and run that platform. So, it's stable, secure, it scales and has all that elasticity you want. You get the highest up time possible. So the third thing, as I said, is just look for a firm that has deep expertise of understanding the technologies and the languages that you're interested in. GLOVER: You talk about languages, and obviously you guys got start in the Ruby community. And recently you've begun supporting Node.js. Java isn't in your stack, so I'm just curious. Obviously Node is taking off. Kind of what went behind your decision as a company to say, hey, look, let's go after Node first, let's say, before Java? PLATT: This is Bill. So a couple of points there. First, what we found in the past and what we were able to do when we started out

6 with the Ruby community and the Rails community was that when you join the community and to have your platform begin to deeply support those community members in their work and the earlier you do that, the more your platform can really help those people who are working in that language or that database -- databases are just as important as languages in this platform world. And so our successes for both ourselves and our customers that came in the Ruby on Rails area came by joining in and having our platform evolve with the community by being a part of the community but also by actually providing a place to run it with Node.js expertise behind the platform and with actually helping to solve the real problems that real developers have when they really innovate. So we decided that as we tend to watch what's happening in the communities and the projects and the programs, and Node.js is the second most watched GitHub repository out there, and the growth rate of jobs and projects in that area is one of the highest that there is. PHP is on a similar path. It's a little...it's been around a little longer. It is a little more mature. So we kind of grabbed that one a little past the early phase. But Node.js is in that exact same spot where Ruby on Rails was where we really focused on that with our platform. And we find if we can do that, we can create a tremendous powerful ecosystem of success around that community. It really allows the innovation to happen in a fundamental way, where

7 developers are working on apps and they're solving their real world problems of how to do a better job of putting JavaScript into the back end and make a really efficient performance application for their users. And when they do, if the platform vendors working with them and figuring out how to optimize the performance and create better and better stack images for them to use, the joint work together turns into an exponential improvement in the end user's experience. And so that's why we joined into the Node.js world right now as tightly as we have, because it's at that kind of peak of activity where the most will be learned and the most innovation will occur. And it's certainly not because Java doesn't matter. We have lots of people now talking to us, lots of developer communities. And particularly some large application development houses who are saying we would love for you to add Java. It's not that we won't be doing Java, because that's certainly something that we see as an important community. But to Mark's point we'd really like to make sure we're completely invested in everything necessary to make success with ourselves and our customers. And we think that's a really important part of being a truly great platform vendor. Java has a spot in our time over the next year or so.. But right now we wanted to focus on a really hot growing community and join them in trying to make sure our platform can support them and help the growth

8 of that community. GLOVER: One of your points earlier about the third reason, the third thing to look at when you're looking at a PaaS is language support and I wanted to delve a little bit deeper there. With your support of Node and Ruby in EngineYard, if I'm building a Node application, am I usually specialized EngineYard code to run my Node app can I throw it up on EngineYard, and could I just as easily throw it up on cloud provider Foo? Is that something to be aware of as people start to look at cloud? Other cloud vendors will lock you in via certain proprietary or libraries. Is that the case with EngineYard? Is that where the evolution there going? PLATT: Great question. So we believe a really important thing is really important in the PaaS world, what platforms are going to help people be successful. So we have a very strong couple of elements in our architecture. One is that we isolate a platform from the actual end user customer running application environment, what we call their domain. So the domain model is isolated from our platform running itself. And there's a really important thing that happens there, which is that the application running on that platform has its own domain and people can do what they need to do in there. And very importantly, when we build the domain for the end user application for the

9 developer to work in, we build it with all open source community content. So it's all open source stack components that we put in there. And so for instance with the Node.js stuff, we're just going to run our continuous integration process and then our continuous delivery process. Continuous delivery means the actual end bits not just integration on the code side but the end bits that get delivered to that domain. We're going to run that such that we're just going to stay in lockstep with the Node.js community. If we think there's something that should be changed in the way Node.js works, we're not interested in having a version of that that's specific to our platform -- we want Node.js to be better -- we focus on making sure that our platform runs that very well, that we support the things that are necessary, but we want to fill the domains that our customers use with open source shared content. We believe making a proprietary version of something inside your platform and then try to create that kind of a lock inhibits innovation. We re much more interested in creating that open community involvement. On our side, we'll focus making sure our platform runs well for you and we'll fill your domain with all open source content, all open source container material so that you can trust that you can develop in Node.js, it will work on our platform and we want the platform community to grow as well. We think that if the markets all grow, we

10 all win. GAYDOS: And Andy before when we were talking about differentiators, you sort of alluded to this. If you give a company developer open access, as Bill was talking about, there's no proprietary technology there is no lock in, and there's no code in there which can either pose performance issues or reliability issues. The minute a vendor, a Platform as a Service vendor, puts in technology that there you've now created a new failure point. And potentially if you put something in between the user and the request from the user and the actual platform, you could cause performance issues. When you click deploy with the EngineYard Platform as a Service, the whole stack is open towards and there's no proprietary technology that's going to cause performance issues or can potentially fail. It is nice and clean beyond just the lock in, so technically there are advantages to that also. GLOVER: Right. You guys have talked about kind of the community that EngineYard is lock onto and you support, and in the Ruby community EngineYard is no stranger. In a previous podcast for IBM developerworks we talked about JRuby, and that's something that obviously EngineYard has participated in. And probably funded it as well in terms of the people who work for you are actively working in these communities.

11 You all have made it look easy to build a community and support around an open source community. I thought it would be interesting to ask, what are the challenges as you're going into the Node community as you might be doing it all over again. Are there lessons learned? Are there tips? If you're looking to support a community, what should you do, and perhaps, what shouldn't you do? PLATT: I'll start the response. We did learn a lot of lessons. And a number of our folks have been in communities, founded communities in both PHP and in Ruby and the Node space. One of the lessons I think we learned was that there is more than one-way to go about it. One way is to contribute to the community and try to support the existing community. Sometimes you have to fund. The second way might be fund your own project to make something happen that wasn't happening in the community of its own. A third is to literally be out there in the community supporting the meet-ups and those various activities that help a community thrive. I think in the Node.js world, one of the lessons we learned is we're trying to make sure we do things a little bit differently this time We re much more interested in participating in the community, supporting the community and ensuring the community in and of itself is accessible. We re not necessarily thinking that we need to fund the project to do something specific for Node; rather, we'll have our folks contributing to the Node community and focus on giving the community

12 a place to run things and make sure that they have a great source for expertise to check things, to get and gain help. In the Node world we're not focused on making our own project and make some things happen over here. We did a bunch of that stuff with the Ruby world probably because it was earlier days and more was needed. But for the Node stuff, we're strongly supporting the existing community and if anything, we want to accelerate the existing community by contributing to it. And we've done both of those ways in the past where we were just strong contributors to communities; in other places, we've founded communities; in other places, we run projects. So right now we're focused on the supporting, contributing part of that community. GAYDOS: And I'll add one thing, Andy, which is, your heart better be pure. Let's put it this way. When you go to the community, you really have to be there to try to assist the community and be sponsoring, really empowering people to innovate, and empowering their applications and their passion. And that we see at EngineYard as one of our main responsibilities to the community as Bill was describing, You can't be there to get an immediate financial gain. You can't be there to leverage the community. You've got to be there supporting it, and it's through that sort of osmosis that you develop a brand that's associated with the community. I jokingly say your heart must be pure when you engage with the community because they're very aware

13 of whose there to empower them and help them. And they're all obviously aware when companies aren't necessarily there with that sort of good perspective. GLOVER: Yes. That makes total sense. I agree with you., EngineYard, how long have you guys been in the cloud? How old is EngineYard? GAYDOS: This is Mark. We first started the company in 2006 and we've been in the cloud since then. We used to run on our own hardware and then we decided that the best thing for our customers from cost effectiveness and a standards type basis was to move our cloud into other infrastructure services. So we run on top of Amazon, we run on top of Terremark, we support CloudStack and OpenStack. Our goal is to give developers choice. And so our Platform as a Service runs on a variety of different infrastructures. But again we've been in the cloud really since GLOVER: So you've been here for a while. We re coming up on What do you see coming down the pike as far as the cloud in terms of innovation? What's next? What should people be aware of, keep their eyes on? PLATT: This is Bill. We see some trends to be kind of crucial to the continuation of the growth in the cloud. The first is that there is a growing number of, and a bit of variety in, the number of infrastructure providers and beginnings of a standardization of what

14 we call the cloud OS, which is the layer of interfaces that are presenting itself on top of the infrastructure. That trend is being fueled by very large companies, right? Lots of money being spent. It's going to continue, it's growing relatively fast right now and it s super important. And you have these open and API centric platform capabilities we've been talking about as the right way for platforms to evolve, based on REST APIs are API centric and because of that, there is some standardization occurring. But it won't all happen overnight. There's going to be the need for people to focus on the API very strongly for the next year or two and to recognize that working together hand and hand with communities and creating APIs that actually work together will be the key to taking advantage of this large investment infrastructure that's occurring. The other thing is a lot greater awareness now of the fact that infrastructure is available, there are some ways to get at it. The motion in this direction the probably the largest computing change that's occurred since the PC came into existence. It is a gigantic wave. And it s happening is that the end buyers, the people that want to take advantage of all the things that we described that are great about going to the cloud, those end buyers are accepting of the fact that they're probably not going to own their own infrastructure and what they actually want to do is go shopping.

15 We hear this every day when we're out talking to customers. They want to go shopping. They used to go shopping by looking at websites of people with hardware and now they want to go shopping across these infrastructures. So creating standard interfaces and allowing for platforms that can expand and as we said before, allow for standard applications to be written to a given community's AIPs that will work across different infrastructures, that's the big shift that everybody wants to have happen and that customers and buyers want to have happen. And that's where investment needs to be made in communities and across platform vendors to make sure that that happens -- because when that happens, the more that that happens, the cloud will be on an even steeper growth ramp. And that's the big benefit that we see happen in the next year or two. GLOVER: So it's interesting when you talk about the notion of shopping. If you go shopping, let's say for hardware,? If I look for storage or whatever, memory, whatever it is, racks, et cetera, I have so many choices. In the cloud is if you started looking, let's say, in 2006, there were a few players out there, right? So your decision making process was a default easy, right? As more and more cloud providers and players come online, that

16 shopping experience may become a little bit more difficult because you have so many choices. And back to the earlier discussion about differentiation. Is the cloud going to become commoditized? What do you feel about that? GAYDOS: That's a really good question. I think that when you go through these sort of large wave changes you tend to get a front-end leader who sort of shows the way. And then a bunch of folks join in because it's very clear because there's a lot of demand for these services for these services. And that demand is showing itself right now and because of that, there's a lot of people entering Because of that it will be a little bit confusing for a little while. And that's where we find the big benefit of actually looking up from the Infrastructure as a Platform., It s platform's job is to sort that out a little bit and make it easier for people to understand what they could do. So sort of like an operating system would allow an application to be written to run across multiple types of hardware. So you used to go shopping for hardware. In the nineties, Dell made it so that everybody could go shopping for hardware by just going on a website, look at all the prices, compare the prices of what you could buy from Dell, from HP, from everybody else and buy. Now data centers themselves being commoditized and then placed into the cloud. And we call it Infrastructure as a Service all of a sudden. But you're really still looking at the same kind of

17 fundamental units, right? CPU, RAM, feeds, size of the capacity that you want And there's a lot of people coming online because there's a large demand, and at the same time, we're beginning to see the sort sense of that commoditization of a thing against which you can shop. And it is being seen. The different platform vendors are starting to make that easier for people to see and that's the good news in the market. We're going to make it easier for people to understand that if you need this capacity to run your application and you think that your application will benefit from using a NoSQL technology versus a SQL technology or you need a big data service, like Hadoop service, to run your stuff, Platform as a Service is making it easier to understand how do you buy it and what are the knobs you might turn over time to change how much you spend. That is going to enable the massive buying and massive consumption faster. I was lucky enough to work through the era in the dot-com era, worked at Sun Microsystems. We saw these things happening. What we're seeing is the data center as something that you can purchase like a utility. The platform is making it possible for the application innovator to focus on innovation. And the buying is going to get easier to understand over the next year or so as the standards around APIs and the standards around how one consumes that commodity are starting to emerge.

18 GLOVER: Very interesting. Well, I know I speak for all our listeners when I say, Mark and Bill, thank you very much for spending some time with us and helping educate us on the difference between Infrastructure as a Service, Platform as a Service. I really enjoyed hearing what you should look for in the PaaS, and I think your collective view on what's coming down the pipe in the next year or so is interesting. I hadn't necessarily thought of it that way, so I think there's a lot of excitement still yet to be seen. So thank you very much for joining us. GAYDOS: Thank you. Thank you, Andy. GLOVER: And again, my guests today were Mark Gaydos and Bill Platt from EngineYard. I look forward to talking to you all again sometime soon. [END OF SEGMENT]