The term cloud native is important, but wildly overused. What does it really mean and what are the important aspects that organizations need to understand? Analysts Jean Atelsek and Jay Lyman join host Eric Hanselman to explore the ideas that cloud native embodies. Is it really Apps, Automation and Abstraction? Should everyone be on a journey to the Planet of the Apps? There are many aspects and similar obstacles to be overcome that we’ve seen before, only harder this time. Silo busting again!
Learn more about 451 ResearchClick Here
Subscribe to Next in TechSubscribe
Transcript provided by Kensho
Welcome to Next in Tech, and S&P Global Market Intelligence podcast where the world of emerging tech lives. I'm your host, Eric Hanselman, principal Research Analyst for the 451 research arm of S&P Global Market Intelligence. And today, we will be discussing cloud-native, really looking at a cloud-native primer with 2 members of our analyst team, Jean Atelsek and Jay Lyman. Welcome to the podcast, both of you.
Great. Thanks for having me.
Yes. Glad to be here. Thanks.
So we've talked about cloud native in various forms and delved in some aspects of some of the implementations of cloud native and a number of different pieces about sort of what cloud native is.
But I really wanted to take a step back and really think about what are the fundamentals because people sort of toss cloud-native around as a term, but I think it's really useful to understand in a little more detail about what cloud native is really all about.
But I guess the thing that I want to start with is, do we actually need to define cloud native to start that discussion? Or are we better off defining what we'll be discussing because cloud native is a term that's been used in so many different ways.
Yes. Well, this is Jay. I'm used to this because one of my other coverage areas is DevOps. And we've seen a sort of -- it's a similar...
Yes. similar in the nebulous term admittedly. But I guess, we do have sort of a definition, but we have to understand that's sort of a living definition. It has to be with these types of trends.
We've seen changes in time over with open-source software. We've seen changes over time in what DevOps sort of means used to be about just devs and ops and now it includes security, traditional IT teams. So for cloud native, I think it sort of starts with that definition, but there's more to it than that.
So it's these -- and now I'm going to be accused maybe of being redundant. But I think on the last podcast, I was on here, I mentioned that it's -- our definition of cloud native is applications designed from the ground up to take advantage of cloud architectures and automation and to leverage things like API provisioning, auto scaling and those types of operational functions. That maybe I can let out is our starting place.
Well, redundancy in the service of clarity is never a problem. So we don't mind repeating definitions. But Jean, what are your thoughts?
I think of cloud native as largely as being a mindset in terms of the options that you gave us for defining it. It really is a series of overlapping technologies that don't necessarily need to run on the cloud but sort of grew out of cloud scalability and provisioning.
And effectively, what it's done is sort of moved up the addressable layer of infrastructure from the server and the VM and into the application, and that allows a lot of great things to happen in terms of resiliency, security, connectivity and so on.
So you're heading in a direction that William Fellows was mentioning. His term, I think, was we're all living in the planet of the apps.
But heading in that sort of -- is that -- is it that we need to raise the level of our expectations and maybe the level of our abstractions when we're thinking cloud native?
I think so, absolutely. One of the principles is to sort of decompose applications that were developed in the web era, but the pre-cloud era that are inflexible, hard to update and very unwieldy to manage almost to the point where people don't even know what's in them anymore.
And what cloud native thinking does is lets you carve away functional components of applications and upgrade them and maintain them independently. And that opens up just a world of innovative possibilities, especially given the tools that the cloud providers are supplying in terms of everything from streaming, applying machine learning and AI to stream data and so on. I mean, it's just incredible what's happening with that.
Well, I like what you said, Jean, about it growing out of some of the sort of operational needs and realities. And when I think of cloud native, one of the things I think it was good timing, right? Containers sort of arrived and evolved at a time when enterprises were trying to figure out how best to package and deploy applications in the cloud.
Kubernetes has come of age as organizations grapple with managing hybrid and multi-cloud infrastructure. And it really has sort of grown out of what a lot of leaders in the industry, practitioners have needed and want?
So it's arrived at the right time with the right set of capabilities?
I think, to some extent, right, not all of them, right? There's still a high degree of complexity. And I think there's still a ways we can go with abstraction. But that's another way in which I often think of cloud native as the technologies that are in play here, containers, Kubernetes, serverless and service mesh primarily.
And that may change, we may add to that list, but these aren't competing initiatives within organizations. They're typically using all of them. And your container strategy sort of leads to your Kubernetes strategy leads to what you're going to maybe do with serverless and service mesh. They're very interrelated and they're also simultaneously adopted and expanded by organizations.
So it sounds like we're really -- Jean was talking about it being a mindset. You've been describing what is the tool chain aspect. And I guess we're sort of skirting around what is also really an operational philosophy.
Jean, you were talking about getting away from the monstrous monolith or the decomposition of the monolith in some form or fashion. I mean it sounds like there are a lot of different aspects that really make up cloud native more broadly or should we be focusing on some of the individual ones or giving them more priority in terms of how we think about this?
I think one of the things that you're seeing is that the granularity of the components in cloud-native applications and connectivity is leading to a lot of complexity. But the ability to actually log and trace all of the activity that's happening, the overall term for that is observability, makes it possible to automate a lot of the operational functions that used to have to be human mediated.
And so that's where the whole -- in terms of development, that's where the whole notion of shift left is coming from, where the code in these applications in these composable applications can be instrumented with security, with connectivity that's via service mesh.
So it's a -- the applications become more complex, but it also opens up the possibility for automation based on the telemetry data that is coming from the processing of those jobs, those workloads.
So we've got automation as a way to tame some of the complexity that gets generated by thinking about greater quantities or greater dispersed services, I guess, that are making up cloud native.
That's the way I see it.
Yes. Well, I would agree. Automation and abstraction. And one of the things I've heard a lot in 2021, it's been we don't want to be a Kubernetes company. We just want to be able to use it.
And so -- and that speaks to the desire to give the power of Kubernetes and cloud native to your DevOps and developer teams and operational teams but to not leave the 162 different configuration choices to them, so that all they're spending their time doing is configuring Kubernetes.
My analyst brain just lands on an acronym or actually an abbreviation, I guess, we've got AAA, we've got apps, abstraction and automation. Have we characterized cloud native there sufficiently?
I think those are all pretty compelling for where we're going in terms of IT moving increasingly out of corporate data centers and into public clouds and taking advantage of the scalability and the resiliency of those environments.
So okay, you talk about things moving out of traditional corporate environments. What do organizations have to consider when they're looking at cloud native? And I guess are there particular steps that they should be looking at to adopting a cloud-native mindset?
Is this an incremental journey? Is it a wonderous transformation? What should organizations be doing? I mean we hear about all of -- we've been through a lot of shifts in software development mindset. The move to Agile, which I think for many organizations, was a complex process, you had to overcome a lot of internal barriers.
With cloud native, it seems like we've got the potential to run into a lot of the same kind of organization process stumbling blocks that we've had in a lot of initiatives to help get technology to greater levels of agility and lower case A, not upper case A.
Well, as Jean said, it is sort of a mindset, right? And cloud native is not just the technology, it's the methodology and the mindset. And it's -- so yes, there's going to be technical challenges like complexity, and there's also going to be cultural challenges.
And when we look at our survey data, those tend to center on communication among teams not accustomed to working together, differing objectives and priorities or different resources and priorities and just good old-fashioned enterprise IT inertia resistance to change, right?
So yes, I think that's all in play and similar to what we have seen is like open-source software and DevOps, and it requires a different sort of mindset mentality and that's typically ushered in by champions. And I think we can all appreciate how hard to find those champions are. And we hear stories about poaching of cloud-native teams.
So this -- there's a real need for these skills and expertise and experience and a dearth of talent out there. So organizations have to figure out ways otherwise around it, and that might be retraining existing staff, and it also requires a different approach to some of your human resources and recruiting and hiring efforts.
So that's where we see a lot of times, managed services, and talk about sort of good timing, right, as organizations are having a hard time finding this type of talent. And even if they could find them, might not be able to afford it, a managed service might make a lot more sense to them.
And that kind of brings us back to some more of that extraction where you're taking it away from the organization to sort of run your sort of cloud-native deployments, but you have to sort of figure out that flexibility and the ability to customize things when you want.
We used to have this old chart on the spectrum of abstraction, right? And one end was sort of containers that you could use where you made your own choices on languages, and frameworks and APIs, maybe for low latency or longer compute jobs or when traffic can be predicted. But on the other end, it's like [indiscernible] sort of standardizing opinionated choices that are abstracted away from the end user.
What Jay said about organizational resistance, I think a lot of IT departments and especially in large enterprises, have grown up around a non-cloud-native model of using and operating IT and provisioning IT for that matter.
And I think part of the change is sort of getting people in the organization to see some of the benefits of the kind of end state and that it can be done incrementally. That's what the app modernization of back-end applications that just carves out functional pieces that lets people see the possibilities.
And there is a ton of training and webinars and certifications and so on. The cloud providers themselves have been packaging some of these technologies into the sort of turnkey platforms that really take away a lot of the complexity, a lot of the learning curve to help lines of business sort of get on board without having to deal with the actual learning of containers and Kubernetes.
Now there is a sacrifice in terms of that you're dealing with and you don't have all the knobs and levers to turn that you might ultimately need, but there seems to be a real land grab now to just get people onto their platforms and then deal with the intricacies of the configuration and where they might want to break that mold a little later.
Well, the bad news is you don't have quite so many levers or knobs to turn. But the good news is you don't have quite so many levers or knobs to turn.
Well, I think it's interesting, Melanie Posey has been talking about the Voice of the Enterprise hosting cloud managed services study, in which we're asking about journey to cloud and how our organization is actually making this.
And we've been seeing a roll-off in the number of organizations that are identifying that they're going to do just straight lift and shift, take a workload, package it up, ship it to the cloud. And I've always said I wondered, and I think we've got a lively debate going on about whether or not that's because all the stuff that could be lift and shifted is the easy workloads that you move to cloud have already been moved.
And in fact, what's left are the hard ones or the fact that people are starting to realize that maybe they should start actually doing some of that modernization journey, Jean, that you were talking about and really thinking about doing some rearchitecting unpacking monoliths, those sorts of things.
Right. And the difficult thing with that, I mean, not only are you dealing with a moving target in terms of the services that are available off-premises. But it's a very -- it's heavy lifting. And a speedy return on investment isn't guaranteed.
So it's very hard for companies to go into a modernization project with a clear idea of what it's going to cost how long it's going to take and what the benefits are going to be.
So -- but companies are an open-source projects and academic labs are really working on providing tools to examine those monolithic code bases in a similar way to how natural language processing works for translation.
So making it possible to sort of look at one of those inflexible code bases and identify which functions can be taken away. So there are little pockets of acceleration that are being made possible that are going to make the process and make the return on investment a lot more definite as time goes on, I think.
Yes, it can be pretty daunting to look at some great monolithic app of none of the authors of which are still at -- the organization is trying to decompose it and try and figure it out. But there are a set of patterns as you were saying, that can be applied to that process.
Well, and Jean, I'm glad you mentioned sort of the open-source aspect. I mean, I think that's a big part of the growth of cloud native. Nearly all of these components are open-source software projects at their core.
And the difference of 25 or so years ago when open source software was sort of coming of age in the enterprise is that now there's no shortage of commercial vendors that are ready to provide the sort of support that organizations want.
So we sort of get the benefit of open-source software code with more eyeballs, more heads on the problems, more fingernail scratching the right itches and yet plenty of sort of commercial support, which most enterprise organizations expect and need in many cases, are required to.
If you look at sort of government and public sector clients. So that's been sort of interesting to see and the cloud-native computing foundation is a perfect example of sort of this next generation of open-source software.
I mean, if you thought the Linux market was kind of wild, boy, this Kubernetes market is something to see. And that's sort of the other thing is we're -- the organizations, enterprises generally across the industry, some are like cloud first, serverless first and really diving into this.
But most organizations are coming from this similar place of sort of the traditional intersecting with this new and Kubernetes has been around in the enterprise, but it's still a new operational paradigm. And we're seeing this play out in the size of Kubernetes clusters that are deployed.
A lot of organizations, I think, started out thinking we'll keep it simple, right? There's this complexity with Kubernetes. We'll go with one big cluster, many nodes per cluster, but we're finding out that they're just as able to manage a handful or more Kubernetes clusters, which makes more sense typically across an enterprise application portfolio and the number of teams that you're going to have to serve with that.
So that's sort of one example of where we're learning as we go a little bit. But it is -- sometimes I have to step out of the cloud native Kubernetes echo chamber. And remember that this is still new for a lot of organizations.
Well -- and you raised an interesting point there. Is cloud native an end unto itself? Or is this an ongoing process?
Well, I would say the latter for sure because, again, it kind of goes back to that definition that has to be somewhat fluid to account for reality and the world as it is. But yes, obviously, it's sort of like an endpoint with DevOps.
Is it about just going faster and managing things more efficiently? No. Our survey data tells us that it's about organizational agility or the latest survey tells us that it's about improving the experience of end users of applications and services.
And that's pretty interesting, too, to see that sort of evolution of developing software, not because it's elegant code necessarily, but because it's going to help the experience of the end user.
And what are your thoughts, Jean? Is it an end, you were talking about this being a mindset, if you've achieved cloud-native nirvana, do you need to go further? Or is this always something that needs some furtherance?
I think it will always need some furtherance. Even the largest, most successful born in the cloud, cloud-native companies are continually evolving their services and taking advantage of new capabilities that are being developed.
I mean, think of Netflix and Spotify and so on. Another thing I just wanted to point out is as Jay was pointing out before about the sort of talent shortage and how that hamstrings some companies as they're trying to go through this digital transformation. I believe that cloud native is going to really help with that as well.
Companies are showing that they can package reliability and security and optimization of cost and performance. That they can, with this ability to get this granular view of the infrastructure and respond to it in an automated way, they end up taking a lot of the toil off of the plates of operations teams and sort of putting it into the infrastructure and the orchestration platform.
So that really, if you can get to a more cloud-native operational stance, in fact, you can deal with a number of the staff shortages and skills gaps, just simply because you're building systems that simply don't require the same depth of -- same volume of toil, the same set of bodies that you have to throw at the problem to actually make it work.
Yes. Yes, absolutely. That's a story we hear about is keeping developers, DevOps teams, SREs from focusing on configuring their environments and manual tasks so that they can focus on new features, new products and innovation.
And yes, that's sort of a continuous improvement stance that you can sort of always do better if you're using the feedback loop. And I think the other interesting angle is we're seeing the use of data analytics as well as artificial intelligence and machine learning to -- as Jean kind of highlighted, by leveraging that data, organizations are not only improving their internal processes and workflows.
Now they're looking to those -- some of those business metrics, right, customer satisfaction, user experience. And I think we're just going to see more of that and more of that analytics business-driven deployments, and cloud native will be a big part of it.
Well, you have actually opened the door to what is going to be part of the next episode, which actually is the big picture report that just recently came out, looking at the year ahead, a big part of which is identifying that digital leaders have better performance in equity and credit markets.
If, in fact, they're moving into greater levels of digitization. So thank you, Jay, for a great lead in. But that is time for us for today. Thank you both for joining me on this episode.
Thanks a lot. It was great.
Yes, enjoyed the discussion.
And thanks to our audience for staying with us. I hope that you will join us for our next episode. We'll be talking about the big picture report, which is bringing together a whole set of different perspectives across S&P, it's tech, it's metals and mining, it's energy, it's all set of different pieces that are being pulled together.
And we'll dive into a couple of different pieces of that in the next episode. We hope you'll join us then because there's always something Next in Tech.
No content (including ratings, credit-related analyses and data, valuations, model, software or other application or output therefrom) or any part thereof (Content) may be modified, reverse engineered, reproduced or distributed in any form by any means, or stored in a database or retrieval system, without the prior written permission of Standard & Poor's Financial Services LLC or its affiliates (collectively, S&P).