 from the SiliconANGLE Media office in Boston, Massachusetts. It's theCUBE. Now, here's your host, Dave Vellante. Hi everybody, welcome to this special CUBE conversation with a practitioner, a real world enterprise journey to the cloud. I'm here with Jake Burns, who's the Vice President of the Cloud Services at Live Nation Entertainment in from LA. Jake, thanks for coming into our Marlboro studio. Appreciate you having me. I'm glad to be here. So tell me about your role. So I'm ahead of Cloud Services for Live Nation and what that means is me and my team are in charge of infrastructure for IT, including cloud infrastructure, as well as the move to the cloud, which we completed early 2017. Enterprise messaging, which includes e-corporate email, DNS database services and storage management. So recent journey, how did it start? Was it a top-down push? Did you go to management and say, hey, we got to do this? You described that. Yeah, so it started off as kind of a bottom-up push. For a number of years, I've been really wanting to get us involved in public cloud, at least in some level. But it really didn't hit critical mass until our CEO late 2015 had a mandate that we're going to move 100% to cloud and modernize all of IT. And that's when we really hit the ground running. Why did, from a bottom-up standpoint, why did you guys want to do that? Was it because the cloud's cool? That's where all the action is? The developers want to be there? Or was it something else? You know, we spent a lot of time managing infrastructure and data centers and it's just not part of our core business. We wanted to focus more on satisfying the business and providing value to the business. And our time could be better spent really helping solve their problems rather than deal with hardware and systems. You know, another thing is just business agility in general, you know, if we want to stand up a new system, the typical life cycle could be three to six months just to get an application up and running. With cloud, we can do that in days, you know, weeks, worst case. So being able to respond quickly to business needs is something that's really important to us and we saw with public cloud that we could do that a lot more efficiently. And when you think about the early cloud days, the rhetoric was all about agility. And actually, that really was the main business benefit. You guys, of course, saved a lot of money too and want to get into that, but how did you get started? It must have been kind of a little nervous like the first time you jumped off a high cliff or something, right? Because you have an existing business to run and yet you're going to migrate, everything migrates like this evil word. So how did you get started? Yeah, so for us, we realized very early on that this was a big technology change for us and it was going to require new skills that we didn't have. So the first thing we did was we really just got training across the board. We brought trainers from AWS to our offices and we did every training program that they offered, got the certifications and made sure that we really understood what we were dealing with before we got started. So that was really step number one. And how did that go? They were really supportive. I mean, everybody says AWS really not, you know, hands-on, they just sent me an email. How did that go? In the beginning, there's resistance, you know, just like all projects like this, people are concerned they're going to lose their jobs. Resistance from your guys? Oh yeah, yeah. Not the AWS people, they were. Oh, of course, right. No, no, our guys, you know, before they really understand the situation, it looks like we're being outsourced, right? We're moving all of our infrastructure. This is our job. We're managing hardware, we're managing servers, we're managing data centers and all that stuff's going to go away. So what are we going to do, right? So really, even before the training, the priority for me was to get people to understand that this is not something that's a danger for your career. Quite the contrary, this is going to make you more valuable. You know, you're going to get trained on this technology. You're going to get real world experience, moving Fortune 500 company to the cloud. And at the end of this, somebody's going to need to maintain it. So not only will you have job security, but you're probably not going to care about job security at the end of this, because you're going to be so valuable in the marketplace. So we're all in sales, aren't we? So you had to sell them a little bit on the concept, but then they responded positively, it sounds like. Yeah, and part of that is because it's the truth. You know, I was telling them the truth, so it was an easy sell. But it's a very important component of any cloud migration project like this. If you don't have support from your people, it's not going to succeed. Okay, so you get through the training, your guys are on board, you have alignment there. And then take us through, so the journey, how long did it take? What were some of the challenges that you faced? Yeah, so the target was 12 months to move everything. And we're talking about 668 servers, 118 applications, including Oracle, SAP, some really things that are not trivial to move to the cloud. We were able to move 90% of everything in 12 months. And then the long tail took an additional five months, so 17 months in total to move everything. And that long tail, was that the Oracle app? Yeah, so our strategy was to move the easy stuff first as we learned, because we learned along the way. We really didn't know what we were doing when we started. By the end of the project, we knew exactly how to do the project, right? Easy stuff like messaging? Like single server applications that are running supported software, where we have a business stakeholder that's cooperative and... Web stuff? Yeah, like internal stuff, like our monitoring systems, things that we completely control. Things that were under the control of IT didn't involve a lot of politics. Exactly. Learn there. Okay. So the idea was get real world experience moving live production systems on the easy stuff, and it builds up our skill set. But at the same time, it builds forward momentum, which is critical for a project like this. There's a lot of people that are just waiting for the first failure to put a stop to the whole thing. And there's a lot of skepticism as to whether this can even be accomplished or not. So getting, I truly believe a key component for a project like this is to get momentum on your side early on. And the way you do that is by attacking the easy problems first, and then get progressively more difficult as you go along. And so at the end, you end up with the most difficult applications to move. But at that point, you have full buy-in from everyone because you've been successful so far, and you and your team are practiced and accomplished and have the skill sets necessary through moving all the more easy stuff before that. Okay, and just a quick aside, I have to ask. So Oracle's kind of using licensing as a weapon, especially in this, I call it urinary Olympics, sorry, with Oracle and AWS. You may not have visibility on it if you don't, we can move on, but was that a concern? Absolutely, yeah. So this is a major problem that we've had to deal with. And Oracle doesn't make it easy. They don't necessarily want their customers moving to AWS. So that was part of the challenge. Part of the challenge was how do we move this without having to pay more in licensing? And what it really comes down to is you have to make your Oracle databases run more efficiently in AWS in order to lower the core count, which is what the licensing is based on in order to keep your costs neutral because Oracle will charge you double for your database per processor in the cloud in AWS than it will on-prem. So really the only way around that besides negotiating with Oracle, if you're able to do that, if you're not able to do that, then your only option is to make it run twice as efficiently from a processor standpoint. Thank you for sharing that with our audience. We've written a lot about ways to reduce your core count, ways to make IO optimized. And if you can do that, you can actually save a lot of money. Maybe we'll have you back on at re-invent. We can talk more about that. But so back to your story here, you've got a huge budget to do this, right? Big pile of big bag of money to go move to AWS? Unfortunately, we didn't have that luxury. So we run very lean. And so we had essentially a flat budget 2016 when we did the majority of these moves. So we just had to find a way to do it without spending money. And so it was a bit of a juggling act. We were decommissioning systems in the data center and canceling support contracts. So we were able to kind of use some of that money and repurpose some of that money for moving to AWS. But we really didn't have a budget for hiring consultants or to buy expensive software or anything like that. So what we had to do was basically become the consultants to do the cloud migration. And so that's where that training comes into play. So by training the team and getting them up to speed and essentially creating cloud engineers, we were able to be internal consultants to the business, perform the move internally at a very low cost. All within that sort of 12 slash 17 month timeframe, we were able to affect that skills transition. Right. So we were simultaneously maintaining the old infrastructure, moving the infrastructure to AWS and maintaining the infrastructure in AWS. So there were a lot of long hours. I bet. Next weekends. We were enthusiastic about doing it. Everyone was very excited once we got going. And so people were willing to do it. You talked about the people challenges. I think we've addressed that a little bit anyway. What were some of the other challenges? I mean, you got, you know, big app, reasonably sized application portfolio. You got data. You got, you know, your backup systems. What were some of the challenges that you faced and how did you address them? Yes, that's a great question. You know, one thing that people don't realize is that AWS isn't necessarily designed for enterprise applications. You know, it's getting a lot better, but there are some things where it just doesn't fit automatically. So one area where that's especially true is with storage. AWS has fantastic storage offering, especially with S3, their object storage. But unfortunately, most enterprise applications, they can't utilize legacy enterprise applications, won't utilize object storage, they want block storage. They don't want get put, they want block storage. Yeah, exactly. And then the block storage in AWS is different than the block storage than what you're used to in the data center, typically. So kind of allowing these applications like Oracle to work on AWS' block storage can be a challenge. It can be expensive and there can be some risk there just because of the way that it works. So this is where using a third party makes sense. This is one of the rare circumstances where I think using a third party makes sense. We found a company called Actifio that does virtual storage in AWS. And one of the great things about this product is it essentially mimics the way that the old storage worked in our old environment and our data center. So the application will continue to function. So we're able to take snapshots, we're able to clone environments, we're able to do all of these things that we are not able to do in AWS natively with the Actifio product. And it saved us a lot of money and allowed us to avoid a lot of having to change our workflows to get around some of the delays with doing snapshots and stuff natively. And is your strategy to have this sort of hybrid approach between on-prem and public cloud or multiple public clouds? Is that part of the strategy and how does this capability fit into that? Yeah, so great question. Our initial strategy was 100% go in all in with AWS and officially that's still our strategy. I am a proponent of multi-cloud in certain circumstances. For example, disaster recovery and backups, I think it makes sense if you're 100% in the cloud to have a second cloud provider to hold your backup data just so you don't have everything in one place. I think for the same reason hybrid cloud makes a lot of sense. And I think also hybrid cloud makes a lot of sense just because not all applications are a good fit for public cloud. And Oracle SAP would be two of those examples. Now we were forced to move everything to AWS and it was a fun challenge and we were able to accomplish that. But doing it over again, if we had the option of doing hybrid cloud, there may be a couple applications that I would say keep it on-prem because it just works better that way. And you double-click on the storage virtualization capability that you talked about. Kind of how does that work? And are there any kind of things that you had to do to prepare for that? Any sort of out-of-scope expectations that customers should be aware of? With Actifio, it's a pretty turnkey solution. So there's a little bit of a learning curve, but there's a learning curve with using AWS native tools as well. So I would say probably less of a learning curve if you use a product like Actifio because it's more familiar to the people that are already working on these systems. So if you have existing staff and they're used to doing things in the data center and they're used to doing things with traditional enterprise storage, the Actifio tool is gonna look a bit more familiar than the AWS tools. So there's a learning curve either way, and but I would say look at a product like Actifio if you're an enterprise trying to do this. So what was the business impact of using Actifio? I don't want to ask you about the whole move to AWS. Did it speed the time to deployment for AWS? Did it help you cut costs? What was the business impact? Unfortunately, we didn't become aware of this product until after we had moved. So we're in the process now of replacing some of our storage devices with virtual storage with Actifio, but I wish we had found this product sooner. I advise anyone who's new at this, anyone who's doing a migration to leverage something like this to actually move their data because it's a much more efficient way to do it. So if I could go back in time, I would do that. What would have been the business impact? Is this time and money? Yeah, time and money for sure. So the moving of the data is one of the biggest challenges that you're gonna have moving to cloud. We had a petabyte of data that we had to move and that's no small task to get that moved in 12 months. So any tool that you can use that can make that more efficient is going to shorten the amount of time you're gonna be doing the migration and consequently shorten the amount of money that you spend doing the migration. Also, it would have saved us a lot of time because now we're going back and having to change things and put things under Actifio. If we would have done it like that to begin with, we wouldn't have to spend that effort after the fact. Why does Actifio make it more efficient? Is it data reduction? Is it automation? So essentially, the biggest benefit is that it allows you to not have duplicates of your data. So if you have a dozen or so copies of your database for different types of environments, test, UIT, Dev, et cetera, and you're duplicating those and storing each one of those separately, you're gonna pay for each one of those separately, you have to manage each one of those separately. If you're able to use virtual storage, then you really have one copy of the data or however many copies of data you really need to be protected and the rest of those can be virtual copies and those don't cost you anything from a storage point of view. The other benefit is if you want to clone an environment or copy an environment or take a snapshot of an environment, it can happen instantaneously rather than wait for the hours or days that it would take to copy a large dataset. So it becomes the single point of control with the catalog and the visibility over all your data and your copies and all your management, is that correct? Yeah, and the management becomes a lot easier because you have a software that's keeping track of your snapshots and keeping track of all your copies of data rather than try to track that all manually. Okay, let's bring it back to the big AWS picture. So you move to the cloud, what was the business impact of that? You mean you mentioned agility, did you save money? You know, how much, give us some visibility on that. Yeah, so because we're so conscious, saving money was a priority. I don't think it's necessarily something to expect, especially initially if you're an enterprise moving to the cloud, cost shouldn't be the driver, agility should be the driver. But in our case, we were able to achieve 18% reduction in TCO on year one. And that's just because we were just very focused on cost. We're very cost sensitive and it's very important for us to be efficient and to not spend money unnecessarily. I know that's a priority for everyone, but it's a top priority for us. And so my point is it can be done. You can move to the cloud, you can move 100% to public cloud if you're an enterprise and you could make it cost neutral or even favorable, it is possible. So you hear a lot of stuff in the press about how the cloud is very expensive, you could actually do it cheaper on-prem based on your experience, you don't buy that. Well, I wouldn't say that's false. You can, in a lot of circumstances, do it cheaper on-prem. It really depends on the workload. So I mentioned earlier that I think hybrid is probably the right approach for most people. So just because we're saving money by going 100% cloud doesn't mean we wouldn't save more money if we went hybrid cloud and put the more expensive things that are to run on-prem. So because it's paid for what you use, the things that you very heavily utilize, those are good candidates to keep on-prem. The things that are more bursty, those are the things that are better candidates to put in the cloud. The easiest candidates to put in the cloud are disaster recovery and backups, those are no-brainers. DR because that's only something you need to scale up when you use it. So anything that you need to scale up when you use it or anything that scales up and down, those are the best candidates for cloud. Okay, now I understand you're kind of an expert at cutting the AWS utility bill. Maybe you could give us some advice on how to do that and how'd you learn how to do that? Yeah, so that's kind of my area of focus now is now that we're in the cloud, getting those costs reduced as much as possible. So there's a lot of ways to do this, but I like to keep it simple and attack the things that have the biggest impact first. So people like fancy solutions, but it's really simple. The biggest thing you can do is delete things you're not using. You're paying for consumption, so find things that are not being used and simply delete them. After that, then find things that are oversized and right size them. And then another big thing is, in the cloud, you have such an easy access to spin things up, to take snapshots of data, to copy data, and it's a classic problem in IT where everyone requests what they want and they never tell you when they're done with it. So it needs to be a full-time effort to be actively looking for resources that are unused, snapshots that are no longer needed, volumes that are no longer needed, instances that are no longer needed, and be cleaning those things up on a continuous basis. I find that that's a large percentage of what my team does now, and that's one of the things that keeps our costs in mind. That's interesting. I mean, we always talk here about GRS getting rid of stuff. Not only did you get rid of a bunch of stuff when you moved into the cloud, you said 600 servers, you got rid of unused capacity, you got rid of a bunch of data which must have made your general counsel happy, but you're now actively continuing to get rid of stuff. Like you said, it's volumes, it snaps, it's other things now that you're in the cloud, that's GRS mentality is sort of ingrained. It has to be. I think that anyone who's in the cloud for some time is going to realize this, you're going to have inflation of costs simply by doing nothing. So just to keep your costs neutral, you're going to have to be deleting things on a continuous basis. Now if you want your costs to go down, that's even more difficult. You have to be more aggressive with it, but just as it's easier to spin things up in the cloud, the good news is it's easier to keep track of what you have and find things that can be deleted in the cloud because you don't have to go in the data center and track things down. You know, everything is virtual, it's all can be automated, it's all done, it can be scripted. So everything's easier, spinning things up is easier, cleaning things up is easier. You just have to make it a priority and make sure it gets done. So some of the financial people in our audience might be listening to this and yeah, you know, okay, year one, roughly 20% savings, it's not that exciting. But we haven't quantified the sort of other business impacts in terms of agility and that's a harder thing to quantify, but it's early days for you still. Do you expect like to get on that S curve and really start to see a major business impact beyond that 17, 18%? That's a great question, you know, that 18% reduction in TCO, that's just infrastructure costs. So that's not taken into account, you know, things like how long does it take for us to spin up an application and what does that cost the business, that delay, we're not taking that into account. How about the opportunity cost of, you know, we wanna try something, but it's too expensive because we gotta buy servers and we gotta hire people to build the application and install the operating system, all that kind of stuff, you know, those opportunity costs, they're not captured either. Now we can try as many things as we want, very inexpensively and only keep the things that work. So I think there's a lot of hidden cost savings, a lot of hidden value that's very difficult to capture, but we certainly have those benefits. Even if we're not articulating it and counting it very well, the business feels it and you know, it's certainly a superior level of service. That's kind of like when we first got email, you know. Nobody really quantified about the productivity impact was in other words the first, you know, local area network that you ever installed and the collaboration that brought, it's one of those things that's, it's probably telephone numbers, but it's hard to quantify, right? Do you, you said the business people see it, do the finance people see it as well and are they supportive of this? Yeah, it takes a while I think for the non-technical teams to catch up and really get to where at in terms of understanding of what we're dealing with at this point. So they're starting to see it, but you know, all the financial models have to change, all the budgeting needs to change. There's a lot of things that beyond IT, this kind of transformation affects and those processes have to change and those processes generally change more slowly, so procurement needs to change, finance needs to change, security needs to change. Everything's really, it's a new world and once they catch up and kind of really grasp what we're dealing with, I think the whole business is gonna be transformed. So two last questions. You talked about maybe things you do differently, maybe some advice, but let's focus clearly on advice to your colleagues that are trying to do something similar, get to the cloud, what would you tell them? Invest in your people. Focus on cost savings, day one, don't look at doing that after the fact. And don't get too caught up in all the fancy methodologies and fancy tools, everybody's gonna try to sell you something, everybody's going to try to tell you they have the best way to do it, but in general, those things are just gonna add complexity to your project. I say keep it simple, keep it lean, leverage your own people because at the end of the day, somebody's gonna have to support this environment as well and if you're relying too much on outside help, then they're not gonna be there when it's all said and done. So consider the end game, consider the end state and how you're gonna support that because it's one thing to be successful migrating to the cloud but then you have a whole new set of challenges after that. You're gonna have to live with that moving forward and I'm not saying it's a bad thing, it's a great thing but it's something different and you're gonna have to be prepared for that. Own it. Own it. Okay and then last question is sort of what's next for you guys? You're just sort of getting started here, you've made a tremendous amount of progress in a year and a half. What's next, where you want to take this thing? Yeah, so like I said, right now we're really focused on cost optimization. I think that like you alluded to earlier, the cloud could be very expensive. The range of how much you can cost is amazing, right? So this is uncharted territory. We don't know how expensive it should be, how cheap it should be. We just know that we can affect that to a large degree. So I'm interested in seeing how, to what degree we can affect that and I want to see how efficient we can make this. 18% favorable TCO is one thing. Let's see if we can get 30% or 40%. So really I'm focused on optimizing for cost, security, which is a whole new world in the cloud and going from there. Mike, Jake Burns, awesome having you on. Thanks very much for your insights. Really appreciate your time and thank you for watching everybody. This is Dave Vellante. We'll see you next time.