 My name is Larry Corvallo. I have my own analyst firm called Robust Cloud. And with me, I have three panelists that will just introduce themselves in a minute. What we are here to talk about is the business value of cloud-native solutions. What I hear from CIOs, from other folks who are more on the business side, they say, hey, we understand technology, but what's the business value? I don't know about, can't talk about latency and this and that. I just need to know more of the business value. What we're going to attempt to do over here today is to give you that approach of reaching out to your business and getting the funding that you need when you're going in for a cloud-native solution. So with that, I will start with our panelists introducing themselves. Start with Betty. Hello. Hi, I'm Betty Janad. I run product marketing for VMware at Tanzu, which is the Kubernetes side of our portfolio. And let's see, I'm a long-time cloud-native person. I've spent time at Docker as well as in Service Mesh and now at VMware. So really excited to talk to you about this today and really kind of bringing forward once you start looking at how do you do this and what does it mean to justify this at an enterprise level? Like, how do you make that case? Because you're not going to show up with a list of projects, like the list of all the OSS projects. But translating that for the other people, that may not be hands-on keyboard or deep in the projects in your organization. Great. Chris Rosen. So they've got two crises here. I'm going to just forget the full name here. Right, Chris. Yeah, exactly. So I apologize for being named Chris and causing confusion. My name is Chris Rosen. I'm the director of product management in IBM Cloud. I'm responsible for our cloud-native Paz and IBM Cloud Satellite, which is our answer to distributed cloud or local cloud as a service. I've been with IBM for over 22 years and a number of different roles. In this current stint, like I said, it's really about working with our customers, helping them find the why of why we need to leverage technology to help us be able to move fast and innovate and get that business value. So I'm really excited to be here as part of this panel. I expect everyone in the audience to think of some hard questions. I'll deflect those to the other Chris. If you have any easy, I'll take those. Thank you. Chris Flotner. OK, first challenge passed. Hi, I'm Chris Flotner. I'm in product strategy in Cisco. And I'm in the ET&I part of Cisco, which you may have noticed from your Wi-Fi login. It stands for emerging technology and incubation. It's a part of Cisco that actually is trying to do a lot of software. It's emerging for Cisco in the sense that it's a new area in software as opposed to just the bread and butter that used to be Cisco's or that is Cisco's foundation business. I guess my history is I came to Cisco through an acquisition of a company called Bonsai Cloud. I used to be the CEO of that company. And what we did is actually a lot of technology to make cloud-native stuff simple and accessible for the masses. And in some part, this is actually still the mission in ET&I on the cloud-native front, just to simplify it and make it accessible. Lots of great technology, but how can we get a lot of people to actually adopt it and deploy it amass? So what we want to talk about is, again, not about the technology aspects of cloud-native. But when I talk to some folks, and especially those who run IT or the business folks who talk to IT, they say, hey, my IT department comes and says, hey, invest half a million or a million dollars on this. And why are we doing this? Because we are running out of support. Or we have to just, they say, why are we just doing it for that reason? Can we bring in a solution that actually, I don't mind paying $2 million if you give me the kind of business value that will make me competitive in the market from a business standpoint. So what I asked our three panelists to come up with one use case that they have. Each of them have one use case. I'm sure they have a lot more use cases that they have. And we're going to start with Chris Flotner to talk about his use case and talk about the business benefits of his use case. So, Chris? That sounds good. Should I? You want to look at it? It's fine. Yeah, I wonder what I wrote. Yeah. So I guess a lot of the technology in cloud-native are kind of a Swiss army knife of nature that you can apply them in lots of different ways. And in this particular story, actually, what I'd like to focus on is the value of the service mesh and some security layer that actually gives you a full lifecycle solution. And in this particular instance, there are lots of digital transformation happening in various businesses, including financial and fintechs, et cetera. And these products feel an important niche, which is how do you actually take some legacy systems and incorporate it into your forward-looking cloud-native solution? And how do you secure them? One of the things I'd like to highlight here that people often gloss over is in terms of the value of a service mesh. By the way, on this is the Cisco Callista product. Is that it actually enables enterprises to kind of decouple the development cycles of the various teams. So you can actually have a separate set of people working on the foundation layer, the operational layer, and then you can have a number of applications teams that I can focus on the various components. I think what we've seen in terms of value of these applications is that people can combine existing solutions that might be legacy, non-cloud-native, in a very simple way across clouds, across various deployment techniques on-prem, into a holistic solution. It's also worth mentioning that kind of the heritage and, well, pretty much everybody in the cloud-native space is lots of open-source projects. I just highlighted a few that we actually do inside Cisco AT&I. Some of these come from Bonsai Cloud. Some of these come from various other Cisco efforts. But these are very much to form the core part of the products that we deliver. And they really have two functions. One of them is actually enabling the ecosystem to converge the integration story around them. But it's also for the broader ecosystem to benefit from some of these components. And then the customer value that we sell to them is the simplicity of combining these things to form useful solutions at the application and the foundation operational layers. So perhaps that's it. When you look at this story primarily on the financial and digital transformation, you see a lot of banks and others coming in to go to a cloud-native solution for a lot of reasons. Biggest examples are Capital One and others that you may have heard of. So with that, we're going to go to the next Chris Rosen to talk about another FinTech story on what you do. Sure, so what's fascinating to me is that at the end of the day, regardless of the industry that customers are in when we go and talk to them, they really have the same set of challenges in some form or fashion. Number one is I need consistency. And that's consistency across my developers, across my operations teams, across environments. The reality that we all live in between hybrid cloud, distributed cloud, these are real challenges. How do I move that data? How do I ensure that I've got common CICD pipelines? Because all of that technology is going to drive in focus on innovation, enabling those teams to not only move faster, but also do so in a more secure manner. Because when you think about building in those checks throughout the entire pipeline, we're making it easier for developers to consume security guidelines that we put in place. Because at the end of the day, they want to align, but they don't want to become a CISO in their job. They want to really focus on innovation. That's what drives them as a developer. So we want to kind of mix both sides of that equation where we can interject the technology that helps them and enables them, but also provides the guard rails to prevent them from making silly mistakes, deploying code with vulnerabilities, violating open source guidelines. So it's building in those tools. And the other piece is around regardless of where I want to run. So this particular use case that I'm focused on was a FinTech customer of very large bank that I'm sure you're all familiar with that their problem statements were around, I want to run some of my workload in cloud, but the reality is not everything can or should run in public cloud yet. So how do I get that consistent, fully SRE managed capability in my data center, in my edge locations, which in this case are the customer facing banks where they don't have Kubernetes or OpenShift or Tecton or Istio or so on and so forth expertise. So how can we provide those managed services? And when I think about a managed service, it's moving up that line of responsibility so that customer can focus on what's important to them because it's not these open source projects and all the things that we love digging into the weeds around the different open source projects and things that we're here to learn about all week. It's bringing in the managed capabilities so we can focus on innovation and delivering capabilities to our end consumers. In this example, it's the banking customers. It's the people that are filling out mortgage applications. They wanna deposit a check, something as simple as that. They wanna be able to do that in a very secure and seamless manner. So the customer needed to be able to build and innovate in cloud but also run those workloads consistently in their data centers or in those banking locations. So that's really what we're focused on is providing consistency, whether that's using OpenShift as the common platform that can run in our cloud and other clouds in your data center and giving that very consistent CI-CD pipeline automation controls to let the customer focus on building what's important to them. Good, so one thing I picked from this one is the sovereignty or data sovereignty, if you were. It is really important for banks and one of the business value that you can bring up is they can say, hey, do you need to go cloud native to do data sovereignty? No, you can still do it. But what is the difference in cost for doing it with cloud native versus not cloud native? I think that's, if you can articulate that value, it's much more easy for somebody to understand that not just you go to cloud native but you also get some additional value. With that, we'll start the next slide with Betty talking about a retailer. So it's a little different from the previous two. Yeah, so let me refresh you for all the things I wrote here, but what's great about this use case here is that when I was looking back at some of the presentations and such that the customer had written to talk about their journey thus far, it starts off with like, hey, let me explain to you quickly our business. And then immediately they go to like, here's some like challenges, the immediate challenges we were facing. And then right after that was, here are our goals. So by orienting pretty specifically on what their first like, what is ultimately do we need to achieve out of this first? And at that time it was really related to like, we need better application performance. We need to make things easier to maintain because things were like, just upgrading their primary app was difficult. So they had some very clear principles on like which goals that they were targeting and then they focused it on the first app, one app. So I think that really helped them kind of go through this journey of becoming cloud native. They took that in phases. So this is like a four part journey in that, I only listed six projects here, but it is like, if I would actually list all the logos I would need a whole separate slide. But what they did is at each stage, they were able to go and focus on, let me adopt a few of these things. Because first thing I'm gonna solve for is the fact that everything takes too long. So what I wanna do is make sure that we do automation. I wanna make sure that we build in some automation so that provisioning the environments goes much faster. Or now I can do some things to automate the developer workflow. So they focus on a couple of projects, get some of those things in, learn, and then they would go to the next stage to bring in some more technologies, like adding more configurations and other things into the cluster, more technologies into the cluster. And what's surprising is that around stage, I think it was like the third stage, what they found is that, hey, now we actually need to go back and do this other work around costing. Because all the work that we did, because we added so much, we have failed on one of our additional design principles for goals. So being super focused in the beginning, it's like what were they looking for? Better performance, they wanted things to go faster so that they were delivering environments to their employees faster, developers could deploy faster, like automation. And then the ability to scale on demand, scale up and down on demand, which made them look at other technologies. And then just greater flexibility. Being able to go through those step by step and then not biting off all of the entire CNCF ecosystem, that slide with all the logos at one time, but phasing that in, allowed them to adjust and go along the way. Now that they've gone, they're at stage four where they're adding in things like service mesh and some other more advanced technologies. Now that they're there on the core platform, what they're now doing is, hey, now let's now look at these other two apps and bring them into the fold. So I think one of the things with the business cases, like being really clear and crisp on what are the outcomes that you're looking for, putting that out and mapping that back to, how does that deliver back to the organization? The app that was selected here in the first phase was their primary retail management app. This was the app that all of their stores use, as well as the partners who sold their products. This was the configurator for a customer to say like, I would like this thing in this color, this fabric, this blah, blah, blah. It was the customizer tool for the product that they sold. They were able to optimize that and then they can show value related to that app, harden what they're doing on the platform, optimize that and then now they're going back and adding more apps. So I think the big thing is being focused and then being iterative to show incremental value over time. Right, thanks, thanks Betty. I want to ask a common question to all these folks. When we talk about developers and on different platforms, when you hire a new developer, how long does it take to become productive? What I have found in a lot of cases, you need a lot of time to educate them, to get them up to speed, training them. Some companies take months before a developer can get a single line of code. The difference which I find about cloud native is what Chris Rosen talked about earlier is you have enforced security, that you can bring in a brand new computer science graduate, bring, put him online and say, hey, start writing code or start doing it. He's not going to be able to break the system. There is a lot of enforcements done. One of the ways I feel that you can communicate to your business users is I can get a developer productive so much faster. They can do work so much faster. I want each of the panel to say, what are you seeing in the market? Is that a business value that you can see from a cloud native solution of developer productivity? And we can then relate it to other things in that. Who wants to go first? Yeah, I wanna say like developer productivity and this concept of path production. So that's a lot of conversations that we have with companies today because if you talk about onboarding time, even an experienced developer, let's say onboarding at a new company, onboarding into a new project, how long before they get the environment? How long does it take them to figure out like what are all the APIs, where's the code bases, all the things that they need to work on if it's a new team? I'd say like that is a keen thing. That has been really a hot topic and you can see it by like how packed BackstageCon was as a day zero event here. The community is really kind of gravitating towards like this whole concept of can we have this internal developer portal that has everything that we can put like the application catalogs, APIs, and can we use that as a way to also build in some guardrails so that anyone, even someone you've just hired, so it could be a new college grad. We have some customers talking about I wanna have new college grads start and I want them to be productive much faster. Can they also get their environment with all the right guardrails built in provisioned much faster? Because the more time they spend waiting is the more time we can't ship a new feature and what if our competitor ships a feature? If it takes us months or a year, what does that mean for us from, you know, loss of revenue potentially? Chris? Rosen? Yeah, I agree. So I think that's definitely the focus is around the return on investment of our scarce resources, which in this case are humans that we need to develop and innovate. And I think one of the ways that we've seen is an abstraction from the underlying technology that enables that. So whether you're running, you know, on OpenShift or Tanzu or whatever that the developers aren't really interacting there because reality, and we all acknowledge this, that Kubernetes is hard. So building that shim, the proxy to the developer where they engage in tools, you know, whether it's GitHub, GitLab, whatever your developer tools are, those things are consistent. That's my one place where I interact and it's that tooling, the pipelines that integrate with the other things, the security and compliance checking tools, the provisioning tools. All of those things are abstracted from me as a developer and that's what allows them to move faster because they don't need to learn all of the nuances of company A versus company B versus, you know, project C and so on and so forth. So that's really the premise of acceleration. Great. Chris, any comments? Yeah, I think we are in violent agreement but just one point I wanted to make is, I mean, Cloud Native has won. It's not clear to me are there really any other alternatives out there that are, so everybody's using Cloud Native stuff and most people that go forward take some flavor of it. But then if you just go one layer above it, exactly what are the integration stories around it? Do you actually get these services? Can an organization actually provision clusters on demand for engineers or do they have to go through a process? That still hasn't quite settled. There's a wide variety of approaches to it. Some are very old school, you know, you go through an IT department for your development cluster and that's today still happening in some places and some are in a self-service and very dynamic but there's a huge variance within the Cloud Native community on these approaches, especially at the enterprise level and I think that's really the challenge to change so that those developers can actually be productive. It's one thing to know the tools and know the environments but do they actually get the kind of the infrastructure to be really productive? That's really the challenge in enterprise space. So going to Betty, you brought up the retail example that's still up there. What was the cost of downtime? Because one of the things that if you talk about the business value and you say, hey, with this Cloud Native solution, we can reduce downtime but can you relate that to what would have been the cost of downtime if that retail store had that experience? Yeah, they actually had an interesting thing. They're like, when it came to rolling out any upgrades or changes to the application, it required downtime but they're like, hey, this app is for all of our US stores so luckily there's a period in which all stores are closed so they're rolling it there. The risk was, they didn't quite calculate like the cost of downtime but 99% of retail sales runs through this application. So it's a huge risk, right? So it's not only for their stores but it's also for any of their partners in which are selling their merchandise but the thing was they're like, it was so inflexible. So the fact that we wanted to add more functionality but we were fundamentally unable to because just doing that is so cumbersome because it's not only just the architecture of that but it was monolithic so it was just hard every time we wanted to make one change it would take so long before we could do all the testing and get it out there but it was had a cascading effect and so the change was just not happening. Meanwhile, the business is growing like they'd acquired it at companies and expanded their portfolio and they wanted to kind of bring that into the fold but they couldn't because architecturally their hands were tied. Great, so Chris Rosen, you brought up the talk about claim processing in your example. How was the claim processing speeded up because that's very important to the business user. Can we speed up that process that will give you drive bottom line value to that customer? Exactly, yeah, so in our example it was ultimately about claims and how quickly they can get from initial request to processing and closing it out because at the end of the day that's what their KPI was around the time from onset to conclusion and the way that they built in the automation in the life cycle management that helped drive that total period in which they were closing and shipping those because the reality is we're dealing with hardware and software so we're gonna deal with bugs and outages and things like that that happened so building in resiliency and those operational characteristics to the services to the applications that we're building improve reliability and availability. Now, when they do detect the bug because everything is automated instead of we've all been there where it takes weeks or longer to get something through QA ultimately rolled out into production now with the tooling in place in the automation they can do so much, much faster and when those bugs and those issues are identified go through develop effects and roll that through their automated change management process and that then improves the efficiency on the end to end claims process because that's really what they care about. They assume the technology is there the capacity is there all of the elasticity that they need to run these cloud native applications to them it's really can we handle and make keep our customers happy because we all fear NPS scores and getting a bad rating so they're also focused on that and driving the customer experience. Great, thanks, thanks. So question for Chris Flotner about your story what kind of new applications were being able to be done in this situation and what kind of actually bottom line business value did it drive for this use case you talked about? So in one of the things that surprised me was that born in the cloud companies I should go through digital transformations as well it's not just kind of established large companies that move from an on-prem to the cloud but it's also companies that have always started on the cloud but now they've actually reached enough maturity to have to re-engineer the foundations of their technology stack and that's often as the panelists also said earlier it's driven by a couple of key metrics for example how much are they spending on the cloud and what they expect as a result of a transformation as an ability to save money and become more flexible about it when, where and how they deploy and in our case we actually address these multiple layers so there's a foundation layer that you need to put in place to be able to transform business to adopt a cloud native technologies which then in turn enables a much more flexible application development cycle than what they're used to so there are multiple layers of this transformation and at the end of the day a lot of the times it's about some level of cost savings and flexibility that they gain at the application deployments Okay, I'm going to ask one more question to the panelists and then I would like the audience to ask you questions you guys all talked about automation especially Betty and Chris Rosen and you talk so I want to understand the business value of automation the way I look at automation is if I have a capability of taking an application and automating the complete way to go and get into production I can build a one time application faster I can put it on the public cloud I can put it on the private cloud I can do that that's for me it gets you that business value of being able to respond to sudden market changes can you articulate in either your use cases that you already spoke about or some other use cases that where does automation drive the bottom line business value to the customer? I think the biggest driver is just around consistency so we have different use cases where data sovereignty or latency or these different concerns come into place where I need to run an instance in a given country or in this particular data center or in this region so if we've automated the development pipeline and that automate everything through infrastructures code from deploying my resources to deploying applications to standing up software defined storage if all that's automated it's consistent so we're saving that time and resource we are reducing human error it allows us to deploy those applications consistently in the different environments so it really drives home the repeatability the consistency the building in the security checks and ensuring that we don't have rogue people we don't want Chris Rosen pushing code to IBM cloud that's not the move we want so we've got the right controls in place so that way everything is auditable it's fully enforceable we can control who has what level of access and that's where the value comes in and that's gonna vary for each customer in each of their unique situation because everyone has a different starting point if I'm running completely in monolithic apps today and I go through and I refactor to cloud native that's gonna be a different return on the investment compared to someone that was already like Chris had born on the cloud I embrace containers and serverless but now I'm focusing on the automation and the consistency that's gonna come with it so we spent a lot of time working with customers meeting them where they are to understand where you are in your journey and then let's help accelerate that to get you to the fully automated end goal Yeah, and I think with automation also it's a what you know well and then those are the things that you can then define and standardize I think that's the thing because if you wanna go into a mode of self service what you wanna do is make sure that if you want people to be able to self service environments what you wanna do is build in the right policies and the configuration so it's not like at time of self servicing I as a developer I'm gonna say like ooh, what do I get? I can pick whatever I want because that's not what you're going for, right? So it's really kind of defining those for the customer what they have mapped out is when a developer is ready to like deploy their code it was a nine step manual process with lots of people involved and they were like that is hugely inefficient prone to error that's not gonna get us to be a more agile organization so what they wanted to do was automate the process so that it is the developer all they need to do is check it in it's going through all the steps automatically the system is doing that and the system can then spit out a port saying like hey something is not compliant and then you're managing by exception versus making the everyday be the thing somebody has to hand hold and just make sure that that handoff is physically complete and correct. Chris? Yes and the one aspect I would focus on just next to the others that were mentioned is actually know-how and encapsulating know-how the you know if you look at the cloud native space it's actually fairly large and not every engineer is as adapt that Kafka as they would be at the service mesh versus CI CD pipelines whatever it is and encapsulating that know-how making it reusable, making it automated is key and I think that's one aspect that's really important. Great. That's a really great point. Sorry. I was gonna say that's a really great point because then you're finally also scaling the expertise of a few people by automating that into your larger operating model. Got it. So I'd like to open it up to the audience for any questions and while we do that I can also put up the QR code for some feedback or rate the session. Any questions from the audience? Yes, go ahead. So can you repeat the question? Yeah, so the question is in different customers have we seen that the organization within that customer impacts their ability to adopt DevOps cloud native and I chuckle because the answer is absolutely yes. It's generally more of a cultural shift to embrace it than it is a technology challenge and honestly, that's the biggest hurdle is people get stuck and this is how I've done it. This is how we've always done it and we have to step back and say, you know, let's not take this personally but maybe that's not working optimally for what you're trying to accomplish. So thinking about how to really embrace and break down internal silos between our old IT world and we had a server team, we had a storage team and network team to really break down those barriers to embrace change, embrace DevOps. Exactly, exactly. It really requires buying in the thing that I liked that Betty said when she was introducing her use case was and this is the key to success is start small. Pick one project, one team that's willing to be an innovator and try something and then stand them up as the gold standard and success breeds success. When another team sees that this team is being so successful and they're pushing out 20 times a day, they wanna embrace that and be able to accelerate and innovate at the same pace. I just wanted to bring up something about organizational structure. For those who have seen the history of Amazon, they came up with their web services back up in 2008. However, their journey really started in 2002 or 2003 when the CEO came and said everything is going to be API driven. So the whole company was built on an SOA architecture starting in 2002 till they came up with their first product fully API driven in 2006 or 2008. That's kind of the change you have and then the way Chris said, Chris Rosen just brought up, when you get one team, when Salesforce started getting adopted for CRM, some folks say, hey, why is this sales guy doing so well? Oh, he's using this cloud CRM and he's much more effective than the rest of us. So everybody started adopting that because they see success on one side. So Betty, go ahead. Oh, so I was gonna say what's interesting is if I look back from my time, in the early days of containerization at Docker to what I'm seeing now is back then, they were called innovation teams. You had this team that kind of went out to figure out, what is all this stuff? They were experimenting in cloud, they were playing around with containers, they were kind of pushing the vendors to understand and then they were like, okay, let's figure out someone who can be a candidate in the organization to be the first sample person to get something onto the platform. Now, I feel like it's become a little more mainstream. I see this sometimes living in those who own the cloud strategy, like if you're making decisions on cloud, you're also making decisions on cloud native, and then also seeing things like platform teams. But there is a bit of like, it's a separate group kind of, but they're looking at things holistically. So it's not just the tech, but the practices. They're different than the current model, the institutionalized model, and then they're also the ones like, they're responsible for onboarding the apps and the app teams onto them. Any other questions from the audience? Raise your hand, shout it out. Okay, if that's the thing I'm gonna ask the panelists, where do you see the future of cloud native going and adding value to businesses? Is there any particular industry you might see or anything multi-cloud or edge or something that you see that is going to be driving additional value in the next maybe three to five years with cloud native technologies? And that'll be how we land that session. That okay? Who wants to go first? Yeah, I mean, I kind of see all these technologies rolling out very, very widely. I think the edge is a very exciting place where it is greatly influenced by the cloud native technologies. I mean, there was already an edge kind of evolution about a decade ago, but it partially fizzled out because the technology stack was not really in place. And I think the cloud native stack actually provides a new high quality foundation to kind of redesign how the edge works. But that's just one example. I think the same thing is happening in various other industries. Eddie? What I'm seeing right now is starting off as like on the developer tool side of the front. Because I think as Kubernetes has gotten pretty mature, but what the ecosystem around it has really been around, I think innovating at the infrastructure surrounding Kubernetes, like how do we do all that stuff there first for our runtime and management? And now we're like, oh right, this is really kind of complicated to throw a developer just right at it. So that's where I'm seeing a lot of stuff. The, I mean, we're big into backstage and that's in the last two years gotten a lot of traction, but I'm seeing so many new startups just in the whole space for like that whole developer experience side, all of that in front of Kubernetes. So I expect that to just get, that could get become very specific to certain types of apps, you know, like, you know, we I don't think we've even gone real deep in all the ML and AI stuff, but I see that as a whole area. Yeah, good, got it. Chris? Yeah, the other, I would just broadly say I think the direction is going around usability and really focused on the user experience of consuming these technologies. When you think about when a new project comes out and I'll pick on Istio as an example, when that became an open source project, it was very powerful. There were a lot of things that you could do with it, but docs were a little lagging, the usability was a little bit behind. So they really had to focus as a community to improve those areas, to be able to bring that technology to mainstream else, you really limited to a few outliers. So I think the whole cloud native space is focused on streamlining the usability, building the DevTools, taking that to the edge and making all of that more consumable, more secure for those users. Great, with that, give a hand to our panelists. And thank you for, thank you for attending. If you want to rate this session, it would be great for us to get feedback for the next session. And for those who are really interested in Edge, we had a session earlier today and you can watch the recording of that. Chris brought up that Edge was popular for this. So you want a deep dive into that, that's an earlier session. Thank you.