Today's leading minds talk Cloud with host David Linthicum
JP Morgenthal is chief technology officer, Application Services, for DXC Technology, an internationally renowned thought leader in IT transformation, modernization and cloud computing, His areas of expertise include strategy, architecture, application development, infrastructure and operations, cloud computing, DevOps, microservices, internet of things (IoT) and integration. JP routinely advises C-level executives on the best ways to use technology to derive business value. He is a published author or coauthor of “Delight customers with better digital application experiences” and four trade publications, including “Cloud Computing: Assessing the Risks.”
David Linthicum: Hey guys welcome to the GigaOm.com Voices in the Cloud podcast. This is the one place where you can hear from industry thought leaders who will provide ‘no nonsense’ advice on how to succeed with cloud computing, IOT edge computing, and cognitive computing. JP, so how are you doing?
JP Morgenthal: I'm doing well. Thanks for having me… inaugural show, I'm excited.
Yeah. Episode number one, looking forward to this. Looking forward to getting back into the podcasting stuff, especially in the objective kind of analyst area. So anyway JP Morganthal is a globally recognized industry thought leader, representing the leading edge of emerging technology, sharing his knowledge through blogs, articles, books and public speaking.
He looks at technological waves and has been recognized as a thought leader, including micro-services, DevOps, service management, cloud computing, so… XML, Java and distributed opposite computing. And [he] was involved in the formation of many industry participation organizations such as X-ACT, the integration consortium, and Oasis. So what did I miss? Fill in the blanks… specifically where you're working now. By the way JP and I are longtime friends. We've known each other since the ‘60s, met at Woodstock.
Just managed this friendship ever since. So what have you been doing since then JP?
Fair enough. Well, for just about four years now I've been with what was CSC, merged with the HP Enterprise Services to become DXC last year. Coming up on Year 2 with the DXC, I'm in the office of the CTO and I am the CTO for our application services offering family and also a distinguished technologist.
Distinguished. Wow, I love that. So what does that mean? Does that mean that you're better than a technologist?
Means that I made ‘Fellow’.
I never got fellow. I know IBM has fellows. I thought was that there was going to funny, like a you're rather a fellow there. Well, I guess it's kind of an academic kind of relation to that because they'd been doing that for since a long time. So kind of tell us what you've been doing as far as books and speaking and some of the thought leadership stuff. I've met J.P… we didn't meet at Woodstock by the way. I think you figured that one.
I think they got that.
Yeah but we did meet speaking in conferences. And JP’s an outstanding speaker and he knows his stuff. And I always refer to him as… if someone was looking for someone who had expertise in the SOA space and the integration space things like that. You know he and I were in essence running in the same circles. So what have you been doing lately?
Really working on a lot of this digital technology, digital transformation efforts. Looking at how to help companies to move to the next level with a lot of this emerging tech. I actually wrote a piece which was a blog entry put on GigaOm. And you know it basically addressed the multitude of emerging techs that are coming at the same time.
You have IoT, blockchain, cloud containers. And in this amalgam of technologies that are coming out and and really how is the enterprise except expecting to be able to adopt all of this stuff? I mean I find it really interesting. You know some really useful stories coming out about adoption of this stuff. But at the end of the day, I can't believe that executives in IT aren't overwhelmed in consideration of all this new stuff. I mean, they just you have a low level of maturity behind it. Right? Which to me says that you know I was on a podcast just last week at Dynatrace Perform, and you know it's like, ‘I'll take somebody who has eight years of Kubernetes on there. You know, can you give me somebody with eight years Kubernetes?’ Sure. We might need a time machine and teach people back then what Kubernetes was.
Maybe somebody at Google who's in a lab might have it, but this is what they want, right? So this kind of thinking that this technology has been around in a production level manner for more than two or three years is a concern for me especially as I see companies really talking about all that they're doing with it. So it's for me, it's a real interesting proposal as to… somebody is cooking this stuff up really. And then you have on the other side the traditional ops organizations in IT for many of these enterprises. And really what did they think about this? You know the guys in the NOC, in the SOCs sitting there watching screens, doing tickets you know. What are they thinking about all this stuff that's coming down the pipe that's being integrated into the new application domain? It’s just such an interesting time.
Yeah. It's a shiny object syndrome. So in other words we've been going through this. I use to call it ‘manage by magazine’ and we read magazines and…
I still use that.
Yeah. Well, the I thing is…
Of course I credit you… but, I still use that.
The thing is it's kind of there's there's a big divergence with the attitudes of Silicon Valley and how they look at technology. They want to adopt anything that comes down the road. And so now it's Kubernetes and containers and serverless computing, and cognitive computing and things I write and speak about because people are interested in reading about it and hearing about it, even talking on podcast about it.
But the thing is if you deal with most of the global 2000 companies out there, they can't move that fast. Their IT budget is 1% of their revenues. And so they can only move in terms of a digital transformation as the money lets the move, and the resources let the move. And even though they would like to chase every shiny object, there's desire to make that happen. It doesn't really make sense that they do that.
The thing is I think it's okay to be a devil's advocate and look at second guessing some of the technology that's coming down the road, just to make sure that it's right for you—and that there's a true value in moving that direction. There's such a knee jerk reaction to in essence follow the stars, follow with the brightest object is in the space, and then I think people are going to start making mistakes and they're going to make mistakes with many zeros on the end. What do you think?
I think you're right on target. You actually have an article out there about how expensive now the cloud computing starting to show up, right? At the end of the day. And you know this is this it is the driving factor behind operational realization and industrialization of this that really hasn't been accounted for. I think we're past some of these technologies’ proof of concept. And you know looking at ‘How do I really formalize this in an operational setting?’ And that's what people don't consider. Right?
I mean you have a small group out there of technical elitists who can talk about things like no ops, right, where no ops is the developers responsible for whatever code they put into production and they can push whatever they want to production. And companies like Netflix can say, “Oh look how cool we are.” Don't you want to come work for us if you're a techie because this is the domain and the culture you want to live in. But I don't know many banks, insurance companies, even hospitals who would dare to expose [themselves] to the upside risk from that kind of activity.
And so I think you end up in this conundrum of everything that's being demonstrated to the field looks, not only shiny, but that is easy and it should cost nothing to run. And I think this is an invalid perception. I think it's a dangerous perception that's being set by these tech companies. And like you said, there needs to be a pragmatic template for an industry to say “You're in insurance. Stop looking at Netflix. Look at this template that says this is the way it should work in an environment where you have risk management equal to this level of scale. And these are the things that you need. This is the benefits of these technologies that you can expect to achieve and these are the risks in it assuming them. And know your operational costs aren't going to be the same as a company who hires a developer who's willing to also be on pager duty. It just you know, I don't see it. I don't see the equating. I don't see people looking at it logically. I see them as you said, chasing the shiny object saying, “Oh I've got to have one of those.”
And the other side of it is and I'm really interested in your take on this day because I know you've looked at this over the years and watched it the same as I have. Really. Shouldn't we have moved further down the chain, the train down the tracks on using low code environments to get to our business outcomes? If everything's about business process and logic and driving new business processes, shouldn't we have moved further on the spectrum towards low code easy to develop—having business analysts actually producing and designing processes visually, than elitists still picking our platforms for us?
Yeah. I mean when I got into college I was told COBOL was developed for the business executives for them to program things so developers weren't going to be needed anymore and therefore [you should] find another occupation. So we go through all this stuff all the time, and what's happened is is that ultimately we're just ADD when it comes to technology and we can't get the low code until we get to kind of a fundamental level setting as to what the technology is: common database technology, common coding technology, process integration technology.
We shift everything all the time and so as we do this, we make things more complex and we just kind of dig ourselves deeper in the hole. One of the things that kind of struck me… I've been focusing on cloud complexity. In other words, the complexity is being brought into the enterprises, which is kind of what we're talking about here by the use of cloud and also the use of all the things a cloud is able to bring. And the cool thing is I'm able to fire up any different technologies I need to fire up. I can fire up a database in cognitive computing and Kubernetes and all the cool stuff which is the price of a credit card in a few minutes. But ultimately if I'm operating that, how do we operate these very complex environments?
I'm dealing with multi cloud. I may have you know 600 endpoints on an AWS, it'd be less than 500 endpoints out on Google, and a 700 endpoints out on something else and then going forward I have to manage those endpoints and have to operate them I have to secure them, I have to govern them and that's really not thought out. And so what we're doing is we're getting this in this complexity corner. I mean this goes to your point. We're not only not doing low code kind of stuff, but we're doing too much code and too many technologies being brought into production.
And we're asking the operations guy who's by the way who are not getting any more money to go ahead and figure out how to make this happen. And we have you know lots of different ways to deal with the cloud management platforms, cloud services brokers. That technology isn't really cooked enough to really make the kind of progress that we need to make. So my concern is we're going to hit a tipping point sometime in 2020-2021—where just the amount of operational complexity is going to be so high that a lot of these things are just going to tip over. What are your thoughts on that?
I think you're right. I see it heading in that direction. It could come out from the cloud. I know it definitely will come out around all this work around micro-services and APIs. I've seen companies with 2500 to 6,000 APIs already developed internally for their applications.They may think it's manageable. I don't see how that's manageable. Managing not only the consumption of them and the maintenance of that, but the the traffic to them—how they're connected up, what are the dependencies that are being formed, what, who was consuming them and how and why are they being consumed, right?
I mean this is some really complex event based architectures and you and I know it's an event based architectures that have not gone over well in IT over the years, right? We've seen them attempted to be used for some of the most complex processing around derivatives, financials and securities industry and even they, with hundreds of thousands of dollars to throw at an employee, have backed off large scale event architectures because they're just too complex to really maintain and run at scale.
And so yes, you add in the cloud, you add in how many services does Amazon have now? Ninety five. Ninety five services. Do you know that or is there any one person or group of people that can actually govern and operate the you know 50% of those services in use? I mean it's only just you know for Amazon the fact that somebody is using a service, right? They've done the right thing but in doing so made it more complex. They've integrated their access management. Their ability to limit or manage security around these services and such—they've enhanced it in such a way that you have to now know how to tie these things together and give rights between services in order to have them connect. And so yeah, a certain amount of that is expected to happen by the developer, but that's going to be managed in operations. And how does that all come across? Some people say ‘oh DevOps.’ That's answered everything by the way. The answer to everything is DevOps.
And I keep reminding people DevOps isn't magic. Somebody has got to do the hard work of putting together an automation script, testing that script, making sure that it works and staging and pre-prod, making sure that it when it goes into production that it executes as planned. And so it actually is an additional overhead on the entire QA cycle. It all shifting left will the whole complexity shift left too. And then yes, I've seen success. People have great stories out there and I've seen wonderful things occur. But I just don't think it's really hit scale. And I think right now what we're looking at are small bites of opportunity of what it could be, glimpses of what it could be. But you take that and you try to deploy that and make your entire operation enterprise run that way. I don't know that where we've seen that at a scale other than maybe a technology driven company.
Yeah. I couldn't agree more, and I think that we have to kind of relay to the audience that we can succeed with this technology. This does not mean that it's unfathomable, in how we are able to take this stuff forward . And what we're saying is that typical companies have limitations in what they can spend and also limitations on the talent of the people who work in IT. And we can't spend half a billion dollars on an IT budget that was $100M last year. Ultimately this has to scale up at an incremental scale. And even though there may be some diminished operational costs and we may be eeking out in the next couple, two or three years, but we're just ultimately not thinking about how these things are going to be operated. I mean well you said 95 services. I mean it's even worse than that because if you take each one of those services, you decompose them to the sub services of the APIs that are part of those services, we can have 10,000 things that we're managing in an instance of those things that we're managing. And this doesn't mean that we shouldn't do it. This just means we have to think about how we're controlling that stuff and put some architectural forethought into how we're building these systems.
And so I don't want to get this like ‘we're down on tech on cloud technology.’ But ultimately you have to cull your enthusiasm with your ability to use this stuff effectively just like any other technology, use of computers, rise of the Internet every kind of technological shift you went through.
In all fairness when cloud first came out, I saw that there were many organizations that were addressing the absorption and the adoption of cloud in a very governed way. You had the CISO involved. You had the head of IT infrastructure involved. There were rules. There was a thought process about: how would be how would you go to the public cloud, how are we going to handle accounts, how are we going to handle you know the the rights and roles within that. And they all got hit deep for moving too slow.
And I think some of that actually unfortunately dissipated because of that pressure to, ‘hey we had to do cloud now, we got to cloud now, you’re moving too slow.’ And so I think that's impacted and probably dissuaded some of these same people from taking the same approach with these other technologies. But it's the right thing to do—it’s sit back, say, ‘All right here's a new technology, we're bringing it into our company. What does it mean for us? What does it mean for the developers? What does it mean for the quality assurance testing organizations? What does it mean for operations? And who's supposed to have the rights within these environment to make changes and do things? And if you're not going to think that out in advance and you're just going to take the ‘hey let's just dive into the pool’ [approach], well we all know what the outcome of that is likely to head towards.
So the message here is we're not saying don't do cloud. We're saying, do cloud in a methodical way with some forethought and planning and therefore do it right.
So how do you do it right?
Exactly as I was saying. I like thinking through architecture. Our architects have taken on a bad name of recent. It seems like nobody wants to design anything anymore. Everything is ‘let's just jump in the pool and figure it out as we go.’ That's Agile, right? But in this Agile world, we seem to have left out the desire to have a big picture, a map of where you're going. So now remember those games (people who are our age remember these games when you were younger) I think there was one on Atari. It's like a maze. But you figure out the room as you bump into things and go through it. It's dark until you actually go to a spot, and then it uncovers it. Well that's how we're doing adoption of some of these technologies is. We we're just going into the room and and going down a particular path until we hit a wall and then backtracking and saying “oh that's a wall so I'll go the other route.” And we don't have the big picture. We don't.
We've sacrificed the enterprise architecture, the understanding of how everything is supposed to interrelate and relate back to the business processes as a way of guiding us. And I think that both are needed. I think you need the balance. I like the thought of Agile. I like the Agile approach of ‘here's something we are thinking about… well let's instead of just spending weeks thinking about it, let's just put something together and see how that what that looks like. That's a great thing! Because you get feedback. You spent that same two weeks that you would have thought about it, now sharing and collaborating about it. Okay.
But that's not the way you are supposed to build your whole business. Yeah, that's not the way you would financially design it. Let's just start selling stuff, see if it works. You're gonna do focus groups. You're going to do product design. You're going to put together MRDs and TRDs and you're going to know how to produce that. You're going to get your sourcing right. That's how you build and bring a product to market. So there’s planning and some of that seems to be getting lost now with regard to the digital application realm because I guess you can, you can't sacrifice that thinking.
You do realize we sound like a couple of grumpy old men.
Oh, yeah, probably do. Well you know what? I don't. I hate to agree with you that because it just sounds horrible the way you say it, but we're we're trying to help give wisdom, right? Old men also bring wisdom.
Well I think.
Young kids never listen to it. So it doesn't really matter.
Well, the thing is there's no extremes here and that's what you're saying. I think I used it when I went into the CTO days and I ran product development. You know I used to say “We're all for Agile.” We didn't have DevOps around then. “We're definitely moving to automate Agile,” I said, “but we can't be a technological drum circle.” Instead ultimately there needs to be some vision. People need to be moving toward a common goal. Now if you want to do then an iterative way and do that in a continuously improved way, that's fine. But ultimately, we have to be building the same things.
The idea that people are going off and building things that really don't live up to the expectations of the product is sometimes where Agile falls down. I think most people who are you know SCRUM masters and Agile leaders they kind of understand that. That's where they're SCRUMing up in the morning and getting everybody moving in the same direction. But I think we've kind of ‘jumped the shark’ a bit in terms of our thinking and the ability to in essence move forward with the technology in an orderly way, which is we're able to get it so quickly we can get that satisfaction right away. We're able to allocate these these cloud provisioning things, so it's very easy for these folks to build things as they need it, and once it’s built and we have applications on it, it's very difficult to tear them down. But guess what? Someone has to operate it.
Exactly. And that's really what it all comes down to is themethodical approach in the beginning is really about helping the people at the end to run it in a secure, highly available way. And you need to build in those non functional requirements.
So that goes to a survey I blogged about today out on InfoWorld and it's my my blog. So a survey of 100 decision makers and companies with 500 more employees conducted by NetEnrich found that 85% claimed either moderate or extensive production and use of cloud infrastructure, which isn't surprising. I think I've been claiming that as well. But the trouble in paradise is the survey also finds a top cloud provider, computing issues around security 68%, followed by IT spend and cost overruns 59%, day to day maintenance 36%, and root cause analysis and post mortems 22%, and also 48% claim that their IT organization is finding that the cost of recruiting cloud professionals to solve these problems is an ongoing issue. So it's kind of what we're talking about.
I think we're finding out is that cloud computing seems suddenly hard and expensive, what's the name of the blog. But the reality is I think we you know we oversold cloud computing as an industry. I don't think even I did. I think we were the designated curmudgeons back in 2006, 2007 when clouds started to rise.
But because we're not putting I think the necessary planning in this, we're not necessarily thinking about how the technology needs to live and breathe within the organization. We're getting a bit of kind of a hangover going forward. It's not that bad by the way versus other hangovers we had in the past. But you know ultimately there's a bit of a downside to cloud computing. It's more expensive. Typically Agile is going to… agility is going to be the core benefit of it. It's not going to be ops savings in many instances.
We need to hire people that are very expensive and very very hard to find now, there to make these things happen. And yet our boards of directors who are now all in on the cloud where they weren't five years ago, are screaming to get IT moving forward. So how do they survive this?
That's the holy grail. That's the million dollar question, and resources are a very large problem. You know, case in point: look at Apple and Google have backed off from requiring college educations as a as a prerequisite for hiring. There are plenty people that are self-taught. But the fact that they're willing to recognize it, I think is an indicator of the market itself—in saying that maybe there aren't enough people who are going through college programs to satisfy this demand. So there is a huge demand that is greater than supply, is certainly greater than supply of people who are learning it in college more than that.
The college education programs haven't kept up. If the kids coming out of college and it's a horrible time. I can't believe I just said ‘kids.’ The people, the adults coming out of college and going through these programs are not getting… they're not coming out prepared to just start work the next day. It's not Day One for them. There is additional training and requirements that they need to go through in order to have utility on a on a real project at a real enterprise company. And when my son graduated Mason… You're a Mason grad, right?
My son graduated Masons.
Go Patriots. So he graduated to Comp Sci degree with honors but that doesn't mean he was ready to sit down the next day and start doing you know Java web applications. I know I got him started on going through a bunch of Udemy courses to become aware of things like Jenkins and Github and React, and server side computing and serverless computing. Because that's what people are looking for.
And so there is obviously a gap in… So for those companies to say “Maybe university isn't the prerequisite I need to look for. I need to look for people who are ambitious, people who are willing to sit down and able to do basics, to train themselves against a curriculum that I can give them online” is going to… It shows the opening of the aperture to say, we've got to find other ways to satisfy this demand.
Yeah, I couldn't agree more. I think ultimately becomes you know really a matter of everybody doing a little bit more planning in terms of how they can leverage technology including understanding their skills gap and where they're looking to take it. I'm always surprised that people are surprised that there's a downside to that.
So anyway, please pick up a copy in my book Cloud Computing & SEO Convergence available on Amazon as well as other places books are sold. So make sure to follow me on Twitter and @DavidLinthicum, as well as LinkedIn where I have several cloud computing courses on LinkedIn Learning. J.P. where can they find you on the web?
Take a look at JP. He is always ahead of the game and always glad to have him on the podcast and I'll have you back back pretty soon. So until next time, best of luck with your cloud now.
And then we're grumpy old men.
No, not about that.
More about that and Jack Lemmon.
Yeah. Anyway, so until next time, best of luck in building cloud computing projects. We'll talk to you again in about seven days. You guys take care. Bye!