 The Cube at EMC World 2014 is brought to you by EMC. Redefine VCE, innovating the world's first converged infrastructure solution for private cloud computing. Brocade, say goodbye to the status quo and hello to Brocade. We're back, welcome everybody to Las Vegas. This is Dave Vellante. We're here live at EMC World 2014. This is the Cube. The Cube is SiliconANGLE's live mobile studio. We go out to events, we extract the signal from the noise and it all started in 2010 at EMC World and it's amazing to see the growth of this show, the growth of the Cube. Thanks very much for your comments, your tweets. You can go to crowdchat.net slash EMC World. We got a live crowd chat going all week. We're doing a drill down into converged infrastructure. Christian Lewis is here along with Charles Preston. They're both principal cloud architects, same title at the Apollo Group. Those of you who don't know the Apollo Group, I'm sure you've heard of University of Phoenix. The Apollo Group is actually the governing body, the holding company of University of Phoenix. Gentlemen, welcome to the Cube. Thank you. So you're both cloud architects. That's right, yes we are. That's cool. How did you become cloud architects? And that's a cool title. What's that all about? What's the start? Go ahead. I'll start. For me at least, I recognized a few years ago that things were shifting in the IT world and that being a siloed server guy or storage guy or whatever kind of silo you were in was probably not going to last. And everybody was in the silo, right? That's right, and everyone was in the silo. So you had to figure out how to get out of it. And what was happening in the public space, in the public cloud space at that time was very exciting and interesting and kind of glommed onto that. Same for you, Christian. Same, I mean, what was happening in a public cloud was amazing, the automation, the orchestration, the business enablement and developer agility that you could achieve out there was tremendous. And that at the time was our only avenue to, from an architectural standpoint, to take advantage of that kind of technology. So you actually were using the public cloud. That's sort of what all started, sort of the DevOps culture emerged within your shop. Is that, what was the chicken and what was the egg? How did that come about? Well, I think it's individual business units and development teams having credit cards. That's the impotence. So it was a big shadow IT action. That's right. And what timeframe is this? Like what year? 2009, 2010. So yeah, so I've been saying this. Coming out of the downturn, the credit cards came out, right? Because it's during the downturn, it was like, okay, get rid of the CapEx. But then coming out of the downturn, all the business guys said, okay, time to spend, let's hire developers and go. Okay, so you guys are watching this and we've seen this movie before. Like, uh-oh, what happens when you let business guys run IT? It never ends well. So how did it happen? Did the CIO come to you guys say I need help? Or did you guys sort of come forward and say I think we'd like to play this role? Talk about that a little bit. So I think both things happened. CIO was interested in understanding what the spends were and how we were providing sort of service assurance out there, right? And at the same time, developers realized this is a huge, big thing that needs to be managed and we can't do it all ourselves. And so we started to drive Converged Teams, right? And the result of that was lots of folks talking and working together. And then someone introduced DevOps in the marketplace and we started to read those books and started to try and align ourselves around those kinds of concepts, right? As we were learning as we went just like everyone else. And so we built sort of a DevOps organization and whose focus was do it fast, make sure it works and someday we'll get back to fixing it. So you guys were kind of, do I have this right? You were ops dev. So that's kind of, if you read that book, you say I want on this bandwagon, so it's taken off. Okay, so essentially when you started to formulate the strategy for your Converged set of services, was the edict try to replicate or duplicate the value, the agility, the economics of the public cloud internally? And what was the impetus there? I think speed and agility, having the ability for us to present useful IT services to our customers to consume in a self-service on demand model was most intriguing to us about the public cloud. And that we wanted to set out to replicate that but for our legacy environments, right? So it wasn't, at the time it wasn't, hey, let's take this DevOps methodology and move it back in-house. It was, let's learn from what we did from that DevOps methodology and provide that same kind of service to our traditional waterfall legacy application development team. Okay, so it wasn't a public cloud is too expensive, let's reel it back in impetus. Not when we first started this. We'll get to that part of the story. But it was more, okay, we've got this legacy infrastructure that we're not going to move to the public cloud. Let's try to replicate. Let's try and consolidate that onto the VBlock system. Let's try and replicate that cloud-like experience but in the confines of our data center. So the obvious question is, how close did you get? I'm going to say we surpassed it. Yes, we achieved that goal. You achieved it and surpassed it. In what sense? How do you measure that? How do you sort of give you some proof points? We both love telling the story. So we designed and implemented this platform, brought it onsite, turned it over to our first customer and our first customer was one of our smaller marketing departments. They got onto the platform, deployed their own machines, had applications up and running on it in multiple environments in a matter of minutes. And that was the first proof that we were able to provide to the rest of our customer base to say, what we said we were going to do, it exists. What we set out to achieve on this journey, we've now implemented and we have a customer that's benefiting from it. Okay, so let's go further down the line. You decided, okay, we can achieve these levels of productivity and cost savings. I want to come back to that and see if we can quantify that. For our internal, you said, why don't we just bring this stuff back from the public cloud? Now, what was the impetus there? It was working fine, right? I mean, you loved it, but was it too expensive? Was it just too hard to control? Was it hard to align the security compliance edicts? All the above? Largely cost was our challenge, right? Really? We felt reasonably comfortable with what we were doing and all of those operational concerns, right? We felt like we understood how to do it and where the pitfalls were and what to do about those things, right? We felt like we had it dialed, but cost really became obvious as soon as we delivered this platform and it did what we said it would and it cost what we said it would. We kind of put a hold on everything we were doing and pointed everything towards it. Right? Rent is a little more expensive than own. That's right. Is that right? Yeah, and now the more we use it, the more value we get out of it. So you hit your targets. That's right. And you probably exceeded them a little bit because you were sandbagging. Right? Well, and so now we're thinking about, now we've created this capability and now we want to add endpoints, which instead of thinking about public cloud versus private cloud, now we're thinking about I have a cloud capability. I want to add providers to my capability. I don't want to operate in two methodologies. I want to operate in one. And so that becomes a big concept for us now. How do I abstract my consumers from all of these providers who have valuable services without buying the lock-in of those kinds of services? What workloads were you running in the public cloud? We ran all of our workloads. Oh, really? It wasn't just test dev? No, no. We ran at scale in production. At scale. Talk about the applications you were running, both off-premise and on-premise. So we ran databases, right? Application servers, web servers, things that we're student facing, things that we're involved in delivering our primary mission. They were Java-based, custom or packaged. That's right. You know, SQL Oracle, no SQL. I mean, there was a wide array of third-platform application applications. What got us to public cloud was a need to deliver new capabilities to our students as quickly as we could, right? And our internal processes and procedures just couldn't satisfy that demand. Okay, so I thought this was going to be really simple. Okay, move test dev back in, but no. So how complicated was it to move all those apps back in, in the data? So I think we really benefited from all of the things we learned about how to operate in a cloud-like way. And so I think bringing things back while complicated would probably be more complicated if we were migrating from legacy IT to cloud or cloud back to the legacy IT model. We were migrating back from a public cloud and a specific set of services back to a private cloud where we also had to find a specific set of services. And you could build a matrix between those services and understand what to do about which application. So you mapped. And then you sort of made sure that you knew what you were doing. That's right, and we had this DevOps capability who helped sort of fit the rough edges to make sure that at the end of the day the applications really functioned and functioned as well as they needed to. So for you, it wasn't the Hotel California. You were able to actually move stuff back. Do you feel like had you gone too far down the path maybe a number of years down the road that wouldn't have been doable or achievable? Or do you think that your systems and processes would have allowed you to still come back? So I think the industry is solving more and more of this problem over time. Five years ago there weren't a lot of tools. Today we're heavy users of VCA, CV Cloud Automation Center. There weren't tools like that three or four or five years ago that you could pick up from a company as large as VMware with as much of an investment in where that's going. And so as an enterprise it was a lot harder to invest in the kinds of tools you could get. So I think the tooling has improved significantly and that's largely solving this ground to cloud, cloud to cloud, back to ground kind of problem. Well I think the tooling has improved significantly but what that tooling has enabled us to do is open up these services to our customers so they can consume them on demand. And our customers have consumed them on demand at a very, very rapid pace. So what we've enabled on the Vblock platform has sort of fostered innovation within those development teams and within the business community to increase speed to market and improve agility that wasn't ever capable before. Could you have done this without a Vblock or a converged infrastructure platform? I know. Not in the time we did it. We would not be able to focus on the additional value at services. You would have been doing a lot more non-differentiated heavy lifting. That's right. It doesn't provide business value. That's right. All right, we have to leave it there, guys. That's a great story. I wish we could go on, but I wish we could come back actually, we'd love to have you on again. Invite us back. Open invitation, this is a great story. We'd love to dig into it more. All right, keep it right there everybody. We'll be back, John Furrier and I with our next guest. We're live from EMC World and this is the queue.