 Hi, Jeff Frick here with theCUBE. We are having a CUBE conversation here in the Palo Alto offices of SiliconANGLE Media's theCUBE, and really it's a special treat to have a couple of really big brains, or Wikibon analysts, and talk a little bit in depth about this whole private cloud, hybrid cloud, what you should do, why you should do what you should do, and really some specific work that we've published here at Wikibon. So really excited, we've got David Floyer, co-founder and CTO of Wikibon, and Howard Marks, chief scientist, deep storage LLC. Welcome gentlemen. Thank you. So the paper that you've published, and really what we wanna dig down into is called the Strategic Comparison of Public Cloud versus Hybrid Cloud. So I'm gonna start with you, David. Why do we do this research? So we talk to a lot of users, and one of the debates that they're having is what is the strategic direction they should take with the cloud? There's no, absolutely no doubt that the cloud is a fantastic opportunity, that every organization should take advantage of it. But should they move everything to the cloud? Is every cloud the same? What's the basis on which they should choose what were closed to run where, and how to set up the cloud so it's going to be an additive to it, and enhance the application value that's delivered, and not a botanga that's gonna keep them from growing. Excellent. So we're gonna provide a little guidance on that present value of this investment as well as payback terms. So Howard, talk a little bit about the research. Kind of what was the methodology, how'd you set it up? We took two examples of cloud infrastructures, the Federation Hybrid Cloud, which is based on the VCR and VCloud, and the most commonly compared and used public cloud environment Amazon web services. And we went out to see just what the operational differences were. And the first thing that came out very clearly is, once you've added the automation and orchestration layers to your virtualization platform, that from the user experience, if a developer in HR wants to spin up a machine, as long as he's going to a website and spinning up that machine from a self-service catalog, the difference between doing it on-premises in the Federation Hybrid Cloud or in that the public cloud portion of that or on AWS is negligible. One was 27 or 28 clicks and the other was 31 or 32 clicks. But a minute here and there really doesn't matter. So the goodness from the user point of view of cloud can be replicated along any of these clouds? Cloud cloud really means that orchestration and automation layer, that the ability to take a developer in HR who wants to spin up a test environment from having to write a memo that goes to the change control committee that gets approved that then generates a memo to the storage guy and a memo to the network guy and a memo to develop to the virtualized server guy. And all of that takes three weeks and then he can start working. If we orchestrate all of that, he can start working in 15 minutes instead of three weeks. That's the benefit of cloud. And that benefit doesn't come from the fact that it's off-premises run by Amazon or Microsoft or Google, that benefit comes from the fact that it's self-service and automated and we built a service catalog that limits what the choices for those people are to ones that won't get them in big trouble. Okay, so that's kind of the same from the user experience. But in terms of from a functionality point of view, there are differences. And so if you are looking at reasons why you might want to use the public cloud, obviously there are a lot of SaaS applications which are fantastic to use, you know, salesform.com or some of the ads, yes, Office 365. Lots of examples of that where that's exactly what you want. You want to effectively outsource. From a development point of view, if you go to somewhere like Amazon, they really have a very rich set of application tools. You can spin up any sort of software you like. They have a fantastic capability of running application development. So if you are looking at developing a completely new application of some sort, that's where you go. Now, equally though, if you've got an application in-house and you want to modify it, add something on, whatever it is, then almost certainly that's going to be the best platform because you've got the applications there, you've got the databases on-site, the previous databases on-site, you've got all the tools that you use. That's going to be the best way. So it's horses for courses and your choice of cloud is going to be dependent upon what it is you're trying to do. But the other thing that we have to really make sure that people bear in mind is there's a big difference between that AWS model, which is you can develop applications quickly as long as because we've given you all of these tools and the virtualization model, which is you can take anything you have and run it in this automated environment because for example, and really probably the biggest example is an EC2 compute instance can only have one network interface. And so if you have complex enterprise applications that run across multiple virtual machines and don't communicate with each other over the same connection, the users communicate with them over, which is common, then moving that to AWS is going to mean rewriting the application to fit the fact there's only one virtual ethernet interface on that piece, on that virtual server. That's a complicated process. But we're talking now though about as a strategic level, when the command comes from down high, the guy comes back from Davos or whatever and says we got to all get on cloud, right? I just went there and that's what all the other smart people said. Then there's significant challenges and then according to the graph here on the executive summary, there is a very significant difference between a public cloud and your own kind of hybrid cloud. So what this choice was, this particular piece of research we were doing, we were looking at the option of going to migrating or converting an application from its current private cloud to the public cloud or moving it from the current private cloud to a compatible public cloud. So that's the environment we were looking at. So if you, and the reason why this is important is that applications have value. They've been developed in-house or you've taken a package in-house, they're running, they're working well and they have value. That value goes down over time. It's around 10% a year, we've done a lot of research in this area. It's around 10% which is the value that they drop and to keep that application going, you have to maintain it. You either have to bring a new version of a packaged application or you have to maintain it yourself and that's work that goes into it. If you try and convert an application from one environment to another environment, then that's hard work and it's no way a good way of doing it and you can do one of two things. You can either stop or any sort of update to that application, freeze the application or you can convert it and then at the same time be updating it on both platforms. Neither are good. One is complicated and the other one, you're gonna get a lot of complaints if you freeze things. I'm having nightmares of the Y2K process where I was on the team building. We're still here 15 years later. I was on the team building the new Y2K compliant infrastructure and there was another team retrofitting the old infrastructure just in case I didn't finish in time. So talk a little bit about kind of migration versus conversion because clearly if it's migration that sounds really easy and pretty simple, you're just moving it. Conversion sounds much more complicated and clearly I think that's what the driver is behind the Delta as we're looking at this chart. So if you take migration, if you have a virtualized environment and you're moving it, let's say VMware because I saw obviously the strongest out there and you're moving it to, what are they calling it these days, vCloud Air or something? Yeah, something like that. And then you can migrate it to another cloud, public cloud using vCloud Air. That's a migration. That it's the same platform. You're moving the data, you're moving the applications. That's relatively simple. It's still work, but it's relatively simple to do that. There's still the bandwidth issue. Still bandwidth, yeah. I'm gonna move this application but this application's five gigabytes. And what happens for some period of time it's going to be neither fission or foul. And so there is some complication of while that data is in flight, I might have to tell the users you can't use that. What do you mean? It's a cloud app now. It's up all the time. It is, but from running in location A to running in location B, while the data is in transit, I might not actually be able to run that application right now. And you also have the issue of there's a lot of local access to data. You may have some slowdown and things like that. What's the effect of latency of putting in? But in essence, it's not too bad. If you have to convert it, you're converting it one from platform to another. And if you go back to any of the days where people tried to convert things off mainframes, it took a long time. It was very slow and efficient. And in fact, I personally know of companies that were brought to the edge of bankruptcy by doing that sort of operation. They were so out of a line with what the business requirements were that they almost went bankrupt. So personally, I know that. So that's why it takes a lot longer. And then the research, the comparison was, it was 25 months for a breakeven versus five months if you are doing a migration. And the opportunity cost of this was six, what was it, 18 million versus six million? A $12 million opportunity cost. That's a lot of money. And what was the scale? Because based on what you just said, that even seems like a small number to me. A 25 month breakeven relative to, I think you have five on the other one, still doesn't seem long enough. Seems to be... We weren't trying to make it. Right, right. As hard as possible or anything else like this. It's just a pretty normal situation. So the message really is, don't convert. Conversion is never a good thing. Minimize the effort for migration. Minimize whatever you're gonna do. Minimize that and take it in small steps. Small steps where you can make sure that each step is a win-win along the way. Right, right. So it begs the question and you kind of just answered it. When people are doing this evaluation and again, assuming there's a challenge from on high, that we want the goodness of cloudness on as many applications as we can get, what are the really critical factors that they should look at when they're making this decision? And are there midpoints? We often hear about direct connect at AWS. You can have some of that critical data that for whatever reason cannot be inside the walls of AWS that's across the street or on the other side of the rack or maybe the other side of the sheet metal or the other side of the motherboard or whatever it is. In my cage as opposed to their cage. So what are really the key factors when people are making this decision that should really drive them one way or the other? Do you want to take that first then? Well, the first is that the real benefit doesn't come from location. It comes from automation and orchestration. And so, you know, pick the low hanging fruit first. You're going to get 80% of the benefit by automating and orchestrating and then the additional 20% of the benefit that comes from moving some of those workloads offsite in a hybrid environment as opposed to all of those workloads offsite in a hybrid environment, in a public cloud environment can come second. The second thing is that you have to be very aware of what's involved in the conversion. You know, the numbers that we used in the report are kind of mid case assuming the conversion was doable. And I have been involved in projects, well, I was involved in one project where Anderson Consulting built the HR system as a black box for this multi-billion dollar company. And that was three months before the Enron crisis which put Anderson Consulting out of business. And so now they had a five-year contract that Anderson would run this application in their data center for them. And there was no Anderson to run it. And that required- Not to mention the young kid that actually wrote the code, right? He's- The really good news in that particular case was we found him and hired him. But if that wasn't available, we were just lucky on that. You know, now the conversion becomes much more complicated. And the truth is if you dig in the bowels of most corporate data centers, there are those cobalt applications written 30 years ago and nobody writes cobalt anymore. They're just there. It can, you know, if I need to migrate it, I can migrate it. The truth is one of the saving graces for VMware, one of their earliest use cases was applications like this that were running on NT4. And you could virtualize that NT4 machine when the hardware it was running on was going out of support and that saved you from ever having to worry about if it broke, how am I gonna get spare parts? Right, right. But we didn't change it. We just moved it. And now if I wanna send it to AWS, well, that application doesn't use elastic load balancer in the elastic database service. It uses some 1492 Kodasil-style database that's not even SQL. And to change that to fit a modern architecture, well, the truth is you should just write a new spec and write it from scratch. It would be easier. Right, right. So going back to another point that you made, which is location and where you should position things, that's actually a very crucial decision to make. Clearly there are a lot of new data that's coming off the cloud and a lot of new applications which we'll want to access there. But equally clearly, you've got a lot of data on site as well. Now sometimes you can draw a very good distinction. So for example, email, it's pretty easy to put that out somewhere else. The degree of integration. You just talked to SMTP to it anyway and in the latency, isn't that big a deal? It isn't that big a deal. But for a real time, for your call center application, which is the heart of your business, if you want to link that to data coming off from the internet, for example, about who's calling you and what they're doing and where they are, if you want to integrate in that sort of way, then you've got a requirement to have your data and the cloud data close. You can't have seconds of delay there. You want to have it really close. And that's where, for example, the benefit of having a metadata center outsourcing your private cloud into that metadata center and then being able to throw a cable over the transom and connect using Direct Connect or whatever it is to the cloud makes a huge amount of sense. So again, you can keep your private cloud but you just position it close to the public cloud and then optimize the latency between the two environments. So it sounds like then, if I'm hearing this right, the real focus, the real priority should be really on the orchestration and the automation and cloudness is really a method to get to that but it's really not cloud first and then the other. No, orchestration and automation is cloud. Do cloud before you worry about public? Not anything, we have to be really clear about the fact that cloud doesn't mean public. Cloud means the self-service, the automation and the orchestration. And I think most people get that mixed up or they just are wrongly prioritizing around geography or commercials. Your CEO is stuck in an airport and you saw it, to the cloud. This is just not where you want to go. So they think and they don't really think through that I can achieve the orchestration and the automation other ways than just simply doing it via one of the public clouds. Yes, and there should be a priority. That, if you're gonna survive as a CIO, if you don't get your own costs down by making your operation cloud-like, that's very, very important. Convergence and cloud capability are too easy to do things which are prerequisite. And then you're not gonna be a million miles away from that. And then you can make decisions based on where the data is, where the functionality is, where, what I have, what data do I have, et cetera. You can make rational decisions. And like everything else, some is gonna be better on site, some is gonna be better on a cloud of some sort, either yours in the cloud or some SaaS vendor. It's a mixture of those two things with taking into account latency and taking into account cost and functionality. So again, the paper is on wikibon.com, strategic comparison of public cloud and hybrid cloud. Before we go, I wanna give you guys each the last word. Haven't done this work. You guys are in the field a ton. Two or three sentences of advice to people that are evaluating this move. The advice is really simple. Pick the low-hanging fruit first. You can implement orchestration and automation through commercially available products like the cloud director or they realize whatever they renamed it to or through open source projects like OpenStack if you have the requisite PhDs on staff to manage it. But either way, you're gonna get the acceleration of business process that comes from developers being able to spin up instances in minutes instead of weeks. And that's where the first benefit comes. That's the big money and let's worry about everything else after we've started doing that. And in fact, if you do that and leave it in place for several months, then you'll better understand what your requirements are for the next step because you've absorbed it into your IT department culture. So I've got two things that I think are really strategically very important indeed. The first is recognize that if you're going into conversion, you are going to lose a lot of money and probably if you're a CIO, be out of a job. So that's number one is don't convert sometimes you have to convert. The only reason to convert is you don't like that application anyway. Yeah, in case you rewrite it or buy something else. You have to want to change it first. But the other thing that I want to emphasize is the long view of this. Where I believe we're going is being able to take all of that data in the cloud that's available in the cloud and available locally and use that data to improve the current business processes and the current operational systems. And if you can get that data and you can get it fast and if you can use it, what we call systems of intelligence create those systems of intelligence that's where you want to be. So in designing your architecture of your data centers and your cloud architecture, et cetera that's the end point. The business benefit of being able to automate processes that previously needed people. Automate those processes, get the data so that you can automate it and improve your business processes. Those are in the order of 30 to 50% improvement in productivity and they're going to make discussions about what cloud or where I just look puny in relation to it. So have that as the end objective of what you're trying to do and then pick the set of hybrid or where things are with that objective in mind. Excellent, it was a great close. So Howard, thanks for stopping by. David, always good to see you. You're watching CUBE Conversations at SiliconANGLE Media's theCUBE offices in Palo Alto. We'll see you next time. Thanks for watching.