It’s the latest episode of The Skytap Podcast! This week we’re joined by JP Morgenthal, CTO for Americas’ Digital Applications at CSC. Skytap’s Dan Jones and JP discuss solving the challenges of multi-cloud adoption, so listen now, download for later, or read the full transcript below!
Noel: I was on the Tech Evangelist Blog about a month ago and I noticed a piece that you had on there recently, JP, and it was called, “A Reality Check on “Everyone’s Moving Everything to The Cloud.” I really liked the piece a lot, and shared it with some other people here at Skytap; we’ll be sure and have a link to it for those listening to the podcast now where you can access it, because it really is an interesting article.
For those listening today, the piece was a recap of a discussion that JP had with a number of what he describes as “well-respected thought leaders in cloud, with significant experience guiding senior IT executives through transitions to modern architectures.” We talk a lot at Skytap about modernizing architectures, infrastructure, and applications as a whole, and this discussion that you had was focused on the future of “self-managed infrastructure.” What I wanted to do today is not further recap your recap, but to focus on a couple of the points that were made in the piece that I thought kind of deserved a deeper dive.
JP: Yeah, absolutely, there is a lot in there that deserves a deeper dive, in fact, one of the panelists said, “You should take each one of those things and write a whole blog on each one.”
Noel: I was just going to say the same thing! That could be done for every point that was brought up. You mentioned that your initial ask of the guests you had in this conversation was to get pros and cons from them for businesses to either continue investing in their own managed infrastructure, as well as some for the opposite end of the spectrum, doing things like moving their entire business to the cloud.
My first question to the both of you would be: I love the simplicity around the point that someone made of, “Look, IT is complex.” Moving everything to the cloud is not only extremely difficult, it’s often impossible or unnecessary. I’d love to your input as to how that complexity can impact business decisions and some steps you can do to overcome something that large.
JP: Sure, I’ll start. Cloud is such a game-changer. I believe that there’s a significant body of business individuals who have gotten their education on cloud through business publications, and through their own peer networks. It’s definitely triggered boardroom level conversations. There’s been an expectation among many executives, C-level groups and even between the CEO and the board. What is your cloud strategy? As if, if you don’t have one then you’re not doing what you need to do, and I think a lot of that was a belief that cloud was a less expensive way of running your business.
In fact, I wrote a different blog around operational costs. cloud computing, adopting a cloud computing model and the things that are associated with that. One thing that becomes of that is, I gave the example of ComEd, our local electric company here in Chicago. ComEd sends me these emails every week, or every month comparing me to my neighbors’ electric use. I’m always higher, but one of the things I noticed was that, in my area, there’s a broad spectrum of housing. There’s everything from a two-bedroom ranch up to what I had, which is the largest model, a four-bedroom. I called it “the anonymous neighbor problem.” I’m being compared to my anonymous neighbors.
Now, we do this in IT all the time. We have groups like ISG and such who go out and do analyses of different businesses and then put reports together and send them to CEOs. And in these reports it says “Well, you’re in the insurance business and you do life insurance and car insurance and your business does this much money a year, so based on that and your peers, you should be spending “x” amount on IT.
That’s a great scientific answer. “If they can do it for this amount, then you can do it for this amount.” But the artistic side of this, the creative side of this says, well, no. There’s a lot of pieces that go into the computation of what is the right price to pay for IT.
For example, I’ve been in business this long, I started doing IT thirty years ago. We went down this particular route. We’ve made these recommendations for new cap-ex spending that was rejected by the board five years ago. All these different things come into play that would end up limiting you from being able to meet that average IT spend. And then as I say in my own blog, if I were to try to meet the neighborhood average, I’d live like an Amish person.
That, to me, in a nutshell, is how IT is complex, right? You can’t apply this general anonymous neighbor problem to your own universe.
Dan: Yeah, you bring up the board of directors asking, “What’s your cloud strategy?” What I’ve seen is, it invokes a bit of bravado on the part of IT leadership, in which either the bravado swings one way, which is, “everything to the cloud,” or it swings the other way, “nothing to the cloud, we can do it all ourselves. We don’t need to rely on AWS or Azure or whoever,” instead of stepping back and looking at a balanced approach to it.
It’s sort of like saying, “My financial strategy is, I’m going to put all my money in mutual funds.” Well, which ones, and are they meeting your goals? Really, the question shouldn’t be, “What is your cloud strategy?” But, “What are the goals for IT to satisfy the business requirements?” And then, “What are the right tools or vehicles to satisfy those goals?” Take much more of a balanced approach to the whole problem.
JP: You raise a really interesting point, and I haven’t seen it discussed, oddly, in that way with regards to cloud: building a diversified portfolio. Why wouldn’t we consider this area of IT requiring a diversified portfolio? Why is extremism the only approach that’s acceptable?
Dan: That’s a great question, maybe you should pose that to your gang and see what they come back with!
JP: I will!
Don’t miss a single episode of The Skytap Podcast! Subscribe to the show on iTunes to be the first to know when new episodes are released!
Noel: Yeah, that bleeds into the next point that I had is that one of your guests, JP, brought up the following questions that some are asking today. “Do we have the internal resources to accomplish the move to the cloud, in order to not significantly disrupt ongoing operations and development? Can we justify having all of our eggs in one basket? And if we don’t put all of our eggs in an AWS or Azure basket, how do we safely, securely, and efficiently manage a multi-cloud portfolio?” I was hoping to get some insight from you both on what are some of those things that you do need to have when trying to manage a multi-cloud portfolio? How do you assess what you currently have, and what you need? How do you juggle the disruption that’s good and the disruption of ongoing systems and systems that are relied on heavily that you don’t want to be disrupted? It has to require a lot to manage that.
JP: Oh, it’s huge. And there are so many different angles to approach it from. For example, if I go to a public cloud like Amazon or Azure, I have a new way of dealing with operations that I need to take into account. Amazon will tell you, they’ll be the first to tell you, “If you really want to benefit from a move to Amazon, you want to leverage our services. If you’re not leveraging our services, and you’re just consuming virtual machines, you’re never going to get the benefits that you’re expecting out of this thing.” If I’m going to move to leveraging their services, I don’t have those same capabilities, those same services, and certainly not the same management interfaces in my own organization.
So now I have a choice. Do I implement and leverage my own homogeneous layer for management that I create, maybe from a company like a BMC, or an HP, or an IBM or somebody like that, made of tools that I can buy and I can use them everywhere—which is still hard to do, but at least it gives me a common footprint. Or do I start to try to figure out, how do I build a single pane of glass that integrates with each of the different platforms in their own native way?
So right from the get-go, you have this complex question that you need to respond to, which is, “How am I going to run this stuff?” And then you get into skills. At least if I spend the money, invest, create this homogeneous layer, I can use one set of people, and train them once. Otherwise, I have to have Amazon people, and Azure people, and Remedy people, and ServiceNow people, and it can really become quite expensive to have all this specialization. Specialization is difficult and expensive. Generalization is probably less expensive, but equally complex to build that on the initial form.
Dan: Yeah, I think the availability of a skilled workforce, there was a term used in your article, “skills gravity,” I really like that one. It’s not just having the skill set to be able to run on-premises, it’s like, nobody wants to run on-premises anymore so we can’t attract the right talent. So they think, “Okay, we’ll go to the cloud.” Well, guess what? Probably a very large percentage of your existing workforce have no clue how to run services applications up in AWS or Google, and get them configured correctly from a networking perspective, from a security perspective, from an availability and a DR perspective. That’s all really hard stuff, and the way you do it on one cloud vendor is completely different than the way you do it on the other cloud vendor.
That skills gap, you can’t use it just as an excuse to get out of your own data center, you have to be honest with yourself and say, “Do I have the right skills to move up to a cloud, and if I don’t, how am I going to attract that talent to my organization and retain them?”
JP: It is really difficult, too, to start with, and even identify and find the resources, and then to bring them on in a competitive way. I believe that group of individuals has a lot of choice in where they want to work today. Organizations that haven’t really prepared appropriately for that workforce, and are still looking to hire in the old fashioned way, and they force them through five levels of interviews, and they’re like, “Screw this, I can go to Joe Shmo and do one interview and get a job and not only that, I can probably make more money.”
The game is changing with this skills gap as well. You’re dealing with a supply/demand issue, and, for many businesses, they’re trying to address it with aged and inappropriate hiring methods.
Dan: Yeah, trust me, I lived through that prior to coming to Skytap and it was, “Hey, we’ll put a ping-pong table out there or a foosball table and we’ll be able to attract talent. Because we saw that startups are doing that or other successful IT shops are doing that, so if we do the same thing, we’ll get the same quality of people.” And the reality is, it’s a lot more nuanced than that.
JP: Have you seen that there’s a backlash now against that model and people telling Google, and Amazon, and all the other companies, “You’ve got it wrong.” Nobody wants the open workspace. It’s not flying after all these years, we need our “me” space, we need to be able to shut things off.
Dan: My favorite example of that is when you walk into an open office space setup and everybody has their headphones on and is focused on their monitor. And two people might start talking, and everybody turns to them and goes, “SHH.” Okay, we’re not in a library folks, we’re supposed to be collaborating.
JP: I was just in Copenhagen, and I’ll tell you a quick, funny story because, hey, these things should be entertaining, and not bore people to death. So I’m in Copenhagen, it’s warm. They don’t have air conditioning in the building. This is not unusual, but there were maybe eight people in a small conference room, and the only way to get the air flowing was to open the door and open the window. You did that, there was a nice breeze outside, you’re fine. But somebody kept coming and closing our door because they were sitting outside in an open workspace area and they’re getting pissed because the volume from our room is coming out. So they kept asking us to close the door and we’re dying in there and I’m just like, “screw this, this guy’s just going to have to live with it. Because it’s hot in here.”
It’s that age old battle, are we going to suffer in here so that that person can have quiet out there, or can that person go find somewhere else to work? But those are the types of things that occur in the real world, when you go to these open models.
Dan: I wanted to touch on one other thing you said, JP, about really benefiting from moving to the cloud. It’s not running straight VMs, it’s adopting their services, is where you’re really going to see the benefit. And I think that is absolutely 100% by design. All the vendors want to increase switching costs, so they want their services to be sticky. If it’s cheaper to bind to RDS services versus running SQL on bare-metal on a VM up in AWS, that’s what they want, because the switching cost to go from RDS to something else is going to be high, and it’s just going to prevent customers from doing that switch. It creates a bit of a lock-in effect. It’s good business, right? But the buyer needs to understand that when they’re making that decision.
JP: That could be mediated to some degree. I think it’s more of a volume/cost issue, so Amazon wants you to use their leveraged services because the more people that use them, the less expensive they can make them. It helps them to compete. If you have five people on the service, it costs you “x.” If you have ten, then you have a percentage. It’s going to cost you a percentage less to run. The more people using a leveraged service, the less expensive it becomes to offer.
From an Amazon or cloud service provider perspective, getting more people on their services allows them to be even more price competitive. I think that’s a bigger issue for them being a subscription-based service, then being sticky at this point. Because they’re making sub-pennies on a margin anyway, so it’s a volume game. And then, for the customer, using anything, anytime you’re using a leveraged service you should gain better economic advantage from using that leveraged service.
It’s good on both ends. The problem is, as you said, “How do I … It doesn’t come for free, I have to actively transform in order to be able to use those services and that’s an investment.”
And so then the question becomes, “Is this an investment I can take now? Is it one I’m ready for? Do I have the skills?” So all those questions start to come into play once you decide that the leveraged services are the right approach.
Dan: Right, and then, what is going to be your architectural pattern for adopting those services? Are you going to tightly bind to them? Are you going to loosely bind through some sort of shim that gives you choice down the road but that comes with a cost? There’s a lot of complexity here, and as I go around and talk to various IT shops and different levels in the organization, I don’t know that that level of complexity is deeply understood or internalized by the organization as they make us dance. “We’re moving everything to AWS. We’re going to rewrite everything and it’s all going to run up in the Cloud, and next year we’ll be in a better position.” It’s back to that bravado statement.
Noel: One of the things we talk about at Skytap is moving those things to the cloud first that are going to give you that kind of quick, initial return on that investment, things that aren’t going to take so long to realize that you may never actually get there. It’s kind of like you were saying early on, JP, as far as people saying, “Well, this guy moved everything over and he does what I do—I’ve got to do the same thing.” A lot of times, you can kind of move just the things over that makes sense, things that remove bottlenecks that can be quickly eliminated, and not things that are going to take an entire year to deliver results for you.
JP: Good stuff.
Noel: One last thing I wanted to touch on was that, in your piece here on your blog, there was a list of reasons that people gave when they look at this complexity and they see the difficulty it’s going to require to move to the cloud. There’s a list of reasons to stay put and to continue investing in their own infrastructure. Did any of those stand out as problems that have been around forever, ones you see the most often?
JP: Interestingly enough, I think one of the first ones that rises quite quickly is vendor licensing. I know somebody who was developing a great solution for migrating a customer to a new Amazon infrastructure from an existing managed infrastructure on bare-metal. The whole idea was the belief that they were going to just take the Windows 2003 servers and move them over, and they get to the end of the proposal and all of a sudden, somehow it got introduced that Microsoft won’t support the Windows 2003 on a new hardware—it’s end of life. They need to move or upgrade to a later server operating system. Then the issue comes, well that throws the whole thing out of the water. The whole idea was to lift and shift, and if I can’t do that to get started because of vendor licensing, then that’s a huge problem.
Dan: Yeah, I totally agree. There’s a lack of friendliness across the ISV space, the packaged software space. Getting things out of the data center and running elsewhere. Licensing rules are written for lawyers, they’re not written for IT developers or application developers, and there are a lot of nuances there.
I personally lived through “data gravity,” so I was glad to see that, and I would actually put it as right where it is, number one on the list. When I worked at a large retailer, we had hundreds of terabytes of data on-premises, and the majority of data was being born on-premises. So, systems running on-premises. You can’t necessarily pick that whole thing up and move it with zero downtime up to the cloud. So that was a real challenge of how do we make that transition and what systems go and that led to another one on the list which was significant integration requirements.
I was in an area around data warehousing, master data management, and BI analytics. Talking about data integration, and if you have systems running and some on-premises, some up in the cloud, etc. How do you handle the latency and the security and networking requirements when you’re dealing with large volumes of data? Those hit me near and dear to my heart of things that I lived through.
Noel: Well that is everything that I had for today, like I said, this could easily have been three or four hours long if we had hit every single one of these in your lists and like you mentioned earlier, JP, that this entire piece has got about fifty different potential blogs in here so as long as people keep having issues around this complexity, and other people like yourself and Skytap continue to write about them and help people overcome them, I think these will be conversations that are going to be around for a while, so, thank you both for participating today.
JP: My pleasure. I was surprised, there was a lot of readership on this, but there wasn’t a lot of forward conversation after the fact. Which is really interesting. I would have imagined that more practitioners would have stepped up and asked more questions. And it would be interesting to know what conversations this has spawned, but it would be also more interesting to have been asked “what’s behind this? What’s behind that?” Because, like we said, there isn’t a blog entry for each of these, and that was a bit surprising that it was published in a number of different areas and even talked about on another podcast, and there wasn’t a lot of follow-up conversations asking questions. So that leaves me to the question, “Where are people in this conversation in their own organizations?”
Noel: It’s like when you go to a conference, and you take in all of this incredible amount of information and you learn a lot of new ways to go about doing things you think will work really well in your organization. And you go back home, and all those notes just get filed away and you keep doing things the same…old…way. You don’t put any of that new stuff into play. Hopefully, that will change.
