 I'm John Furrier, the founder of SiliconANGLE, and I'd like to introduce Amar Kapadia from Evolt to kick it off, and we're going to start the debate right after this. Good evening. Welcome to Evolt. We are your hosts for tonight. And my name is Amar Kapadia. Before we get started on today's exciting topic, I know Randy has kicked off the storm with the open letter. I've never actually seen press at a meet-up before. So it should be exciting. Just some quick logistics. Restrooms are out that way, and they should be open if they aren't, you know, let one of us know. There's Wi-Fi instructions and food and drinks. Please enjoy. A quick brief, 30 seconds on Evolt. Evolt is a Seagate subsidiary, and we are in the cloud storage business. We have several software as a service and offerings. And if you think about an enterprise, and you see any on-premise storage software or infrastructure, that's on our target. Those are the things we are looking at in terms of adding a dash as a service. We are also active in OpenStack. We have contributed to Swift 3. Randy, please take note. It's a S3 API on top of Swift, and we are also involved with other projects in OpenStack. So without further ado, I'm going to hand it back to John, and John can introduce the panel. Okay, thank you, Mark. Appreciate it. SiliconANGLE's dedicated coverage to going out to the action is really what it's all about tonight. When we cover the OpenStack summit in Portland, one of the things we mentioned on the Cube is the new standards process about the community and documenting it all, and Randy Baez kicked off the great conversation at USCON and we want to continue that coverage. We want to pass it off to Randy Baez of Cloud Scaling, Mattis, and Joe Arnold, our host here. Guys, take it away for the great API debate. It's an open discussion, right? I think Randy kicked off this discussion in a way that only Randy Baez could do in the community, I think. So I think we owe him a debt of gratitude for being able to create so much momentum and dialogue around this issue. And the issue is how important is it to be compatible with another set of industry APIs that are in broad adoption? And so the format of tonight's discussion will be to talk about this issue, ask a lot of the important questions, and the format will be, we're going to kick this off, introduce each other or do introductions of ourselves, and then I have a couple of questions that we'll kick off with, but then I'd really like to ask the audience to participate and ask the questions that you have burning desire to ask from between Boris and Randy on the topic. And we'll go for about an hour here, and we'll see where the sparks start to fly. So briefly, so my name is Joe Arnold, and I'm the CEO of Swift Stack, and what we do is we focus on the object side of OpenStack, a project in OpenStack called Swift, and we built product and services around that. Before I was doing that, actually I had the privilege to work with Randy to get inducted into OpenStack, but before that I was building out platform services on top of Amazon, one of their early customers. So that's kind of the background I'll hopefully lend to the questions as they come up. Boris, can you care to introduce yourself? Yes, my name is Boris, I am co-founder and chief marketing officer at Mirantis. I would imagine that a lot of you folks have heard of Mirantis, if you've heard of OpenStack, hopefully you have, that means I'm doing my job. We are probably today the largest systems integrator around OpenStack, and we're also a technology company. And I guess to kick it off, opening remarks I wanted to also thank Randy, he's kind of been historically the biggest visionary behind Cloud and one of the first people to kind of hop on to the OpenStack bandwagon. Some of you may not know this, but this guy was actually the guy that to a large extent influenced our existing company direction. So a lot of the things that we're doing in OpenStack today is because of him, and probably now he's like, damn, why did I do that? So, you know, just, you know, two years ago nobody knew about Mirantis and OpenStack. The other father of the OpenStack is Randy. I couldn't have envisioned, you know, sitting myself next to this guru. But yeah, thank you. So now please introduce yourself. Okay. Slightly embarrassed. I'm probably fleshing red, but that's all good. I'm Randy Baez. I'm the CEO of Cloud Scaling. I'm a longtime infrastructure guy, which I think is a little bit different in a lot of this particular ecosystem. I grew up on infrastructure. I've been doing it for 22 plus years. Got a lot of experience on systems, network storage, like the whole stack, building data centers, really all those aspects. So building infrastructure clouds has hit my sweet spot. Really where that started to become something I focused on was when I was VP of Technology Strategy at GoGrid, kind of in a CTO style role. They're kind of leading the direction of the architecture and the platform. And then that really morphed into cloud scaling, which in our early days was a professional services business like Morantis, where we were focused on helping people with strategy and architecture and then eventually large scale cloud deployments, two of which are very relatively famous. One was Korea Telecom, which was one of the top three cloud stack deployments and also one of the first Swift deployments, certainly the first Swift public cloud deployment in Korea. And then the second of which was a company called Internet where we built the first compute cloud and Swift cloud. Actually, all three of us were involved with that. So we're a very early proponent of open stack. We are part of the launch. Cloud scaling was part of the launch in summer of 2010. And we're really the only one of our competitors out there today who was part of that initial launch and has been deeply committed to open stack since the very beginning. So sometimes I find it a little funny and then people will easily misinterpret my intentions and sort of seem to feel that I am not, that I don't love open stack and nothing can be further from the truth. My entire business is built around open stack. We've pivoted over to become a product company that offers a product based on open stack. I am deeply in love with open stack and I want it to succeed and that's why I have an opinion and that's why I share it. So let me start by asking, I think one of the first questions when it comes to API standardization and adopting somebody else's standards. And Amar Kapadia, the guy who just introduced the meetup from Evil, wrote a blog post yesterday talking about some of the trade-offs where when you begin to standardize on a set of APIs, particularly one that you may not necessarily control, that stifles innovation where you can't make changes to the services or the product offerings that you want to offer. Working on erasure coding in Swift, for example. And we may expose new API elements in order to add that functionality. Networking with Quantum, or I guess not Quantum anymore. Neutron. What do you have to say to that argument where choosing another API standard limits your ability to add functionality into products? I'll start with Randy first on this one. So there's absolutely a trade-off between standardizing and innovation. I think we all know that to claim there isn't is kind of nonsensical. But I think what gets missed a lot of the time is that those things kind of follow each other. You're sort of innovating out the front end and then some of the things behind you as you go along are really starting to standardize. HTTP follows TCP. So it's not the zero-sum game where I'm either all innovating or I'm all standardizing. It's a much more nuanced kind of situation. And I think when we look at something like the AWS APIs just to make this more concrete, it's a little ridiculous to say that they stifle innovation for a couple of reasons. One, they're only one of the APIs in OpenStack. Two, they've been extremely stable. So we're not talking about APIs that supposedly Amazon controls them, but they very, very rarely break backwards compatibility. And so we're just talking about them adding new feature functionality in the APIs that aren't exposed in ours so we would lag them. Big deal. Who cares, right? It's a fast-fall strategy anyway. Embrace and extend. No big deal. So, you know, I think it's a valid argument. I just think it sort of misses the mark, which is that in many ways we can do innovation and standardize simultaneously. Of course. Yeah, so, you know, my take on it is that it's definitely noble cause to support cross-platform API compatibility. And I don't think when we're talking about the API compatibility necessarily has to be Amazon, although Amazon is definitely the most dominant mover there. But it's... How do I say that? I'd like to level-set, I guess, on the argument a little bit first, because there is a big difference between taking somebody else's API and adopting it as your native API. Any system, in my opinion, always has to have its own native API. And having a native API does not necessarily preclude you from actually, you know, going ahead and making some sort of effort to be cross-compatible with other platforms. So, in the original kind of a manifesto that Randy has produced, I think, it wasn't exactly clear what we're talking about. I was talking about just throwing away the native API behind the stack. No, it was absolutely completely crystal clear. I've had to go back and read it multiple times now because people made those kinds of claims. And in my bullet list, I very clearly did not say that. Moreover, you even put in a follow-on letter, which I think is... Which was even more clear. I think it's an indication that it's only okay of me to misinterpret it because everybody misinterpreted it to the point where you had to put a follow-on letter afterwards. So, let's be specific about a couple of things here. So, there is a statement in the project technical board. Sorry, what's the name of the technical project committee? TCL. Technical Committee. Technical Committee, right? That said, we're going to support the one set of APIs, the OpenStack APIs, and everything else is going to be outside of that. So, question for you. Is the statement that the AWS APIs need to be an official thing as approved by the technical committee to be officially supported and maintained? And is that really what the crux of the debate is here? Well, there's two elements. I mean, I'm okay if they're outside of the core. Like, I don't actually have a problem with that. But the first thing I asked is for the community to stop sort of saying like it's us against Amazon, which I think is just a totally ludicrous type of attitude. I mean, it's like saying it's OpenStack versus VMware. I mean, we need to go co-opt these systems. OpenStack is going to win by beating VMware and Amazon at their game, which means co-opting them. I mean, that's my belief. And so, I think we should support the vCloud Director API in the same way we support the AWS API in the ecosystem, whether it's in core or not, I don't really care. But the second thing that I think is more important in a way is that there's sort of this attitude of that Nova has a native API. It's complete and utter bullshit. If you read my first email, you'll see very clearly that the native original API in OpenStack is the EC2 API. That is what it was built with. The Rackspace API was added later and it was checked in called Rackspace. And then it was renamed to Nova at a later date. And it's not an unopinionated API. It's a new different opinion from the AWS API. And that's a huge problem because it constrains OpenStack in as many ways. And people say, oh, Rackspace contributed. No, they contributed specification, not the code. It was actually done by Anso Labs. That's number one. And number two, you know, if you win and you've pulled some functionality out of that API right now, Rackspace is going to cry foul. Like, there's a password reset capability in there now that many people probably don't want or care about. You pull that out and it impacts Rackspace's public cloud. Now, if we really want a native API in Nova, we should say, what does it need to be? What purpose does that API solve? And we should build it from scratch. Boris, in the core or outside of the core? Definitely outside of the core. And I would like to kind of... I feel that the whole argument is a little bit flawed because it's based on the premise that the OpenStack community historically has been very anti-Amazon. And frankly, I don't see any of that. You're advocating, you know, the community embracing Amazon, but I don't really see any manifestation of a community kind of going the other direction. There are indications if you're sitting from far outside and kind of observing that, yes, OpenStack is kind of an anti-Amazon competitor, but I can completely... I understand it. And the reasons for it is first, it was started by Rackspace, effectively. And yes, this API was called Rackspace API originally, but since then, the situation has changed dramatically. Rackspace is no longer very heavily involved in any of the stuff. In fact, Rackspace is not even in the top five contributors. They're smaller contributors to OpenStack, in fact, today than even Mirantis, a much smaller company. Second, it's because OpenStack community never really was going around like everybody else and screaming, or we're out there to support Amazon API. And the path for that was really kind of laid by guys like Eucalyptus. And the Eucalyptus guys, they took this approach, they understood they cannot be OpenStack, so they have to kind of hinge themselves on Amazon and create this marketing push and say that we are not OpenStack, so we are Amazon. That all predates OpenStack, so that's not how it went down. Eucalyptus predates OpenStack, but Eucalyptus has moved to embrace Amazon and the whole PR push. That's how they started. That was their entire business model from the very outset. There was a big PR push. Wait a second, let me go back to it. They started as, you know, yet, okay, maybe, but Eucalyptus made their strongest push around API compatibility when they made this big PR spiel where they supposedly signed an agreement with Amazon where Amazon has licensed them the right to actually use their API. And there was a big shebang around it and the whole thing was just a PR stunt because they can't really license a public API. It's bullshit and you know it and you write about it yourself. So this whole momentum started and OpenStack was just quiet. And OpenStack did not give a shit because they're already themselves a powerful enough movement. They don't need this kind of PR stunt. So there was a whole response like prior to that where Citrix left OpenStack and went to the Apache Foundation and they made all these claims about AWS compatibility at that point in time. And I remember because I've had these conversations going with the Rackspace senior leadership like Jim Curry and Lou Mormon for a very long time and I remember that those two guys who had just been like, hell no, we got to get the EC2 API out of the system suddenly backtracked their entire attitude and Citrix bailed and there was this whole kerfuffle that happened and the whole community was very engaged on the discussion of yes we want AWS compatibility in the system at that time and that predates the whole eucalyptus thing. So you're talking about an anticlimatic kind of thing. But that thing is a long time ago and that's completely different. Where Rackspace is today, in terms of the OpenStack development velocity that's like a thousand years. And you can't take it. So this is debating timelines and I think you know that's going forward, right? So I guess I'm going to ask one more question and I'd invite whomever wants to ask the next question please start coming up. I think there's a microphone, a mark. Can you help get a microphone whomever wants to ask the first question? So I'm going to beg the proposition or beg the case, right? Is what's important about being Amazon compatible? Is it about the API or is it about that ecosystem that Amazon has created? Where if you get plugged into the Amazon cloud you're surrounded by all sorts of other services that you can consume. Some from Amazon, some not from Amazon by people who have set up shop in there and selling platform services. How much does OpenStack really, how much does OpenStack deployments really gain if they don't have that ecosystem? How important is just the compatibility from a business perspective, from rollout, from hybrid clouds. How important is that for what you're seeing in the field with customers to be able to transition back and forth between those two environments? Tactically speaking it's not important and that's what we have seen in the context of now over 50 OpenStack implementations. This is early days, strategically speaking the importance is going to grow. But I do not think that you can ever really reach the cross-platform compatibility with two independent ecosystems innovating and building their native APIs independently. Anybody who is in their same mind and is trying to run an application on top of OpenStack that is running on premise and maybe burst into AWS they will use some sort of proxy in the middle. There's plenty of libraries you can do. You can use something like Fog, you can use J Clouds and if your application is dependent on two systems you will always have a guy inside and a library inside, a guy responsible for that library and that's going to be the single kind of a check point that you control. You will never trust two communities to maintain compatibility and just run across. I mean APIs don't matter. I don't know why we're stuck on this and I kind of made the point that it's about the architecture to begin with and I don't understand why people don't get this. APIs always expose a subset of functionality. It's impossible for them to provide the entire richness of the architecture that they basically talk to you. They're an application programming interface. So they inherently are a contract to the system behind it. So right now if you go to any of these clouds as a for example and you spin up an instance there's no way to guarantee that instance comes up in any amount of time. You can't specify it with the API. You get no SLAs from the provider whether it's a private or public cloud. There's no time between a few seconds or a couple hours, right? So if you build your application even using an abstraction like J Clouds and Fog and it assumes because it's been running on AWS that instances always come up within 10 minutes and you go and you stick down on another cloud and the behavior is different. You're screwed because there actually has to be a way that you've got a reference architecture that you model against and then you're measuring how that behaves so that when you're actually doing the cloud compatibility you're doing it based off of the behavior of the system not the APIs, right? APIs can be semantically equivalent. If you look at Google Compute Engine and AWS they're the exact same API except the APIs themselves look totally different because the syntax is different the semantics are the same and they expose a very similar architecture behind them. I agree. I mean, yes. And in fact you wrote a blog about that and I said I agree. That has a question here for us. Okay, I thought I'd... Okay, I won't tap. I guess it's not for us, okay? It's for the... Sorry about that, folks. Okay, so let's just say for argument's sake that it was a good idea to mirror the AWS APIs. I can imagine how that might make sense possibly for compute, storage, some of the basic components that applications use. But it would be absolutely insane for the entire community to say, okay, you know, Cart Blanche, we're gonna go replicate all of the APIs Amazon ever does. They're a for-profit company trying to pursue their own interests. There's no freaking way they have the best interests of everybody else in mind. So where would you draw the line? So this is kind of a long lines of Amazon isn't asking us to use them as a standard for proliferating projects and services. It's not gonna stop. It's not only that, but let's just say that we all of a sudden said, okay, let's go replicate their APIs. Don't you think they'd find that amusing and perhaps use that in some way? Of course. Yeah, that's exactly what Randy was talking about, basically. That, you know, you can't have... If we're talking about native API, you can't have two systems that have the same low-level native API. You can have an awkward attempt at it and then it'll boil down to just you kind of mimicking the system awkwardly and exposing similar same API. But I think today we are still way too early along the innovation curve. Both, it pertains to Amazon and it pertains to OpenStack squared to actually really even concern ourselves so deeply about those issues. And the reason why I think the community today in OpenStack is not really proactively embraced Amazon API, even embraced the Amazon compatibility issue because the stuff that the OpenStack community is struggling with today is much more basic and concrete. It's about just feature function acceleration and just making the shit work. I mean, it's hard still, it's still new. So why are you starting to think about this cross-stuff compatibility when it's such a challenge to just deploy an OpenStack cloud and make it work? I mean, I think that it sort of gets to a pretty deep divide in our perspectives. You know, I would say that OpenStack is more akin to the Linux kernel and the idea that it'll ever be a complete cloud operating system is completely ludicrous and it's really a framework that will allow us to build cloud operating systems that do different things. Just like you can take the Linux kernel and wrap a distribution around it and run it on monovista, on an embedded appliance, or you can run Kray Linux on a super computer and everything in between. And I think it's really a mistake to pretend that OpenStack will be something that's going to be this single unified reference architecture that, you know, is totally interoperable because in doing that interop you're going to reduce innovation. It's the same kind of problem as having the standards-based solution because you have to say that this drive behaves like this just drive. It's inherent in the issue of creating interop. You reduce and you stifle innovation. And so the thing is that if you sort of give up that OpenStack isn't a complete cloud operating system, if you say it's just a framework and I'm always going to have to add stuff, then this kind of notion that people should stop innovating around like the AWS APIs doesn't make any sense because there needs to be room for people like me to say look the best way to deploy OpenStack successfully in production is via this model that I developed that does leverage the AWS APIs and AWS as a reference architecture and then that becomes the AWS flavor of OpenStack and everybody else in the community is allowed to do what they want to as well. And I have absolutely no objection to any of this and I think that there should be an AWS flavor and I think you guys should take the lead and I think you have been doing that to a large extent already and build this AWS flavor but I guess the point is, you know, how much sense does it make to focus on it right now and I think that I agree with you completely that OpenStack will never be this one monolithic thing. So I didn't say focus, I said embrace, I said stop pushing away. But that goes back to my first argument that really OpenStack I didn't have a chance to rebut that. Okay, well go ahead and rebut that but I remain convinced that there's no kind of opposition in the native opposition in the OpenStack community against AWS and then again what does it even mean? Like the open source community just go ahead and commit code and you drive it and everybody drives it. Absolutely. There's no one guy that says we're going to be against AWS. Code rules. So make the code and you get AWS compatibility. Absolutely. But that's not the that's not the point. The point is is that in many ways Rackspace poisoned the well on this, right? I mean, you know the Rackspace APIs aren't in there as an accident. It's a very deliberate move. There was a decision as much and so I think Randy's point is saying, hey, let's at least embrace this. After that they were the top number one contributor until recently. Granted, I'll give you their influence in the community is waning so it is a good time for me to go frankly in some ways kick them in the teeth and say look I think we were led down the wrong path here which is what I did. Jeff Arnold has a question. I'll repeat it since he's not near the mic. You'll go over the mic. So I guess my question my question is did politics constrain Linux? I mean Linux only succeeded because they started off saying we're going to do a politics an open source politics operating system and without politics compatibility Linux would have never got accepted because it would never it would never have been an easy safe adoption move from Solaris or HP or X or whatever. So this conversation so far has completely ignored customers, completely ignored the ecosystem. It's all been all about the development community and I think that sucks. So nobody has said what's the cost to the customer of having these incompatible APIs. Randy is right in saying that we can have multiple APIs but I would like to be able to take the Netflix OSS and just run it. And I can't. Now it's not just a simple saying well let's full support for the APIs. It really isn't that simple. And the reason it's not that simple is because we've poisoned the well in two ways. One is we've poisoned the well by putting in APIs which have constrained the system in certain ways. The other thing we've done frankly is to let too much crap into the system. Too much variation. Too many options. Too many extensions. And as a result it's very very difficult and I speak of somebody who's waiting for a company that's building plugins and building components to go into OpenStack. It's very difficult to create a subset of that collection of all stuff we built which actually provides the right level of semantic compatibility. Yeah so why is it that we can't as a community say hey running Netflix OSS on OpenStack is an objective. And then make it happen whether it's on the damn OpenStack APIs or not. It should be. And while I've got the mic I'll say one of the things we recently celebrated the third birthday of the project. And a lot of people were very happy. Look how much we've done. I was disappointed. In three years we have not even replicated the basic services through AWS in 2009. Just the services. Where's elastic load balancing? We don't have basic cloud services. Come and talk to me about the stifling innovation when we've actually out-innovated AWS. Until that happens all I want is to get a really kick-ass open source system which meets the basic functionality. I think that though this comment is really not about the compatibility or compatibility of APIs or embracing AWS basically what you're saying is that you're unhappy with the existing structure of how the development process and how the ideas bubble up to the top and get implemented in OpenStack. It's too distributed to many organizations involved and they're getting poisoned from all kinds of different sides. Instead you should have more control more of a kind of benevolent dictator mentality that was present in Linux and is absent in OpenStack. And that's the argument that I guess that you're making. It's a whole different debate and I have my opinion on that as well but you know. I think you bring up a good point around the kind of the undercurrent of customers and using these services. And I think where at least each of our companies were involved in just working on our customers' projects and we're contributing back as we're meeting those needs as functionality develops. I don't know about what you guys are finding but at least what we're finding is that customers are adopting OpenStack because sometimes they have some pretty unique requirements. So in terms of what you guys are seeing, how important back to that question, how important is it for having complete compatibility between what you're developing to solve some unique problems at the customer's site to bridge that out to the public environment or to answer Jeff's question I guess directly. I think what you said is basically OpenStack and you mentioned that as well that OpenStack is really not a product it's more like a framework and you can build all kinds of different clouds out of it and because it's early and because it's being innovated against so much this variability is just great and there's so many different configurations and yes I agree that's definitely a curse and if you come into OpenStack and you expect to download OpenStack packages and get where everything just works and all the decisions have been made for you then you come into it with a wrong mentality ultimately yes there will be different kinds of OpenStack. There'll be cloud scaling OpenStack, there'll be merantis OpenStack there'll be different opinionated kind of implementations all that and then opinionated to a different degree but the reason OpenStack succeeded to begin with I think is because of that flexibility and because that's why everybody started embracing it because there's an enormous spent-up demand there for some sort of framework that gets you 80% of the way to the functioning cloud and allows you 20% where you can build plugins and make decisions and change around the API and that's really been the primary driver behind OpenStack's success so far. Alright so we have an online question from Craig Tracy and he asks what I have not heard is how API adoption will help or hurt the OpenStack adoption curve so while embracing these APIs help or hurt like is it more important to create this alternative ecosystem that people can latch on to or well why wouldn't we want the OpenStack ecosystem plus the AWS ecosystem plus the GC ecosystem plus the VM where like why wouldn't we I can't imagine why we wouldn't it's a matter of focus right in terms of what came into it. EC2 APIs are in there today well for example like Amar just mentioned the S3 API for Swift something that we track as well and we've been adding architectural components in there so we can better support the S3 API because architecture maps down to that API but we only do that once we hit a customer who has that issue and now we need to start folding that but you are hitting those customers who have requirements around the S3 API we are pulling people off of S3 is what we're doing and so we need to take the fire hose from over here and point it over here into their private environment and so when they do that they have specific tools and they have specific use cases that they're using and if we need to we'll patch them up but we'll also they'll also new applications use the native API because that's what they want we see the same in our customer base a lot of people want the AWS API so they can migrate off and it eases that but they also use a lot of the open stack APIs natively and we allow them the choice of using whichever one works best for them and it's interesting because it turns out that in many ways those two different opinions surface in some strange manner so if you look at the EC2 API things like EBS or VPC are a subset of that entire API and it's networking functionality that's part of the compute API and in open stack there's like nine different APIs and you kind of got to know how to talk to each different one and it just winds up looking very different I would like to add one thing before we move on just kind of from our perspective and the reason why I'm kind of you know DED how would you say it like putting less accent on the whole API and getting an open stack today because in our maybe skewed experience so far we've seen two kind of entry points into the customer where they are embracing open stack so one is you know they're just green-filling an internal cloud or they're trying to maybe get rid of VMware and the Amazon in that case is not even in the picture they've never touched Amazon you come into open stack and you know it works and they buy and it's an easy sale now we've had a number of enterprise customers where we try to enter at a different point the guys that have been using Amazon for a long time and they have a bunch of applications that are written to leverage Amazon API the whole ecosystem is inside and they come in and they're like Amazon is kind of charging us a lot of money we can build our internal cloud open stack in that case what happens is these guys they do research around they look at cloud stack they look at open stack they look at eucalyptus and virtually every single case that we have seen so far they stick with Amazon anyway simply because of Amazon's current superiority over all the other solutions so would have helped if we would have said that we have this API compatibility no because they use the 90% of other features that Amazon has that none of these open stack or cloud stack eucalyptus systems have we're seeing different we're seeing a ton of people cloud back from Amazon can you state your name in the company you work for so it's an interesting conundrum because in one hand being open means that you can allow anything but at the same time we can't support everyone every API it's kind of just making money but in the other hand you don't have a dictator who would be on rails where you could say I'm just going to cut it and just use one I wonder if there's not a solution for this whereby we can use the customers and use D so the forest API we are right now we instrument them and collect data then we can figure out what the customers are telling us in addition to surveys and so on and in that way we can make decisions that are not just emotionally involved but based on the data so I'm actually totally in favor of this the problem is is that you see a lot in the community the fact that people are like oh I'm not sure I should use the EC2 API because I should use the native NOVA API except the native NOVA API is the Rackspace cloud servers API so there's already inherent bias if we had a different low level API that didn't have any opinion to which there was the Rackspace API the EC2 API and whatever else then we could let the market decide and we could use that real data so there's inherent bias that already exists because the Rackspace APIs are somehow the native APIs but I think that realistically I agree with it's been kind of poisoned but this is again going back to my original argument but I think that they tried to influence it they did open their APIs the community started to innovate around their APIs but I mean it has gone so far now that it just the former Rackspace API it's gone for open stack and I'm not saying it's a perfect API it probably could be improved and I'm all for improving and making a better native API but I disagree with the premise that the existing open stack API is Rackspace API and it's somehow by that today inherently poisoned I have a question David from Puppet Labs my question is something that has been touched upon at all in this conversation is governance and that's where AWS is very different from positives for example or in a long way it feels more like in the early days asking Linux to adopt the Win32 API, namely an API in which the community has no input, no way of getting any changes in there from a technical point of view in AWS to really make a standard API you would want to have some sort of discoverability in there but there's no way no chance in hell that anybody's going to convince Amazon to put that in there and that's also how the open stack API even though it used to be the Rackspace API is a very very different animal because it's now governed by the community and there's an open process around it and foundation and all these things that make this really a community driven approach whereas AWS is a vendor driven approach it's a great point we notice it from the Swift world they don't rev the version number and they change the API I mean they do that because they can well I mean to range this point AWS API is pretty stable because they have the ecosystem around it they can't afford to change the API just like that because they will kill the ecosystem it's more stable than open stack when you go talk to the Eucalyptus guys when you go talk to the Eucalyptus guys I think they have there's a bit of chasing that they're having to do it's always chasing but then I think we're missing the whole point the point is embrace and extend and allow people on Amazon to easily get off on to open stack or to build hybrid clouds that are connected to open stack we constrain things and we say okay we're only going to do the open stack APIs we inherently limit the total addressable market of open stack I've heard this ridiculous statement about how very few of the open stack deployments are using the EC2 APIs according to the user survey it was 30% 33.5% but that's a third and that's a lot in market share we don't want to shut out those people we don't want to shut out people who want to have AWS compatibility just like we don't want to shut out people who want Google Compute Engine compatibility and VMware vCloud Director compatibility we want all those people to come over and use open stack and one of the best ways to do it is to support those APIs as well and it's okay if they're outside of core and then allow an on ramp on to open stack I mean don't we want open stack to win we have another question so my name is Victoria Lipschitz I've been actually running services company that's been doing open stack work funny enough actually before Mirantis did so it's been a long time but these days I run a different company actually a PaaS platform as a service company and that color is a lot of my perception around the issues that we were having today so I want to pick up on the theme of community and also of interest so when we try to debate what's in the interest or against the interest it's the first question is whose interest and what are we optimizing against or for so open stack is a collection of bad fellows who are each by larger commercial entity who made a conscious choice to embrace open stack for their commercial interest right as opposed to other alternatives now looking at from an ecosystem perspective we have at least six ecosystems we have Amazon for sure we have Microsoft we are fast having Google coming not just with the Google App Engine but also underlining cloud as well and then in a private world we have at least Citrix, VMware and open stack right and probably more so here is six of them and let's assume we are all competing for consumer dollars so open stack community collectively actually does compete with Amazon so when we talk about friend or foe almost by definition of the structure Amazon is a foe of anybody who's commercially betting on open stack or a frenemy well I mean a frenemy a friend and an enemy we can argue about the best way to fight and the best way to fight might very well be to obtain their customer base so here's a question that I have for the panel given that the name of the game is optimized the interest of open stack community where the focus should be late and speaking of API I find it interesting that it's framed as AWS compatibility debate but AWS is neither compute nor storage it's a tremendous amount of web services APIs that are more than what pause platforms tend to provide than what compute and storage infrastructures are so the question that I have of community do we want open stack compute and storage the best that it can be competing with EC2 and S3 or do we really want to how are we going to play that game one level up that's a great question right so I think Boris touched on it like Jcloud and other provisioning low level APIs there's platforms as a service companies like the one that you're building now and you have engineer art and haroku and dot cloud and then the ones from VMware and Red Hat they're all producing them I guess they got spun out in the pivotal so why why not use that as a mediating layer. And I think Rob Hirschfeld from Dell on the chat also mentioned between automation tools between Puppet and using Chef and tools like that. Why isn't the abstraction layer up there rather than why are we mucking around down here trying to bridge API compatibility? Why don't we rely on that layer above that infrastructure to do that abstraction for us? Okay, you go. So just one thing real quick. I want to push back just briefly on some of what you said. You know, when we were at GoGrid, we looked at, when I was at GoGrid, we looked at Amazon and we said, man, these guys are amazing. They're going to make our business. They're like educating all the customers. They're building this massive cloud. Some of those customers are going to peel off and we were like, yeah, we're working in cooperation with those guys to make the pie as big as fricking possible because if cloud computing is something that displaces enterprise computing like that displaced mainframe computing, what if it's 10x bigger like enterprise IT was than mainframe IT? We're talking about a massive, massive market. So just driving the whole thing as quick as possible, as fast as possible and making customers as successful as possible is all the fricking matters. Now to the issue about why can't we bring a compatibility layer like J Clouds or Fog or something like that and run it, the thing is that, you know, I've done a lot of these deployments on Amazon Web Services. I built a whole framework with Chef and RightScale that would deploy like 100 VM clusters that had image processing capabilities and all this crap in a fully automated fashion. I could do all 100 servers by myself, spin them up in five minutes, run the cluster, spin it down. Clouds don't behave the same, right? I talked about spin up times earlier, but there's other problems too. Something like Chef or Puppet interrogates the system that it runs on and it determines what its IP is. Like in Chef, it's called MyIP. If you've got one network interface, which one that, which IP that is on your box is very apparent. If you've got two network interfaces, it's not as apparent. And if you allow people to have arbitrary numbers of network interfaces like you can with a V Cloud, then, you know, which one is MyIP and which VLAN is that plugged into? And how the Frick do I even find that stuff out? Because Chef is going to have to do a whole lot more heavy lifting and figure out what the front end VLAN is on a V Cloud as opposed to AWS where there is no choice. There's just a Frick in network interface and that stuff is all over the place. It is all over the place. You know, early customer for us that, well potential customer with Skype and they're telling us how they would take their stuff off of Amazon and they put on bare metal and they suddenly got two, three X performance and it was the same basic configuration. Now here's the problem, right? If your pass or whatever assumes that the box is this big and then you move over to this cloud and the box's performance is half or 25%, then suddenly like all of your logic that's scaling the system could be in jeopardy. So these things that just because you have semantic equivalence on the front end of a cloud doesn't mean you have architectural equivalence and that is a huge problem. And those abstractions cannot fix that problem unless there are better APIs that allow us to like, you know, measure the resource in an accurate way. So then what about the projects that are more pass oriented? With what we're seeing, you know, for example, with the Swift API, the API maps very directly down into how the architecture works. And so there's some slight variations in how things are done with S3. Absolutely. And then that's not, I mean, you have, I mean, it's not, there's the provisioning APIs, right, which would be great to have compatibility between, but then there's the other ones like that aren't necessarily provisioning APIs or services APIs, you know, between like Keystone. What's the, what's the ADBS equivalent of Keystone? It doesn't matter, right? Because here's the thing, right? If you go and you measure Amazon Web Services, like revenue streams, and which are a measure of the adoption of the various services, that's not some even usage pattern. It's a power law distribution curve where you've got EC2, and you've got S3, VPC, EBS, ELB, something like that. And then there's this long tail, like I haven't encountered one customer using Dynamo DB, not one. So like, who gives a shit about Dynamo DB or bean stock or any of the other stuff? All we care about is the fat end of the tail, and replicating that to make it good enough so that people can get off of AWS on the open stack. It's like a no-brainer. I don't even understand why it's contentious. It's ridiculous. I think we maybe got away from the question a little bit that was originally asked, but I think you touched upon it. I think my, I mean, in general, it's always better to interface with a low-level API of a system. If you have a choice, you want to be able to do that. As soon as you move just a little bit up and you introduce something like Fog with J Clouds on top, an abstraction layer, and you start bursting between the two environments that have different implementations, you start running into all these kind of incompatibility issues that on the surface are not apparent, but once you start doing it, they will come up. And the higher up you go, if you start moving higher up into kind of a pass-level abstraction, then this all multiplies by as an exponent, basically. Any more burning questions from the audience? One more? Yeah, come on. Thanks for this effect. I mean, I torrented what you just said that I think open stack is going to be more than just a foundation. It's going to become a full stack eventually that will get optimized down the stack, in the middle of the stack, and then up the stack. And that whole stack is going to be the ecosystem that we're trying to create. Now, as far as interoperability, I think, you know, to make it right, it has to work on its own native API. And the native API should be optimized for the system itself. For the interoperability, it's no different from what happened in the database world where you had Oracle building its own API, Sybase building its own. And then people came up with ODBC and then JDBC and they, you know, built reasonable level of interoperability, but suggesting that Sybase should win because Oracle's native API should become Sybase's API. They're building off of SQL 92. If there hadn't been an agreement on at least some base foundation syntax, the syntax of all the SQLs are almost exactly the same. That's why an ODBC or JDBC is possible. If it wasn't for that, if there wasn't some baseline syntax, you'd be talking about huge differences like here's a JSON database, here's XML, and things like ODBC would be tremendously harder to do. Well, I hear you, but the counter argument to that is that what makes Oracle a winner, you know, in many, in many cases today is not just the SQL itself, but the, you know, PL SQL and all the other things in stored procedures, which are a lot more powerful and optimized to Oracle engine. And so it's not interoperable. Exactly. But, you know, but for interoperability, those who care to use the subset, and we should do the same thing. And there will be people who will do the subset that will talk to both. But if you want to solve the complex problems that you yourself just mentioned exists, you have to do it based on the based best architectural decisions that are optimized for the system itself. So the native stuff must be native and different. But for interoperability, that will happen. We will all drive it because we have to, we have customers who are coming in with that requirement. And, you know, people will build it. Yeah. Excellent point. One more. Let's do one more question. And then we'll wrap this up. Thanks. Sorry, Dave, you already got one. What's that? Hi, David. We're all winners. Hi, David Bernstein here. I did, you know, when other industries have gotten pretty mature, they have served customers well with with standards. And there's been several of them. Things like Ethernet have gone through 30 years of innovation. And there's they're still innovation. And yet, there's lots of different standards. But, you know, that has served customers well. I know that a lot of customers are nervous about AWS APIs or other APIs, not so much from the legal side, but maybe just how do they specify what kind of cloud they want? Right now, governments and big companies are used to specifying, you know, standards to buy stuff in RFPs. Do you guys think that we could help the adoption of clouds in mature, you know, markets like governments, enterprises who want to specify this by using, you know, standards in this equation somewhere? I think that this is a point I've made many times, I think that definitely standards are good. But standards are really only possible when we're talking about the industry or rather, you know, even specific technology or sub segment, where there hasn't been very much innovation. And I talked about this before, it's like a lot of people, they compare, you know, infrastructure to the outlet on the wall. And the idea is that, you know, it's like, sometime down the road in the near future, all of infrastructure is just going to be standard. And you can just, you know, like plug in your application anywhere and it'll work and everything's commoditized. And this electricity thing, it works, but there hasn't been any innovation in electricity in the last 100 years. But the infrastructure market is so dynamic, and so much moving forward of such velocity, that you simply can't create a standard. You create a standard and then Amazon creates a new service, and open stack spins up a new project, and then you make a new API, and you're done. And that's all that is pretty plug and play, right? I'm sorry. Well, I mean, the thing is, is that I think we're still sometimes I feel like every time we get into this discussion, we wind up, we wind up in the whole zero something again, there's been tons of innovation in electricity, right? I mean, solar power, you know, different LEDs, different to standard. They can standardize one thing, you can standardize like the networking protocol, but you cannot standardize a cloud API, because it's too high level, like it's too, it touches upon too many things. Is it too much innovation happening around there? Okay, I think let's we've been going on for 55 minutes on this. I think it'd be great for us to get a chance to socialize with each other, at least for a few minutes, we were off to head back home to summarize. I think someone said, let's do a straw pool. I think that'd be kind of fun actually. So we have so statistically state the well, I think this is the end core outside of core. And I think what we develop strong affinity or completely outside of well, that's like neither one of us really. So if we if we are to summarize, I think, what I was going to say is that if we are to summarize ultimately, there's not going to be any disagreements. So but let's how about you summarize and then I summarize. Okay, let me summarize. Let me summarize first. I think it's a novel cause to pursue API compatibility, not just Amazon, but across everywhere. Open stack community should not be eliminating Amazon or doing anything to the contrary of not embracing its API and trying to feed off of its user base and things like that. Is this something that's priority one today for the open stack community, given the all other opportunities around the innovation and simply augmenting the stability of the system? No, I think it is not a number one priority. Randy. Well, it's problematic, because I'm not claiming it should be a number one priority, right? I'm just claiming it shouldn't be forgotten in the mix. And that you know, I don't want I want the fact that rack space is now shrunken as a instigator of a lot of these sort of poisoning the well around Amazon to go away. And I want it to be really clear that we care about compatibility with a variety of different cloud systems. And the open stack native APIs absolutely are the primary place for innovation. But we should continue to have compatibility. And I think it's a mistake to to ignore it. Okay, so the straw poll is if you have more affinity towards Boris's arguments, raise your hand, please. Sorry, Boris. Wait, wait, wait, let's let's see if it's a non participatory. And then for those for Randy, you know, the the other hand here, a little bit more affinity. Thank you very much. But there it's a very we had a bunch of abstains. So we just tried to put a patch set back working with Juniper on the all the VPC capabilities into the EC two API yesterday, but Russell's not going to take it because it's a little late in the cycle, unfortunately. And we just tried to push back the GCE APIs. It's the same story as well, because it's a man of free. But you can expect both of those in ice house and we'll put them in the very first ice house released after Havana drops. And there'll be more after that. Randy, so how do people get a hold of you or follow you? And what's the website for cloud scaling? Randy bias r a n d y b I a s blogs or anything be surprised if you can't find me. Just typing in a Google, you'll be good to go for us like same thing. Yeah, just Google me add zero to its merantis.com, zero treats with a zero. Yeah, Joe, Joe Arnold Swiss stack.com. And we'll hand it back to you to close us out. Okay, so the replay of the video is still live right now, but we had over 300 concurrence. I just checked the stream of about 252 live concurrent viewers. So lean leaning back watching live go to YouTube.com slash Silicon angle, you'll see on demand replay of this video. And we're going to have some great comments on the crowd chat.net, kind of the Twitter chat room that we put together for this and it's going to be on the record. So if you want, we're going to keep it open for an hour, then we're going to shut it down. So if you want to go there, log in with your Twitter handle, or LinkedIn handle, leave a question and comment threads, we're going to have that be a document of record for this event. So go to crowd chat.net slash open stack for the next hour. So guys, thanks a lot. And thank you guys for coming. Appreciate the broadcast. Thanks a lot.