Okay, thank you. My name is George Reese. I'm the CTO of enStratus. We're a cloud management platform focused mostly on enterprise governance needs. Got into cloud computing because I ran another company called Valtira that did marketing software and we've done a whole bunch of management stuff and spun it off into enStratus. And in the course of that I had written a couple of books; one on cloud computing, one in REST APIs.
Well, the tricky part isn’t necessarily the fluid nature of the market because the market definitely is fluid and even I who have been intimately engaged in this have been surprised constantly by it. But that's not really the big challenge. The big challenge is that cloud is a term that's so overloaded, and so everybody who comes in to the conversation is bringing their own baggage. So for some people they think it's time sharing warmed over, and other people have Amazon as a cloud and anything that isn’t just like Amazon is a cloud. Those are two visions that are completely nothing alike. And so even if I'm talking to somebody who is knowledgeable or not knowledgeable, I'm having to set some sort of common vocabulary and that is almost always the difficult part.
[Richard's full question: So you're speaking today and for those who are watching and want to catch that session after the fact, we're going to be covering enterprise cloud strategy this afternoon. I mean in a nutshell, what are some of those components that are key? What are some of those nice to have that you might get bogged down because you're too obsessed with too much and it becomes such a slog that people give up? So what's that kind of core stuff?]
Yes, the biggest challenge about cloud from an enterprise perspective is that it is a multidisciplinary thing that there are - you have to bring in development and engineering teams. You have to have operations people. You have to involve the business decision makers, and on top of that it's not - cloud isn’t a technology. It isn’t like making the jump to Java from the old C world, like that transition or SQL to NoSQL type transition. When you're talking about adopting cloud, you're talking about potentially bringing in those SQL databases, bringing in configuration management. In a lot of cases, people just started with virtualization and now they have to take on this on-demand thing.
So there are just so many problems you have to solve that are new to an organization and where you start gets to be difficult. And on top of it the people who have been driving the adoption of cloud aren’t the ones responsible for strategy. It's generally the development teams, the business units who have been pushing this adoption of cloud and then the ones who have to unify that in terms of the strategy tend to be central IT and operations. And so you end up in a lot of cases either with central IT trying to enforce control as some mechanism of strategy or trying to boil the ocean and neither of those are good approaches. The enforcing control destroys the value proposition of cloud computing, and the boil the ocean thing just doesn’t work because it's too much to swallow at once.
Richard: Yes. So breaking that up, I think it's something you tweeted this morning – you made me think of it – was I can have a cloud strategy, and if I don’t change my process it still takes me two months to get a server. I mean just the fact that I can provision on demand. Who cares if most companies they have virtualization. Nothing prevents a big enterprise from spinning up a box in five minutes.
Absolutely.
What made me tweet it this morning is because, I think it was Jassy up there talking about how cloud brings this ability to provision VMs in minutes, and it's like no virtualization brought us that capability. The problem with provisioning and virtualization is that virtualization kept the procurement process and the control at central IT entirely, and so what we ended up seeing is people went to virtualization in part to reduce procurement times from six months or three months to six weeks or six days. And in reality that number didn’t change for most organizations because it turns out it wasn’t the buying the hardware that was the problem. It was the approval's processes and the "I've got more important things to do" issues that I mean, you know.
The last decade has stripped IT of resources so they don’t have free time to worry about non-core issues. And so you end up with these long procurement processes whether it's virtualization or even cloud if the people who are making decisions about that are not the people who need to consume. So the reason from Amazon's perspective cloud is the enabler rather than virtualization is because again, as I said earlier, the people driving the adoption of cloud is the consumers of technology and they are going out there and they are using their credit cards. And that's what's different about cloud is that if IT is going to take me three months to procure a VM, I can go to Amazon and get a VM in three minutes and I don’t have to involve IT and I can get whatever I want done.
Richard: So to the point of enterprise cloud trend arguably – I've done this myself where I'm doing proof of concepts with Amazon which is simpler – that's not an enterprise strategy. Arguably, that's me rouging a little bit.
Exactly.
Well, the mind shift has to be that you don’t have to control everything and understand. I had a conversation with a guy named Chris Hoff and so I have to give him credit for this expression, but it's about the graceful relinquishing of control by central IT and retaining control over the things that matter while not having the stranglehold over the procurement process. And the way you gracefully give up control is that you eliminate or greatly reduce approvals to start with and then you focus on things like budget constraints, like access rights and enforcement of critical operational controls around information security, about safe harbor and things like that. And once the control shift has moved from procurement to operations, then it's a lot easier for the business to not feel like IT is getting in the way and what they’re trying to do and the business to still feel like that; the ITs do not feel like the business is putting them at risk.
I think it's too hard of a question to deal with because first off companies across the space, Amazon obviously, but even in many areas you don't think of are innovating. And so let's just take API standardization as one example. If we, let's say, standardized on the EC2 APIs, there are so many things that OpenStack and CloudStack do just for example, and vCloud as well is another example and certainly competitors to Amazon do that can't be expressed in the Amazon API. So you either have to extend the Amazon API to consider those things which Amazon obviously isn’t about to go do which means that the other alternative as you go and develop something in a vacuum, something like an AKI or whatever. And what ends up happening is nobody implements it because it's not solving a real cloud problem. It is abstracting the real cloud problems in saying "Come and use me" hopefully, and people are more busy on leveraging the actual clouds.
Richard: And you guys obviously bridge some of those gaps for the time being. If there is mismatches, I can provision in one. I can bridge multiple clouds...
Yes. And obviously, a benefit of being an enStratus customers that you do get one API that spans all the clouds and certainly there are some people who use this in that way. I don’t wish to suggest that we are a standard. We're not. You have to be an enStratus customer to take advantage of that now. We would be fine if people started implementing our API for their stuff, but people don’t and I wouldn’t expect anytime soon for that to happen.
Well, I mentioned earlier that the thing about cloud, cloud isn’t a technology innovation. It's an innovation in how technology is managed and consumed. And in particular what happened is at this point one company achieved such massive economies of scale and how they operate a technology infrastructure that they were actually able to, for the most part, sell that to other people cheaper than those other people could do with themselves. And in a lot of cases as other people or company said have operations we would traditionally think of at scale, but the economies in scale of those Fortune 500 companies pales into comparison to that Amazon has done.
So the idea that we would see a proliferation of people who have achieved that level of scale isn’t realistic. Realistically, today there are two primary people who have that kind of scale. There's Amazon and there's Google. And the other cloud players, some of them have reasonable economies of scale that aren’t the same as Amazon and Google but still one where they can be good solid clouds, and then there's another group out there that are either want to be clouds or they are regional or other kind of niche players. And I think there's room for all three groups but you need to - when you're approaching a cloud strategy - to understand what you're trying to achieve when you're selecting a vendor. You want the complete on-demand anytime no matter how many I'm going to provision that an Amazon would provide. Or do you need a local throat to choke? In which case, a regional provider is going to be much better seated towards you or do you need a purpose specific cloud for certain things.
So there are justifications for all three, but in the end the big ones are going to be a very small club.
I probably could give two answers for that. Probably, two answers to the both of the question. So SDN might be one; OpenStack another. I'll focus more in OpenStack because it's more cloudy - I mean not that SDN isn’t, but OpenStack - so why we're not talking enough about it is because when we are talking about it, we're probably talking about the wrong things. And so we're talking way too much about the wrong things about OpenStack. And the reality in situation is OpenStack still hasn’t seen production, private cloud deployments, running businesses on a day-to-day basis except for some very specific exceptions, whereas the other players in the space have people living and dying on their cloud platforms every single day in a variety of scenarios.
But there is a lot of potential in OpenStack and people tend to get lost in the hype of OpenStack and not understand where it really can start to add value. And part of that I think is a community's fault because a community gets lost in the cool factor I think a little bit and not the operational factor of what it's going to be like to live with OpenStack in terms of things like the possibilities, what it's going to mean to be able to operate seamlessly in multiple different environments potentially managed by multiple different vendors.
Well, it's funny I brought SDN because I didn’t want to really - I think that's an overhyped term, but I'll say more broadly networking problems in the cloud. I thought 2011 would be the year we would focus on networking issues. In some level we started to focus on networking issues in the cloud in 2011 but I think got distracted by a lot of things. The fact that you can't find a public cloud of any reasonable adoption today just to take a simple piece of the network puzzle that is IPv6 enabled and just astonishes me. I think that's problematic. I think as a whole we're all sort of - the people who know as well as the people who are just coming into the picture are all sort of feeling their way in the dark about what a network in the cloud should look like.
I think network intrusion detection is an artifact of perimeter-based security controls. So really efficient network intrusion detection means you have a single choke point at which you can analyze data that's coming in and going out. If you wanted to do network intrusion detection in Amazon, for example, you really need to have network intrusion detection software on each host examining packets that it can see which in Amazon are only packets destined for it, doing the network intrusion detection and the host intrusion detection. And the reality is that you get the same benefit out of host intrusion detection with much less processing power and management overhead than you do with the network intrusion detection.
The fun stuff like being able to inspect the full range of traffic that's passing through the network so you can do smart guessing as to whether there's an attack going on just that data isn’t available to you and to me, that's one of the strengths in network intrusion detection. So it isn’t a problem per se with network intrusion detection. It's that the cloudy way of designing of networks doesn't lend itself well to the central choke point that I can look at what's coming in and out.
Well, there are two types of cloud architect. One is the person who's designing applications that are going to be deployed for cloud deployment. So that's somebody who knows stuff about design for failure, can reasonably converse when it's right to use a relational database versus when you should be putting data in a NoSQL system and how you can get full redundancy in 5 9's availability across Amazon regions that have a lesser availability ready. So that's one kind of cloud architect and the kind of things that I would look in that.
There's another type of cloud architect whose job it is to build the clouds. That person is going to be very conversant in the full cloud computing stack, know about your cloud platforms like Eucalyptus, OpenStack, CloudStack, vCloud, Nebula. They're going to understand cloud management. They're going to understand configuration management and how all of that needs to be put together so that you can operate a cloud infrastructure and make it available to people in a way that is consistent with the governance policies of your organization.
Well, I'm not the biggest fan of taking legacy apps and moving it into the cloud. As a matter of fact, as you're approaching a cloud strategy the worst mistake you can make is probably saying, "Well, I've got this legacy application that is just a pain in the butt to manage in my data center. So I want to move that into the cloud and not worry about it." That's not how it works. If it's a problem in your internal data center, it's going to be a problem in the cloud. And it probably isn’t even designed to work well in the cloud so it's probably going to be a greater problem in the cloud.
So I'm much more in favor of greenfield applications going into the cloud. Now, the challenge with that is typically you are going to have to swallow newer technologies as part of doing a greenfield because if you're traditionally a WebShphere DB2 shop, you're not going to - and you're going to decide to do a greenfield cloud thing, you're probably going to want to look at those NoSQL database and WebSphere may or may not play in that, certainly not the clustering features of WebSphere or of a more rudimentary form of Java development which may be alien to your team.
I don’t think it's a conversation that matters. So I'm with a company that makes a lot of money off of people who are building private clouds, and at the same time I'm tweeting a private cloud is not a cloud. There isn’t a disconnect there. The reality is that private clouds have value, but it is not the same value you're getting from going to Amazon. So a mature cloud strategy is actually going to involve both a public cloud piece and a private cloud component for a sufficiently large enterprise. If you're a startup, unless you have some sort of weird regulatory requirements, you are insane to own your own infrastructure.
Having said that, if you are a Fortune 500 company, you're going to have a private cloud and whether you will admit or not, you have a public cloud. There are cases where CIOs won't acknowledge the fact that they've got people doing Amazon but they've got people doing Amazon. And the reality is that you get some things out of the public cloud that you can't possibly get out of private cloud. And in the keynote today there is a checklist of items that you get out of public cloud. They really define what it means to be a cloud and you don’t get those in private cloud, but you can use a private cloud to give a cloud-like experience to your internal consumers that you have greater transparency into.
And it's important to note, it's not greater security. There is nothing inherently more or less secure about a private cloud. But the one thing you could get out of a private cloud that you can never get out of a public cloud is transparency. You know exactly how it's being managed and how it's being done and there's a lot of circumstances in which that has value.
Richard: So given that paradigm, obviously hybrid is here to stay for quite a while, what do you think are some of those services then are going to be the last to move? It's the things like identity or certain storage or once those things are going to - I'm going to have public but I'm going to keep going back maybe through a secure connection.
I think it's going to be vertical-focused because we saw in the keynote today with NASDAQ is doing. There aren’t really kinds of data that can't go in the cloud. It's just a general thing. I know people like to say they'll put personally identified information in the cloud. That's nonsense. There's no rule of thumb. Any kind of data out there except probably top secret data can go in and even top secret data can go in the proper government cloud. So there is no such thing as data that can go into the cloud.
However, there are governance requirements that certainly restrict what clouds you can deploy data and processing into and in some cases eliminate cloud computing from the choices that you have available and that's where private cloud comes into play. Now, a lot of that relies on the fact that we've got a lot of these compliance frameworks that predate cloud computing. So going back to my original point that it's more vertical-focused is because it really comes down to how loosely you're willing to interpret the compliance frameworks you have to live with, and there are obviously industries that are more willing to take risks and there are that are less willing.
Richard: So switching gears, I'm an unabashed fan of your API book.
Oh, thanks.
Richard's full question: For our viewers who are developers, architects, and you freely admit the things you’ve done wrong, the things you've obviously hopefully done well and I think it's realized in your enStratus API as well. What were some of those things that when you were doing the new API and obviously writing the book when you were done, what were those things you knew you did wrong, the most key things that, boy, that was a good thing you learned it?
I think the biggest mistake I made was putting versioning in the URI, and I even got into big arguments in the OpenStack mailing list around "Listen for me. I've learned this mistake." And it gets into a lot of esoteric merits about what it is to be in URI, but the thing is that your URI shouldn’t change just because the version of your API changed. And so I think version negotiation should be a header thing just like content type negotiation. And unfortunately, in the enStratus API as it exists today I made the mistake of putting it in the URI. I am migrating gracefully to a world in which that's not the case.
Richard: As well as supportive of content, I think at the moment you just have, you do have a JSON and XML. I think you are just REST, right? Not so.
Right, yes.
[Richard's full question: And then you evangelized - again, I like the pragmatic approach that again anyone who's a zealot that says REST is the only way or SOAP is the only way or JSON is the only way, it misses the point. Again, I think your point was that there's right reasons to use XML. There's reasons JSON is better. How do you come down on that sometimes when you're talking to somebody who is very focused that one or the other is the best?]
So SOAP versus REST really comes down to toolsets and REST is much better suited towards a general purpose scenario where you don’t know who your users are and what their possible use cases are going to be. SOAP is better when you have a well-defined set of consumers and you know what the toolsets are going to be using and the use cases are going to be using it for because you will get to market quicker with a SOAP API than you will a REST API every single time assuming that the languages in place have solid SOAP support. Obviously, there are some that don’t and in those cases SOAP is an absolute mess but assuming you're dealing with one that has a good SOAP support.
Whereas REST is much better suited when you don’t have control over the tools that the end consumers are using or when you don’t have a full appreciation of the used cases or more important you don’t want to be a limiting factor on what the used cases on consuming the API are. And so for people building cloud services, REST really is the right way to go; whereas if you're building internal web services, SOAP might be the better way to go.
The XML versus JSON thing is interesting because the problem domains for which JSON is good for and the problem domains for which XML is good for tend to be the people who solve the one problem generally never solve the other so they're absolutely convinced that - XML developers are absolutely convinced that JSON is stupid and it has no point. And similarly, JSON developers are equally convinced that XML is archaic legacy thing that they don’t want anything to do with.
The reality is that JSON and XML have two very different parsing structures that are beneficial to different types of data, and the people consuming your applications are going to - if you're going to have a wide variety of consumers again, some are going to be enterprises that have a lot of infrastructure built up around XML sometimes for good reason, sometimes for no reason at all. But you as a cloud builder, you're not there to judge people's used cases and reasons. You're to provide a service and let them do whatever they will. And enterprises have a lot of tools built around consuming XML.
And so no matter how much of a JSON zealot you might be, if you want to support an enterprise, you better support XML. The same thing is most new application developments, newer web-oriented tools, most designed for failure systems are designed to be very flexible and forgiving and leveraging JSON as a data layer that enables that level of flexibility. And enterprise developers don’t tend to appreciate that or they'll - and it's this whole schema versus schema-less ultimately is what it comes down to. XML developers often can't fathom why you would ever not have a schema, and JSON developers don’t understand why he would be constrained by a schema.
Richard: I guess as long as the tools support it, that's what matters. That's easy enough to parse all of them.
Yes. And so I'm a big fan of if you're a cloud, you're presenting a cloud APR and API for mass consumption support both. It's not that hard and you will avoid a lot of arguments that way.
I think it's amazing that it's taken till 2012 for us to have an Amazon Web Services focused conference, and I think it's great to finally get people who are consuming Amazon Web Services all together in a room. I mean this is a conference where the people who are attending it, a cloud conference where the people who are attending it are actually doing this stuff. And you haven’t seen a lot of that, and really that's the best thing about it for me. And I'm just happy to be able to get to talk to people who are really doing stuff.
Richard: Yes. It's great. Well, thanks for taking some time with this. I'm sure our folks will enjoy watching some of your take on these issues.
Thank you very much for having me.