BACKGROUND IMAGE: iSTOCK/GETTY IMAGES
Download for later:
- Internet Explorer: Right Click > Save Target As
- Firefox: Right Click > Save Link As
I'm looking at some of the information you sent me. We're talking about the PaaS landscape and how things are looking ahead in the future. I noticed you like to bring up the Gartner's forecast that the market will reach $1.8 billion by 2015. What's going to change, from a technology perspective, from here to then that will aid that sort of growth?
Sinclair: It's a couple of components. One is that we're starting to see more major platform vendors getting involved in PaaS, which is a good thing for everybody, right? A lot of people say that big vendors are going to be competitive to these start-ups that have built these brilliant businesses. It's true, but I think it also up-levels the message for everybody, so that the more customers understand what's going on with PaaS, what it is. That's something that's typically only funded by big dollars coming from big vendors. I think the overall up-leveling of PaaS in the market happens. When that happens, I think what you'll see is customers being more aggressive about purchasing habits and being more scrutinizing about the technology they're going to evaluate.
All of that, I think is a rising tide, and in that scenario you'll see spending go up, and you'll probably see that aggregates are going to go up, so you'll see numbers that are much more interesting in 2015. The other thing that catches my attention about that number is that it's likely bound to the idea that technologies have become mature. If you look at platform as a service, it started a couple of years back, in more serious ends on the public side, but public PaaS doesn't generate as many sales dollars as private PaaS would, private PaaS that's sold on-premises. The contracts tend to be a little bigger. You're starting to see vendors that have that focus. For example, we are exclusively focused on the Global 2000 private PaaS market. And it's about helping those organizations build private cloud with platform as a service, and they're willing to spend money to do that. They're building these, you need big data centers and they want to achieve cog-like agility of house, so we were their equipment. Then you merge those two things together and you start to see some serious headway toward significant revenue numbers across the board.
Adam: When you mentioned vendors taking a more mature look at the PaaS market, who do you see coming in now, with maybe more mature focus than they had, let's say a year ago?
Sinclair: Well, it's not necessarily coming right in, some have already been there. Look at Microsoft with Azure, for example. Azure's a great technology. It's been around for a while, and taken its lumps, but it's only gotten better over time. I think that sort of story gets everybody warmed up to the idea that PaaS is primetime. You see VMware with Cloud Foundry coming to the market, and they're trying to make headway. So we're seeing some of the larger vendors either up-leveling the maturity of their existing PaaS offerings or introducing first-time PaaS offerings. Mix that with the multitude of startups that have popped up, ranging from public PaaS offerings to folks like us. On the private PaaS side, you end up with a real kind of critical mass on the vendor's side of things.
Adam: Now, when we talk about PaaS, a lot of what we're talking about is cost savings and agility. Can you describe for listeners how PaaS accomplishes those two goals?
Sinclair: Sure. Actually, before I do that, one thing I would also suggest is that there are two components. One is the cost savings and agility, but that's in the context of existing software development practices and existing deployment models. There's also a significant new value creation around equipping developers to build modern cloud apps. That's something that people tend not to talk about in PaaS, and we're very passionate about it. So I'll definitely dive into that.
On the cost savings and efficiency side, and agility side of things, you have to look at what's been the historical precedent for application management, deployment, scaling, e-enterprise, IT, up until today. The typical story goes: An enterprise software developer builds an application, and it might take a few months to do that. Then they need to deploy the application, and when it's time to deploy the app, they would call IT up. IT would spend 30, 40, 50, or 60 days setting up a server, provisioning the OS, configuring it, setting up load balancers, a lot of manual activities that happen from code complete to primetime. That slowdown around what should be a pretty "simple task" of getting the app up and running is amazing, because you spend two or three months writing the app, and then you spend two or three months deploying it. That's a huge, huge loss of productivity and agility for both the developers and the IT pros that manage infrastructure.
Second, the typical model of deploying applications involves having dedicated server infrastructure or dedicated OS instances, on a per-app basis, which is a very, very coarse-grained allocation. For example, you'll be paying a window server license every time you need to host an app on its own OS. Those two things end up resulting in what would be really significant productivity losses, and huge cost efficiency problems. PaaS comes in and says, "Well, what if all of that could be hidden and extracted away?" What if a developed, inside the constraints defined by the IT pros, running a PaaS cloud, could, at a button-click, publish an application almost like a blog post. It's up and running, and the load bouncers are all configured for you, and the OS's are prepped and ready to go. Furthermore, the ongoing management tasks of say, scaling the app out or in, are managed by the PaaS as well. All those dealing problems we talked about go away entirely. That's something that is not longer part of the problem, and we essentially reframed the problem, and brought it a new solution, which PaaS is. On the cost efficiency side, most platform offerings are now focusing on really dense multi-tendencies, so the idea being that you can pack lots and lots of apps into single OS instances, which means you're getting better utilization out of your infrastructure and your OS licenses. That's huge. The amount of cost savings there is tremendous for any organization. Those are the ways those two savings happen.
Adam: One thing I was curious about is that PaaS seems to take a lot of what people might describe as the drudgery out of the work. It seems to do a lot of the things that maybe aren't interesting to people and are maybe just monotonous labor. It allows them to spend their time differently. How do you see PaaS reshaping the way an enterprise spends its IT resources?
Sinclair: I think it ends up reshaping it such that everybody's focusing more on value creation and less on these mundane tasks that you're talking about. They're boring because you don't really create value out of them. Deploying an app isn't the phase that creates value in building an application. It's a necessary step to get it in front of people. Value creation happens when people are writing code, and that's a fundamental truth across the board. I think it reshapes it where every cycle investment on the enterprise IT side gets refocused on those value-creating points of writing code. To talk about the point that I mentioned earlier, PaaS also becomes the engine for new types of value creation. One thing that most PaaS vendors don't talk about, because most of them don't touch is that, while the deployment and management aspects of PaaS are super valuable and super important. In fact, we do it better than anybody else, in my opinion. The question becomes "What's next? What is PaaS supposed to do for me?" If you look at enterprise IT applications, they're becoming much, much more complex. They're becoming distributed, they're becoming multi-tenant in their own right. They're becoming high-scale in some cases. Those are patterns or requirements that PaaS offerings today do not help with. They help you deploy the app. If we're going to focus on value creation, how do we help developers build these really new types of architectures without having to learn some black arts skill set, when it comes to multi-tenants or distributive apps? When we look at the past market and we kind of think about it over the next couple of years, past vendors need to step up their game and say, "Well, we're providing EPI's and out-of-the-box architecture patterns that allow a developer to write real world-class cloud applications without any of the effort. Our entire company thesis is built around that. That's why, when we look at past vendors, we ask what components they provide. Is it just deployment and management, and if so, what's the real value over time there? Do they provide you the EPI's and frameworks that let you write really powerful modern cloud apps.
Adam: Is there an educational component to all this? I'm curious that maybe there are people sitting around, stuck with this monotonous work for so long that maybe they don't know how to do anything else at this point. Is there an educational component from the past?
Sinclair: There's a very big educational component. You see it every day at Apprenda. We talk to people about this being a downright routine, both in the enterprise and people in the industry, the analysts or what have you. We find that there are three big buckets. There are those who have a very good fundamental understanding of PaaS. In the buying market of Global 2000, that group typically has active real PaaS projects going on, because they understand the pains and they understand the savings. There's a second group that has pursued private cloud, and understands private cloud very well, and it's not a stretch for them to imagine how PaaS brokers into that. There's a little less education required there because they have the fundamentals down. Then there's the "everybody else" bucket, which is the majority of the market right now, where, exactly what you said, they've been in this traditional way of thinking, and they haven't stopped to say "Well, is there an opportunity to reshape our processes and our thoughts. There's where the big education perk is for everybody. We also see that coming around. If you compare last year, this time, to this year, if I have a random conversation with somebody on the street about PaaS, you'd probably see the text read proverbial. They right away understand what it is that we do, if we give them a little bit of a description. That's very encouraging to me, I think the education burden will relax a little bit over the next couple of years.
Adam: Is there anything that's still a barrier? Is there any question that you find yourself stall-answering more often than not, when you work with people in that third bucket?
Sinclair: Yes. The public-private discussion comes into play very often, and that's a barrier for people. If you look at "traditional PaaS", it's been offered in a public-only form factor, which we think is not in tune with the way the market is right now. That's a huge barrier. You're talking to organizations who have thousands of custom apps, many of which for regulatory, security, or compliance reasons can't move to the public cloud. They're being told by these vendors, "You're wrong. You just need to move them." We took an approach where we said, "What if we could bring the PaaS to the enterprise instead of bringing the enterprise to the PaaS. What if we could privatize that lair, and let them operate a hyper-efficient data center as a platform offering, and expose that to their developers and IT pros. Would that get over that hurdle? I think that's one of the education pieces. You can get that cultural shift to happen if you're not ideological about the public-private discussion, and help enterprises understand that they can achieve value privately. Later if they choose to find certain apps that they can move, public workloads, they'll do that. They might do that in six months, a year, two years, that has to be at their own pace. You can't have that rigid barrier in front of it.
Adam: To me, the way the public-private argument is framed, most of the time is that it's an either-or decision. Is that a false dilemma?
Sinclair: It is, and that's big part of our strategy and hypothesis. It's something that is a false dilemma because, if you look at a properly built cloud architecture, a past offering of ours for example, you shoot for symmetry. Can you layer that on top of any arbitrary infrastructure in a plug and play way? Meaning, I can have a past layer at house, I can build applications against it and know that I can have a past layer running, say, on some other public cloud infrastructure, and have application portability. Symmetry is key there. If you can produce that, then you have a false dilemma in that debate. The problem is that in practice, what's happening is that since most PaaS providers have been public-only, there has been no symmetry. It does become an either-or for those people. That's why when we look at PaaS today, it's evolved quite a bit over the past of years. Because most PaaS vendors are saying "Look, our layers downloadable, our layer can be installed on everything from laptops to clusters of thousands of servers." Or you can deploy your app to equal symmetric instance running in the public cloud. Everybody's happy in that context.
Adam: Was there a logic to the initial push of PaaS vendors just pushing towards public as opposed to allowing people to do these things in-house?
Sinclair: I think it was probably because a lot of the early traction was around shadow IT and shadow ops. People were frustrated with their processes, and having purview over some small part of the infrastructure if they could say "Well we're just going to push this out. The reality of the matter is that that's kind of beach-head, and that's a very small segment of all the custom apps an enterprise writes. The logic was probably appropriate in terms of early traction, but I don't know that from a strategy perspective, if it make sense when 95% of the apps are still going to stay within the firewall of an enterprise IT. I think that's where we're going to see either PaaS vendors moving to a model where they're introducing private components if they don't already have it, or ones that were native public-private from the get-go, which most PaaS startups are today.
Adam: One thing I don't think we discuss enough when we talk about PaaS, and I certainly don't have a firm understanding of it, is how do licensing fees work, or how pricing models work. Could you go into that a little bit?
Sinclair: Sure, I can give a high-level description of how ours works. I don't know if there's ones that are like it across the industry. Basically, the way private PaaS licensing works, as we it, is that it tends to be around a team-managed resource. When you look at something like Apprenda, the enterprise might layer it across ten servers, 500 servers, 1,000 servers, whatever it might be. Those servers represent an aggregate memory footprint. Memory is the important quantifier when it comes to app management, how many apps you're going to support on that infrastructure. We license our technology, based on the total memory across a cluster, that somebody's running a private cloud. That gives the enterprise the ability to fine-tune what kind of infrastructure is going to support it. Are they going to have a few very massive servers underlying their product PaaS cloud, or are they going to have hundreds of commodity servers. We want that question to be answered only by the vendor and not by the licensing. I've seen people do it on a per-server model, or per-core model, which is also seems to be commonplace out there in the private PaaS market. Public PaaS tend to be paper-used, right? It's going to be based on certain parameters, an expect-to-compute storage, and memory resources that are consumed. If you publish an application to public cloud, you can expect that you are going to have some sort of buckets, almost t-shirt sized, small, medium, and large like you would see on Amazon [inaudible 00:14:30]. You choose what resources to assign to your app, and you're going to get billed monthly for that.
Adam: One thing that we care about in the past market is, I've seen different vendors go in different ways, as far as what languages they support. There are some that seem to want to be broad, and have generic support for almost all languages. And there are others that seem to want to specify on one language. Do you have any thoughts on that, in regard to the market in general, and maybe in regards to what you guys are doing?
Sinclair: Yeah, both actually. So the market in general, I think one thing we have to ask ourselves is what is it that PaaS is trying to accomplish. That will help influence whether we should be talking about multi-language or single-language. What I mentioned earlier is that one common thing that PaaS members much do, is they have to provide facilities for easy deployment and management of apps. That is something that is very easy to achieve in a cross language compatible way. Because typically it means being able to push applications out to servers. So what we do know is that every language and it's bi-products, the compiled assets or the actual application components are bits and bytes at the end of the day. If you want to install them, it's a matter of moving files from one server to another, doing configuration work, something that is an easy lift to do in a very common way, across 50 languages.
Now if we introduce a second component and say PaaS must help developers build very modern could app architecture, then things become very tricky. Programming models across languages are very different from one another. And if you're going to try and tackle that challenge, you have to pick a language or two that you're going to focus on, and provide APIs and frameworks and very deep integration's with those languages and run-times that help developers build world class cloud apps. That's where I think a lot of people get stuck in this discussion. If you look at the market, anything that is multi-language, they tend to provide value around that deployment and management side of things, but they provide very little value with respect to helping build modern cloud apps. So you're essentially like building yesterday’s web apps, but deploying them in a modern environment.
So our strategy has been that since we believe both of those components are super valuable on the deploying manage side of things, as well as the strategic component help people build next generation cloud applications. We take a vested read approach. We think it requires very deep integration, it is unlikely that you can replicate that information, across languages at once. So we focus on .net, because of that. We want the .net developers to have that ultimate value of helping move them into the next generation app architecture arena. And it really is an interesting problem. Everybody has placed bets here in different categories to see what happens, though we're pretty confident that you're not going to see the cross language stuff work over time, very much like you don't see cross language IDE's, if you're a .NET developer you're going to use Visual Studio and typically writing in G sharp. If you're a Java developer you're using Eclipse. There are reasons why we haven't seen text editing work at a multi-language fashion at scale.
Adam: Hmm, OK.
Sinclair: If I ask myself that, you have to ask yourself, well what makes us think that's going to happen at a run-time level, if you can't at the IDE level, perfect at this point.