(Upbeat music playing) >> Hey everyone, thanks for joining us today. Welcome to this event of Building your Cloud Center of Excellence with Hitachi Vantara. I'm your host, Lisa Martin. I've got a couple of guests here with me next to talk about redefining cloud operations and application modernization for customers. Please welcome Prem Balasubramanian the SVP and CTO at Hitachi Vantara, and Manoj Narayanan is here as well, the Managing Director of Technology at GTCR. Guys, thank you so much for joining me today. Excited to have this conversation about redefining CloudOps with you. >> Pleasure to be here. >> Pleasure to be here >> Prem, let's go ahead and start with you. You have done well over a thousand cloud engagements in your career. I'd love to get your point of view on how the complexity around cloud operations and management has evolved in the last, say, three to four years. >> It's a great question, Lisa before we understand the complexity around the management itself, the cloud has evolved over the last decade significantly from being a backend infrastructure or infrastructure as a service for many companies to become the business for many companies. If you think about a lot of these cloud bond companies cloud is where their entire workload and their business wants. With that, as a background for this conversation if you think about the cloud operations, there was a lot of there was a lot of lift and shift happening in the market where people lifted their workloads or applications and moved them onto the cloud where they treated cloud significantly as an infrastructure. And the way they started to manage it was again, the same format they were managing there on-prem infrastructure and they call it I&O, Infrastructure and Operations. That's kind of the way traditionally cloud is managed. In the last few years, we are seeing a significant shift around thinking of cloud more as a workload rather than as just an infrastructure. And what I mean by workload is in the cloud, everything is now code. So you are codifying your infrastructure. Your application is already code and your data is also codified as data services. With now that context apply the way you think about managing the cloud has to significantly change and many companies are moving towards trying to change their models to look at this complex environment as opposed to treating it like a simple infrastructure that is sitting somewhere else. So that's one of the biggest changes and shifts that are causing a lot of complexity and headache for actually a lot of customers for managing environments. The second critical aspect is even that, even exasperates the situation is multicloud environments. Now, there are companies that have got it right with things about right cloud for the right workload. So there are companies that I reach out and I talk with. They've got their office applications and emails and stuff running on Microsoft 365 which can be on the Azure cloud whereas they're running their engineering applications the ones that they build and leverage for their end customers on Amazon. And to some extent they've got it right but still they have a multiple cloud that they have to go after and maintain. This becomes complex when you have two clouds for the same type of workload. When I have to host applications for my end customers on Amazon as well as Azure, Azure as well as Google then, I get into security issues that I have to be consistent across all three. I get into talent because I need to have people that focus on Amazon as well as Azure, as well as Google which means I need so much more workforce, I need so many so much more skills that I need to build, right? That's becoming the second issue. The third one is around data costs. Can I make these clouds talk to each other? Then you get into the ingress egress cost and that creates some complexity. So bringing all of this together and managing is really become becoming more complex for our customers. And obviously as a part of this we will talk about some of the, some of the ideas that we can bring for in managing such complex environments but this is what we are seeing in terms of why the complexity has become a lot more in the last few years. >> Right. A lot of complexity in the last few years. Manoj, let's bring you into the conversation now. Before we dig into your cloud environment give the audience a little bit of an overview of GTCR. What kind of company are you? What do you guys do? >> Definitely Lisa. GTCR is a Chicago based private equity firm. We've been in the market for more than 40 years and what we do is we invest in companies across different sectors and then we manage the company drive it to increase the value and then over a period of time, sell it to future buyers. So in a nutshell, we got a large portfolio of companies that we need to manage and make sure that they perform to expectations. And my role within GTCR is from a technology viewpoint so where I work with all the companies their technology leadership to make sure that we are getting the best out of technology and technology today drives everything. So how can technology be a good compliment to the business itself? So, my role is to play that intermediary role to make sure that there is synergy between the investment thesis and the technology lures that we can pull and also work with partners like Hitachi to make sure that it is done in an optimal manner. >> I like that you said, you know, technology needs to really compliment the business and vice versa. So Manoj, let's get into the cloud operations environment at GTCR. Talk to me about what the experience has been the last couple of years. Give us an idea of some of the challenges that you were facing with existing cloud ops and and the solution that you're using from Hitachi Vantara. >> A a absolutely. In fact, in fact Prem phrased it really well, one of the key things that we're facing is the workload management. So there's so many choices there, so much complexities. We have these companies buying more companies there is organic growth that is happening. So the variables that we have to deal with are very high in such a scenario to make sure that the workload management of each of the companies are done in an optimal manner is becoming an increasing concern. So, so that's one area where any help we can get anything we can try to make sure it is done better becomes a huge value at each. A second aspect is a financial transparency. We need to know where the money is going where the money is coming in from, what is the scale especially in the cloud environment. We are talking about an auto scale ecosystem. Having that financial transparency and the metrics associated with that, it, these these become very, very critical to ensure that we have a successful presence in the multicloud environment. >> Talk a little bit about the solution that you're using with Hitachi and, and the challenges that it is eradicated. >> Yeah, so it end of the day, right, we we need to focus on our core competence. So, so we have got a very strong technology leadership team. We've got a very strong presence in the respective domains of each of the portfolio companies. But where Hitachi comes in and HAR comes in as a solution is that they allow us to excel in focusing on our core business and then make sure that we are able to take care of workload management or financial transparency. All of that is taken off the table from us and and Hitachi manages it for us, right? So it's such a perfectly compliment relationship where they act as two partners and HARC is a solution that is extremely useful in driving that. And, and and I'm anticipating that it'll become more important with time as the complexity of cloud and cloud associate workloads are only becoming more challenging to manage and not less. >> Right? That's the thing that complexity is there and it's also increasing Prem, you talked about the complexities that are existent today with respect to cloud operations the things that have happened over the last couple of years. What are some of your tips, Prem for the audience, like the the top two or three things that you would say on cloud operations that that people need to understand so that they can manage that complexity and allow their business to be driven and complimented by technology? >> Yeah, a big great question again, Lisa, right? And I think Manoj alluded to a few of these things as well. The first one is in the new world of the cloud I think think of migration, modernization and management as a single continuum to the cloud. Now there is no lift and shift and there is no way somebody else separately manages it, right? If you do not lift and shift the right applications the right way onto the cloud, you are going to deal with the complexity of managing it and you'll end up spending more money time and effort in managing it. So that's number one. Migration, modernization, management of cloud work growth is a single continuum and it's not three separate activities, right? That's number one. And the, the second is cost. Cost traditionally has been an afterthought, right? People move the workload to the cloud. And I think, again, like I said, I'll refer back to what Manoj said once we move it to the cloud and then we put all these fancy engineering capability around self-provisioning, every developer can go and ask for what he or she wants and they get an environment immediately spun up so on and so forth. Suddenly the CIO wakes up to a bill that is significantly larger than what he or she expected right? And, and this is this is become a bit common nowadays, right? The the challenge is because we think cost in the cloud as an afterthought. But consider this example in, in previous world you buy hard, well, you put it in your data center you have already amortized the cost as a CapEx. So you can write an application throw it onto the infrastructure and the application continues to use the infrastructure until you hit a ceiling, you don't care about the money you spent. But if I write a line of code that is inefficient today and I deploy it on the cloud from minute one, I am paying for the inefficiency. So if I realize it after six months, I've already spent the money. So financial discipline, especially when managing the cloud is now is no more an afterthought. It is as much something that you have to include in your engineering practice as much as any other DevOps practices, right? Those are my top two tips, Lisa, from my standpoint, think about cloud, think about cloud work, cloud workloads. And the last one again, and you will see you will hear me saying this again and again, get into the mindset of everything is code. You don't have a touch and feel infrastructure anymore. So you don't really need to have foot on the ground to go manage that infrastructure. It's codified. So your code should be managing it, but think of how it happens, right? That's where we, we are going as an evolution >> Everything is code. That's great advice, great tips for the audience there. Manoj, I'll bring you back into the conversation. You know, we, we can talk about skills gaps on on in many different facets of technology the SRE role, relatively new, skillset. We're hearing, hearing a lot about it. SRE led DevSecOps is probably even more so of a new skillset. If I'm an IT leader or an application leader how do I ensure that I have the right skillset within my organization to be able to manage my cloud operations to, to dial down that complexity so that I can really operate successfully as a business? >> Yeah. And so unfortunately there is no perfect answer, right? It's such a, such a scarce skillset that a, any day any of the portfolio company CTOs if I go and talk and say, Hey here's a great SRE team member, they'll be more than willing to fight with each of to get the person in right? It's just that scarce of a skillset. So, so a few things we need to look at it. One is, how can I build it within, right? So nobody gets born as an SRE, you, you make a person an SRE. So how do you inculcate that culture? So like Prem said earlier, right? Everything is software. So how do we make sure that everybody inculcates that as part of their operating philosophy be they part of the operations team or the development team or the testing team they need to understand that that is a common guideline and common objective that we are driving towards. So, so that skillset and that associated training needs to be driven from within the organization. And that in my mind is the fastest way to make sure that that role gets propagated across organization. That is one. The second thing is rely on the right partners. So it's not going to be possible for us, to get all of these roles built in-house. So instead prioritize what roles need to be done from within the organization and what roles can we rely on our partners to drive it for us. So that becomes an important consideration for us to look at as well. >> Absolutely. That partnership angle is incredibly important from, from the, the beginning really kind of weaving these companies together on this journey to to redefine cloud operations and build that, as we talked about at the beginning of the conversation really building a cloud center of excellence that allows the organization to be competitive, successful and and really deliver what the end user is, is expecting. I want to ask - Sorry Lisa, - go ahead. >> May I add something to it, I think? >> Sure. >> Yeah. One of the, one of the common things that I tell customers when we talk about SRE and to manages point is don't think of SRE as a skillset which is the common way today the industry tries to solve the problem. SRE is a mindset, right? Everybody in >> Well well said, yeah >> That, so everybody in a company should think of him or her as a cycle liability engineer. And everybody has a role in it, right? Even if you take the new process layout from SRE there are individuals that are responsible to whom we can go to when there is a problem directly as opposed to going through the traditional ways of AI talk to L one and L one contras all. They go to L two and then L three. So we, we, we are trying to move away from an issue escalation model to what we call as a a issue routing or a incident routing model, right? Move away from incident escalation to an incident routing model. So you get to route to the right folks. So again, to sum it up, SRE should not be solved as a skillset set because there is not enough people in the market to solve it that way. If you start solving it as a mindset I think companies can get a handhold of it. >> I love that. I've actually never heard that before, but it it makes perfect sense to think about the SRE as a mindset rather than a skillset that will allow organizations to be much more successful. Prem I wanted to get your thoughts as enterprises are are innovating, they're moving more products and services to the as a service model. Talk about how the dev teams the ops teams are working together to build and run reliable, cost efficient services. Are they working better together? >> Again, a a very polarizing question because some customers are getting it right many customers aren't, there is still a big wall between development and operations, right? Even when you think about DevOps as a terminology the fundamental principle was to make sure dev and ops works together. But what many companies have achieved today, honestly is automating the operations for development. For example, as a developer, I can check in code and my code will appear in production without any friction, right? There is automated testing, automated provisioning and it gets promoted to production, but after production, it goes back into the 20 year old model of operating the code, right? So there is more work that needs to be done for Devon and Ops to come closer and work together. And one of the ways that we think this is achievable is not by doing radical org changes, but more by focusing on a product-oriented single backlog approach across development and operations. Which is, again, there is change management involved but I think that's a way to start embracing the culture of dev ops coming together much better now, again SRE principles as we double click and understand it more and Google has done a very good job playing it out for the world. As you think about SRE principle, there are ways and means in that process of how to think about a single backlog. And in HARC, Hitachi Application Reliability Centers we've really got a way to look at prioritizing the backlog. And what I mean by that is dev teams try to work on backlog that come from product managers on features. The SRE and the operations team try to put backlog into the say sorry, try to put features into the same backlog for improving stability, availability and financials financial optimization of your code. And there are ways when you look at your SLOs and error budgets to really coach the product teams to prioritize your backlog based on what's important for you. So if you understand your spending more money then you reduce your product features going in and implement the financial optimization that came from your operations team, right? So you now have the ability to throttle these parameters and that's where SRE becomes a mindset and a principle as opposed to a skillset because this is not an individual telling you to do. This is the company that is, is embarking on how to prioritize my backlog beyond just user features. >> Right. Great point. Last question for both of you is the same talk kind of take away things that you want me to remember. If I am at an IT leader at, at an organization and I am planning on redefining CloudOps for my company Manoj will start with you and then Prem to you what are the top two things that you want me to walk away with understanding how to do that successfully? >> Yeah, so I'll, I'll go back to basics. So the two things I would say need to be taken care of is, one is customer experience. So all the things that I do end of the day is it improving the customer experience or not? So that's a first metric. The second thing is anything that I do is there an ROI by doing that incremental step or not? Otherwise we might get lost in the technology with surgery, the new tech, et cetera. But end of the day, if the customers are not happy if there is no ROI, everything else you just can't do much on top of that >> Now it's all about the customer experience. Right? That's so true. Prem what are your thoughts, the the top things that I need to be taking away if I am a a leader planning to redefine my cloud eye company? >> Absolutely. And I think from a, from a company standpoint I think Manoj summarized it extremely well, right? There is this ROI and there is this customer experience from my end, again, I'll, I'll suggest two two more things as a takeaway, right? One, cloud cost is not an afterthought. It's essential for us to think about it upfront. Number two, do not delink migration modernization and operations. They are one stream. If you migrate a long, wrong workload onto the cloud you're going to be stuck with it for a long time. And an example of a wrong workload, Lisa for everybody that that is listening to this is if my cost per transaction profile doesn't change and I am not improving my revenue per transaction for a piece of code that's going run in production it's better off running in a data center where my cost is CapEx than amortized and I have control over when I want to upgrade as opposed to putting it on a cloud and continuing to pay unless it gives me more dividends towards improvement. But that's a simple example of when we think about what should I migrate and how will it cost pain when I want to manage it in the longer run. But that's, that's something that I'll leave the audience and you with as a takeaway. >> Excellent. Guys, thank you so much for talking to me today about what Hitachi Vantara and GTCR are doing together how you've really dialed down those complexities enabling the business and the technology folks to really live harmoniously. We appreciate your insights and your perspectives on building a cloud center of excellence. Thank you both for joining me. >> Thank you. >> For my guests, I'm Lisa. Martin, you're watching this event building Your Cloud Center of Excellence with Hitachi Vantara. Thanks for watching. (Upbeat music playing) (Upbeat music playing) (Upbeat music playing) (Upbeat music playing)

(Upbeat music playing) >> Hey everyone, thanks for joining us today. Welcome to this event of Building your Cloud Center of Excellence with Hitachi Vantara. I'm your host, Lisa Martin. I've got a couple of guests here with me next to talk about redefining cloud operations and application modernization for customers. Please welcome Prem Balasubramanian the SVP and CTO at Hitachi Vantara, and Manoj Narayanan is here as well, the Managing Director of Technology at GTCR. Guys, thank you so much for joining me today. Excited to have this conversation about redefining CloudOps with you. >> Pleasure to be here. >> Pleasure to be here >> Prem, let's go ahead and start with you. You have done well over a thousand cloud engagements in your career. I'd love to get your point of view on how the complexity around cloud operations and management has evolved in the last, say, three to four years. >> It's a great question, Lisa before we understand the complexity around the management itself, the cloud has evolved over the last decade significantly from being a backend infrastructure or infrastructure as a service for many companies to become the business for many companies. If you think about a lot of these cloud bond companies cloud is where their entire workload and their business wants. With that, as a background for this conversation if you think about the cloud operations, there was a lot of there was a lot of lift and shift happening in the market where people lifted their workloads or applications and moved them onto the cloud where they treated cloud significantly as an infrastructure. And the way they started to manage it was again, the same format they were managing there on-prem infrastructure and they call it I&O, Infrastructure and Operations. That's kind of the way traditionally cloud is managed. In the last few years, we are seeing a significant shift around thinking of cloud more as a workload rather than as just an infrastructure. And what I mean by workload is in the cloud, everything is now code. So you are codifying your infrastructure. Your application is already code and your data is also codified as data services. With now that context apply the way you think about managing the cloud has to significantly change and many companies are moving towards trying to change their models to look at this complex environment as opposed to treating it like a simple infrastructure that is sitting somewhere else. So that's one of the biggest changes and shifts that are causing a lot of complexity and headache for actually a lot of customers for managing environments. The second critical aspect is even that, even exasperates the situation is multicloud environments. Now, there are companies that have got it right with things about right cloud for the right workload. So there are companies that I reach out and I talk with. They've got their office applications and emails and stuff running on Microsoft 365 which can be on the Azure cloud whereas they're running their engineering applications the ones that they build and leverage for their end customers on Amazon. And to some extent they've got it right but still they have a multiple cloud that they have to go after and maintain. This becomes complex when you have two clouds for the same type of workload. When I have to host applications for my end customers on Amazon as well as Azure, Azure as well as Google then, I get into security issues that I have to be consistent across all three. I get into talent because I need to have people that focus on Amazon as well as Azure, as well as Google which means I need so much more workforce, I need so many so much more skills that I need to build, right? That's becoming the second issue. The third one is around data costs. Can I make these clouds talk to each other? Then you get into the ingress egress cost and that creates some complexity. So bringing all of this together and managing is really become becoming more complex for our customers. And obviously as a part of this we will talk about some of the, some of the ideas that we can bring for in managing such complex environments but this is what we are seeing in terms of why the complexity has become a lot more in the last few years. >> Right. A lot of complexity in the last few years. Manoj, let's bring you into the conversation now. Before we dig into your cloud environment give the audience a little bit of an overview of GTCR. What kind of company are you? What do you guys do? >> Definitely Lisa. GTCR is a Chicago based private equity firm. We've been in the market for more than 40 years and what we do is we invest in companies across different sectors and then we manage the company drive it to increase the value and then over a period of time, sell it to future buyers. So in a nutshell, we got a large portfolio of companies that we need to manage and make sure that they perform to expectations. And my role within GTCR is from a technology viewpoint so where I work with all the companies their technology leadership to make sure that we are getting the best out of technology and technology today drives everything. So how can technology be a good compliment to the business itself? So, my role is to play that intermediary role to make sure that there is synergy between the investment thesis and the technology lures that we can pull and also work with partners like Hitachi to make sure that it is done in an optimal manner. >> I like that you said, you know, technology needs to really compliment the business and vice versa. So Manoj, let's get into the cloud operations environment at GTCR. Talk to me about what the experience has been the last couple of years. Give us an idea of some of the challenges that you were facing with existing cloud ops and and the solution that you're using from Hitachi Vantara. >> A a absolutely. In fact, in fact Prem phrased it really well, one of the key things that we're facing is the workload management. So there's so many choices there, so much complexities. We have these companies buying more companies there is organic growth that is happening. So the variables that we have to deal with are very high in such a scenario to make sure that the workload management of each of the companies are done in an optimal manner is becoming an increasing concern. So, so that's one area where any help we can get anything we can try to make sure it is done better becomes a huge value at each. A second aspect is a financial transparency. We need to know where the money is going where the money is coming in from, what is the scale especially in the cloud environment. We are talking about an auto scale ecosystem. Having that financial transparency and the metrics associated with that, it, these these become very, very critical to ensure that we have a successful presence in the multicloud environment. >> Talk a little bit about the solution that you're using with Hitachi and, and the challenges that it is eradicated. >> Yeah, so it end of the day, right, we we need to focus on our core competence. So, so we have got a very strong technology leadership team. We've got a very strong presence in the respective domains of each of the portfolio companies. But where Hitachi comes in and HAR comes in as a solution is that they allow us to excel in focusing on our core business and then make sure that we are able to take care of workload management or financial transparency. All of that is taken off the table from us and and Hitachi manages it for us, right? So it's such a perfectly compliment relationship where they act as two partners and HARC is a solution that is extremely useful in driving that. And, and and I'm anticipating that it'll become more important with time as the complexity of cloud and cloud associate workloads are only becoming more challenging to manage and not less. >> Right? That's the thing that complexity is there and it's also increasing Prem, you talked about the complexities that are existent today with respect to cloud operations the things that have happened over the last couple of years. What are some of your tips, Prem for the audience, like the the top two or three things that you would say on cloud operations that that people need to understand so that they can manage that complexity and allow their business to be driven and complimented by technology? >> Yeah, a big great question again, Lisa, right? And I think Manoj alluded to a few of these things as well. The first one is in the new world of the cloud I think think of migration, modernization and management as a single continuum to the cloud. Now there is no lift and shift and there is no way somebody else separately manages it, right? If you do not lift and shift the right applications the right way onto the cloud, you are going to deal with the complexity of managing it and you'll end up spending more money time and effort in managing it. So that's number one. Migration, modernization, management of cloud work growth is a single continuum and it's not three separate activities, right? That's number one. And the, the second is cost. Cost traditionally has been an afterthought, right? People move the workload to the cloud. And I think, again, like I said, I'll refer back to what Manoj said once we move it to the cloud and then we put all these fancy engineering capability around self-provisioning, every developer can go and ask for what he or she wants and they get an environment immediately spun up so on and so forth. Suddenly the CIO wakes up to a bill that is significantly larger than what he or she expected right? And, and this is this is become a bit common nowadays, right? The the challenge is because we think cost in the cloud as an afterthought. But consider this example in, in previous world you buy hard, well, you put it in your data center you have already amortized the cost as a CapEx. So you can write an application throw it onto the infrastructure and the application continues to use the infrastructure until you hit a ceiling, you don't care about the money you spent. But if I write a line of code that is inefficient today and I deploy it on the cloud from minute one, I am paying for the inefficiency. So if I realize it after six months, I've already spent the money. So financial discipline, especially when managing the cloud is now is no more an afterthought. It is as much something that you have to include in your engineering practice as much as any other DevOps practices, right? Those are my top two tips, Lisa, from my standpoint, think about cloud, think about cloud work, cloud workloads. And the last one again, and you will see you will hear me saying this again and again, get into the mindset of everything is code. You don't have a touch and feel infrastructure anymore. So you don't really need to have foot on the ground to go manage that infrastructure. It's codified. So your code should be managing it, but think of how it happens, right? That's where we, we are going as an evolution >> Everything is code. That's great advice, great tips for the audience there. Manoj, I'll bring you back into the conversation. You know, we, we can talk about skills gaps on on in many different facets of technology the SRE role, relatively new, skillset. We're hearing, hearing a lot about it. SRE led DevSecOps is probably even more so of a new skillset. If I'm an IT leader or an application leader how do I ensure that I have the right skillset within my organization to be able to manage my cloud operations to, to dial down that complexity so that I can really operate successfully as a business? >> Yeah. And so unfortunately there is no perfect answer, right? It's such a, such a scarce skillset that a, any day any of the portfolio company CTOs if I go and talk and say, Hey here's a great SRE team member, they'll be more than willing to fight with each of to get the person in right? It's just that scarce of a skillset. So, so a few things we need to look at it. One is, how can I build it within, right? So nobody gets born as an SRE, you, you make a person an SRE. So how do you inculcate that culture? So like Prem said earlier, right? Everything is software. So how do we make sure that everybody inculcates that as part of their operating philosophy be they part of the operations team or the development team or the testing team they need to understand that that is a common guideline and common objective that we are driving towards. So, so that skillset and that associated training needs to be driven from within the organization. And that in my mind is the fastest way to make sure that that role gets propagated across organization. That is one. The second thing is rely on the right partners. So it's not going to be possible for us, to get all of these roles built in-house. So instead prioritize what roles need to be done from within the organization and what roles can we rely on our partners to drive it for us. So that becomes an important consideration for us to look at as well. >> Absolutely. That partnership angle is incredibly important from, from the, the beginning really kind of weaving these companies together on this journey to to redefine cloud operations and build that, as we talked about at the beginning of the conversation really building a cloud center of excellence that allows the organization to be competitive, successful and and really deliver what the end user is, is expecting. I want to ask - Sorry Lisa, - go ahead. >> May I add something to it, I think? >> Sure. >> Yeah. One of the, one of the common things that I tell customers when we talk about SRE and to manages point is don't think of SRE as a skillset which is the common way today the industry tries to solve the problem. SRE is a mindset, right? Everybody in >> Well well said, yeah >> That, so everybody in a company should think of him or her as a cycle liability engineer. And everybody has a role in it, right? Even if you take the new process layout from SRE there are individuals that are responsible to whom we can go to when there is a problem directly as opposed to going through the traditional ways of AI talk to L one and L one contras all. They go to L two and then L three. So we, we, we are trying to move away from an issue escalation model to what we call as a a issue routing or a incident routing model, right? Move away from incident escalation to an incident routing model. So you get to route to the right folks. So again, to sum it up, SRE should not be solved as a skillset set because there is not enough people in the market to solve it that way. If you start solving it as a mindset I think companies can get a handhold of it. >> I love that. I've actually never heard that before, but it it makes perfect sense to think about the SRE as a mindset rather than a skillset that will allow organizations to be much more successful. Prem I wanted to get your thoughts as enterprises are are innovating, they're moving more products and services to the as a service model. Talk about how the dev teams the ops teams are working together to build and run reliable, cost efficient services. Are they working better together? >> Again, a a very polarizing question because some customers are getting it right many customers aren't, there is still a big wall between development and operations, right? Even when you think about DevOps as a terminology the fundamental principle was to make sure dev and ops works together. But what many companies have achieved today, honestly is automating the operations for development. For example, as a developer, I can check in code and my code will appear in production without any friction, right? There is automated testing, automated provisioning and it gets promoted to production, but after production, it goes back into the 20 year old model of operating the code, right? So there is more work that needs to be done for Devon and Ops to come closer and work together. And one of the ways that we think this is achievable is not by doing radical org changes, but more by focusing on a product-oriented single backlog approach across development and operations. Which is, again, there is change management involved but I think that's a way to start embracing the culture of dev ops coming together much better now, again SRE principles as we double click and understand it more and Google has done a very good job playing it out for the world. As you think about SRE principle, there are ways and means in that process of how to think about a single backlog. And in HARC, Hitachi Application Reliability Centers we've really got a way to look at prioritizing the backlog. And what I mean by that is dev teams try to work on backlog that come from product managers on features. The SRE and the operations team try to put backlog into the say sorry, try to put features into the same backlog for improving stability, availability and financials financial optimization of your code. And there are ways when you look at your SLOs and error budgets to really coach the product teams to prioritize your backlog based on what's important for you. So if you understand your spending more money then you reduce your product features going in and implement the financial optimization that came from your operations team, right? So you now have the ability to throttle these parameters and that's where SRE becomes a mindset and a principle as opposed to a skillset because this is not an individual telling you to do. This is the company that is, is embarking on how to prioritize my backlog beyond just user features. >> Right. Great point. Last question for both of you is the same talk kind of take away things that you want me to remember. If I am at an IT leader at, at an organization and I am planning on redefining CloudOps for my company Manoj will start with you and then Prem to you what are the top two things that you want me to walk away with understanding how to do that successfully? >> Yeah, so I'll, I'll go back to basics. So the two things I would say need to be taken care of is, one is customer experience. So all the things that I do end of the day is it improving the customer experience or not? So that's a first metric. The second thing is anything that I do is there an ROI by doing that incremental step or not? Otherwise we might get lost in the technology with surgery, the new tech, et cetera. But end of the day, if the customers are not happy if there is no ROI, everything else you just can't do much on top of that >> Now it's all about the customer experience. Right? That's so true. Prem what are your thoughts, the the top things that I need to be taking away if I am a a leader planning to redefine my cloud eye company? >> Absolutely. And I think from a, from a company standpoint I think Manoj summarized it extremely well, right? There is this ROI and there is this customer experience from my end, again, I'll, I'll suggest two two more things as a takeaway, right? One, cloud cost is not an afterthought. It's essential for us to think about it upfront. Number two, do not delink migration modernization and operations. They are one stream. If you migrate a long, wrong workload onto the cloud you're going to be stuck with it for a long time. And an example of a wrong workload, Lisa for everybody that that is listening to this is if my cost per transaction profile doesn't change and I am not improving my revenue per transaction for a piece of code that's going run in production it's better off running in a data center where my cost is CapEx than amortized and I have control over when I want to upgrade as opposed to putting it on a cloud and continuing to pay unless it gives me more dividends towards improvement. But that's a simple example of when we think about what should I migrate and how will it cost pain when I want to manage it in the longer run. But that's, that's something that I'll leave the audience and you with as a takeaway. >> Excellent. Guys, thank you so much for talking to me today about what Hitachi Vantara and GTCR are doing together how you've really dialed down those complexities enabling the business and the technology folks to really live harmoniously. We appreciate your insights and your perspectives on building a cloud center of excellence. Thank you both for joining me. >> Thank you. >> For my guests, I'm Lisa. Martin, you're watching this event building Your Cloud Center of Excellence with Hitachi Vantara. Thanks for watching. (Upbeat music playing) (Upbeat music playing) (Upbeat music playing) (Upbeat music playing)

(Upbeat music playing) >> Hey everyone, thanks for joining us today. Welcome to this event of Building your Cloud Center of Excellence with Hitachi Vantara. I'm your host, Lisa Martin. I've got a couple of guests here with me next to talk about redefining cloud operations and application modernization for customers. Please welcome Param Balasubramanian the SVP and CTO at Hitachi Vantara, and Manoj Narayanan is here as well, the Managing Director of Technology at GTCR. Guys, thank you so much for joining me today. Excited to have this conversation about redefining CloudOps with you. >> Pleasure to be here. >> Pleasure to be here >> Param, let's go ahead and start with you. You have done well over a thousand cloud engagements in your career. I'd love to get your point of view on how the complexity around cloud operations and management has evolved in the last, say, three to four years. >> It's a great question, Lisa before we understand the complexity around the management itself, the cloud has evolved over the last decade significantly from being a backend infrastructure or infrastructure as a service for many companies to become the business for many companies. If you think about a lot of these cloud bond companies cloud is where their entire workload and their business wants. With that, as a background for this conversation if you think about the cloud operations, there was a lot of there was a lot of lift and shift happening in the market where people lifted their workloads or applications and moved them onto the cloud where they treated cloud significantly as an infrastructure. And the way they started to manage it was again, the same format they were managing there on-prem infrastructure and they call it I&O, Infrastructure and Operations. That's kind of the way traditionally cloud is managed. In the last few years, we are seeing a significant shift around thinking of cloud more as a workload rather than as just an infrastructure. And what I mean by workload is in the cloud, everything is now code. So you are codifying your infrastructure. Your application is already code and your data is also codified as data services. With now that context apply the way you think about managing the cloud has to significantly change and many companies are moving towards trying to change their models to look at this complex environment as opposed to treating it like a simple infrastructure that is sitting somewhere else. So that's one of the biggest changes and shifts that are causing a lot of complexity and headache for actually a lot of customers for managing environments. The second critical aspect is even that, even exasperates the situation is multicloud environments. Now, there are companies that have got it right with things about right cloud for the right workload. So there are companies that I reach out and I talk with. They've got their office applications and emails and stuff running on Microsoft 365 which can be on the Azure cloud whereas they're running their engineering applications the ones that they build and leverage for their end customers on Amazon. And to some extent they've got it right but still they have a multiple cloud that they have to go after and maintain. This becomes complex when you have two clouds for the same type of workload. When I have to host applications for my end customers on Amazon as well as Azure, Azure as well as Google then, I get into security issues that I have to be consistent across all three. I get into talent because I need to have people that focus on Amazon as well as Azure, as well as Google which means I need so much more workforce, I need so many so much more skills that I need to build, right? That's becoming the second issue. The third one is around data costs. Can I make these clouds talk to each other? Then you get into the ingress egress cost and that creates some complexity. So bringing all of this together and managing is really become becoming more complex for our customers. And obviously as a part of this we will talk about some of the, some of the ideas that we can bring for in managing such complex environments but this is what we are seeing in terms of why the complexity has become a lot more in the last few years. >> Right. A lot of complexity in the last few years. Manoj, let's bring you into the conversation now. Before we dig into your cloud environment give the audience a little bit of an overview of GTCR. What kind of company are you? What do you guys do? >> Definitely Lisa. GTCR is a Chicago based private equity firm. We've been in the market for more than 40 years and what we do is we invest in companies across different sectors and then we manage the company drive it to increase the value and then over a period of time, sell it to future buyers. So in a nutshell, we got a large portfolio of companies that we need to manage and make sure that they perform to expectations. And my role within GTCR is from a technology viewpoint so where I work with all the companies their technology leadership to make sure that we are getting the best out of technology and technology today drives everything. So how can technology be a good compliment to the business itself? So, my role is to play that intermediary role to make sure that there is synergy between the investment thesis and the technology lures that we can pull and also work with partners like Hitachi to make sure that it is done in an optimal manner. >> I like that you said, you know, technology needs to really compliment the business and vice versa. So Manoj, let's get into the cloud operations environment at GTCR. Talk to me about what the experience has been the last couple of years. Give us an idea of some of the challenges that you were facing with existing cloud ops and and the solution that you're using from Hitachi Vantara. >> A a absolutely. In fact, in fact Param phrased it really well, one of the key things that we're facing is the workload management. So there's so many choices there, so much complexities. We have these companies buying more companies there is organic growth that is happening. So the variables that we have to deal with are very high in such a scenario to make sure that the workload management of each of the companies are done in an optimal manner is becoming an increasing concern. So, so that's one area where any help we can get anything we can try to make sure it is done better becomes a huge value at each. A second aspect is a financial transparency. We need to know where the money is going where the money is coming in from, what is the scale especially in the cloud environment. We are talking about an auto scale ecosystem. Having that financial transparency and the metrics associated with that, it, these these become very, very critical to ensure that we have a successful presence in the multicloud environment. >> Talk a little bit about the solution that you're using with Hitachi and, and the challenges that it is eradicated. >> Yeah, so it end of the day, right, we we need to focus on our core competence. So, so we have got a very strong technology leadership team. We've got a very strong presence in the respective domains of each of the portfolio companies. But where Hitachi comes in and HAR comes in as a solution is that they allow us to excel in focusing on our core business and then make sure that we are able to take care of workload management or financial transparency. All of that is taken off the table from us and and Hitachi manages it for us, right? So it's such a perfectly compliment relationship where they act as two partners and HARC is a solution that is extremely useful in driving that. And, and and I'm anticipating that it'll become more important with time as the complexity of cloud and cloud associate workloads are only becoming more challenging to manage and not less. >> Right? That's the thing that complexity is there and it's also increasing Param, you talked about the complexities that are existent today with respect to cloud operations the things that have happened over the last couple of years. What are some of your tips, Param for the audience, like the the top two or three things that you would say on cloud operations that that people need to understand so that they can manage that complexity and allow their business to be driven and complimented by technology? >> Yeah, a big great question again, Lisa, right? And I think Manoj alluded to a few of these things as well. The first one is in the new world of the cloud I think think of migration, modernization and management as a single continuum to the cloud. Now there is no lift and shift and there is no way somebody else separately manages it, right? If you do not lift and shift the right applications the right way onto the cloud, you are going to deal with the complexity of managing it and you'll end up spending more money time and effort in managing it. So that's number one. Migration, modernization, management of cloud work growth is a single continuum and it's not three separate activities, right? That's number one. And the, the second is cost. Cost traditionally has been an afterthought, right? People move the workload to the cloud. And I think, again, like I said, I'll refer back to what Manoj said once we move it to the cloud and then we put all these fancy engineering capability around self-provisioning, every developer can go and ask for what he or she wants and they get an environment immediately spun up so on and so forth. Suddenly the CIO wakes up to a bill that is significantly larger than what he or she expected right? And, and this is this is become a bit common nowadays, right? The the challenge is because we think cost in the cloud as an afterthought. But consider this example in, in previous world you buy hard, well, you put it in your data center you have already amortized the cost as a CapEx. So you can write an application throw it onto the infrastructure and the application continues to use the infrastructure until you hit a ceiling, you don't care about the money you spent. But if I write a line of code that is inefficient today and I deploy it on the cloud from minute one, I am paying for the inefficiency. So if I realize it after six months, I've already spent the money. So financial discipline, especially when managing the cloud is now is no more an afterthought. It is as much something that you have to include in your engineering practice as much as any other DevOps practices, right? Those are my top two tips, Lisa, from my standpoint, think about cloud, think about cloud work, cloud workloads. And the last one again, and you will see you will hear me saying this again and again, get into the mindset of everything is code. You don't have a touch and feel infrastructure anymore. So you don't really need to have foot on the ground to go manage that infrastructure. It's codified. So your code should be managing it, but think of how it happens, right? That's where we, we are going as an evolution >> Everything is code. That's great advice, great tips for the audience there. Manoj, I'll bring you back into the conversation. You know, we, we can talk about skills gaps on on in many different facets of technology the SRE role, relatively new, skillset. We're hearing, hearing a lot about it. SRE led DevSecOps is probably even more so of a new skillset. If I'm an IT leader or an application leader how do I ensure that I have the right skillset within my organization to be able to manage my cloud operations to, to dial down that complexity so that I can really operate successfully as a business? >> Yeah. And so unfortunately there is no perfect answer, right? It's such a, such a scarce skillset that a, any day any of the portfolio company CTOs if I go and talk and say, Hey here's a great SRE team member, they'll be more than willing to fight with each of to get the person in right? It's just that scarce of a skillset. So, so a few things we need to look at it. One is, how can I build it within, right? So nobody gets born as an SRE, you, you make a person an SRE. So how do you inculcate that culture? So like Param said earlier, right? Everything is software. So how do we make sure that everybody inculcates that as part of their operating philosophy be they part of the operations team or the development team or the testing team they need to understand that that is a common guideline and common objective that we are driving towards. So, so that skillset and that associated training needs to be driven from within the organization. And that in my mind is the fastest way to make sure that that role gets propagated across organization. That is one. The second thing is rely on the right partners. So it's not going to be possible for us, to get all of these roles built in-house. So instead prioritize what roles need to be done from within the organization and what roles can we rely on our partners to drive it for us. So that becomes an important consideration for us to look at as well. >> Absolutely. That partnership angle is incredibly important from, from the, the beginning really kind of weaving these companies together on this journey to to redefine cloud operations and build that, as we talked about at the beginning of the conversation really building a cloud center of excellence that allows the organization to be competitive, successful and and really deliver what the end user is, is expecting. I want to ask - Sorry Lisa, - go ahead. >> May I add something to it, I think? >> Sure. >> Yeah. One of the, one of the common things that I tell customers when we talk about SRE and to manages point is don't think of SRE as a skillset which is the common way today the industry tries to solve the problem. SRE is a mindset, right? Everybody in >> Well well said, yeah >> That, so everybody in a company should think of him or her as a cycle liability engineer. And everybody has a role in it, right? Even if you take the new process layout from SRE there are individuals that are responsible to whom we can go to when there is a problem directly as opposed to going through the traditional ways of AI talk to L one and L one contras all. They go to L two and then L three. So we, we, we are trying to move away from an issue escalation model to what we call as a a issue routing or a incident routing model, right? Move away from incident escalation to an incident routing model. So you get to route to the right folks. So again, to sum it up, SRE should not be solved as a skillset set because there is not enough people in the market to solve it that way. If you start solving it as a mindset I think companies can get a handhold of it. >> I love that. I've actually never heard that before, but it it makes perfect sense to think about the SRE as a mindset rather than a skillset that will allow organizations to be much more successful. Param I wanted to get your thoughts as enterprises are are innovating, they're moving more products and services to the as a service model. Talk about how the dev teams the ops teams are working together to build and run reliable, cost efficient services. Are they working better together? >> Again, a a very polarizing question because some customers are getting it right many customers aren't, there is still a big wall between development and operations, right? Even when you think about DevOps as a terminology the fundamental principle was to make sure dev and ops works together. But what many companies have achieved today, honestly is automating the operations for development. For example, as a developer, I can check in code and my code will appear in production without any friction, right? There is automated testing, automated provisioning and it gets promoted to production, but after production, it goes back into the 20 year old model of operating the code, right? So there is more work that needs to be done for Devon and Ops to come closer and work together. And one of the ways that we think this is achievable is not by doing radical org changes, but more by focusing on a product-oriented single backlog approach across development and operations. Which is, again, there is change management involved but I think that's a way to start embracing the culture of dev ops coming together much better now, again SRE principles as we double click and understand it more and Google has done a very good job playing it out for the world. As you think about SRE principle, there are ways and means in that process of how to think about a single backlog. And in HARC, Hitachi Application Reliability Centers we've really got a way to look at prioritizing the backlog. And what I mean by that is dev teams try to work on backlog that come from product managers on features. The SRE and the operations team try to put backlog into the say sorry, try to put features into the same backlog for improving stability, availability and financials financial optimization of your code. And there are ways when you look at your SLOs and error budgets to really coach the product teams to prioritize your backlog based on what's important for you. So if you understand your spending more money then you reduce your product features going in and implement the financial optimization that came from your operations team, right? So you now have the ability to throttle these parameters and that's where SRE becomes a mindset and a principle as opposed to a skillset because this is not an individual telling you to do. This is the company that is, is embarking on how to prioritize my backlog beyond just user features. >> Right. Great point. Last question for both of you is the same talk kind of take away things that you want me to remember. If I am at an IT leader at, at an organization and I am planning on redefining CloudOps for my company Manoj will start with you and then Param to you what are the top two things that you want me to walk away with understanding how to do that successfully? >> Yeah, so I'll, I'll go back to basics. So the two things I would say need to be taken care of is, one is customer experience. So all the things that I do end of the day is it improving the customer experience or not? So that's a first metric. The second thing is anything that I do is there an ROI by doing that incremental step or not? Otherwise we might get lost in the technology with surgery, the new tech, et cetera. But end of the day, if the customers are not happy if there is no ROI, everything else you just can't do much on top of that >> Now it's all about the customer experience. Right? That's so true. Param what are your thoughts, the the top things that I need to be taking away if I am a a leader planning to redefine my cloud eye company? >> Absolutely. And I think from a, from a company standpoint I think Manoj summarized it extremely well, right? There is this ROI and there is this customer experience from my end, again, I'll, I'll suggest two two more things as a takeaway, right? One, cloud cost is not an afterthought. It's essential for us to think about it upfront. Number two, do not delink migration modernization and operations. They are one stream. If you migrate a long, wrong workload onto the cloud you're going to be stuck with it for a long time. And an example of a wrong workload, Lisa for everybody that that is listening to this is if my cost per transaction profile doesn't change and I am not improving my revenue per transaction for a piece of code that's going run in production it's better off running in a data center where my cost is CapEx than amortized and I have control over when I want to upgrade as opposed to putting it on a cloud and continuing to pay unless it gives me more dividends towards improvement. But that's a simple example of when we think about what should I migrate and how will it cost pain when I want to manage it in the longer run. But that's, that's something that I'll leave the audience and you with as a takeaway. >> Excellent. Guys, thank you so much for talking to me today about what Hitachi Vantara and GTCR are doing together how you've really dialed down those complexities enabling the business and the technology folks to really live harmoniously. We appreciate your insights and your perspectives on building a cloud center of excellence. Thank you both for joining me. >> Thank you. >> For my guests, I'm Lisa. Martin, you're watching this event building Your Cloud Center of Excellence with Hitachi Vantara. Thanks for watching. (Upbeat music playing) (Upbeat music playing) (Upbeat music playing) (Upbeat music playing)

(gentle bright music) >> Okay, welcome back to our "Supercloud 2" event live coverage here at stage performance in Palo Alto syndicating around the world. I'm John Furrier with Dave Vellante. We've got exclusive news and a scoop here for SiliconANGLE and theCUBE. Zhamak Dehghani, creator of data mesh has formed a new company called NextData.com NextData, she's a cube alumni and contributor to our Supercloud initiative, as well as our coverage and breaking analysis with Dave Vellante on data, the killer app for Supercloud. Zhamak, great to see you. Thank you for coming into the studio and congratulations on your newly formed venture and continued success on the data mesh. >> Thank you so much. It's great to be here. Great to see you in person. >> Dave: Yeah, finally. >> John: Wonderful. Your contributions to the data conversation has been well-documented certainly by us and others in the industry. Data mesh taking the world by storm. Some people are debating it, throwing, you know, cold water on it. Some are, I think, it's the next big thing. Tell us about the data mesh super data apps that are emerging out of cloud. >> I mean, data mesh, as you said, it's, you know, the pain point that it surfaced were universal. Everybody said, "Oh, why didn't I think of that?" You know, it was just an obvious next step and people are approaching it, implementing it. I guess the last few years, I've been involved in many of those implementations, and I guess Supercloud is somewhat a prerequisite for it because it's data mesh and building applications using data mesh is about sharing data responsibly across boundaries. And those boundaries include boundaries, organizational boundaries cloud technology boundaries and trust boundaries. >> I want to bring that up because your venture, NextData which is new, just formed. Tell us about that. What wave is that riding? What specifically are you targeting? What's the pain point? >> Zhamak: Absolutely, yes. So next data is the result of, I suppose, the pains that I suffered from implementing a database for many of the organizations. Basically, a lot of organizations that I've worked with, they want decentralized data. So they really embrace this idea of decentralized ownership of the data, but yet they want interconnectivity through standard APIs, yet they want discoverability and governance. So they want to have policies implemented, they want to govern that data, they want to be able to discover that data and yet they want to decentralize it. And we do that with a developer experience that is easy and native to a generalist developer. So we try to find, I guess, the common denominator that solves those problems and enables that developer experience for data sharing. >> John: Since you just announced the news, what's been the reaction? >> Zhamak: I just announced the news right now, so what's the reaction? >> John: But people in the industry that know you, you did a lot of work in the area. What have been some of the feedback on the new venture in terms of the approach, the customers, problem? >> Yeah, so we've been in stealth modes, so we haven't publicly talked about it, but folks that have been close to us in fact have reached out. We already have implementations of our pilot platform with early customers, which is super exciting. And we're going to have multiple of those. Of course, we're a tiny, tiny company. We can have many of those where we are going to have multiple pilots, implementations of our platform in real world. We're real global large scale organizations that have real world problems. So we're not going to build our platform in vacuum. And that's what's happening right now. >> Zhamak: When I think about your role at ThoughtWorks, you had a very wide observation space with a number of clients helping them implement data mesh and other things as well prior to your data mesh initiative. But when I look at data mesh, at least the ones that I've seen, they're very narrow. I think of JPMC, I think of HelloFresh. They're generally obviously not surprising. They don't include the big vision of inclusivity across clouds across different data stores. But it seems like people are having to go through some gymnastics to get to, you know, the organizational reality of decentralizing data, and at least pushing data ownership to the line of business. How are you approaching or are you approaching, solving that problem? Are you taking a narrow slice? What can you tell us about Next Data? >> Zhamak: Sure, yeah, absolutely. Gymnastics, the cute word to describe what the organizations have to go through. And one of those problems is that, you know, the data, as you know, resides on different platforms. It's owned by different people, it's processed by pipelines that who owns them. So there's this very disparate and disconnected set of technologies that were very useful for when we thought about data and processing as a centralized problem. But when you think about data as a decentralized problem, the cost of integration of these technologies in a cohesive developer experience is what's missing. And we want to focus on that cohesive end-to-end developer experience to share data responsibly in this autonomous units, we call them data products, I guess in data mesh, right? That constitutes computation, that governs that data policies, discoverability. So I guess, I heard this expression in the last talks that you can have your cake and eat it too. So we want people have their cakes, which is, you know, data in different places, decentralization and eat it too, which is interconnected access to it. So we start with standardizing and codifying this idea of a data product container that encapsulates data computation, APIs to get to it in a technology agnostic way, in an open way. And then, sit on top and use existing existing tech, you know, Snowflake, Databricks, whatever exists, you know, the millions of dollars of investments that companies have made, sit on top of those but create this cohesive, integrated experience where data product is a first class primitive. And that's really key here, that the language, and the modeling that we use is really native to data mesh is that I will make a data product, I'm sharing a data product, and that encapsulates on providing metadata about this. I'm providing computation that's constantly changing the data. I'm providing the API for that. So we're trying to kind of codify and create a new developer experience based on that. And developer, both from provider side and user side connected to peer-to-peer data sharing with data product as a primitive first class concept. >> Okay, so the idea would be developers would build applications leveraging those data products which are discoverable and governed. Now, today you see some companies, you know, take a snowflake for example. >> Zhamak: Yeah. >> Attempting to do that within their own little walled garden. They even, at one point, used the term, "Mesh." I dunno if they pull back on that. And then they sort of became aware of some of your work. But a lot of the things that they're doing within their little insulated environment, you know, support that, that, you know, governance, they're building out an ecosystem. What's different in your vision? >> Exactly. So we realize that, you know, and this is a reality, like you go to organizations, they have a snowflake and half of the organization happily operates on Snowflake. And on the other half, oh, we are on, you know, bare infrastructure on AWS, or we are on Databricks. This is the realities, you know, this Supercloud that's written up here. It's about working across boundaries of technology. So we try to embrace that. And even for our own technology with the way we're building it, we say, "Okay, nobody's going to use next data mesh operating system. People will have different platforms." So you have to build with openness in mind, and in case of Snowflake, I think, you know, they have I'm sure very happy customers as long as customers can be on Snowflake. But once you cross that boundary of platforms then that becomes a problem. And we try to keep that in mind in our solution. >> So, it's worth reviewing that basically, the concept of data mesh is that, whether you're a data lake or a data warehouse, an S3 bucket, an Oracle database as well, they should be inclusive inside of the data. >> We did a session with AWS on the startup showcase, data as code. And remember, I wrote a blog post in 2007 called, "Data's the new developer kit." Back then, they used to call 'em developer kits, if you remember. And that we said at that time, whoever can code data >> Zhamak: Yes. >> Will have a competitive advantage. >> Aren't there machines going to be doing that? Didn't we just hear that? >> Well we have, and you know, Hey Siri, hey Cube. Find me that best video for data mesh. There it is. I mean, this is the point, like what's happening is that, now, data has to be addressable >> Zhamak: Yes. >> For machines and for coding. >> Zhamak: Yes. >> Because as you need to call the data. So the question is, how do you manage the complexity of big things as promiscuous as possible, making it available as well as then governing it because it's a trade off. The more you make open >> Zhamak: Definitely. >> The better the machine learning. >> Zhamak: Yes. >> But yet, the governance issue, so this is the, you need an OS to handle this maybe. >> Yes, well, we call our mental model for our platform is an OS operating system. Operating systems, you know, have shown us how you can kind of abstract what's complex and take care of, you know, a lot of complexities, but yet provide an open and, you know, dynamic enough interface. So we think about it that way. We try to solve the problem of policies live with the data. An enforcement of the policies happens at the most granular level which is, in this concept, the data product. And that would happen whether you read, write, or access a data product. But we can never imagine what are these policies could be. So our thinking is, okay, we should have a open policy framework that can allow organizations write their own policy drivers, and policy definitions, and encode it and encapsulated in this data product container. But I'm not going to fool myself to say that, you know, that's going to solve the problem that you just described. I think we are in this, I don't know, if I look into my crystal ball, what I think might happen is that right now, the primitives that we work with to train machine-learning model are still bits and bites in data. They're fields, rows, columns, right? And that creates quite a large surface area, an attack area for, you know, for privacy of the data. So perhaps, one of the trends that we might see is this evolution of data APIs to become more and more computational aware to bring the compute to the data to reduce that surface area so you can really leave the control of the data to the sovereign owners of that data, right? So that data product. So I think the evolution of our data APIs perhaps will become more and more computational. So you describe what you want, and the data owner decides, you know, how to manage the- >> John: That's interesting, Dave, 'cause it's almost like we just talked about ChatGPT in the last segment with you, who's a machine learning, could really been around the industry. It's almost as if you're starting to see reason come into the data, reasoning. It's like you starting to see not just metadata, using the data to reason so that you don't have to expose the raw data. It's almost like a, I won't say curation layer, but an intelligence layer. >> Zhamak: Exactly. >> Can you share your vision on that 'cause that seems to be where the dots are connecting. >> Zhamak: Yes, this is perhaps further into the future because just from where we stand, we have to create still that bridge of familiarity between that future and present. So we are still in that bridge-making mode, however, by just the basic notion of saying, "I'm going to put an API in front of my data, and that API today might be as primitive as a level of indirection as in you tell me what you want, tell me who you are, let me go process that, all the policies and lineage, and insert all of this intelligence that need to happen. And then I will, today, I will still give you a file. But by just defining that API and standardizing it, now we have this amazing extension point that we can say, "Well, the next revision of this API, you not just tell me who you are, but you actually tell me what intelligence you're after. What's a logic that I need to go and now compute on your API?" And you can kind of evolve that, right? Now you have a point of evolution to this very futuristic, I guess, future where you just describe the question that you're asking from the chat. >> Well, this is the Supercloud, Dave. >> I have a question from a fan, I got to get it in. It's George Gilbert. And so, his question is, you're blowing away the way we synchronize data from operational systems to the data stack to applications. So the concern that he has, and he wants your feedback on this, "Is the data product app devs get exposed to more complexity with respect to moving data between data products or maybe it's attributes between data products, how do you respond to that? How do you see, is that a problem or is that something that is overstated, or do you have an answer for that?" >> Zhamak: Absolutely. So I think there's a sweet spot in getting data developers, data product developers closer to the app, but yet not burdening them with the complexity of the application and application logic, and yet reducing their cognitive load by localizing what they need to know about which is that domain where they're operating within. Because what's happening right now? what's happening right now is that data engineers, a ton of empathy for them for their high threshold of pain that they can, you know, deal with, they have been centralized, they've put into the data team, and they have been given this unbelievable task of make meaning out of data, put semantic over it, curates it, cleans it, and so on. So what we are saying is that get those folks embedded into the domain closer to the application developers, these are still separately moving units. Your app and your data products are independent but yet tightly closed with each other, tightly coupled with each other based on the context of the domain, so reduce cognitive load by localizing what they need to know about to the domain, get them closer to the application but yet have them them separate from app because app provides a very different service. Transactional data for my e-commerce transaction, data product provides a very different service, longitudinal data for the, you know, variety of this intelligent analysis that I can do on the data. But yet, it's all within the domain of e-commerce or sales or whatnot. >> So a lot of decoupling and coupling create that cohesiveness. >> Zhamak: Absolutely. >> Architecture. So I have to ask you, this is an interesting question 'cause it came up on theCUBE all last year. Back on the old server, data center days and cloud, SRE, Google coined the term, "Site Reliability Engineer" for someone to look over the hundreds of thousands of servers. We asked a question to data engineering community who have been suffering, by the way, agree. Is there an SRE-like role for data? Because in a way, data engineering, that platform engineer, they are like the SRE for data. In other words, managing the large scale to enable automation and cell service. What's your thoughts and reaction to that? >> Zhamak: Yes, exactly. So, maybe we go through that history of how SRE came to be. So we had the first DevOps movement which was, remove the wall between dev and ops and bring them together. So you have one cross-functional units of the organization that's responsible for, you build it you run it, right? So then there is no, I'm going to just shoot my application over the wall for somebody else to manage it. So we did that, and then we said, "Okay, as we decentralized and had this many microservices running around, we had to create a layer that abstracted a lot of the complexity around running now a lot or monitoring, observing and running a lot while giving autonomy to this cross-functional team." And that's where the SRE, a new generation of engineers came to exist. So I think if I just look- >> Hence Borg, hence Kubernetes. >> Hence, hence, exactly. Hence chaos engineering, hence embracing the complexity and messiness, right? And putting engineering discipline to embrace that and yet give a cohesive and high integrity experience of those systems. So I think, if we look at that evolution, perhaps something like that is happening by bringing data and apps closer and make them these domain-oriented data product teams or domain oriented cross-functional teams, full stop, and still have a very advanced maybe at the platform infrastructure level kind of operational team that they're not busy doing two jobs which is taking care of domains and the infrastructure, but they're building infrastructure that is embracing that complexity, interconnectivity of this data process. >> John: So you see similarities. >> Absolutely, but I feel like we're probably in a more early days of that movement. >> So it's a data DevOps kind of thing happening where scales happening. It's good things are happening yet. Eh, a little bit fast and loose with some complexities to clean up. >> Yes, yes. This is a different restructure. As you said we, you know, the job of this industry as a whole on architects is decompose, recompose, decompose, recomposing a new way, and now we're like decomposing centralized team, recomposing them as domains and- >> John: So is data mesh the killer app for Supercloud? >> You had to do this for me. >> Dave: Sorry, I couldn't- (John and Dave laughing) >> Zhamak: What do you want me to say, Dave? >> John: Yes. >> Zhamak: Yes of course. >> I mean Supercloud, I think it's, really the terminology's Supercloud, Opencloud. But I think, in spirits of it, this embracing of diversity and giving autonomy for people to make decisions for what's right for them and not yet lock them in. I think just embracing that is baked into how data mesh assume the world would work. >> John: Well thank you so much for coming on Supercloud too, really appreciate it. Data has driven this conversation. Your success of data mesh has really opened up the conversation and exposed the slow moving data industry. >> Dave: Been a great catalyst. (John laughs) >> John: That's now going well. We can move faster, so thanks for coming on. >> Thank you for hosting me. It was wonderful. >> Okay, Supercloud 2 live here in Palo Alto. Our stage performance, I'm John Furrier with Dave Vellante. We're back with more after this short break, Stay with us all day for Supercloud 2. (gentle bright music)

(upbeat music) >> Welcome back to our Supercloud 2 event live coverage here of stage performance in Palo Alto syndicating around the world. I'm John Furrier with Dave Vellante. We got exclusive news and a scoop here for SiliconANGLE in theCUBE. Zhamak Dehghani, creator of data mesh has formed a new company called Nextdata.com, Nextdata. She's a cube alumni and contributor to our supercloud initiative, as well as our coverage and Breaking Analysis with Dave Vellante on data, the killer app for supercloud. Zhamak, great to see you. Thank you for coming into the studio and congratulations on your newly formed venture and continued success on the data mesh. >> Thank you so much. It's great to be here. Great to see you in person. >> Dave: Yeah, finally. >> Wonderful. Your contributions to the data conversation has been well documented certainly by us and others in the industry. Data mesh taking the world by storm. Some people are debating it, throwing cold water on it. Some are thinking it's the next big thing. Tell us about the data mesh, super data apps that are emerging out of cloud. >> I mean, data mesh, as you said, the pain point that it surface were universal. Everybody said, "Oh, why didn't I think of that?" It was just an obvious next step and people are approaching it, implementing it. I guess the last few years I've been involved in many of those implementations and I guess supercloud is somewhat a prerequisite for it because it's data mesh and building applications using data mesh is about sharing data responsibly across boundaries. And those boundaries include organizational boundaries, cloud technology boundaries, and trust boundaries. >> I want to bring that up because your venture, Nextdata, which is new just formed. Tell us about that. What wave is that riding? What specifically are you targeting? What's the pain point? >> Absolutely. Yes, so Nextdata is the result of, I suppose the pains that I suffered from implementing data mesh for many of the organizations. Basically a lot of organizations that I've worked with they want decentralized data. So they really embrace this idea of decentralized ownership of the data, but yet they want interconnectivity through standard APIs, yet they want discoverability and governance. So they want to have policies implemented, they want to govern that data, they want to be able to discover that data, and yet they want to decentralize it. And we do that with a developer experience that is easy and native to a generalist developer. So we try to find the, I guess the common denominator that solves those problems and enables that developer experience for data sharing. >> Since you just announced the news, what's been the reaction? >> I just announced the news right now, so what's the reaction? >> But people in the industry know you did a lot of work in the area. What have been some of the feedback on the new venture in terms of the approach, the customers, problem? >> Yeah, so we've been in stealth mode so we haven't publicly talked about it, but folks that have been close to us, in fact have reached that we already have implementations of our pilot platform with early customers, which is super exciting. And we going to have multiple of those. Of course, we're a tiny, tiny company. We can have many of those, but we are going to have multiple pilot implementations of our platform in real world where real global large scale organizations that have real world problems. So we're not going to build our platform in vacuum. And that's what's happening right now. >> Zhamak, when I think about your role at ThoughtWorks, you had a very wide observation space with a number of clients, helping them implement data mesh and other things as well prior to your data mesh initiative. But when I look at data mesh, at least the ones that I've seen, they're very narrow. I think of JPMC, I think of HelloFresh. They're generally, obviously not surprising, they don't include the big vision of inclusivity across clouds, across different data storage. But it seems like people are having to go through some gymnastics to get to the organizational reality of decentralizing data and at least pushing data ownership to the line of business. How are you approaching, or are you approaching solving that problem? Are you taking a narrow slice? What can you tell us about Nextdata? >> Yeah, absolutely. Gymnastics, the cute word to describe what the organizations have to go through. And one of those problems is that the data as you know resides on different platforms, it's owned by different people, is processed by pipelines that who knows who owns them. So there's this very disparate and disconnected set of technologies that were very useful for when we thought about data and processing as a centralized problem. But when you think about data as a decentralized problem the cost of integration of these technologies in a cohesive developer experience is what's missing. And we want to focus on that cohesive end-to-end developer experience to share data responsibly in these autonomous units. We call them data products, I guess in data mesh. That constitutes computation. That governs that data policies, discoverability. So I guess, I heard this expression in the last talks that you can have your cake and eat it too. So we want people have their cakes, which is data in different places, decentralization, and eat it too, which is interconnected access to it. So we start with standardizing and codifying this idea of a data product container that encapsulates data computation APIs to get to it in a technology agnostic way, in an open way. And then sit on top and use existing tech, Snowflake, Databricks, whatever exists, the millions of dollars of investments that companies have made, sit on top of those but create this cohesive, integrated experience where data product is a first class primitive. And that's really key here. The language and the modeling that we use is really native to data mesh, which is that I'm building a data product I'm sharing a data product, and that encapsulates I'm providing metadata about this. I'm providing computation that's constantly changing the data. I'm providing the API for that. So we we're trying to kind of codify and create a new developer experience based on that. And developer, both from provider side and user side, connected to peer-to-peer data sharing with data product as a primitive first class concept. >> So the idea would be developers would build applications leveraging those data products, which are discoverable and governed. Now today you see some companies, take a Snowflake for example, attempting to do that within their own little walled garden. They even at one point used the term mesh. I don't know if they pull back on that. And then they became aware of some of your work. But a lot of the things that they're doing within their little insulated environment support that governance, they're building out an ecosystem. What's different in your vision? >> Exactly. So we realized that, and this is a reality, like you go to organizations, they have a Snowflake and half of the organization happily operates on Snowflake. And on the other half, "oh, we are on Bare infrastructure on AWS or we are on Databricks." This is the reality. This supercloud that's written up here, it's about working across boundaries of technology. So we try to embrace that. And even for our own technology with the way we're building it, we say, "Okay, nobody's going to use Nextdata, data mesh operating system. People will have different platforms." So you have to build with openness in mind and in case of Snowflake, I think, they have very, I'm sure very happy customers as long as customers can be on Snowflake. But once you cross that boundary of platforms then that becomes a problem. And we try to keep that in mind in our solution. >> So it's worth reviewing that basically the concept of data mesh is that whether you're a data lake or a data warehouse, an S3 bucket, an Oracle database as well, they should be inclusive inside of the data. >> We did a session with AWS on the startup showcase, data as code. And remember I wrote a blog post in 2007 called "Data as the New Developer Kit" back then we used to call them developer kits if you remember. And that we said at that time, whoever can code data will have a competitive advantage. >> Aren't the machines going to be doing that? Didn't we just hear that? >> Well, we have. Hey, Siri. Hey, Cube, find me that best video for data mesh. There it is. But this is the point, like what's happening is that now data has to be addressable. for machines and for coding because as you need to call the data. So the question is how do you manage the complexity of big things as promiscuous as possible, making it available, as well as then governing it? Because it's a trade off. The more you make open, the better the machine learning. But yet the governance issue, so this is the, you need an OS to handle this maybe. >> Yes. So yes, well we call, our mental model for our platform is an OS operating system. Operating systems have shown us how you can abstract what's complex and take care of a lot of complexities, but yet provide an open and dynamic enough interface. So we think about it that way. Just, we try to solve the problem of policies live with the data, an enforcement of the policies happens at the most granular level, which is in this concept of the data product. And that would happen whether you read, write or access a data product. But we can never imagine what are these policies could be. So our thinking is we should have a policy, open policy framework that can allow organizations write their own policy drivers and policy definitions and encode it and encapsulated in this data product container. But I'm not going to fool myself to say that, that's going to solve the problem that you just described. I think we are in this, I don't know, if I look into my crystal ball, what I think might happen is that right now the primitives that we work with to train machine learning model are still bits and bytes and data. They're fields, rows, columns and that creates quite a large surface area and attack area for privacy of the data. So perhaps one of the trends that we might see is this evolution of data APIs to become more and more computational aware to bring the compute to the data to reduce that surface area. So you can really leave the control of the data to the sovereign owners of that data. So that data product. So I think that evolution of our data APIs perhaps will become more and more computational. So you describe what you want and the data owner decides how to manage. >> That's interesting, Dave, 'cause it's almost like we just talked about ChatGPT in the last segment we had with you. It was a machine learning have been around the industry. It's almost as if you're starting to see reason come into, the data reasoning is like starting to see not just metadata. Using the data to reason so that you don't have to expose the raw data. So almost like a, I won't say curation layer, but an intelligence layer. >> Zhamak: Exactly. >> Can you share your vision on that? 'Cause that seems to be where the dots are connecting. >> Yes, perhaps further into the future because just from where we stand, we have to create still that bridge of familiarity between that future and present. So we are still in that bridge making mode. However, by just the basic notion of saying, "I'm going to put an API in front of my data." And that API today might be as primitive as a level of indirection, as in you tell me what you want, tell me who you are, let me go process that, all the policies and lineage and insert all of this intelligence that need to happen. And then today, I will still give you a file. But by just defining that API and standardizing it now we have this amazing extension point that we can say, "Well, the next revision of this API, you not just tell me who you are, but you actually tell me what intelligence you're after. What's a logic that I need to go and now compute on your API?" And you can evolve that. Now you have a point of evolution to this very futuristic, I guess, future where you just described the question that you're asking from the ChatGPT. >> Well, this is the supercloud, go ahead, Dave. >> I have a question from a fan, I got to get it in. It's George Gilbert. And so his question is, you're blowing away the way we synchronize data from operational systems to the data stack to applications. So the concern that he has and he wants your feedback on this, is the data product app devs get exposed to more complexity with respect to moving data between data products or maybe it's attributes between data products? How do you respond to that? How do you see? Is that a problem? Is that something that is overstated or do you have an answer for that? >> Absolutely. So I think there's a sweet spot in getting data developers, data product developers closer to the app, but yet not overburdening them with the complexity of the application and application logic and yet reducing their cognitive load by localizing what they need to know about, which is that domain where they're operating within. Because what's happening right now? What's happening right now is that data engineers with, a ton of empathy for them for their high threshold of pain that they can deal with, they have been centralized, they've put into the data team, and they have been given this unbelievable task of make meaning out of data, put semantic over it, curate it, cleans it, and so on. So what we are saying is that get those folks embedded into the domain closer to the application developers. These are still separately moving units. Your app and your data products are independent, but yet tightly closed with each other, tightly coupled with each other based on the context of the domain. So reduce cognitive load by localizing what they need to know about to the domain, get them closer to the application, but yet have them separate from app because app provides a very different service. Transactional data for my e-commerce transaction. Data product provides a very different service. Longitudinal data for the variety of this intelligent analysis that I can do on the data. But yet it's all within the domain of e-commerce or sales or whatnot. >> It's a lot of decoupling and coupling create that cohesiveness architecture. So I have to ask you, this is an interesting question 'cause it came up on theCUBE all last year. Back on the old server data center days and cloud, SRE, Google coined the term, site reliability engineer, for someone to look over the hundreds of thousands of servers. We asked the question to data engineering community who have been suffering, by the way, I agree. Is there an SRE like role for data? Because in a way data engineering, that platform engineer, they are like the SRE for data. In other words managing the large scale to enable automation and cell service. What's your thoughts and reaction to that? >> Yes, exactly. So maybe we go through that history of how SRE came to be. So we had the first DevOps movement, which was remove the wall between dev and ops and bring them together. So you have one unit of one cross-functional units of the organization that's responsible for you build it, you run it. So then there is no, I'm going to just shoot my application over the wall for somebody else to manage it. So we did that and then we said, okay, there is a ton, as we decentralized and had these many microservices running around, we had to create a layer that abstracted a lot of the complexity around running now a lot or monitoring, observing, and running a lot while giving autonomy to this cross-functional team. And that's where the SRE, a new generation of engineers came to exist. So I think if I just look at. >> Hence, Kubernetes. >> Hence, hence, exactly. Hence, chaos engineering. Hence, embracing the complexity and messiness. And putting engineering discipline to embrace that and yet give a cohesive and high integrity experience of those systems. So I think if we look at that evolution, perhaps something like that is happening by bringing data and apps closer and make them these domain-oriented data product teams or domain-oriented cross-functional teams full stop and still have a very advanced maybe at the platform level, infrastructure level operational team that they're not busy doing two jobs, which is taking care of domains and the infrastructure, but they're building infrastructure that is embracing that complexity, interconnectivity of this data process. >> So you see similarities? >> I see, absolutely. But I feel like we're probably in a more early days of that movement. >> So it's a data DevOps kind of thing happening where scales happening. It's good things are happening, yet a little bit fast and loose with some complexities to clean up. >> Yes. This is a different restructure. As you said, the job of this industry as a whole, an architect, is decompose recompose, decompose recompose in new way and now we're like decomposing centralized team, recomposing them as domains. >> So is data mesh the killer app for supercloud? >> You had to do this to me. >> Sorry, I couldn't resist. >> I know. Of course you want me to say this. >> Yes. >> Yes, of course. I mean, supercloud, I think it's really, the terminology supercloud, open cloud, but I think in spirits of it this embracing of diversity and giving autonomy for people to make decisions for what's right for them and not yet lock them in. I think just embracing that is baked into how data mesh assume the world would work. >> Well, thank you so much for coming on Supercloud 2. We really appreciate it. Data has driven this conversation. Your success of data mesh has really opened up the conversation and exposed the slow moving data industry. >> Dave: Been a great catalyst. >> That's now going well. We can move faster. So thanks for coming on. >> Thank you for hosting me. It was wonderful. >> Supercloud 2 live here in Palo Alto, our stage performance. I'm John Furrier with Dave Vellante. We'll back with more after this short break. Stay with us all day for Supercloud 2. (upbeat music)

(gentle music) >> Now welcome back to theCUBE, everyone. I'm John Walls, and once again, we're glad to have you here for AWS re:Invent 22. Our coverage continues here on Thursday, day three, of what has been a jam-packed week of tech and AWS, of course, has been the great host for this. It's now a pleasure to welcome in Anurag Gupta, who is the founder and CEO of Shoreline, joining us here as part of the AWS Global Showcase Startup Program, and Anurag, good to see you, sir. Thanks for joining us. >> Thank you so much. >> Tell us about Shoreline, about what you're up to. >> So we're a DevOps company. We're really focused on repairing issues. If you think about it, there are a ton DevOps companies and we all went to the cloud in order to gain faster innovation and by and large check. Then all of the things involved in getting things into production, artifact generation, testing, configuration management, deployment, also by and large, automated. Now pity the poor SRE who's getting the deluge of stuff on them, every week, every two days, sometimes multiple times a day, and it's complicated, right? Kubernetes, VMs, lots of services, multiple clouds, sometimes, and you know, they need to know a little bit about everything. And you know what, there are a ton of companies that actually help you with what we call Day-2 Ops. It's just that most of them help you with observability, telling you what's gone wrong, or incident management, routing something to someone. But you know, back when I was at AWS, I never got really that excited about one more dashboard to look at or one more like better ticket routing. What used to really excite me was having some issue extinguished forever. And if you think about it, like the first five minutes of an incident are detecting and routing. The next hour, two hours, is some human being going in and fixing it, so that feels like the big opportunity to reduce, so hopefully we can talk a little bit about different ways that one can do that. >> What about Day-2 Ops? Just tell me about how you define that. >> So I basically define it as once the software goes into a production, just making sure things stay up and are healthy and you're resilient and you don't get errors and all of those sorts of things because everything breaks sooner or later, you know, to a greater or lesser degree. >> Especially that SRE you're talking about, right? >> Yeah. >> So let's go back to that scenario. Yeah, you pity the poor soul because they do have to be a little expert in everything. >> Exactly. >> And that's really challenging and we all know that, that's really hard. So how do you go about trying to lighten that burden, then? >> So when you look at the numbers, about somewhere between 40% to even 95% of the alarms that fire, the alerts that fire, are false positives and that's crazy. Why is someone waking up just to deal with? >> It's a lot of wasted time, isn't it? >> A lot of wasted time. And you know, you're also training someone into what I call ClickOps, just to go in and click the button and resolve it and you don't actually know if it was the false positive or it's the rare real positive, and so that's a challenge, right? And so the first thing to do is to figure out where the false positives are. Like, let's say Datadog tells you that CPU is high and alarms. Is that a good thing or a bad thing? It's hard for them to tell, right? But you have to then introspect it into something precise like, oh, CPU is high, but response times are standard and the request rate is high. Okay, that's a good thing. I'm going to ignore this. Or CPU is high, but it kind of resolves itself, so I'm going to not wake anybody up. Or CPU is high and oh, it's the darn JVM starting to garbage collect again, so let me go and take a heap dump and give that to my dev team and then bounce the JVM and you know, without waking anybody up, or CPU is high, I have no idea what's going on. Now it's time to wake somebody up. You know, what you want to use humans for is the ability to think about novel stuff, not to do repetitive stuff, so that's the first step. The second step is, about 40% of what remains is repetitive and straightforward. So like a disk is full, I'd better clean up the garbage on the disk or maybe grow the disk. People shouldn't wake up to deal to grow a disk. And so for that, what you want to do is just have those sorts of things get automated away. One of the nice things about Shoreline is, is that we take the experience in what we build for one company, and if they're willing, provide it to everybody else. Our belief is, a central tenant is, if someone somewhere fixes something, everyone everywhere should gain the benefit because we all sit on the same three clouds, we all sit on the same set of database infrastructure, et cetera. We should all get the same benefits. Why do we have to scar our own backs rather than benefiting from somebody else's scar tissue, so that's the second thing. The third thing is, okay, let's say it's not straightforward, not something I've seen before, then in that case, what often happens is on average like eight people get involved. You know, it initially goes to L1 support or L1 ops and, but they don't necessarily know because, as you say, the environment's complex. And so, you know, they go into Slack and they say, "At here, can somebody help me with this?" And those things take a much longer time, so wouldn't it be better that if your best SRE is able to say, "Hey, check these 20 things and then run these actions." We could convert that into like a Jupyter Notebook where you could say the incident got fired I pre-populated all the diagnostics, and then I tell people very precisely, "If you see this, run this, et cetera." Like a wiki, but actually something you could run right in this product. And then, you know, last piece of the puzzle, the smaller piece, is sometimes new things happen and when something new happens, what you want is sort of the central tech of Shoreline, which is parallel distributed, real-time debugging. And so the ability to do, you know, execute a command across your fleet rather than individual boxes so that you can say something like, "I'm hearing that my credit card app is slow. For everything tagged as being part of my credit card app, please run for everything that's running over 90% CPU, please run a top command." And so, you know, then you can run in the same time on one host as you can on 30,000 and that helps a lot. So that's the core of what we do. People use us for all sorts of things, also preventative maintenance, you know, just the proactive regular things. You know, like your car, you do an oil change, well, you know, you need to rotate your certs, certificates. You need to make sure that, you know, there isn't drift in your configurations, there isn't drift in your software. There's also security elements to it, right? You want to make sure that you aren't getting weird inbound/outbound traffic across to ports you don't expect to be open. You don't want to have these processes running, you know, maybe something's bad. And so that's all the kind of weird anomaly detection that's easy to do if you run things in a distributed parallel way across everything. That's super hard to do if you have to go and Whac-A-Mole across one box after the next. >> Well, which leads to a question just in terms of setting priorities then, which is what you're talking about helping companies establish priorities, this hierarchy of level one warning, level two, level three, level four. Sounds like that should be a basic, right? But you're saying that's not, that's not really happening in the enterprise. >> Well, you know, I would say that if you hadn't automated deployments, you should do that first. If you haven't automated your testing pipeline, shame on you, you should do that like a year ago. But now it's time to help people in production because you've done that other work and people are suffering. You know, the crazy thing about the cloud is, is that companies spend about three times more on the human beings to operate their cloud infrastructure as on the cloud infrastructure itself. I've yet to hear anybody say that their cloud bill is too low, you know, so, you know, there's a clearer savings also available. And you know, back when I was at AWS, obviously I had to keep the lights on too, but you know, I had to do that, but it's kind of a tax on my engineers and I'd really spend, prefer to spend the head count on innovation, on doing things that delight my customers. You never delight your customers by keeping the lights on, you just avoid irritating them by turning 'em off, right? >> So why are companies so fixed in on spending so much time on manually repairing things and not looking for these kinds of little, much more elegant solution and cost-efficient, time-saving, so on so forth. >> Yeah, I think there just hasn't been very much in this space as yet because it's a hard, hard problem to solve. You know, automation's a little bit scary and that's the reality of it and the way you make it less scary is by proving it out, by doing the simple things first, like reducing the alert fatigue, you know, that's easy. You know, providing notebooks to people so that they can click things and do things in a straightforward way. That's pretty easy. The full automation, that's kind of the North Star, that's what we aspire to do. But you know, people get there over time and one of our customers had 700 instances of this particular incident solved for them last week. You imagine how many human beings would've been doing it otherwise, you know? >> Right. >> That's just one thing, you know? >> How many did it take the build a pyramid? How many decades did that take, right? You had an announcement this week. I don't think we've talked about that. >> No, yeah, so we just announced Incident Insights, which is a free product that lets people plug into initially PagerDuty and pretty soon the Opsgenie ServiceNow, et cetera. And what you can do is, is you give us an API key read-only and we will suck your PagerDuty data out. We apply some lightweight ML unsupervised learning, and in a couple of minutes, we categorize all of your incidents so that you can understand which are the ones that happen most often and are getting resolved really quickly. That's ClickOps, right? Those alarms shouldn't fire. Which are the ones that involve a lot of people? Those are good candidates to build a notebook. Which are the ones that happen again and again and again? Those are good candidates for automation. And so, I think one of the challenges people have is, is that they don't actually know what their teams are doing and so this is intended to provide them that visibility. One of our very first customers was doing the beta test for us on it. He used to tell us he had about 100 tickets, incidents a week. You know, he brought this tool in and he had 2,100 last week and was all, you know, like these false alarms, so while he's giving us- >> That was eye opening for him to see that, sure. >> And why he's, you know, looking at it, you know, he's just like filing Jiras to say, "Oh, change this threshold, cancel this alarm forever." You know, all of that kind of stuff. Before you get to do the fancy work, you got to clean your room before you get to do anything else, right? >> Right, right, dinner before dessert, basically. >> There you go. >> Hey, thanks for the insights on this and again the name of the new product, by the way, is... >> Incident Insights. >> Incident Insights. >> Totally free. >> Free. >> Yeah, it takes a couple of minutes to set up. Go to the website, Shoreline.io/insight and you can be up and running in a couple of minutes. >> Outstanding, again, the company is Shoreline. This is Anurag Gupta, and thank you for being with us. We appreciate it. >> Appreciate it, thank you. >> Glad to have to here on theCUBE. Back with more from AWA re:Invent 22. You're watching theCUBE, the leader in high-tech coverage. (gentle music)

>>Hey everyone, it's Vegas. Welcome back. We know you've been watching all day. We appreciate that. We always love being able to bring you some great content on the Cube Live from AWS Reinvented 22. Lisa Martin here with Paul Gill. And Paul, we've had such a great event. We've, I think we've done nearly 70 interviews since we started on the Cube on >>Monday night. I believe we just hit 70. Yeah, we just hit 70. You must feel like you've done half of >>Them. I really do. But we've been having great conversations. There's so much innovation going on at aws. Nothing slowed them down during the pandemic. We love also talking about the innovation, the flywheel that is their partner ecosystem. We're gonna have a great conversation about that >>Next. And as we've said, going back to day one, the energy of the show is remarkable. And here we are, we're getting late in the afternoon on day two, and there's just as much activity, just as much energy out there as, as the beginning of the first day. I have no doubt day three will be the >>Same. I agree. There's been no slowdown. We've got two guests here. We're gonna have a great conversation. Chuck Kubota joins us, senior Director of Cloud Services, GTM at Red Hat. Great to have you on the program. And Ted Stanton, global head of Sales, red Hat at IBM at aws. Welcome. >>Thanks for having us. >>How's the show going so far for you guys? >>It's a blur. Is it? Oh my gosh. >>Don't they all >>Blur? Well, yes, yes. I actually like last year a bit better. It was half the size. Yeah. And a lot easier to get around, but this is back to normal, so >>It is back to normal. Yeah. And and Ted, we're hearing north of 50,000 in-person attendees. I heard a, something I think was published. I heard the second hand over like 300,000 online attendees. This is maybe the biggest one we ever had. >>Yeah, yeah, I would agree. And frankly, it's my first time here, so I am massively impressed with the overall show, the meeting with partners, the meeting with customers, the announcements that were made, just fantastic. And >>If you remember back to two years ago, there were a lot of questions about whether in-person conferences would ever return and the volume that we used to see them. And that appears to be >>The case. I think we, I think we've answered, I think AWS has answered that for us, which I'm very pleased to see. Talk about some of those announcements. Ted. There's been so much that that's always one of the things we know and love about re men is there's slew of announcements. You were saying this morning, Paul, and then keynote, you lost, you stopped counting after I >>Lost 15, I lost count for 15. I think it was over 30 announcements this morning alone >>Where IBM and Red Hat are concern. What are some of the things that you are excited about in terms of some of the news, the innovation, and where the partnership is going? >>Well, definitely where the partnership is going, and I think even as we're speaking right now, is a keynote going on with Aruba, talking about some of the partners and the way in which we support partners and the new technologies and the new abilities for partners to take advantage of these technologies to frankly delight our customers is really what most excites me. >>Chuck, what about you? What's going on with Red Hat? You've been there a long time. Sales, everything, picking up customers, massively transforming. What are some of the things that you're seeing and that you're excited >>About? Yeah, I mean, first of all, you know, as customers have, you know, years ago discovered it's not competitively advantageous to manage their own data centers in most cases. So they would like to, you know, give that responsibility to Amazon. We're seeing them move further up the stack, right? So that would be more beyond the operating system, the application platforms like OpenShift. And now we have a managed application platform built on OpenShift called Red Out OpenShift service on AWS or Rosa. And then we're even further going up the stack with that with, we just announced this week that red out OpenShift data science is available in the AWS marketplace, runs on Rosa, helps break the land speed record to getting those data models out there that are so important to make, you know, help organizations become more, much more data driven to remain competitive themselves. >>So talk about Rosa and how it differs from previous iterations of, of OpenShift. I mean, you had, you had an online version of OpenShift several years ago. What's different about Rosa? >>Yeah, so the old OpenShift online that was several years old, right? For one thing, wasn't a joint partnership between Amazon and Red Hat. So we work together, right? Very closely on this, which is great. Also, the awesome thing about Rosa, you know, if you think about like OpenShift for, for, as a matter of fact, Amazon is the number one cloud that OpenShift runs on, right? So a lot of those customers want to take advantage of their committed spins, their EDPs, they want one bill. And so Rosa comes through the one bill comes through the marketplace, right? Which is, which is totally awesome. Not only that or financially backing OpenShift with a 99.95% financially backed sla, right? We didn't have that before either, right? >>When you say financially backed sla, >>What do you mean? That means that if we drop below 99.95% of availability, we're gonna give you some money back, right? So we're really, you know, for lack of better words, putting our money where our mouth is. Absolutely right. >>And, and some of the key reasons that we even work together to build Rosa was frankly we've had a mirror of customers and virtually every single region, every single industry been using OpenShift on AWS for years, right? And we listened to them, they wanted a more managed version of it and we worked very closely together. And what's really great about Rosa too is we built some really fantastic integrations with some of the AWS native services like API gateway, Amazon rds, private link, right? To make it very simple and easy for customers to get started. We talked a little bit about the marketplace, but it's also available just on the AWS console, right? So customers can get started in a pay as you go fashion start to use it. And if they wanna move into a more commitment, more of a set schedule of payments, they can move into a marketplace private offer. >>Chuck, talk about, how about Rosen? How is unlocking the power of technology like containers Kubernetes for customers while dialing down some of the complexity that's >>There? Yeah, I mean if you think about, you know, kind of what we did, you know, earlier on, right? If you think about like virtualization, how it dialed down the complexity of having to get something rack, get a blade rack, stack cable and cooled every time you wanted to deploy new application, right? So what we do is we, our message is this, we want developers to focus on what matters most. And that's build, deploy, and running applications. Most of our customers are not in the business of building app platforms. They're not in the business of building platforms like banks, I, you know, financials, right? Government, et cetera. Right? So what we do is we allow those developers that are, enable those developers that know Java and Node and springing and what have you, just to keep writing what they know. And then, you know, I don't wanna get too technical here, but get pushed through way and, and OpenShift takes care of the rest, builds it for them, runs it through a pipeline, a CICD pipeline, goes through all the testing and quality gates and things like that, deploys it, auto wires it up, you know, to monitoring which is what you need. >>And we have all kinds of other, you know, higher order services and an ecosystem around that. And oh, by the way, also plugging into and taking advantage of the services like rds, right? If you're gonna write an application, a tradition, a cloud native application on Amazon, you're probably going to wanna run it in Rosa and consuming one of those databases, right? Like RDS or Aurora, what have you. >>And I, and I would say it's not even just the customers. We have a variety of ecosystem partners, both of our partners leveraging it as well. We have solos built their executive management system that they go ahead and turn and sell to their customers, streamlines data and collects data from a variety of different sources. They decided, you know, it's better to run that on top of Rosa than manage OpenShift themselves. We've seen IBM restack a lot of their software, you know, to run on top of Rose, take advantage of that capabilities. So lots of partners as well as customers are taking advantage of fully managed stack of that OpenShift that that turnkey capabilities that it provides >>For, for OpenShift customers who wanna move to Rose, is that gonna be a one button migration? Is that gonna be, can they run both environments simultaneously and migrate over time? What kind of tools are you giving them? >>We have quite, we have quite a few migration tools such as conveyor, right? That's one of our projects, part of our migration application toolkit, right? And you know, with those, there's also partners like Trilio, right? Who can help move, you know, applications back 'em up. In fact, we're working on a pretty cool joint go to market with that right now. But generally speaking, the OpenShift experience that the customers that we have know and love and those who have never used OpenShift either are coming to it as well via Rosa, right? The experience is primarily the same. You don't have to really retrain your people, right? If anything, there's a reduction in operational cost. We increase developer productivity cuz we manage so much of the stack for you. We have SRE site reliability engineers that are backing the platform that proactively get ahead of anything that may go wrong. So maybe you don't even notice if something went wrong, wrong. And then also reactively fixing it if it comes to that, right? So, you know, all those kind of things that your customers are having to do on their own or hire a contractor, a consultant, what have to do Now we benefit from a managed offering in the cloud, right? In Amazon, right? And your developers still have that great experience too, like to say, you know, again, break the land speed record to prod. >>I >>Like that. And, and I would actually say migrations from OpenShift are on premise. OpenShift to Rosa maybe only represents about a third of the customers we have. About another third of the customers is frankly existing AWS customers. Maybe they're doing Kubernetes, do it, the, you know, do it themselves. We're struggling with some of the management of that. And so actually started to lean on top of using Rosa as a better platform to actually build upon their applications. And another third, we have quite a few customers that were frankly new OpenShift customers, new Red Hat customers and new AWS customers that were looking to build that next cloud native application. Lots of in the startup space that I've actually chosen to go with Rosa. >>It's funny you mention that because the largest Rosa consumer is new to OpenShift. Oh wow. Right. That's pretty, that's pretty powerful, right? It's not just for existing OpenShift customers, existing OpenShift. If you're running OpenShift, you know, on EC two, right. Self-managed, there's really no better way to run it than Rosa. You know, I think about whether this is the 10th year, 10 year anniversary of re right? Right. Yep. This is also the 10 year anniversary of OpenShift. Yeah, right. I think it one oh came out about sometime around a week, 10 years ago, right? When I came over to Red Hat in 2015. You know, if you, if you know your Kubernetes history was at July 25th, I think was when Kubernetes ga, July 25th, 2015 is when it g you have >>A good >>Memory. Well I remember those days back then, right? Those were fun, right? The, we had a, a large customer roll out on OpenShift three, which is our OpenShift RE based on Kubernetes. And where do you think they ran Amazon, right? Naturally. So, you know, as you move forward and, and, and OpenShift V four came out, the, reduces the operational complexity and becomes even more powerful through our operator framework and things like that. Now they revolved up to Rosa, right? And again, to help those customers focus on what matters most. And that's the applications, not the containers, not those underlying implementation and technical details while critically important, are not necessarily core to the business to most of our customers. >>Tremendous amount of innovation in OpenShift in a decade, >>Pardon me? >>Tremendous amount of innovation in OpenShift in the >>Last decade. Oh absolutely. And, and and tons more to come like every day. Right. I think what you're gonna see more of is, you know, as Kubernetes becomes more, more and more of the plumbing, you know, I call 'em productive abstractions on top of it, as you mentioned earlier, unlocking the power of these technologies while minimizing, even hiding the complexity of them so that you can just move fast Yeah. And safely move fast. >>I wanna be sure we get to, to marketplaces because you have been, red Hat has made, has really stepped up as commitment to the AWS marketplace. Why are you doing that now and how are, how are the marketplaces evolving as a channel for you? >>Well, cuz our customers want us to be there, right? I mean we, we, we are customer centric, customer first approach. Our customers want to buy through the marketplace. If you're an Amazon, if you're an Amazon customer, it's really easy for you to go procure software through the marketplace and have, instead of having to call up Red Hat and get on paper and write a second check, right? One stop shop one bill. Right? That is very, very attractive to our customers. Not only that, it opens up other ways to buy, you know, Ted mentioned earlier, you know, pay as you go buy the drink pricing using exactly what you need right now. Right? You know, AWS pioneered that, right? That provides that elasticity, you know, one of the core tenants at aws, AWS cloud, right? And we weren't able to get that with the traditional self-managed on Red Hat paper subscriptions. >>Talk a little bit about the go to market, what's, you talked about Ted, the kind of the three tenants of, of customer types. But talk a little bit about the gtm, the joint go to market, the joint engineering, so we get an understanding of how customers engage multiple options. >>Yeah, I mean, so if you think about go to market, you know, and the way I think of it is it's the intersection of a few areas, right? So the product and the product experience that we work together has to be so good that a customer or user, actually many start talk, talking about users now cuz it's self-service has a more than likely chance of getting their application to prod without ever talking to a person. Which is historically not what a lot of enterprise software companies are able to do, right? So that's one of those biggest things we do. We want customers to just be successful, turn it on, get going, be productive, right? At the same time we wanna to position the product in such a way that's differentiating that you can't get that experience anywhere else. And then part of that is ensuring that the education and enablement of our customers and our partners as such that they use the platform the right way to get as much value out of as possible. >>All backed by, you know, a very smart field that ensures that the customer get is making the right decision. A customer success org, this is attached to my org now that we can go on site and team with our customers to make sure that they get their first workloads up as quickly as possible, by the way, on our date, our, our dime. And then SRE and CEA backing that up with support and operational integrity to ensure that the service is always up and available so you can sleep, sleep, sleep well at night. Right? Right. One of our PMs of, of of Rosa, he says, what does he say? He says, Rosa allows organizations, enables organizations to go from 24 7 operations to nine to five innovation. Right? And that's powerful. That's how our customers remain more competitive running on Rosa with aws, >>When you're in customer conversations and you have 30 seconds, what are the key differentiators of the solution that you go boom, boom, boom, and they just go, I get it. >>Well, I mean, my 32nd elevator pitch, I think I've already said, I'll say it again. And that is OpenShift allows you to focus on your applications, build, deploy, and run applications while unlocking the power of the technologies like containers and Kubernetes and hiding or minimizing those complexities. So you can do as fast as possible. >>Mic drop Ted, question for you? Sure. Here we are at the, this is the, I leave the 11th reinvent, 10th anniversary, 11th event. You've been in the industry a long time. What is your biggest takeaway from what's been announced and discussed so far at Reinvent 22, where the AWS and and its partner ecosystem is concerned? If you had 30 seconds or if you had a bumper sticker to put on your DeLorean, what would you say? >>I would say we're continuing to innovate on behalf of our customers, but making sure we bring all of our partners and ecosystems along in that innovation. >>Yeah. I love the customer obsession on both sides there. Great work guides. Congrats on the 10th anniversary of OpenShift and so much evolution, the customer obsession is really clear for both of you guys. We appreciate your time. You're gonna have to come back now. Absolutely. Absolutely. Thank you. All right. Thank you so much for joining us. For our guests and for Paul Gillin. I'm Lisa Martin. You're watching The Cube, the leader in live enterprise and emerging tech coverage.

>>Hey guys. Welcome back to Detroit, Michigan. Lisa Martin and John Furrier here live with the cube at Coan Cloud Native Con North America. John, it's been a great day. This is day one of our coverage of three days of coverage. Kubernetes is growing up. Yeah, it's maturing. >>Yeah. We got three days of wall to wall coverage, all about Kubernetes. We about security, large scale, cloud native at scale. That's the big focus. This next segment's gonna be really awesome. You have a fast growing private company and a practitioner, big name, blue chip practitioner, building out next NextGen Cloud first, transforming, then building out the next level. This is classic of what we call super cloud-like, like interview. It's gonna be great. I'm looking forward >>To this anytime we can talk about Super Cloud. All right, please welcome back. One of our alumni, Bani is here, the CEO of Rafe. Great to see you Santos. Ula also joins us, the global head of Cloud SRE at Mass Mutual. Ge. Great to have you on the program. Thanks >>For having us. Thank you for having me. >>So Steve, you've been on the queue many times. You were on just recently with the momentum that that's around us today with the maturation of Kubernetes, the collaboration of the community, the recognition of the community. What are some of the things that you're excited about with on, on day one of the show? >>Wow, so many new companies. I mean, there are companies that I don't know who are here. And I, I, I live in this industry and I'm seeing companies that I don't know, which is a good thing. I mean, it means that the, the community's growing. But at the same time, I'm also seeing another thing, which is I have met more enterprise representatives at this show than other coupons. Like when we hung out at, you know, in Valencia for example, or even, you know, other places. It hasn't been this many people, which means, and this is, this is a good thing that enterprises are now taking Kubernetes seriously. It's not a toy. It's not just for developers. It's enterprises who are now investing in Kubernetes as a foundational component, right. For their applications going forward. And that to me is very, very good. >>Definitely becoming foundational. >>Yep. Well, you guys got a great traction. We had many interviews at the Cube and you got a practitioner here with you. You guys are both pioneering kind of what I call the next gen cloud. First you gotta get through gen one, which you guys done at Mass Mutual, extremely well, take us through the story of your transformation. Cause you're on the, at the front end now of that next inflection point. But take us through how you got here. You had a lot of transformation success at Mass Mutual. >>So I was actually talking about this topic few, few minutes back, right? And, and the whole cloud journey in big companies, large financial institutions, healthcare industry or, or our insurance sector. It takes generations of leadership to get, to get to that perfection level. And, and ideally the, the, the cloud for strategy starts in, and then, and then how do you, how do you standardize and optimize cloud, right? You know, that that's, that's the second gen altogether. And then operationalization of the cloud. And especially if, you know, if you're talking about Kubernetes, you know, in the traditional world, you know, almost every company is running middleware and their applications in middleware. And then containerization is a topic that come, that came in. And docker is, is you know, basically the runtime containerization. So that came in first and from Docker, you know, eventually when companies started adopting Docker, Docker Swarm is one of the technologies that they adopted. And eventually when, when, when we were taking it to a more complicated application implementations or modernization efforts, that's when Kubernetes played a key role. And, and Hasi was pointing out, you know, like you never saw so many companies working on Kubernetes. So that should tell you one story, right? How fast Kubernetes is growing and how important it is for your cloud strategy. So, >>And your success now, and what are you thinking about now? What's on your agenda now as you look forward? What's on your plate? What are you guys doing right now? >>So we are, we are past the stage of, you know, proof of concepts, proof of technologies, pilot implementations. We are actually playing it, you know, the real game now. So in the past I used the quote, you know, like, hello world to real world. So we are actually playing in the real world, not, not in the hello world anymore. Now, now this is where the real time challenges will, will pop up, right? So if you're talking about standardizing it and then optimizing the cloud and how do you put your governance structure in place? How do you make sure your regulations are met? You know, the, the, the demands that come out of regulations are met and, and how, how are you going to scale it and, and, and while scaling, however you wanna to keep up with all the governance and regulations that come with it. So we are in that stage today. >>Has Steve talked about, you talked about the great evolution of what's going on at Mass Mutual has talked a little bit about who, you mentioned one of the things that's surprising you about this Coan and Detroit is that you're seeing a lot more enterprise folks here who, who's deciding in the organization and your customer conversations, Who are the deci decision makers in terms of adoption of Kubernetes these days? Is that elevating? >>Hmm. Well this guy, >>It's usually, you know, one of the things I'm seeing here, and John and I have talked about this in the past, this idea of a platform organization and enterprises. So consistently what I'm seeing is, you know, somebody, a cto, CIO level, you know, individual is making a determin decision. I have multiple internal buss who are now modernizing applications. They're individually investing in DevOps. And this is not a good investment for my business. I'm going to centralize some of this capability so that we can all benefit together. And that team is essentially a platform organization and they're making Kubernetes a shared services platform so that everybody else can come and, and, and sort of, you know, consume it. So what that means to us is our customer is a platform organization and their customer is a developer. So we have to make two constituencies successful. Our customer who's providing a multi-tenant platform, and then their customer who's a developer, both have to be happy. If you don't solve for both, you know, constituencies, you're not gonna be >>Successful. You're targeting the builder of the infrastructure and the consumer of that infrastructure. >>Yes sir. It has to be both. Exactly. Right. Right. So, so that look, honestly, that it, it, you know, it takes iterations to figure these things out, right? But this is a consistent theme that I am seeing. In fact, what I would argue now is that every enterprise should be really stepping back and thinking about what is my platform strategy. Cuz if you don't have a platform strategy, you're gonna have a bunch of different teams who are doing different things and some will be successful and look, some will not be. And that is not good for business. >>Yeah. And, and stage, I wanna get to you, you mentioned that your transformation was what you look forward and your title, global head of cloud sre. Okay, so sre, we all know came from Google, right? Everyone wants to be like Google, but no one wants to be like Google, right? And no one is Google, Google's a unique thing. It's only one Google. But they had the dynamic and the power dynamic of one person to large scale set of servers or infrastructure. But concept is, is, is can be portable, but, but the situation isn't. So board became Kubernetes, that's inside baseball. So you're doing essentially what Google did at their scale you're doing for Mass Mutual. That's kind of what's happening. Is that kind of how I see it? And you guys are playing in there partnering. >>So I I totally agree. Google introduce, sorry, Ty engineering. And, and if you take, you know, the traditional transformation of the roles, right? In the past it was called operations and then DevOps ops came in and then SRE is is the new buzzword. And the future could be something like product engineering, right? And, and, and in this journey, you know, here is what I tell, you know, folks on my side like what worked for Google might not work for a financial company, might not work for an insurance company. So, so, so it's, it's okay to use the word sre, but but the end of the day that SRE has to be tailored down to, to your requirements and and, and the customers that you serve and the technology that you serve. Yep. >>And this is, this is why I'm coming back, this platform engineering. At the end of the day, I think SRE just translates to, you're gonna have a platform engineering team cuz you gotta enable developers to be producing more code faster, better, cheaper guardrails policy. So this, it's kind of becoming the, you serve the business, which is now the developers it used to serve the business Yep. Back in the old days. Hey, the, it serves the business. Yep. Which is a terminal, >>Which is actually true >>Now it the new, it serves the developers, which is the business. Which is the business. Because if digital transformation goes to completion, the company is the app. Yep. >>And the, you know, the, the hard line between development and operations, right? So, so that's thining down over the time, you know, like that that line might disappear. And, and, and that's where asari is fitting in. >>Yeah. And they're building platforms to scale the enablement up that what is, so what is the key challenges you guys are, are both building out together this new transformational direction? What's new and what's the same, The same is probably the business results, but what's the new dynamic involved in rolling it out and making people successful? You got the two constituents, the builders of the infrastructures and the consumers of the services on the other side. What's the new thing? >>So the new thing if, if I may go fast these, so the faster market to, you know, value, right? That we are bringing to the table. That's, that's very important. You know, business has an idea. How do you get that idea implemented in terms of technology and, and take it into real time. So that journey we have cut down, right? Technology is like Kubernetes. It makes, it makes, you know, an IT person's life so easy that, that they can, they can speed up the process in, in, in a traditional way. What used to take like an year or six months can be done in a month today or or less than that, right? So, so there's definitely the losses, speed, velocity, agility in general, and then flexibility. And then the automation that we put in, especially if you have to maintain like thousands of clusters, you know, these, these are today like, you know, it is possible to, to make that happen with a click off a button. In the past it used to take like, you know, probably, you know, a hundred, a hundred percent team and operational team to do it. And a lot of time. But, but, but that automation is happening. You know, and we can get into the technology as much as possible. But, but, you know, blueprinting and all that stuff made >>It possible. Well say that for another interview, we'll do it take time. >>But the, the end user on the other end, the consumer doesn't have the patience that they once had. Right? Right. It's, I want this in my lab now. Now, how does the culture of Mass Mutual, how is it evolv to be able to deliver the velocity that your customers are demanding? >>So if once in a while, you know, it's important to step yourself into the customer's shoes and think it from their, from their, from their perspective, business does not care how you're running your IT shop. What they care about is your stability of the product and the efficiencies of the product and, and, and how, how, how easy it is to reach out to the customers and how well we are serving the customers, right? So whether I'm implementing Docker in the background, Dr. Swam or es you know, business doesn't even care about it. What they really care about it is if your environment goes down, it's a problem. And, and, and if you, if your environment or if your solution is not as efficient as the business needs, that's the problem, right? So, so at that point, the business will step in. So our job is to make sure, you know, from an, from a technology perspective, how fast you can make implement it and how efficiently you can implement it. And at the same time, how do you play within the guardrails of security and compliance. >>So I was gonna ask you if you have VMware in your environment, cause a lot of clients compare what vCenter does for Kubernetes is really needed. And I think that's what you guys got going on. I I can say that you're the v center of Kubernetes. I mean, as a, as an as an metaphor, a place to manage it all is all 1, 1 1 paint of glass, so to speak. Is that how you see success in your environment? >>So virtualization has gone a long way, you know where we started, what we call bare metal servers, and then we virtualized operating systems. Now we are virtualizing applications and, and we are virtualizing platforms as well, right? So that's where Kubernetes basically got. >>So you see the need for a vCenter like thing for Uber, >>Definitely a need in the market in the way you need to think is like, you know, let's say there is, there is an insurance company who actually mented it and, and they gain the market advantage. Right? Now the, the the competition wants to do it as well, right? So, so, so there's definitely a virtualization of application layer that, that, that's very critical and it's, it's a critical component of cloud strategy as >>A whole. See, you're too humble to say it. I'll say you like the V center of Kubernetes, Explain what that means and your turn. If I said that to you, what would you react? How would you react to that? Would say bs or would you say on point, >>Maybe we should think about what does vCenter do today? Right? It's, it's so in my opinion, by the way, well vCenter in my opinion is one of the best platforms ever built. Like ha it's the best platform in my opinion ever built. It's, VMware did an amazing job because they took an IT engineer and they made him now be able to do storage management, networking management, VMs, multitenancy, access management audit, everything that you need to run a data center, you can do from a single, essentially single >>Platform, from a utility standpoint home >>Run. It's amazing, right? Yeah, it is because you are now able to empower people to do way more. Well why are we not doing that for Kubernetes? So the, the premise man Rafa was, well, oh, bless, I should have IT engineers, same engineers now they should be able to run fleets of clusters. That's what people that mass major are able to do now, right? So to that end, now you need cluster management, you need access management, you need blueprinting, you need policy management, you need ac, you know, all of these things that have happened before chargebacks, they used to have it in, in V center. Now they need to happen in other platforms. But for es so should do we do many of the things that vCenter does? Yes. >>Kind >>Of. Yeah. Are we a vCenter for es? Yeah, that is a John Forer question. >>All right, well, I, I'll, the speculation really goes back down to the earlier speed question. If you can take away the, the complexity and not make it more steps or change a tool chain or do something, then the devs move faster and the service layer that serves the business, the new organization has to enable speed. So this, this is becoming a, a real discussion point in the industry is that, oh yeah, we've got new tool, look at the shiny new toy. But if it doesn't move the needle, does it help productivity for developers? And does it actually scale up the enablement? That's the question. So I'm sure you guys are thinking about this a lot, what's your reaction? >>Yeah, absolutely. And one thing that just, you know, hit my mind is think about, you know, the hoteling industry before Airbnb and after Airbnb, right? Or, or, or the taxi industry, you know, before Uber and after Uber, right? So if I'm providing a platform, a Kubernetes platform for my application folks or for my application partners, they have everything ready. All they need to do is like, you know, build their application and deployed and running, right? They, they, they don't have to worry about provisioning of the servers and then building the middleware on top of it and then, you know, do a bunch of testing to make sure, you know, they, they, they iron out all the, all the compatible issues and whatnot. Yeah. Now, now, today, all I, all I say is like, hey, you have, we have a platform built for you. You just build your application and then deploy it in a development environment. That's where you put all the pieces of puzzle together, make sure you see your application working, and then the next thing that, that you do is like, you know, you know, build >>Production, chip, build production, go and chip release it. Yeah, that's the nirvana. But then we're there. I mean, we're there now we're there. So we see the future. Because if you, if that's the case, then the developers are the business. They have to be coding more features, they have to react to customers. They might see new business opportunities from a revenue standpoint that could be creatively built, got low code, no code, headless systems. These things are happening where this I call the architectural list environment where it's like, you don't need architecture, it's already happening. >>Yeah. And, and on top of it, you know, if, if someone has an idea, they want to implement an idea real quick, right? So how do you do it? Right? And, and, and you don't have to struggle building an environment to implement your idea and testers in real time, right? So, so from an innovation perspective, you know, agility plays a key role. And, and that, that's where the Kubernetes platforms or platforms like Kubernetes >>Plays. You know, Lisa, when we talked to Andy Chasy, when he was the CEO of aws, either one on one or on the cube, he always said, and this is kind of happening, companies are gonna be builders where it's not just utility. You need that table stakes to enable that new business idea. And so he, this last keynote, he did this big thing like, you know, think like your developers are the next entrepreneurial revenue generators. And I think that, I think starting to see that, what do you think about that? You see that coming sooner than later? Or is that in, in sight or is that still ways away? >>I, I think it's already happening at a level, at a certain level now. Now the question comes back to, you know, taking it to the reality, right? Yeah. I mean, you can, you can do your proof of concept, proof of technologies, and then, and then prove it out. Like, Hey, I got a new idea. This idea is great. Yeah. And, and it's to the business advantage, right? But we really want to see it in production live where your customers are actually >>Using it and the board meetings, Hey, we got a new idea that came in, generating more revenue, where'd that come from? Agile developer. Again, this is real. Yeah, >>Yeah. >>Absolutely agree. Yeah. I think, think both of you gentlemen said a word in, in your, as you were talking, you used the word guardrails, right? I think, you know, we're talking about rigidity, but you know, the really important thing is, look, these are enterprises, right? They have certain expectations. Guardrails is key, right? So it's automation with the guardrails. Yeah. Guardrails are like children, you know, you know, shouldn't be hurt. You know, they're seen but not hurt. Developers don't care about guard rails. They just wanna go fast. They also bounce >>Around a little bit. Yeah. Off the guardrails. >>One thing we know that's not gonna slow down is, is the expectations, right? Of all the consumers of this, the Ds the business, the, the business top line, and of course the customers. So the ability to, to really, as your website says, let's see, make life easy for platform teams is not trivial. And clearly what you guys are talking about here is you're, you're really an enabler of those platform teams, it sounds like to me. Yep. So, great work, guys. Thank you so much for both coming on the program, talking about what you're doing together, how you're seeing the, the evolution of Kubernetes, why, and really what the focus should be on those platform games. We appreciate all your time and your insights. >>Thank you so much for having us. Thanks >>For our pleasure. For our guests and for John Furrier, I'm Lisa Martin. You're watching The Cube Live, Cobe Con, Cloud Native con from Detroit. We've out with our next guest in just a minute, so stick around.

>>Good morning and welcome back to the Cube where we are excited to be broadcasting live all week from Detroit to Michigan at Cuban slash cloud Native con. Depending on who you're asking, Lisa, it's day two things are buzzing. How are you feeling? >>Good, excited. Ready for day two, ready to have more great conversations to see how this community is expanding, how it's evolving, and how it's really supporting it itself. >>Yeah, Yeah. This is a very supportive community. Something we talked a lot about. And speaking of community, we've got some very bold and brave folks over here. We've got this CTO and the head of product from Storm Forge, and they are on a mission to automate Kubernetes. Now automatic and Kubernetes are not words that go in the same sentence very often, so please welcome Patrick and Yasmin. Thank you both for being here. Hello. How you doing? >>Thanks for having us. >>Thanks for having us. >>Talk about what you guys are doing. Cause as you said, Kubernetes auto spelling is anything but auto. >>Yeah. >>The, what are some of the challenges? How do you help >>Eliminate this? Yeah, so the mission at Storm Forge is primarily automatic resource configuration and optimization essentially. So we started as a machine learning company first. And it's kind of an interesting story cuz we're one of those startups that has pivoted a few times. And so we were running our machine learning workloads. Most >>Have, I think, >>Right? Yeah. Yeah. We were, we started out running our machine learning workloads and moving them into Kubernetes. And then we weren't quite sure how to correctly adjust and size our containers. And so our ML team, we've got three PhDs and applied mathematics. They said, Well, hang on, we could write an algorithm for that. And so they did. And then, Oh, I love this. Yeah. And then we said, Well holy cow, that's actually really useful. I wonder if other people would like that. And that's kind of where we got our start. >>You solved your own problem and then you built a business >>Around it. Yeah, exactly. >>That is fantastic. Is, is that driving product development at Storm Forge still? That kind of attitude? >>I mean that kind of attitude definitely drives product development, but we're, you know, balancing that with what the users are, the challenges that they have, especially at large scale. We deal with a lot of large enterprises and for us as a startup, we can relate to the problems that come with Kubernetes when you're trying to scale it. But when you're talking about the scale of some of these larger enterprises, it's just a different mentality. So we're trying to balance that of how we take that input into how we build our product. Talk >>About that, like the, the end user input and how you're taking that in, because of course it's only going to be a, you know, more of a symbiotic relationship when that customer feedback is taken and >>Acted on. Yeah, totally. And for us, because we use machine learning, it's a lot of building confidence with our users. So making sure that they understand how we look at the data, how we come up with the recommendations, and actually deploy those changes in their environment. There's a lot of trust that needs to be built there. So being able to go back to our users and say, Okay, we're presenting you this type of data, give us your feedback and building it alongside them has helped a lot in these >>Relationships. Absolutely. You said the word trust, and that's something that we talk about at every >>Show. I was gonna jump on that too. It's >>Not, Yeah, it's not a buzzword. It's not, It shouldn't be. Yeah. It really should be, I wanna say lived and breathed, but that's probably grammatically incorrect. >>We're not a gram show. It's okay darling. Yeah, thank >>You. It should be truly embodied. >>Yeah. And I, I think it's, it's not even unique to just what we do, but across tech in general, right? Like when I talk about SRE and building SRE teams, one of the things I mentioned is you have to build that trust first. And with machine learning, I think it can be really difficult too for a couple different reasons. Like one, it tends to be a black box if it's actually true machine learning. Totally. Which ours is. But the other piece that we run into. Yeah. And the other piece we run into though is, is what I was an executive at United Health Group before I joined Storm Forge. And I would get companies that would come to me and try to sell me machine learning and I would kind of look at it and say, Well no, that's just a basic decision tree. Or like, that's a super basic whole winter forecast, right? Like that's not actually machine learning. And that's one of the things that we actually find ourselves kind of battling a little bit when we talk about what we do in building that trust. >>Talk a little bit about the latest release as you guys had a very active September. Here we are. And towards the, I think end of October. Yeah. What are some of the, the new things that have come out? New integrations, new partnerships. Give us a scoop on that. >>Yeah, well I guess I'll start and then I'll probably hand it over to you. But like the, the big thing for us is we talked about automating Kubernetes in the very beginning, right? Like Kubernetes has got a vpa it's >>A wild sentence anyway. Yeah, yeah. >>It it >>Has. We're not gonna get over at the whole show. Yeah. >>It as a VPA built in, it has an HPA built in and, and when you look at the data and even when you read the documentation from Google, it explicitly says never the two should meet. Right. Because you'll end up thrashing and they'll fight each other. Well the big release we just announced is with our machine learning, we can now do both. And so we vertically scale your pods to the correct up. Yeah. >>Follow status. I love that. >>Yeah, we can, we can scale your pods to the correct size and still allow you to enable the HPA and we'll make recommendations for your scaling points and your thresholds on the HPA as well so that they can work together to really truly maximize your efficiency that without sacrificing your performance and your reliability of the applications that you're running. That >>Sounds like a massive differentiator for >>Storm launch, which I would say it is. Yeah. I think as far as I know, we're the first in the industry that can do this. Yeah. >>And >>From very singularity vibes too. You know, the machines are learning, teaching themselves and doing it all automatically. Yep. Gets me very >>Excited. >>Yeah, absolutely. And from a customer demand perspective, what's the feedback been? Yeah, it's been a few >>Weeks. Yeah, it's been really great actually. And a lot of why we went down this path was user driven because they're doing horizontal scale and they want to be able to vertically size as they're scaling. So if you put yourself in the shoes of someone that's configuring Kubernetes, you're usually guessing on what you're setting your CPU requests and limits do. But horizontal scale makes sense. You're either adding more things or removing more things. And so once they actually are scaled out as a large environment and they have to rethink, how am I gonna resize this now? It's just not possible. It's so many thousands of settings across all the different environments and you're only thinking about CPU memory, You're not thinking about a lot of things. It's just, but once you scale that out, it's a big challenge. So they came to us and said, Okay, you're doing, cuz we were doing vertical scaling before and now we enable vertical and horizontal. And so they came to us and said, I love what you're doing about right sizing, but we wanna be able to do this while also horizontally scaling. And so the way that our software works is we give you the recommendations for what the setting should be and then allow Kubernetes to continue to add and remove replicas as needed. So it's not like we're going in and making changes to Kubernetes, but we make changes to the configuration settings so that it's the most optimal from a resource perspective. >>Efficiency has been a real big theme of the show. Yeah. And it's clear that that's a focus for you. Everyone here wants to do more faster Of course. And innovation, that's the thing to do that sometimes we need partners. You just announced an integration with Datadog. Tell us about that. Yeah, >>Absolutely. Yeah. So the way our platform works is we need data of course, right? So they're, they're a great partner for us and we use them both as an input and an output. So we pull in metrics from Datadog to provide recommendations and we'll actually display all those within the Datadog portal. Cause we have a lot of users that are like, Look, Datadog's my single pane of glass and I hate using that word, but they get all their insights there. They can see their recommendations and then actually go deploy those. Whether they wanna automatically have the recommendations deployed or go in and actually push a button. >>So give me an example of a customer that is using the, the new release and some of the business outcomes they're achieving. I imagine one of the things that you're enabling is just closing that ES skills gap. But from a business level perspective, how are they gaining like competitive advantages to be able to get products to market faster, for example? >>Yeah, so one of the customers that was actually part of our press release and launch and spoke about us at a webinar, they are a SaaS product and deal with really bursty workloads. And so their cloud costs have been growing 40% year over year. And their platform engineering team is basically enabled to provide the automation for developers and in their environment, but also to reduce those costs. So they want to, it's that trade off of resiliency and cost performance. And so they came to us and said, Look, we know we're over provisioned, but we don't know how to tackle that problem without throwing tons of humans at the problem. And so we worked with them and just on a single app found 60% savings and we're working now to kind of deploy that across their entire production workload. But that allows them to then go back and get more out of the, the budget that they already have and they can kind of reallocate that in other areas, >>Right? So there can be chop line and bottom >>Line impact. Yeah. And I, I think there's some really direct impact to the carbon emissions of an organization as well. That's a good point. When you can reduce your compute consumption by 60%. >>I love this. We haven't talked about this at all during the show. Yeah. And I'm really glad that you brought this up. All of the things that power this use energy. Yeah. >>What is it like seven to 8% of all electricity in the world is consumed by data centers. Like it's crazy. Yeah. Yeah. And so like that's wild. Yeah. Yeah. So being able to make a reduction in impact there too, especially with organizations that are trying to sign green pledges and everything else. >>It's hard. Yeah. ESG initiatives are huge. >>Absolut, >>It's >>A whole lot. A lot of companies have ESG initiatives where they can't even go out and do an RFP with a business, Right. If they don't have an actual active starting, impactful ESG program. Yes. Yeah. >>And the RFPs that we have to fill out, we have to tell them how they'll help. >>Yeah. Yes. It's so, yeah, I mean I was really struck when I looked on your website and I saw 54% average cost reduction for Yeah. For your cloud operations. I hadn't even thought about it from a power perspective. Yeah. I mean, imagine if we cut that to 3% of the world's power grid. That is just, that is very compelling. Speaking of compelling and exciting future things, talk to us about what's next? What's got you pumped for 2023 and and what lies >>Ahead? Oh man. Well that seems like a product conversation for sure. >>Well, we're super excited about extending what we do to other platforms, other metrics. So we optimize a lot right now around CPU and memory, but we can also give people insights into, you know, limiting kills, limiting CPU throttling, so extending the metrics. And when you look at hba and horizontal scale today, most of it is done with cpu, but there are some organizations out there that are scaling on custom metrics. So being able to take in more data to provide more recommendations and kind of extend what we can do from an optimization standpoint. >>That's, yeah, that's cool. And what house you most excited on the show floor? Anything? Anything that you've seen? Any keynotes? >>There's, Well, I haven't had a lot of time to go to the keynotes unfortunately, but it's, >>Well, I'm shock you've been busy or something, right? Much your time here. >>I can't imagine why. But no, there's, it's really interesting to see all the vendors that are popping up around Kubernetes focus specifically with security is always something that's really interesting to me. And automating CICD and how they continue to dive into that automation devs, SEC ops continues to be a big thing for a lot of organizations. Yeah. Yeah. >>I I do, I think it's interesting when we marry, Were you guys here last year? >>I was not here. >>No. So at, at the smaller version of this in Los Angeles. Yeah. I, I was really struck because there was still a conversation of whether or not we were all in on Kubernetes as, as kind of a community and a society this year. And I'm curious if you feel this way too. Everyone feels committed. Yeah. Yeah. I I I feel like there's no question that Kubernetes is the tool that we are gonna be using. >>Yeah. I I think so. And I think a lot of that is actually being unlocked by some of these vendors that are being partners and helping people get the most outta Kubernetes, you know, especially at the larger enterprise organizations. Like they want to do it, but the skills gap is a very real problem. Right. And so figuring out, like Jasmine talked about figuring out how do we, you know, optimize or set up the correct settings without throwing thousands of humans at it. Never mind the fact you'll never find a thousand people that wanna do that all day every day. >>I was gonna, It's a fold endeavor for those >>People study, right? Yeah. And, and being able to close some of those gaps, whether it's optimization, security, DevOps, C I C D. As we get more of those partners like I just talked about on the floor, then you see more and more enterprises being more open to leaning into Kubernetes a little bit. >>Yeah. Yeah. We've seen, we've had some great conversations the last day and, and today as well with organizations that are history companies like Ford Motor Companies for >>Example. Yeah. Right. >>Just right behind us. One of their EVs and, and it's, they're becoming technology companies that happen to do cars or home >>Here. I had a nice job with 'em this morning. Yes. With that storyline, honestly. >>Yes. That when we now have such a different lens into these organizations, how they're using technologies, advanced technologies, Kubernetes, et cetera, to really become data companies. Yeah. Because they have to be, well the consumers on the other end expect a Home Depot or a Ford or whomever or your bank Yeah. To know who you are. I want the information right here whenever I need it so I can do the transaction I need and I want you to also deliver me information that is relevant to me. Yeah. Because there, there's no patience anymore. Yeah. >>And we partner with a lot of big FinTech companies and it's, it's very much that. It's like how do we continue to optimize? But then as they look at transitioning off of older organizations and capabilities, whether that's, they have a physical data center that's racked to the gills and they can't do anything about that, so they wanna move to cloud or they're just dipping their toe into even private cloud with Kubernetes in their own instances. A lot of it is how do we do this right? Like how do we lean in and, Yeah. >>Yeah. Well I think you said it really well that the debate seems to be over in terms of do we go in on Kubernetes? That that was a theme that I think we felt that yesterday, even on on day one of the keynotes. The community seems to be just craving more. I think that was another thing that we felt yesterday was all of the contributors and the collaborators, people want to be able to help drive this community forward because it's, it's a flywheel of symbiosis for all of the vendors here. The maintainers and, and really businesses in any industry can benefit. >>Yeah. It's super validating. I mean if you just look at the floor, there's like 20 different booths that talk about cost reporting for Kubernetes. So not only have people moved, but now they're dealing with those challenges at scale. And I think for us it's very validating because there's so many vendors that are looking into the reporting of this and showing you the problem that you have. And then where we can help is, okay, now you know, you have a problem, here's how we can fix it for you. >>Yeah. Yeah. That, that sort of dealing with challenges at scale that you set, I think that's also what we're hearing. Yeah. And seeing and feeling on the show floor. >>Yeah, absolutely. >>What can folks see and, and touch and feel in your booth? >>We have some demos there you can play around with the product. We're giving away a Lego set so we've let >>Gotta gets >>Are right now we're gonna have to get some Lego, We do a swag segment at the end of the day every day. Now we've >>Some cool socks. >>Yep. Socks are hot. Let's, let's actually talk about scale internally as our closing question. What's going on at Storm Forge? If someone's watching right now, they're excited. Are you hiring? We are hiring. Yeah. How can they stalk you? What's the >>School? Absolutely. So you can check us out on Storm forge.io. We're certainly hiring across the engineering organization. We're hiring across the UX a product organization. We're dealing, like I said, we've got some really big customers that we're, we're working through with some really fun challenges. And we're looking to continue to build on what we do and do new innovative things like especially cuz like I said, we are a machine learning organization first. And so for me it's like how do I collect all the data that I can and then let's find out what's interesting in there that we can help people with. Whether that's cpu, memory, custom metrics, like as said, preventing kills, driving availability, reliability, What can we do to, to kind of make a little bit more transparent the stuff that's going on underneath the covers in Kubernetes for the decision makers in these organizations. >>Yes. Transparency is a goal of >>Many. >>Yeah, absolutely. Well, and you mentioned fun. If this conversation is any representation, it would be very fun to be working on both of your teams. We, we have a lot of fun Ya. Patrick, thank you so much for joining. Thanks for having us, Lisa, As usual, thanks for being here with me. My pleasure. And thank you to all of you for turning into the Cubes live show from Detroit. My name's Savannah Peterson and we'll be back in a few.

(bright upbeat music) >> Hey, guys. Welcome back to Detroit, Michigan. Lisa Martin and John Furrier here live with "theCUBE" at KubeCon CloudNativeCon, North America. John, it's been a great day. This is day one of our coverage of three days of coverage. Kubernetes is growing up. It's maturing. >> Yeah, we got three days of wall-to-wall coverage, all about Kubernetes. We heard about Security, Large scale, Cloud native at scale. That's the big focus. This next segment's going to be really awesome. You have a fast growing private company and a practitioner, big name, blue chip practitioner, building out next-gen cloud. First transforming, then building out the next level. This is classic, what we call Super Cloud-Like interview. It's going to be great. I'm looking forward to this. >> Anytime we can talk about Super Cloud, right? Please welcome back, one of our alumni, Haseeb Budhani is here, the CEO of Rafay. Great to see you. Santhosh Pasula, also joins us, the global head of Cloud SRE at Mass Mutual. Guys, great to have you on the program. >> Thanks for having us. >> Thank you for having me. >> So, Haseeb, you've been on "theCUBE" many times. You were on just recently, with the momentum that's around us today with the maturation of Kubernetes, the collaboration of the community, the recognition of the community. What are some of the things that you're excited about with on day one of the show? >> Wow, so many new companies. I mean, there are companies that I don't know who are here. And I live in this industry, and I'm seeing companies that I don't know, which is a good thing. It means that the community's growing. But at the same time, I'm also seeing another thing, which is, I have met more enterprise representatives at this show than other KubeCons. Like when we hung out at in Valencia, for example, or even other places, it hasn't been this many people. Which means, and this is a good thing that enterprises are now taking Kubernetes seriously. It's not a toy. It's not just for developers. It's enterprises who are now investing in Kubernetes as a foundational component for their applications going forward. And that to me is very, very good. >> Definitely, becoming foundational. >> Haseeb: Yeah. >> Well, you guys got a great traction. We had many interviews at "theCUBE," and you got a practitioner here with you guys, are both pioneering, kind of what I call the next-gen cloud. First you got to get through Gen-One, which you guys done at Mass Mutual extremely well. Take us through the story of your transformation? 'Cause you're on at the front end now of that next inflection point. But take us through how you got here? You had a lot of transformation success at Mass Mutual? >> So, I was actually talking about this topic few minutes back. And the whole cloud journey in big companies, large financial institutions, healthcare industry or insurance sector, it takes generations of leadership to get to that perfection level. And ideally, the cloud for strategy starts in, and then how do you standardize and optimize cloud, right? That's the second-gen altogether, and then operationalization of the cloud. And especially if you're talking about Kubernetes, in the traditional world, almost every company is running middleware and their applications in middleware. And their containerization is a topic that came in. And Docker is basically the runtime containerization. So, that came in first, and from Docker, eventually when companies started adopting Docker, Docker Swarm is one of the technologies that they adopted. And eventually, when we were taking it to a more complicated application implementations or modernization efforts, that's when Kubernetes played a key role. And as Haseeb was pointing out, you never saw so many companies working on Kubernetes. So, that should tell you one story, right? How fast Kubernetes is growing, and how important it is for your cloud strategy. >> And your success now, and what are you thinking about now? What's on your agenda now? As you look forward, what's on your plate? What are you guys doing right now? >> So we are past the stage of proof of concepts, proof of technologies, pilot implementations. We are actually playing it, the real game now. In the past, I used the quote, like "Hello world to real world." So, we are actually playing in the real world, not in the hello world anymore. Now, this is where the real time challenges will pop up. So, if you're talking about standardizing it, and then optimizing the cloud, and how do you put your governance structure in place? How do you make sure your regulations are met? The demands that come out of regulations are met? And how are you going to scale it? And while scaling, how are you going to keep up with all the governance and regulations that come with it? So we are in that stage today. >> Haseeb talked about, you talked about the great evolution of what's going on at Mass Mutual. Haseeb talk a little bit about who? You mentioned one of the things that's surprising you about this KubeCon in Detroit, is that you're seeing a lot more enterprise folks here? Who's deciding in the organization and your customer conversations? Who are the decision makers in terms of adoption of Kubernetes these days? Is that elevating? >> Hmm. Well, this guy. (Lisa laughing) One of the things I'm seeing here, and John and I have talked about this in the past, this idea of a platform organization and enterprises. So, consistently what I'm seeing, is somebody, a CTO, CIO level, an individual is making a decision. I have multiple internal Bus who are now modernizing applications. They're individually investing in DevOps, and this is not a good investment for my business. I'm going to centralize some of this capability so that we can all benefit together. And that team is essentially a platform organization. And they're making Kubernetes a shared services platform so that everybody else can come and sort of consume it. So, what that means to us, is our customer is a platform organization, and their customer is a developer. So we have to make two constituencies successful. Our customer who's providing a multi-tenant platform, and then their customer, who's your developer, both have to be happy. If you don't solve for both, you know, constituencies, you're not going to be successful. >> So, you're targeting the builder of the infrastructure and the consumer of that infrastructure? >> Yes, sir. It has to be both. >> On the other side? >> Exactly, right. So that look, honestly, it takes iteration to figure these things out. But this is a consistent theme that I am seeing. In fact, what I would argue now, is that every enterprise should be really stepping back and thinking about what is my platform strategy? Because if you don't have a platform strategy, you're going to have a bunch of different teams who are doing different things, and some will be successful, and look, some will not be. And that is not good for business. >> Yeah, and Santhosh, I want to get to you. You mentioned your transformations, what you look forward, and your title, Global Head of Cloud, SRE. Okay, so SRE, we all know came from Google, right? Everyone wants to be like Google, but no one wants to be like Google, right? And no one is Google. Google's a unique thing. >> Haseeb: Only one Google. >> But they had the dynamic and the power dynamic of one person to large scale set of servers or infrastructure. But concept can be portable, but the situation isn't. So, Borg became Kubernetes, that's inside baseball. So, you're doing essentially what Google did at their scale, you're doing for Mass Mutual. That's kind of what's happening, is that kind of how I see it? And you guys are playing in there partnering? >> So, I totally agree. Google introduce SRE, Site Reliability Engineering. And if you take the traditional transformation of the roles, in the past, it was called operations, and then DevOps ops came in, and then SRE is the new buzzword. And the future could be something like Product Engineering. And in this journey, here is what I tell folks on my side, like what worked for Google might not work for a financial company. It might not work for an insurance company. It's okay to use the word, SRE, but end of the day, that SRE has to be tailored down to your requirements. And the customers that you serve, and the technology that you serve. >> This is why I'm coming back, this platform engineering. At the end of the day, I think SRE just translates to, you're going to have a platform engineering team? 'Cause you got to enable developers to be producing more code faster, better, cheaper, guardrails, policies. It's kind of becoming the, these serve the business, which is now the developers. IT used to serve the business back in the old days, "Hey, the IT serves the business." >> Yup. >> Which is a term now. >> Which is actually true now. >> The new IT serves the developers, which is the business. >> Which is the business. >> Because if digital transformation goes to completion, the company is the app. >> The hard line between development and operations, so that's thinning down. Over the time, that line might disappear. And that's where SRE is fitting in. >> Yeah, and then building platform to scale the enablement up. So, what is the key challenges? You guys are both building out together this new transformational direction. What's new and what's the same? The same is probably the business results, but what's the new dynamic involved in rolling it out and making people successful? You got the two constituents, the builders of the infrastructures and the consumers of the services on the other side. What's the new thing? >> So, the new thing, if I may go first. The faster market to value that we are bringing to the table, that's very important. Business has an idea. How do you get that idea implemented in terms of technology and take it into real time? So, that journey we have cut down. Technology is like Kubernetes. It makes an IT person's life so easy that they can speed up the process. In a traditional way, what used to take like an year, or six months, can be done in a month today, or less than that. So, there's definitely speed velocity, agility in general, and then flexibility. And then the automation that we put in, especially if you have to maintain like thousands of clusters. These are today, it is possible to make that happen with a click off a button. In the past, it used to take, probably, 100-person team, and operational team to do it, and a lot of time. But that automation is happening. And we can get into the technology as much as possible, but blueprinting and all that stuff made it possible. >> We'll save that for another interview. We'll do it deep time. (panel laughing) >> But the end user on the other end, the consumer doesn't have the patience that they once had, right? It's, "I want this in my lab now." How does the culture of Mass Mutual? How is it evolve to be able to deliver the velocity that your customers are demanding? >> Once in a while, it's important to step yourself into the customer's shoes and think it from their perspective. Business does not care how you're running your IT shop. What they care about is your stability of the product and the efficiencies of the product, and how easy it is to reach out to the customers. And how well we are serving the customers, right? So, whether I'm implementing Docker in the background, Docker Swam or Kubernetes, business doesn't even care about it. What they really care about, it is, if your environment goes down, it's a problem. And if your environment or if your solution is not as efficient as the business needs, that's the problem, right? So, at that point, the business will step in. So, our job is to make sure, from a technology perspective, how fast you can make implement it? And how efficiently you can implement it? And at the same time, how do you play within the guardrails of security and compliance? >> So, I was going to ask you, if you have VMware in your environment? 'Cause a lot of clients compare what vCenter does for Kubernetes is really needed. And I think that's what you guys got going on. I can say that, you're the vCenter of Kubernetes. I mean, as as metaphor, a place to manage it all, is all one paint of glass, so to speak. Is that how you see success in your environment? >> So, virtualization has gone a long way. Where we started, what we call bare metal servers, and then we virtualized operating systems. Now, we are virtualizing applications, and we are virtualizing platforms as well, right? So that's where Kubernetes plays a role. >> So, you see the need for a vCenter like thing for Kubernetes? >> There's definitely a need in the market. The way you need to think is like, let's say there is an insurance company who actually implement it today, and they gain the market advantage. Now, the the competition wants to do it as well, right? So, there's definitely a virtualization of application layer that's very critical, and it's a critical component of cloud strategy as a whole. >> See, you're too humble to say it. I'll say, you're like the vCenter of Kubernetes. Explain what that means in your term? If I said that to you, what would you react? How would you react to that? Would you say, BS, or would you say on point? >> Maybe we should think about what does vCenter do today? So, in my opinion, by the way, vCenter in my opinion, is one of the best platforms ever built. Like it's the best platform in my opinion ever built. VMware did an amazing job, because they took an IT engineer, and they made him now be able to do storage management, networking management, VM's multitenancy, access management, audit. Everything that you need to run a data center, you can do from essentially single platform. >> John: From a utility standpoint, home-run? >> It's amazing. >> Yeah. >> Because you are now able to empower people to do way more. Well, why are we not doing that for Kubernetes? So, the premise man Rafay was, well, I should have IT engineers, same engineers. Now, they should be able to run fleets of clusters. That's what people that Mass Mutual are able to do now. So, to that end, now you need cluster management, you need access management, you need blueprinting, you need policy management. All of these things that have happened before, chargebacks, they used to have it in vCenter, now they need to happen in other platforms but for Kubernetes. So, should we do many of the things that vCenter does? Yes. >> John: Kind of, yeah. >> Are we a vCenter for Kubernetes? >> No. >> That is a John Furrier question. >> All right, well, the speculation really goes back down to the earlier speed question. If you can take away the complexity and not make it more steps, or change a tool chain, or do something, then the Devs move faster. And the service layer that serves the business, the new organization, has to enable speed. This is becoming a real discussion point in the industry, is that, "Yeah, we got new tool. Look at the shiny new toy." But if it move the needle, does it help productivity for developers? And does it actually scale up the enablement? That's the question. So, I'm sure you guys are thinking about this a lot. What's your reaction? >> Yeah, absolutely. And one thing that just hit my mind, is think about the hoteling industry before Airbnb and after Airbnb. Or the taxi industry before Uber and after Uber. So, if I'm providing a platform, a Kubernetes platform for my application folks, or for my application partners, they have everything ready. All they need to do is build their application and deploy it, and run it. They don't have to worry about provisioning of the servers, and then building the Middleware on top of it, and then, do a bunch of testing to make sure they iron out all the compatible issues and whatnot. Now, today, all I say is like, "Hey, we have a platform built for you. You just build your application, and then deploy it in a development environment, that's where you put all the pieces of puzzle together. Make sure you see your application working, and then the next thing that you do is like, do the correction. >> John: Shipping. >> Shipping. You build the production. >> John: Press. Go. Release it. (laughs) That when you move on, but they were there. I mean, we're there now. We're there. So, we need to see the future, because that's the case, then the developers are the business. They have to be coding more features, they have to react to customers. They might see new business opportunities from a revenue standpoint that could be creatively built, got low code, no code, headless systems. These things are happening where there's, I call the Architectural List Environment where it's like, you don't need architecture, it's already happening. >> Yeah, and on top of it, if someone has an idea, they want to implement an idea real quick. So, how do you do it? And you don't have to struggle building an environment to implement your idea and test it in real time. So, from an innovation perspective, agility plays a key role. And that's where the Kubernetes platforms, or platforms like Kubernetes plays. >> You know, Lisa, when we talked to Andy Jassy, when he was the CEO of AWS, either one-on-one or on "theCUBE," he always said, and this is kind of happening, "Companies are going to be builders, where it's not just utility, you need that table stakes to enable that new business idea." And so, in this last keynote, he did this big thing like, "Think like your developers are the next entrepreneurial revenue generators." I think I'm starting to see that. What do you think about that? You see that coming sooner than later? Or is that an insight, or is that still ways away? >> I think it's already happening at a level, at a certain level. Now ,the question comes back to, you know, taking it to the reality. I mean, you can do your proof of concept, proof of technologies, and then prove it out like, "Hey, I got a new idea. This idea is great." And it's to the business advantage. But we really want to see it in production live where your customers are actually using it. >> In the board meetings, "Hey, we got a new idea that came in, generating more revenue, where'd that come from?" Agile Developer. Again, this is real. >> Yeah. >> Yeah. Absolutely agree. Yeah, I think both of you gentlemen said a word as you were talking, you used the word, Guardrails. We're talking about agility, but the really important thing is, look, these are enterprises, right? They have certain expectations. Guardrails is key, right? So, it's automation with the guardrails. Guardrails are like children, you know, shouldn't be heard. They're seen but not heard. Developers don't care about guardrails, they just want to go fast. >> They also bounce around a little bit, (laughs) off the guardrails. >> Haseeb: Yeah. >> One thing we know that's not going to slow down, is the expectations, right? Of all the consumers of this, the Devs, the business, the business top line, and, of course, the customers. So, the ability to really, as your website says, let's say, "Make Life Easy for Platform Teams" is not trivial. And clearly what you guys are talking about here, is you're really an enabler of those platform teams, it sounds like to me. >> Yup. >> So, great work, guys. Thank you so much for both coming on the program, talking about what you're doing together, how you're seeing the evolution of Kubernetes, why? And really, what the focus should be on those platform teams. We appreciate all your time and your insights. >> Thank you so much for having us. >> Thanks for having us. >> Our pleasure. For our guests and for John Furrier, I'm Lisa Martin. You're watching "theCUBE" Live, KubeCon CloudNativeCon from Detroit. We'll be back with our next guest in just a minute, so stick around. (bright upbeat music)

>> Good afternoon everyone, and welcome back to theCUBE where we're coming to you live from Detroit, Michigan at KubeCon and Cloud Native Con. We're going to keep theCUBE puns coming this afternoon because we have the pleasure of being joined by not one but two guests from Kubiya. John Furrier, my wonderful co-host. You're familiar with these guys. You just chatted with them last week. >> We broke the story of their launch and featured them on theCUBE in our studio conversation. This is a great segment. Real innovative company with lofty goals, and they're really good ones. Looking forward to it. >> If that's not a tease to keep watching I don't know what is. (John laughs) Without further ado, on that note, allow me to introduce Amit and Shaked who are here to tell us all about Kubiya. And I'm going to blow the pitch for you a little bit just because this gets me excited. (all laugh) They're essentially the Siri of DevOps, but that means you can, you can create using voice or chat or any medium. Am I right? Is this? Yeah? >> You're hired. >> Excellent. (all laugh) >> Okay. >> We'll take it. >> Who knows what I'll tell the chat to do or what I'll, what I will control with my voice, but I love where you're. >> Absolutely. I'll just give the high level. Conversational AI for the world of DevOps. Kind of redefining how self-service DevOps is supposed to be essentially accessed, right? As opposed to just having siloed information. You know, having different platforms that require an operator or somebody who's using it to know exactly how they're accessing what they're doing and so forth. Essentially, the ability to express your intent in natural language, English, or any language I use. >> It's quite literally the language barrier sometimes. >> Precisely. >> Both from the spoken as well as code language. And it sounds like you're eliminating that as an obstacle. >> We're essentially saying, turn simple, complex cast into simple conversations. That's, that's really what we're saying here. >> So let's get into the launch. You just launched a fresh startup. >> Yeah, yeah, yeah. >> Yeah. >> So you guys are going to take on the world. Lofty goals if that. I had the briefing. Where's the origination story come from? What, how did you guys get here? Was it a problem that you saw, you were experiencing, an itch you were scratching? What was the motivation and what's the origination story? >> Shaked: So. >> Amit: Okay, go first please. >> Essentially everything started with my experience as being an operator. I used to be a DevOps engineer for a few years for a large (indistinct) company. On later stages I even managed an SRE team. So all of these access requires Q and A staff is something that I experience nonstop on Slack or Teams, all of these communication channels. And usually I find out that everything happens from the chat. So essentially back then I created a chat bot. I connect this chat bot to the different organizational tools, and instead of the developers approaching to me or the team using the on call channel or directly they will just approach the bot. But essentially the bot was very naive, and they still needed to know what they, they want to do inside the bot. But it's still managed to solve 70% of the complexity and the toil on us as a team so we could focus on innovation. So Kubiya's a more advanced version of it. Basically with Kubiya you can define what we call workflows, and we convert all of these complexity of access request into simple conversations that the end users, which could be developers, but not only, are having with a DevOps team. So that's essentially how it works, and we're very excited about it. >> So you were up all night answering the same question over and over again. (all laugh) And you said, Hey, screw it. I'm going to just create a bot, bot myself up. (Shaked laughs) But it gets at something important. I mean, I'm not just joking. It probably happened, right? That was probably the case. You were up all night telling. >> Yeah, I mean it was usually stuff that we didn't need to maintain. It was training requests and questions that just keep on repeating themselves. And actually we were in Israel, but we sell three different time zones of developers. So all of these developers, as soon as the day finishes in Israel, the day in the US started. So they will approach us from the US. So we didn't really sleep. (all laugh) As with these requests non-stop. >> It's that 24 hour. >> Yeah, yeah. 24 hours for a single team. >> So the world clock global (indistinct) catches you a little sometimes. Yeah. >> Yeah, exactly. >> So you basically take all the things that you know that are common and then make a chat bot answering as if you're you. But this brings up the whole question of chat bot utilization. There's been a lot of debate in the AI circles that chat bots really haven't made it. They're not, they haven't been good enough. So 'cause NLP and other trivial, >> Amit: Sure. or things that haven't really clicked. What's different now? How do you guys see your approach cracking the code to go that kind of reasoning level? Bots can reason? Now we're in business. >> Yeah. Most of the chat bots are general purpose, right? We're coming with the domain expertise. We know the pain from the inside. We know how the operators want to define such conversations that users might have with the virtual assistant. So we combined all of the technical tools that are needed in order to get it going. So we have a a DSL, domain specific language, where the operators can define these easy conversations and combine all of the different organizational tools which can be done using DSDK. Besides this fact, we have a no code, for less technical people to create such workflows even with no code interface. And we have a CLI, which you could use to leverage the power of the virtual assist even right from your terminal. So that's how I see the domain expertise coming in that we have different communication channels for everyone that needs to be inside the loop. >> That's awesome. >> And I, and I can add to that. So that's one element, which is the domain expertise. The other one is really our huge differentiator, the ability to let the end users influence the system itself. So essentially. >> John: Like how? Give me an example. >> Sure. We call it teach me feature, but essentially if you have any type of a request and the system hasn't created an automation or hasn't, doesn't recognize it, you can go ahead and bind that into your intent and next time, and you can define the scope for yourself only, for the team, or even for the entire organization that actually has to have permission to access the request and control and so on. >> Savannah: That's something. Yeah, I love that as a knowledge base. I mean a custom tool kit. >> Absolutely. >> And I like that you just said for the individual. So let's say I have some crazy workflows that I don't need anybody else to know about. >> 100 percent. >> I can customize my experience. >> Mm hmm. >> Do you see your, this is really interesting, and I'm, it's surprising to me we haven't seen a lot of players in this space before because what you're doing makes a lot of sense to me, especially as someone who is less technical. >> Yeah. >> Do you view yourselves as a gateway tool for more folks to be involved in more complex technology? >> So, so I'll take that. It's not that we haven't seen advanced virtual assistants. They've existed in different worlds. >> Savannah: Right. >> Up until now they've existed more in CRM tools. >> Savannah: Right. >> Call centers, right? >> Shaked: Yeah. >> You go on to Ralph Lauren, Calvin Klein, you go and chat with. Now imagine you can bring that into a world of dev tools that has high domain expertise, high technical amplitude, and now you can go and combine the domain expertise with the accessibility of conversational AI. That's, that's a unique feature here. >> What's the biggest thing that's surprised you with the launch so far? The reaction to the name, Kubiya, which is Cube in Hebrew. >> Amit: Yes. >> Apparently. >> Savannah: Which I love. >> Which by the way, you know, we have a TM and R on our Cube. (all laugh) So we can talk, you know, license rights. >> Let's drop the trademark rules today, John, here. We're here to share information. Confuse the audience. Sorry about that, by the way. (all laugh) >> We're an open source, inclusive culture. We'll let it slide this time. >> The KubeCon, theCUBE, and Kubiya. (John laughs) In the Hebrew we have this saying, third time we all have ice cream. So. (all laugh) >> I think there's some ice cream over there actually. >> There is. >> Yeah, yeah. There you go. >> All kidding aside, all fun. What's, what's been the reaction? Got some press coverage. We had the launch. You guys launched with theCUBE in here, big reception. What's been the common feedback? >> And really, I think I expected this, but I didn't expect this much. Really, the fact that people really believe in our thesis, really expect great things from us, right? We've starting to working with. >> Savannah: Now the pressure's on. >> Rolling out dozens of POCs, but even that requires obviously a lot of attention to the detail, which we're rolling out. This is effectively what we're seeing. People love the fact that you have a unique and fresh way to approaching the self-service which really has been stalled for a while. And we've recognized that. I think our thesis is where we. >> Okay, so as a startup you have lofty goals, you have investors now. >> Amit: Yeah. >> Congratulations. >> Amit: Thank you. >> They're going to want to keep the traction going, but as a north star, what's your, what are you going to, what are you going to take? What territory are you going to take? Is it new territory? Are you eating someone's lunch? Who are you going to be competing with? What's the target? What's the, what's the? >> Sure, sure. >> I'm sure you guys have it. Who are you takin' over? >> I think the gateway, the entry point to every organization is a bottleneck. You solve the hard problem first. That's where you can go into other directions, and you can imagine where other operational workflows and pains that we can help solve once we have essentially the DevOps. >> John: So you see this as greenfield, new opportunity? >> I believe so. >> Is there any incumbent you see out there? An old stodgy? >> Today we're on internal developer platform service catalog type of, you know, use cases. >> John: Yeah. >> But that's kind of where we can grow from there and have the ecosystem essentially embrace us. >> John: How about the technology platform? >> Amit: Yeah. >> What's the vision for the innovation? >> Essentially want to be able to integrate with all of the different cloud providers, cloud solutions, SaaS platforms, and take the atlas approach that they were using right to the chats from everywhere to anywhere. So essentially we want in the end that users will be able to do anything that they need inside all of these complicated platforms, which some of them are totally complicated, with plain English. >> So what's the biggest challenge for you then on that front leading the technology side of the team? >> So I would say that the conversational AI part is truly complicated because it requires to extract many types of intentions from different types of users and also integrate with so many tools and solutions. >> Savannah: Yeah. So it requires a lot of thinking, a lot of architecture, but we are doing it just fine. >> Awesome. What do you guys think about KubeCon this week? What's, what's the top story that you see emerging out of this? Just generally as an industry observer, what's the most important? >> Savannah: Maybe it's them. Announcement halo. >> What's the cover story that you see? (all laugh) I mean you guys are in the innovation intent-based infrastructure. I get that. >> So obviously everyone's looking to diversify their engineering, diversify their platforms to make sure they're as decoupled from the main CSPs as possible. So being able to build their own, and we're really helping enable a lot of that in there. We're really helping improve upon that open source together with managed platforms can really play a very nice game together. So. >> Awesome. So are you guys hiring, recruiting? Tell us about the team DNA. Now you're in Tel Aviv. You're in the bay. >> Shaked: Check our openings on LinkedIn. (all laugh) >> We have a dozen job postings on our website. Obviously engineering and sales then go to market. >> So when theCUBE comes to Tel Aviv, and we have a location there. >> Yeah. >> Will you be, share some space? >> Savannah: Is this our Tel Aviv office happening right now? I love this. >> Amit: We will be hosting you. >> John: theCube with a C and Kube with a K over there. >> Yeah. >> All one happy family. >> Would love that. >> Get some ice cream. >> Would love that. >> All right, so last question for you all. You just had a very big exciting announcement. It's a bit of a coming out party for you. What do you hope to be able to say in a year that you can't currently say right now? When you join us on theCUBE next time? >> No, no, it's absolutely. I think our thesis that you can turn conversations into operations. It's, it sounds obvious to you when you think about it, but it's not trivial when you look into the workflows, into the operations. The fact that we can actually go a year from today and say we got hundreds of customers, happy customers who've proven the thesis or sharing knowledge between themselves, that would be euphoric for us. >> All right. >> You really are about helping people. >> Absolutely. >> It doesn't seem like it's a lip service from both of you. >> No. (all laugh) >> Is there going to be levels of bot, like level one bot level two, level three, and then finally the SRE gets on the phone? Is that like some point? >> Is there going to be bot singularity? Is that, is that what we're exploring right now? (overlapping chatter) >> Some kind of escalation bot. >> Enlightenment with bots. >> We actually planning a feature we want to call a handoff where a human in the loop is required, which often is needed. Machine cannot do it alone. We'll just. >> Yeah, I think it makes total sense for geos, ops at the same. >> Shaked: Yeah. >> But not exactly the same. Really good, good solution. I love the direction. Congratulations on the launch. >> Shaked: Thank you so much. >> Amit: Thank you very much. >> Yeah, that's very exciting. You can obviously look, check out that news on Silicon Angle since we had the pleasure of breaking it. >> Absolutely. >> If people would like to say hi, stalk you on the internet, where's the best place for them to do that? >> Be on our Twitter and LinkedIn handles of course. So we have kubiya.ai. We also have a free trial until the end of the year, and we also have free forever tier, that people can sign up, play, and come say hi. I mean, we'd love to chat. >> I love it. Well, Amit, Shaked, thank you so much for being with us. >> Shaked: Thank you so much. >> John, thanks for sitting to my left for the entire day. I sincerely appreciate it. >> Just glad I can help out. >> And thank you all for tuning in to this wonderful edition of theCUBE Live from Detroit at KubeCon. Who knows what my voice will be controlling next, but either way, I hope you are there to find out. >> Amit: Love it.

>>Hello everyone. My name is Savannah Peterson, coming to you live from the Kim Con Show floor on the cube here in Detroit, Michigan. The energy is pulsing big event for the Cloud Native Foundation, and I'm joined by John Furrier on my left. John. Hello. >>Great, great, great to have you on the cube. Thanks for being our new host. You look great, Great segment coming up. I'm looking forward to this. Savannah, this is a great segment. A cube alumni, an OG in the cloud, native world or cloud aati. I, as I call it, been there, done that. A lot of respect, a lot of doing some really amazing, I call it the super cloud holy grail. But we'll see >>Your favorite word, >>This favorite word, It's a really strong segment. Looking forward to hearing from this guest. >>Yes, I am very excited and I'm gonna let him tee it up a little bit. But our guest and his project were actually mentioned in the opening keynote this morning, which is very, very exciting. Ladies and gentlemen, please welcome Baam Tobar Baam, thanks for being here with >>Us. Thank you guys. So good to be back here on the show and, and this exciting energy around us. So it was super, super awesome to be here. >>Yeah, it feels great. So let's start with the opening keynote. Did you know you were gonna get that shout out? >>No, not at all. I, it was, it was really cool to see, you know, I think Cruz was up there talking about how they were building their own platform for autonomous cars and what's running behind it. And they mentioned all these projects and you know, we were like, Wow, that sounds super familiar. And then, then, and then they said, Okay, yeah, we we're, you know, cross plane. They mentioned cross plane, they mentioned, Upbound mentioned the work that we're doing in this space to help folks effectively run, you know, their own layer on top of cloud computing. >>And then Tom, we've known each other, >>We're gonna do a bingo super cloud. So how many times is this Super cloud? So >>Super Cloud is super services, super apps around us. He enables a lot of great things that Brian Grace had a great podcast this week on super services. So it's super, super exciting, >>Super great time on the queue. Super, >>Super >>Cloud conversation. All seriously. Now we've known each other for a long time. You've been to every cub com, you've been in open source, you've seen the seen where it's been, where it is now. Super exciting that in mainstream conversations we're talking about super cloud extractions and around interoperability. Things that were once like really hard to do back, even back on the opens stack days. Now we're at a primetime spot where the control plane, the data planes are in play as a viable architectural component of all the biggest conversations. Yeah, you're in the middle of it. What's your take on it? Give some perspective of why this is so important. >>I mean, look, the key here is to standardize, right? Get to standardization, right? And, and what we saw, like early days of cloud native, it was mostly around Kubernetes, but it was Kubernetes as a, you know, essentially a container orchestrator, the container of wars, Docker, Mesos, et cetera. And then Kubernetes emerged as a, a, the winner in containers, right? But containers is a workload, one kind of workload. It's, I run containers on it, not everything's containers, right? And the, you know, what we're seeing now is the Kubernetes API is emerging as a way to standardize on literally everything in cloud. Not just containers, but you know, VMs, serverless, Lambda, et cetera, storage databases that all using a common approach, a common API layer, a common way to do access control, a common way to do policy, all built around open source projects and you know, the cloud data of ecosystem that you were seeing around here. And that's exciting cuz we've, for the first time we're arriving at some kind of standardization. >>Every major inflection point has this defacto standard evolution, then it becomes kind of commonplace. Great. I agree with Kubernetes. The question I wanted to ask you is what's the impact to the DevOps community? DevSecOps absolutely dominated the playbook, if you will. Developers we're saying we'll run companies cuz they'll be running the applications. It's not a department anymore. Yes, it is the business. If you believe the digital transformation finds its final conclusion, which it will at some point. So more developers doing more, ask more stuff. >>Look, if you, I'd be hard pressed to find somebody that's has a title of DevOps or SRE that can't at least spell Kubernetes, if not running in production, right? And so from that perspective, I think this is a welcome change. Standardize on something that's already familiar to everyone is actually really powerful. They don't have to go, Okay, we learned Kubernetes, now you guys are taking us down a different path of standardization. Or something else has emerged. It's the same thing. It's like we have what, eight years now of cloud native roughly. And, and people in the DevOps space welcome a change where they are basically standardizing on things that are working right? They're actually working right? And they could be used in more use cases, in more scenarios than they're actually, you know, become versatile. They become, you know, ubiquitous as >>You will take a minute to just explain what you guys are selling and doing. What's the product, what's the traction, why are people using you? What's the big, big mo position value statement you guys think? >>Yeah, so, so, so the, my company's called Upbound and where the, where the folks behind the, the cross plane project and cross plane is effective, takes Kubernetes and extends it to beyond containers and to ev managing everything in cloud, right? So if you think about that, if you love the model where you're like, I, I go to Kubernetes cluster and I tell it to run a bunch of containers and it does it for me and I walk away, you can do that for the rest of the surface area of cloud, including your VMs and your storage and across cloud vendors, hybrid models, All of it works in a consistent standardized way, you know, using crossline, right? And I found >>What do you solve? What do you solve or eliminate? What happens? Why does this work? Are you replacing something? Are you extracting away something? Are you changing >>Something? I think we're layering on top of things that people have, right? So, so you'll see people are organized differently. We see a common pattern now where there's shared services teams or platform teams as you hear within enterprises that are responsible for basically managing infrastructure and offering a self-service experience to developers, right? Those teams are all about standardization. They're all about creating things that help them reduce the toil, manage things in a common way, and then offer self-service abstractions to their, you know, developers and customers. So they don't have to be in the middle of every request. Things can go faster. We're seeing a pattern now where the, these teams are standardizing on the Kubernetes API or standardizing on cross plane and standardizing on things that make their life easier, right? They don't have to replace what they're doing, they just have to layer and use it. And I layer it's probably a, an opening for you that makes it sound >>More complex, I think, than what you're actually trying to do. I mean, you as a company are all about velocity as an ethos, which I think is great. Do you think that standardization is the key in increasing velocity for teams leveraging both cross claim, Kubernetes? Anyone here? >>Look, I mean, everybody's trying to achieve the same thing. Everybody wants to go faster, they want to innovate faster. They don't want tech to be the friction to innovation, right? Right. They want, they wanna go from feature to production in minutes, right? And so, or less to that extent, standardization is a way to achieve that. It's not the only way to achieve that. It's, it's means to achieve that. And if you've standardized, that means that less people are involved. You can automate more, you can st you can centralize. And by doing that, that means you can innovate faster. And if you don't innovate these days, you're in trouble. Yeah. You're outta business. >>Do you think that, so Kubernetes has a bit of a reputation for complexity. You're obviously creating a tool that makes things easier as you apply Kubernetes outside just an orchestration and container environment. Do you, what do you see those advantages being across the spectrum of tools that people are leveraging you >>For? Yeah, I mean, look, if Kubernetes is a platform, right? To build other things on top of, and as a, as a result, it's something that's used to kind of on the back end. Like you would never, you should put something in front of Kubernetes as an application model or consumption interface of portals or Right, Yeah. To give zero teams. But you should still capture all your policies, you know, automation and compliance governance at the Kubernetes layer, right? At the, or with cross plane at that layer as well, right? Right. And so if you follow that model, you can get the best of world both worlds. You standardize, you centralize, you are able to have, you know, common controls and policies and everything else, but you can expose something that's a dev friendly experience on top of as well. So you get the both, both the best of both worlds. >>So the problem with infrastructure is code you're saying is, is that it's not this new layer to go across environments. Does that? No, >>Infrastructure is code works slightly differently. I mean, you, you can, you can write, you know, infrastructures, codes using whatever tooling you like to go across environments. The problem with is that everybody has to learn a specific language or has to work with understanding the constructs. There's the beauty of the Kubernetes based approach and the cross playing best approach is that it puts APIs first, right? It's basically saying, look, kind of like the API meant that it, that led to AWS being created, right? Teams should interact with APIs. They're super strong contracts, right? They're visionable. Yeah. And if you, if you do that and that's kind of the power of this approach, then you can actually reach a really high level of automation and a really high level of >>Innovation. And this also just not to bring in the clouds here, but this might bring up the idea that common services create interoperability, but yet the hyper scale clouds could still differentiate on value very much faster processors if it's silicon to better functions if glam, right? I mean, so there's still, it's not killing innovation. >>It is not, And in fact I, you know, this idea of building something that looks like the lowest common denominator across clouds, we don't actually see that in practice, right? People want, people want to use the best services available to them because they don't have time to go, you know, build portability layers and everything else. But they still, even in that model want to standardize on how to call these services, how to set policy on them, how to set access control, how to actually invoke them. If you can standardize on that, you can still, you get the, you get to use these services and you get the benefits of standardization. >>Well Savannah, we were talking about this, about the Berkeley paper that came out in May, which is kind of a super cloud version they call sky computing. Their argument is that if you try to standardize too much like the old kind of OSI model back in the day, you actually gonna, the work innovations gonna stunt the growth. Do you agree with that? And how do you see, because standardization is not so much a spec and it it, it e f thing. It's not an i e committee. Yeah. It's not like that's kind of standard. It's more of defacto, >>I mean look, we've had standards emerge like, you know, if you look at my S SQL for example, and the Postgres movement, like there are now lots of vendors that offer interfaces that support Postgres even though they're differentiated completely on how it's implement. So you see that if you can stick to open interfaces and use services that offer them that tons of differentiation yet still, you know, some kind of open interface if you will. But there are also differentiated services that are, don't have open interfaces and that's okay too. As long as you're able to kind of find a way to manage them in a consistent way. I think you sh and it makes sense to your business, you should use >>Them. So enterprises like this and just not to get into the business model side real quick, but like how you guys making money? You got the project, you get the cross playing project, that's community. You guys charging what's, what's the business model? >>We we're in the business of helping people adopt and run controlled lanes that do all this management service managed service services and customer support and services, the, the plethora of things that people need where we're >>Keeping the project while >>Keeping the project. >>Correct. So that's >>The key. That's correct. Yeah. You have to balance both >>And you're all over the show. I mean, outside of the keynote mention looking here, you have four events on where can people find you if they're tuning in. We're just at the beginning and there's a lot of looks here. >>Upbound at IO is the place to find Upbound and where I have a lot of talks, you'll see Crossline mention and lots of talks and a number of talks today. We have a happy hour later today we've got a booth set up. So >>I'll be there folks. Just fyi >>And everyone will be there now. Yeah. Quick update. What's up? What's new with the cross plane project? Can you share a little commercial? What's the most important stories going on there? >>So cross plane is growing obviously, and we're seeing a ton of adoption of cross plane, especially actually in large enterprise, which is really exciting cuz they're usually the slow to move and cross plane is so central, so it's now in hundreds and thousands of deployments in woohoo, which is amazing to see. And so the, the project itself is adding a ton of features, reducing friction in terms of adoption, how people ride these control planes and alter them coverage of the space. As you know, controls are only useful when you connect them to things. And the space is like the amount of things you can connect control planes to is increasing on a day to day basis and the maturity is increasing. So it's just super exciting to see all of this right >>Now. How would you categorize the landscape? We were just talking earlier in another segment, we're in Detroit Motor City, you know, it's like teaching someone how to drive a car. Kubernetes pluss, okay, switch the gears like, you know, don't hit the other guy. You know? Now once you learn how to drive, they want a sports car. How do you keep them that progression going? How do you keep people to grow continuously? Where do you see the DevOps and or folks that are doing cross playing that are API hardcore? Cause that's a good IQ that shows 'em that they're advancing. Where's the IQ level of advancement relative to the industry? Is the adoption just like, you know, getting going? Are people advancing? Yeah. Sounds like your customers are heavily down the road on >>Yeah, the way I would describe it is there's a progression happening, right? It, it DevOps was make, initially it was like how do I keep things running right? And it transitioned to how do I automate things so that I don't have to be involved when things are running, running. Right now we're seeing a next turn, which is how do I build what looks like a product that offers shared services or a platform so that people consume it like a product, right? Yeah. And now I'm now transition becomes, well I'm an, I'm a developer on a product in operations building something that looks like a product and thinking about it as a, as a has a user interface. >>Ops of the new devs. >>That's correct. Yeah. There we go. >>Talk about layers. Talk about layers on layers on >>Layers. It's not confusing at all John. >>Well, you know, when they have the architecture architectural list product that's coming. Yeah. But this is what's, I mean the Debs are got so much DevOps in the front and the C I C D pipeline, the ops teams are now retrofitting themselves to be data and security mainly. And that's just guardrails, automation policy, seeing a lot of that kind of network. Like exactly. >>Function. >>Yep. And they're, they're composing, not maybe coding a little bit, but they not, they're not >>Very much. They're in the composition, you know that as a daily thing. They're, they're writing compositions, they're building things, they're putting them together and making them work. >>How new is this in your mind? Cause you, you've watching this progress, you're in the middle of it, you're in the front wave of this. Is it adopting faster now than ever before? I mean, if we talked five years ago, we were kind of saying this might happen, but it wasn't happening today. It kind, it is, >>It's kind of, it's kind of amazing. Like, like everybody's writing these cloud services now. Everybody's authoring things that look like API services that do things on top of the structure. That move is very much, has a ton of momentum right now and it's happening mainstream. It, it's becoming mainstream. >>Speaking of momentum, but some I saw both on your LinkedIn as well as on your badge today that you are hiring. This is your opportunity to shamelessly plug. What are you looking for? What can people expect in terms of your company culture? >>Yeah, so we're obviously hiring, we're hiring both on the go to market side or we're hiring on the product and engineering side. If you want to build, well a new cloud platform, I won't say the word super cloud again, but if you want to, if you're excited about building a cloud platform that literally sits on top of, you know, the other cloud platforms and offers services on top of this, come talk to us. We're building something amazing. >>You're creating a super cloud tool kit. I'll say it >>On that note, think John Farer has now managed to get seven uses of the word super cloud into this broadcast. We sawm tomorrow. Thank you so much for joining us today. It's been a pleasure. I can't wait to see more of you throughout the course of Cuban. My name is Savannah Peterson, everyone, and thank you so much for joining us here on the Cube where we'll be live from Detroit, Michigan all week.

>>Hey everyone. Welcome back to the Cube's coverage of Ansible Fest 2022. We are live in Chicago. This is day two of Waldo Wall coverage on the cube. John Fhrer here with me. Lisa Martin. John, today's a big news day. Yeah, >>Big time. I mean, we got the chief architect on this segments to be great. We have the lead product management. All the new stuff coming out really is a game changer. It's very cool and relevant. Very key to be relevant. And then, and being a part of the future. This is a changeover you see in the NextGen Cloud developer environment. Open source all coming together. So Ansible we've been covering for many, many years. We've always said they're in the middle of all the action and you're starting to see the picture. Yes. For me. So we're looking forward to a great segment. >>Yes. We've got two alumni back with us to unpack the news and all the great stuff that's going on here. Richard Hensel joins us Senior manager, Ansible Product Management, and Matthew Jones here, fresh from the keynote stage, Chief architect of Ansible Automation. Guys, great to have you on the program. Thanks >>For having us. Good to be here. >>So this morning was all about event driven Ansible. Unpack that. Talk about the impact that this is gonna have, The excitement, the buzz that you've heard on the show floor today. >>Yeah. You know, it's, it's exciting. We've been working on this for a while. We've been really excited to show this off because it's something that feels like the natural evolution of the platform and where it's going. Really being able to connect the automation with the sources of data and the actions that we know people want to use. We, we came into this knowing everybody here at this conference, this is something that everybody will be able to use. >>Talk about the innovations strategy. Cause we've always had these great conversations with Ansible. Oh yeah. The, the practitioners, they're, they're building the product with you. You guys are very hardcore on that. No secret. This is different. This is like a whole nother level of opportunity that's gonna take the, the community to new heights in terms of what they do in their job and free them up to do more creative development. >>Yeah, you're exactly right. You know, we, we know that people need to bring that sort of reactive and active automation to it. We've, we've done a lot of work to bring automation to everybody, to the masses. Now we need to meet them at the place where they are, where the, the where, where they have to do the most work and, and act in the most strategic and specific ways. >>All right. So now before we get into some of the deep dive, cause a ton of questions. This is really exciting product. Take a minute to explain what was the key announcement? Why, what specifically does this mean for the audience, watching customers and future customers? What's the big deal? To take a minute to explain what was announced. >>So this is about the, the evolution and the maturity of the automation that our users are doing. So, you know, you think about provisioning servers, you know, configuring networks, all that sort of, the stuff that we've established and everybody's been doing for a number of years. And then you go, Well, I've invested in that. I've done the heavy lifting, I've done the things that cost me agility. I think that cost me time. Well now I need to go further. So what can I go further into? And you move further at the stacks. You move away from the infrastructure, please. You move away from infrastructure as code. You move towards through configures code, up to officer's code. And you start to get into, well, I've got, I've got road tasks, I've got repetitive actions that I'm doing. I've got investigations, I've got remediations, I've got responses. >>Well, there's work that I do on a daily basis that is toil. Right. It's not efficient work. Right. Actually, we doing valuable work in the operation space as much as you were doing in, in the build space. And how do we move them up into that space? And it's, this is all based off observation. You can do this today, but how do we make it easier? We've gonna make it easier for them to do that and get, it's all about success. It's about the outcomes we're gonna drive users towards. They need to be successful as quickly as possible. How do we make that >>Happen? And Matt, I remember we talked in 2019 with Ansible, the word platform where we say, Hey, you know, platforms are super important. It's not a tool, tools and platforms as distinctions. You mentioned platform. This is now platform. A lot of people put a lot of work in into this Yeah. Claim what went on behind the scenes. So >>You're exactly right. And we've spent the last couple of years really taking that disparate set of tools that, that we've invested a lot of time in building that platform. It's been exciting to see it come together. We always knew that we wanted to capture more of, more of where people find automation and find they need automation, not just out on the edge, on the end of the, of the, of the actions and tasks that they need to do. They've got a lot of things coming in, a lot of things that they need to take care of. And the community is really what drives this for us. People who have been doing this for years and they've been asking us, Meet me halfway. Give me something. Give me a part of this platform and a capability that enables me to do this. So I I feel like we've done that and you did >>It. Yeah, exactly. For step one. >>And that must feel pretty good too, to be able to deliver what, you know, the masses are looking for and why they're looking >>For it. Yeah. This was, there was no question that we knew this was gonna deliver the kind of real value that people were looking for. >>Take us through the building blocks real quick. I know on stage you went through it in detail. What should people know about the core building blocks of, of this particular event driven >>Piece? Yeah. You know, I think the most important thing to understand at the, at the outset is the sources of data and events that come in. It's really easy to get lost in the details. Like, what do you mean a source? But, you know, we've shown examples using Kafka, but it's not just Kafka, right? It's, it's, it's web hooks, it's CI systems, it's any, any place that you can imagine an evict coming from your monitoring platforms. You can bring those together under the same umbrella. We're not requiring you to pick one or choose or what's your favorite one. You can bring, you can use them all and and condense them down into the, into the same place. >>There's a lot of data events everywhere now. There's more events. Yeah. Is there a standard interface? Is what's the, is there any kind of hook in there? Is what's, what's gonna limit? Or is there any limits? >>I I don't think there is a limit. I, you know, it's, and we can't even imagine where events and data are gonna come from, but we know we need to get them into the system in a way that makes the most sense for the, the customers. And then that, that drives through into the rule books. Like, okay, we have the data now, but what do we do with that data? How do we translate that into, into the action? What are the rules that need to follow? It's giving the, the, the person who is automating, who understands the data that's coming in and understands the task that they need to take. The, the rules are where they map those into it. And then the last part, of course is the playbook, the automation itself, which they already know. They're already experts in the system. So we've, we've, we've built this like eight lane highway. They get some right end of those actions. >>Let's talk about Richard, let's unpack those actions and the really kind of double click on the business outcomes that this is actually gonna enable organizations and any industry to achieve. >>Yeah, so >>I mean, it's, it, like Matt said, it's really hard to encapsulate everything that we see as possible. But if you just think about what happens when a system goes down, right? At that point in time, I'm potentially not making money, right? I'd say it's costing me time, it's costing me, that's a business impact. If I can speed up how quick I can resolve that problem, if I can reduce time in there, that's customer improvement, that's custom satisfaction. That's bottom line money for businesses, right? But it's also, it's also satisfaction for the users. You know, they're not involved in having the stressful get online, get quickly, activate whatever accounts you need to do, go and start doing discovery. You can detect a lot of that information for the discovery use case that we see, respond to an event, scan the system for that same logic that you would normally do as a user, as a human. >>And that's why the rules are important to add into ed. It's like, how do I take that human, that brain part that I would say, well, if I see this bit, oh, I'll go and have a look in this other log file. If I see this piece, I'll go and do something different. How do we translate that into Ansible so that you've got that conditional logic just to be able to say, if this do that, or if I see these three things, it means a certain outcome has happened. And then again, that defined, that's what's gonna help people like choose where it becomes useful. And that's how we, that's how we take that process >>Forward. I'm sure people are gonna get excited by this. I'm not sure the community already knows that, but as it's gonna attract more potential customers, what's different about it? Can you share the differentiation? Like wait minute, I already have that already. Do they have it already? What's different? What makes this different? What's, what's in it for them? >>Yeah. When we step up into a customer situation, an enterprise, an organization, what's really important becomes the, the ability to control where you do some of that work. So the control and the trust, You know, would you trust an automatic system to go and start making changes to hundreds of thousands of devices? And the answer is often not, not straight away. So how do we put this sort of sep the same separation of duties we have between dev and ops and all the nice structures we've done over the last number of years, and actually apply that to that programmatic access of automation that other systems do. So let's say a AIML systems that are detecting what's going on, observability platforms are, are much more intru or intrusive is the wrong word. They're much more observable of what's going on in the systems, right? But at the same time you go, I wanna make sure that I know that any point in time I can decide what, what is there and what can be run and who can run it and when they can run it. And that becomes an important dimension. >>The versatility seems like a big deal too. They can, Yeah. Any team could get >>Involved. And, and that's the, the same flexibility and the same extensibility of Ansible exists in this use case, right? The, the, the ability to take any of those tasks you wanna do in action, string them together, but what the way that it works for you, not the way that it works that we see, but the way that you see and you convert your operational DNA into how you do that automation and how that gets triggered as you see fit. >>Talk about this both of you. I'd like to get your perspectives on event driven Ansible as part of the automation journey that businesses are on. Obviously you can look at different industries and different businesses are, are at different places along that journey, but where does this fit in and kind of plugin to accelerating that journey? That's, >>That's a good question. You know, sometimes this ends up being like that last mile of we've adopted this automation, we've learned how to write automation. We even understand the things that we would need to automate, but how do we carry it over that last topic and connect it to our, our knowledge systems, our data stores, our data lakes, and how do we combine the expertise of the systems that we're managing with this automation that we've learned? Like you, you mentioned the, the, the community and the, the coalescing of data and information, the, the definition of the event rules and, and the event driven architecture. It lives alongside the automation that you've developed in the exact same place where you can feel that trust and ubiquity that we keep talking about. Right? It's there, it's certified. And we've talked a lot about secure supply chain recently. This gives you the ability to sign and certify that the rules and actions that we're taking and the sources that we're communicating with works exactly the same way. Yeah. And >>There's something we didn't, we didn't correlate this when we first started doing the work. We were, we were, we observe teams doing self-healing and you know, extending Ansible. And then over the last 18 months, what we've also seen is this movement, this platform engineering movement, the SRE teams becoming much more prominent. And this just nicely sits in as a type of use case for that type of transformation. You know, we've gotta remember that Ansible at is heart is also a transformative tool. Is like, how do you teach this behavior to a bunch of people? How do you upscale a larger base of engineers with what you want to be able to do? And I think this is such an important part that we, we just one say we stumbled into it, but it was a very, very nice, >>It was a natural progression. >>Exactly. >>Yeah. Yeah. Tom, Tom, when we were talking about Tom yesterday, Tom Anderson and he said, You guys bring up the SRE to you guys when you come on the cube. This is exactly a culture shift that we're talking about. I mean, SRE is really his legacy with Google. We all know that. Everyone kind of knows that, but it's become like a job title. Well they kind of, what does that even mean now if you're not Google, it means you're running stuff. DevOps has become a title. Yeah. So what that means is that's a cultural shift, not so much semantics Yeah. On title. This is kind of what you guys are targeting here, enabling people to run platforms, engineer them. Yeah. Like an architect and enable more co composability coding. >>And, and it's, so that's, that distinction is so important because one of the, you know, we see many customers come from different places. Many users from, you know, all the legacy or heritage of tools that have existed. And so often those processes are defined by the way that tool worked. Right? You had no other way that, that, and the, and it's, it happened 10 years ago, somebody implemented it, that's how it now works. And then they come and try and take something new and you go, well, you can't let the tool define your process. Now your culture and your objective has to define the process. So this is really, you know, how do we make sure we match that ability by giving them a flexible tool that let's say, Well what are you trying to achieve? I wanna achieve this outcome. That's the way you can do it. I >>Mean, that's how we match basically means my mind to get your reaction. It means I'm running stuff at scale. Yep. Engineer, I'm engineering and infrastructure at scale to enable, >>I'm responsible for it. And it's, it's my, it's my baby. It's my responsibility to do that. And how do we, how do we allow people to do that better? And you know, it, it's about, it's about freeing people up to focus on things that are really important and transformative. We can be transformative. And we do that by taking away the complexity and making things work fast. >>And that's what people want. People in their daily jobs want to be able to deliver value to the organization. You wanna feel that. But something Richard that you were talking about that struck me a couple minutes ago is, was a venture of an Ansible. There's employee benefits, there's customer benefits, Those two are ex inextricably linked. But I liked how you were talking about what it facilitates for both Yes. And all the way to the customer satisfaction, brand reputation. That's an important Yeah. Element for any brand to >>Consider. And that, I mean, you know, think about what digital transformation was all about. I mean, as we evolve past all these initial terms that come about, you know, we actually start getting to the meat of what these things are. And that is it connecting what you do with actually what is the purpose of what your business is trying to achieve. And you can't, you can't almost put money on that. That's, that's the, that's the holy grail of what you're trying to get to. So how, you know, and again, it just comes back to how do we facilitate, how do we make it easy? If we don't make it easier, we're not doing it right. We've gotta make it easier. >>Right. Well, exciting news. I want to get your guys' reaction and if you don't mind sharing your opinion or your commentary on what's different now with Ansible this year than just a few years ago in terms of the scope of what's out there, what's been built, what you guys are doing for the, for the customer base and the community. What's changed? Obviously the people's roles looked that they're gonna expand and have more, I say more power, you know, more keys to the kingdom, however you wanna look at it. But things have changed. What's changed now from a few years >>Ago. It's, you know, it, it's funny because we've spent a lot of time over the last couple years setting up the capabilities that you're seeing us deliver right now. Right. We, we look back two or three years ago and we knew where we wanted to be. We wanted to build things like eda. We wanted to invest in systems like Project Wisdom and the, the types of content, the cloud journey that, that now we're on and we're enabling for folks. But we had to make some really big changes. And those changes take time and, and take investment. The move into last year, John, we talked about execution environments. Yeah. And separating the control plane from the execution plane. All of that work that we did and the investment into the platform and stability of the platform leads us now into what >>Cap. And that's architectural decision. That's the long game in mind. Exactly. Making things more cohesive, but decoupled, that's an operating system kind of thinking. >>It, it totally is. It's a systems engineering and system architecture thinking. And now we can start building on top of these things like what comes after ed, what does ED allow us to do within the platform? All of the dev tools that we focused on that we haven't spent a lot of time talking about that from the product side. But being, coming in with prescriptive and opinionated dev tools, now we can show you how to build it. We can show you how to use it and connect it to your systems. Where can we go next? I'm really excited. >>Yeah. Your customer base two has also been part of from the beginning and they solve their own problems and they rolled it up, grow with it, and now it's a full on platform. The question I then ask is, okay, you believe it's a platform, which it is, it's enabling. What do you guys see as that possible dots that could connect that might come on top of this from a creativity standpoint, from an ecosystem standpoint, from an Ansible standpoint, from maybe Red Hat. I mean, wisdom shows that you can go into the treasure trove of IBM's research, pull out some AI and some machine learning. Both that in or shim layered in whatever you do. >>I mean, what I'm starting to see much more, especially as I, the nice thing about being here is actually getting face to face with customers again and you know, actually hearing what they're talking about. But you know, we've moved away from a Ansible specific story where I'm talking about how I, I was always, I was looking to automate, I was looking to go to Ansible. Well now I've got the automation capability. Now we've enhanced the automation. Capabil wisdom enhances the automation capability further. What about all those, those broader set of management solutions that I've got that I would like to start connecting to each other. So we're starting to take the same like, you know, you mentioned as then software architecture, software design principles. We'll apply those same application design principles, apply them to your IT management because we've got data center with the pressures on there. We've got the expansion into cloud, we've got the expansion to the edge, right? Each adding a new layer of complexity and a new layer of, you know, more that you have to then look after. But there's still the same >>Number of people. So a thousand flower blooms kind of situation. >>Exactly. And so how do I, how do I constrain, how do I tame it, right? How do I sit there and go, I, I can control that now I can look after that. I contain that. I can, I can deal with what I wanna do. So I'm focusing on what's important and we are getting stuff done. >>We, we've been quoting Andy Grove on the cube lately. Let chaos, rain and then rain in the chaos. Yes. Right? I mean that's kind of every inflection point has complexity before it gets simpler. >>Yeah, that's right. >>Yeah. You can't, there's answer that one. That's >>Perfectly. >>Yeah. Yeah. What do you expect to see chief ar you gotta have the vision. What's gonna pop out? What's that low, low hanging fruit? What's gonna bloom first? What do you think's gonna come? >>I, you know, my overarching vision is that I just want to be able to automate more. Where, where can we bring back, So edge cloud, right? That's obvious, but what things run in the cloud and and on the edge, right? Devices, you heard Chad in the keynote this morning talk about programmable logic controllers, sensors, fans, motors, things like that. This is the, the sort of, this is the next frontier of automation is that connecting your data centers and your systems, your applications and needs all the way out to where your customers are. Gas stations, point of sale systems. >>It's instant. It's instant. It is what it is. It's like just add, Just >>Add faster and bigger. Yeah. >>But what happens if, I'll give you a tease. What I think is, is what happens if this happens? So I've got much more rich feature, rich diverse set of tools looking after my systems, observing what's going on. And they go through a whole filtering process and they say such and such has happened, right? Wisdom picks that up and decides from that natural language statement that comes outta the back of that system. That's the task I think is now appropriate to run. Where do you run that? You need a secure execution capability. Pass that to an support, that single task. And now we run inside the automation platform at any of those locations that you just mentioned, right? Stitching those things together and having that sequence of events all the way through where you, you predefine what's possible. You know, you start to bias the system towards what is your accepted standard and then let those clever systems do what you are investing in them for, which is to run your IT and make it >>Easier. Rich here was on earlier, I said, hey, about voice activated it. Provision the cluster. Yeah. >>Last question guys, before we run out of time for this. For customers who take advantage of this new frontier, how can they get started with the bench of an what's? >>That's a good question. You know, we, we've engaged our community because they trust us and we trust them to build really good products. ansible.com/events. Oh man, >>I did have the, I >>Had the cup, the landing page. >>Find somebody find that. >>Well it's on GitHub, right? GitHub It is. >>Yeah it >>Is. Absolutely ansible.com. It's probably a link somewhere if I on the front page. Exactly. On GitHub. The good code too. >>Right? Exactly. And so look at there, you can see where we're going on our roadmap, what we're capable of today. Examples, we're gonna be doing labs and blogs and demonstrations of it over the next day, week, month. Right. You'll be able to see this evolve. You get to be the, the sort of vanguard of support and actions on this and >>Cause we really want, we really want users to play with it, right? Of course. We've been doing this for a while. We've seen what we think is right. We want users to play with it. Tell us whether the syntax works, whether it makes sense, how does it run, how does it work? That's the exciting part. But at the same time, we want the partners, you know, we, we don't know all the technologies, right? We want the partners that we have that work with us already in the community to go and sort of, you know, do those integrations, do those triggers to their systems, define rules for their stuff cuz they'll talk to their customers about it as >>Well. Right? Right. It'll be exciting to see what unfolds over the next six to nine months or so with the partners getting involved, the community getting involved. Guys, congratulations on the big announcements. Sounds like a lot of work. I can tell. We can tell. Your excitement level is huge and job well done. Thank you so much for joining us on the Cube. Thank you very much. Thank you. Our pleasure. Just All right, for our guests and John Furrier, I'm Lisa Martin. You're watching The Cube Live from Chicago, Ansible Fest 22. John and I will be right back with our next guest of Stay tuned.

(soft music) >> Welcome back to Chicago guys and gals. Lisa Martin here with John Furrier. We have been covering Ansible Fest '22 for the last two days. This is our show wrap. We're going to leave you with some great insights into the things that we were able to dissect over the last two days. John, this has been an action packed two days. A lot of excitement, a lot of momentum. Good to be back in person. >> It's great to be back in person. It was the first time for you to do Ansible Fest. >> Yes. >> My first one was 2019 in person. That's the last time they had an event in person. So again, it's a very chill environment here, but it's content packed, great active loyal community and is growing. It's changing. Ansible now owned by Red Hat, and now Red Hat owned by IBM. Kind of see some game changing kind of movements here on the chess board, so to speak, in the industry. Ansible has always been a great product. It started in open source. It evolved configuration management configuring servers, networks. You know, really the nuts and bolts of IT. And became a fan favorite mainly because it was built by the fans and I think that never stopped. And I think you started to see an opportunity for Ansible to be not only just a, I won't say niche product or niche kind of use case to being the overall capabilities for large scale enterprise system architectures, system management. So it's very interesting. I mean I find it fascinating how, how it stays relevant and cool and continues to power through a massive shift >> A massive shift. They've done a great job though since the inception and through the acquisition of being still community first. You know, we talked a lot yesterday and today about helping organizations become automation first that Ansible has really stayed true to its roots in being community first, community driven and really that community flywheel was something that was very obvious the last couple of days. >> Yeah, I mean the community thing is is is their production system. I mean if you look at Red Hat, their open source, Ansible started open source, good that they're together. But what people may or may not know about Ansible is that they build their product from the community. So the community actually makes the suggestions. Ansible's just in listening modes. So when you have a system that's that efficient where you have direct working backwards from the customer like that, it's very efficient. Now, as a product manager you might want to worry about scope creep, but at the end of the day they do a good job of democratizing that process. So again, very strong product production system with open source, very relevant, solves the right problems. But this year the big story to me is the cultural shift of Ansible's relevance. And I think with multicloud on the horizon, operations is the new kind of developer kind of ground. DevOps has been around for a while. That's now shifted up to the developer themselves, the cloud native developer. But at cloud scale and hybrid computing, it's about the operations. It's about the data and the security. All of it's about the data. So to me there's a new ops configuration operating model that you're seeing people use, SRE and DevOps. That's the new culture, and the persona's changing. The operator of a large scale enterprise is going to be a lot different than it was past five, 10 years. So major cultural shift, and I think this community's going to step up to that position and fill that role. >> They seem to be having a lot of success meeting people where they are, meeting the demographics, delivering on how their community wants to work, how they want to collaborate. But yesterday you talked about operations. We talked a lot about Ops as code. Talk about what does that mean from your perspective, and what did you hear from our guests on the program with respect that being viable? >> Well great, that's a great point. Ops as code is the kind of their next layer of progression. Infrastructure is code. Configuration is code. Operations is code. To me that means running the company as software. So software influencing how operators, usually hardware in the past. Now it's infrastructure and software going to run things. So ops as code's, the next progression in how people are going to manage it. And I think most people think of that as enterprises get larger, when they hear words like SRE, which stands for Site Reliable Engineer. That came out of Google, and Google had all these servers that ran the search engine and at scale. And so one person managed boatload of servers and that was efficient. It was like a multiple 10x engineer, they used to call it. So that that was unique to Google but not everyone's Google. So it became language or parlance for someone who's running infrastructure but not everyone's that scale. So scale is a big issue. Ops as code is about scale and having that program ability as an operator. That's what Ops as code is. And that to me is a sign of where the scale meets the automation. Large scale is hard to do. Automating at large scale is even harder. So that's where Ansible fits in with their new automation platform. And you're seeing new things like signing code, making sure it's trusted and verified. So that's the software supply chain issue. So they're getting into the world where software, open source, automation are all happening at scale. So to me that's a huge concept of Ops as code. It's going to be very relevant, kind of the next gen positioning. >> Let's switch gears and talk about the partner ecosystem. We had Stefanie Chiras on yesterday, one of our longtime theCUBE alumni, talking about what they're doing with AWS in the marketplace. What was your take on that, and what's the "what's in it for me" for both Red Hat, Ansible and AWS? >> Yeah, so the big news on the automation platform was one. The other big news I thought was really, I won't say watered down, but it seems small but it's not. It's the Amazon Web Services relationship with Red Hat, now Ansible, where Ansible's now a product in AWS's marketplace. AWS marketplace is kind of hanging around. It's a catalog right now. It's not the most advanced technical system in the world, and it does over 2 billion plus revenue transactions. So even if it's just sitting there as a large marketplace, that's already doing massive amounts of disruption in the procurement, how software is bought. So we interviewed them in the past, and they're innovating on that. They're going to make that a real great platform. But the fact that Ansible's in the marketplace means that their sales are going to go up, number one. Number two, that means customers can consume it simply by clicking a button on their Amazon bill. That means they don't have to do anything. It's like getting a PO for free. It's like, hey, I'm going to buy Ansible, click, click, click. And then by the way, draw that down from their commitment to AWS. So that means Amazon's going into business with Ansible, and that is a huge revenue thing for Ansible, but also an operational efficiency thing that gives them more of an advantage over the competition. >> Talk what's in it for me as a customer. At Red Hat Summit a few months ago they announced similar partnership with Azure. Now we're talking about AWS. Customers are living in this hybrid cloud world, often by default. We're going to see that proliferate. What do you think this means for customers in terms of being able to- >> In the marketplace deal or Ansible? >> Yeah, the marketplace deal, but also what Red Hat and Ansible are doing with the hyperscalers to enable customers to live successfully in the hyper hybrid cloud world. >> It's just in the roots of the company. They give them the choice to consume the product on clouds that they like. So we're seeing a lot of clients that have standardized on AWS with their dev teams but also have productivity software on Azure. So you have the large enterprises, they sit on both clouds. So you know, Ansible, the customer wants to use Ansible anyway, they want that to happen. So it's a natural thing for them to work anywhere. I call that the Switzerland strategy. They'll play with all the clouds. Even though the clouds are fighting against each other, and they have to to differentiate, there's still going to be some common services. I think Ansible fits this shim layer between clouds but also a bolt on. Now that's a really a double win for them. They can bolt on to the cloud, Azure and bolt on to AWS and Google, and also be a shim layer technically in clouds as well. So there's two technical advantages to that strategy >> Can Ansible be a facilitator of hybrid cloud infrastructure for organizations, or a catalyst? >> I think it's going to be a gateway on ramp or gateway to multicloud or supercloud, as we call it, because Ansible's in that configuration layer. So you know, it's interesting to hear the IBM research story, which we're going to get to in a second around how they're doing the AI for Ansible with that wisdom project. But the idea of configuring stuff on the fly is really a concept that's needed for multicloud 'Cause programs don't want to have to configure anything. (he laughs) So standing up an application to run on Azure that's on AWS that spans both clouds, you're going to need to have that automation, and I think this is an opportunity whether they can get it or not, we'll see. I think Red Hat is probably angling on that hard, and I can see them kind of going there and some of the commentary kind of connects the dots for that. >> Let's dig into some of news that came out today. You just alluded to this. IBM research, we had on with Red Hat. Talk about what they call project wisdom, the value in that, what it also means for for Red Hat and IBM working together very synergistically. >> I mean, I think the project wisdom is an interesting dynamic because you got the confluence of the organic community of Ansible partnering with a research institution of IBM research. And I think that combination of practitioners and research groups is going to map itself out to academic and then you're going to see this kind of collaboration going forward. So I think it's a very nuanced story, but the impact to me is very clear that this is the new power brokers in the tech industry, because researchers have a lot of muscle in terms of deep research in the academic area, and the practitioners are the ones who are actually doing it. So when you bring those two forces together, that pretty much trumps any kind of standards bodies or anything else. So I think that's a huge signaling benefit to Ansible and Red Hat. I think that's an influence of Red Hat being bought by IBM. But the project itself is really amazing. It's taking AI and bringing it to Ansible, so you can do automated configurations. So for people who don't know how to code they can actually just automate stuff and know the process. I don't need to be a coder, I can just use the AI to do that. That's a low code, no code dynamic. That kind of helps with skill gaps, because I need to hire someone to do that. Today if I want to automate something, and I don't know how to code, I've got to get someone who codes. Here I can just do it and automate it. So if that continues to progress the way they want it to, that could literally be a game changer, 'cause now you have software configuring machines and that's pretty badass in my opinion. So that thought that was pretty cool. And again it's just an evolution of how AI is becoming more relevant. And I think it's directionally correct, and we'll see how it goes. >> And they also talked about we're nearing an inflection point in AI. You agree? >> Yeah I think AI is at an inflection point because it just falls short on the scale side. You see it with chatbots, NLP. You see what Amazon's doing. They're building these models. I think we're one step away from model scaling. I think the building the models is going to be one of these things where you're going to start to see marketplace and models and you start to composability of AI. That's where it's going to get very interesting to see which cloud is the best AI scale. So I think AI at scale's coming, and that's going to be something to watch really closely. >> Something exciting. Another thing that was big news today was the event driven Ansible. Talk about that, and that's something they've been working on in conjunction with the community for quite a while. They were very proud of that release and what that's going to enable organizations to do. >> Well I think that's more meat on the bone on the AI side 'cause in the big trend right now is MLAI ops. You hear that a lot. Oh, data ops or AI ops. What event driven automation does is allows you to take things that are going on in your world, infrastructure, triggers, alarms, notifications, data pipelining flows, things that go on in the plumbing of infrastructure. are being monitored and observed. So when events happen they trigger events. You want to stream something, you send a trigger and things happen. So these are called events. Events are wide ranging number of events. Kafka streaming for data. You got anything that produces data is an event. So harnessing that data into a pipeline is huge. So doing that at scale, that's where I think that product's a home run, and I think that's going to be a very valuable product, 'cause once you understand what the event triggers are, you then can automate that, and no humans involved. So that will save a lot of time for people in the the higher pay grade of MLAI ops automate some of that low level plumbing. They move their skill set to something more valuable or more impactful. >> And we talked about, speaking of impact, we talked about a lot of the business impact that organizations across industries are going to be able to likely achieve by using that. >> Yeah, I mean I think that you're going to see the community fill the gap on that. I mean the big part about all this is that their community builds the product and they have the the playbooks and they're shareable and they're reusable. So we produce content as a media company. They'd talk about content as is playbooks and documentation for people to use. So reuse and and reusing these playbooks is a huge part of it. So as they build up these catalogs and these playbooks and rules, it gets better by the community. So it's going to be interesting to see the adoption. That's going to be a big tell sign for what's going to happen. >> Yep, we get definitely are going to be watching that space. And the last thing, we got to talk to a couple of customers. We talked to Wells Fargo who says "We are a tech company that does banking," which I loved. We got to talk with Rockwell Automation. What are some of your takeaways from how the customers are leveraging Ansible and the technology to drive their businesses forward to meet demanding customers where they are? >> I think you're seeing the script flipping a little bit here, where the folks that used to use Ansible for configuration are flipping to be on the front edge of the innovation strategy where what process to automate is going to drive the profitability and scale. Cause you're talking about things like skill gaps, workflows. These are business constructs and people These are assets so they have economic value. So before it was just, IT serve the business, configure some servers, do some stuff. When you start getting into automation where you have expertise around what this means, that's economic value. So I think you're going to see the personas change significantly in this community where they're on the front lines, kind of like developers are. That's why ops as code is to me a developer kind of vibe. That's going to completely change how operations runs in IT. And I think that's going to be a very interesting cultural shift. And some will make it, some won't. That's going to be a big thing. Some people say, I'm going to retire. I'm old school storage server person, or no, I'm the new guard. I'm going to be the new team. I'm going be on the right side of history here. So they're clearly going down that right path in my opinion. >> What's your overall summary in the last minute of what this event delivered the last couple of days in terms of really talking about the transformation of enterprises and industries through automation? >> I think the big takeaway from me in listening and reading the tea leaves was the Ansible company and staff and the community together. It was really a call for arms. Like, hey, we've had it right from the beginning. We're on the right wave and the wave's getting bigger. So expand your scope, uplevel your skills. They're on the right side of history. And I think the message was engage more. Bring more people in because it is open source, and if they are on that track, you're going to see more of hey, we got it right, let's continue. So they got platform release. They got the key products coming out after years of work. So you know, they're doing their work. And the message I heard was, it's bigger than we thought. So I think that's interesting. We'll see what that means. We're going to unpack that after the event in series of showcases. But yeah, it was very positive, I thought. Very positive. >> Yeah, I think there was definitely some surprises in there for them. John, thank you so much. It's been a pleasure co-hosting with you the last couple of days, really uncovering what Ansible is doing, what they're enabling customers in every industry to achieve. >> Been fun. >> Yes. All right for my co-host, John Furrier, I'm Lisa Martin. You've been watching theCUBE's coverage of Ansible Fest 2022 live from Chicago. We hope you take good care and we'll see you soon.

(melodic music) >> Good afternoon. Welcome back to Chicago. Lisa Martin here with John Furrier. Day one of our coverage of Ansible Fest 2022. John, it's great to be back in person. People are excited to be here. >> Yeah. We've had some great conversations with folks from Ansible and the community and the partner side. >> Yeah. One of the things I always love talking about John, is talking with organizations that have been around for a long time that maybe history, maybe around nearly a hundred years, how are they embracing technology to modernize? Yeah, we got a great segment here with the financial services leader, end user of Ansible. So it's be great segment. >> Absolutely. Please welcome Noor Shadid to the program, the senior SVP, excuse me, senior technology manager at Wells Fargo. Noor it's great to have you on theCUBE. Thank you for joining us. >> Of course. Happy to be here. >> Thanks. >> Talk a little bit about technology at Wells Fargo. I was mentioning to you I've been a longtime customer and I've seen the bank evolve incredibly so in the years I've been with it. But... >> Yeah. >> ...talk about Wells Fargo was a technology-driven company. >> Yeah. So I like to consider Wells, right? Being in a financial institution company. So I consider us a technology company that does banking as a customer, right? Like we were talking about. There's so much that we've been able to release over the couple of years, right? I mean, decades worth of automation and technology has been coming out, but lately, right? The way we provide for our customers, how fast at scale, what we're doing for our customers, it's been, it's been significant, right? And I think our goal is always how can we enhance the process for our customers and how can we provide them the next best thing? And I think technology has really allowed us to evolve with our customers. >> The customers. We are so demanding these days. Right? I think one of the things that short supplied in the last two years was patience and tolerance. >> Yes. >> People. And I don't think that's going to rubber band back? >> Yeah. No, I don't think so. >> So how, talk to us about how Wells is using automation to really drive innovation and, surprise and delight those customers on a minute by minute basis. >> Yeah. And so, you know, if you think about banking, we've been able, with automation, we've been able to bring banking into the 21st century. You do not have to go to a branch to manage your money anymore. You do not have to go, you know, go to deposit your check inside of a branch. You can do it through your mobile app, right? That's driven by automation and innovation, right? And, you know, we have all of these back ends tools working for us to help get us to this next generation of, of banking. We can instantly send money to each other. We don't have to worry about, I need to go and figure out how I'm going to get money to this person and I need to wait, you know, X amount of days. You, you have the ability and you have, you feel safe being able to manage your money at the organization. And so automation has really allowed us to get to this place where we can constantly enhance and provide features and reliability to our customers. >> It's interesting you mentioned that you guys are a technology can have it do banking reminds me of the old iPhone analogy. It's a computer that happens to make phone calls. >> Yeah. >> So like, this is the similar mindset. How do you guys keep up? >> Yeah. >> With the technology? >> So it's tough, right? Because there's so much that comes out. And I think the only thing that's constant in technology is change, right? Because it's constantly evolving. But what we do is we, integrate very well with these new tools. We do proof of concepts where we try to, you know, what's on the market, what's hot, how can we involve, like, how can we involve these new tools in our processes? How can we provide a better end result for our customers by bringing in these new tools? So we have a lot of different teams that bring, you know, their jobs are to like, do these proof of concepts and help us build and evolve our own strategies, right? So it keeps us, it keeps us on our toes and I think it keeps, you know, all these new things that are coming out in the market. We're a part of it. We want to evolve with those, what the latest and greatest is. And it's, it's been working right as customers of financial services and us managing our money through, you know, through banks. It's been great. >> So the business is the application. >> Yes. >> And how do you guys make that happen when it comes down to getting the teams aligned? What's the culture like? Explain. >> Yeah. So at Wells we have evolved so much over the, over the last few years. The culture right now is we want to make changes. You know, we are making changes. We want to drive through innovation. We want to be able to provide our, you know, it's a developer centric approach right now, right? We want to push to the next and the greatest. And so everybody is excited and everybody's adapting to all of what's happening in the environment right now. So it's been great because we are able to use all of these new features and tools and things that we were just talking about by allowing our developers to do that work and allowing people to learn these new skills and be able to apply them in their jobs, which is now creating this, you know, a better result for our customers because we're releasing at such a faster pace. And at scale. >> Talk about how, you talked about multiple groups in the organization really investing in innovative technology. How do you get buy-in? What's that sort of pyramid like up to the top level? >> Yeah. >> Because to your point, you're making changes very quickly and consumers demand it. >> Yep. >> You can do everything from home these days. >> Yep. >> You don't have to go into a branch. >> Yeah, yeah. >> Which has changed dramatically in the last it's. >> Powerful few years. Yeah. >> But how, what's that buy-in conversation like from our leadership? >> Yeah. If you don't have leadership buy-in, it's very difficult to make those changes happen. But we at Wells have such a strong support from our leadership to be a part of the change and be, you know, constantly evolve and get better. So the way we work, cause we're such a large organization, you know, we bring in our business, you know, our business teams and we talk to them about what is it that's best going to better our customers. How do we also not just support external but internal, right? How do we provide these automated tools or processes for people to want to do this next work and, and do these, you know, these new releases for our customers. And so we bring in our business partners and, and we bring in our leadership and, our stakeholders and we kind of present to them, you know, this is what we're trying to do. This is the return that you'll get. This is what our customers will also receive. And this is, you know, this is how we keep evolving with that. >> How has the automation culture changed? Because big discussion here is reuse, teamwork, I call it multiplayer kind of organizations where people are working together. 'Cause that's a big theme of automation. >> Yeah. >> Reuse, leverage. >> Yep. >> Can you explain how you guys look at that? >> Yeah. It's changed the way that we do banking because we're eliminating a lot of the repetitive tasks in the toil because we have partners that are developing these, you know, services. So specifically with Ansible, we have these playbooks, rather than having every customer write the same playbook but with their own little, you know, flavor to it, we're able to create these generic patterns that customers can just consume simply by just going into a tool, filling out you know, filling out that playbook template, credentials, or whatever it is that they need and executing it. They don't have to worry about developing something from scratch. And it also allows our customers to feel safe because they don't have to have those skills out the box to be able to use these automation tools, right? They can use what's already been written and executed. >> So that make things go faster with the benefits or what? Speed? >> Faster stability, right? We're now speed, stability, scalability, because we're now able to use this at scale. It's not just individual teams trying to do this within small spaces. We're able to reliable, right? Automation allows us to be reliable internally and for our customers. Because you're not asking, there's no human intervention when you're automating, right? You have these opportunities now for people to just, it's one click, you know, one click solution or you're, you're end to end. You got self-healing involved. It's really driving the way that we do our work today. >> So automation sounds like it's really fueling the internal employee experience at Wells... >> Yes. >> ...as well as the customer experience. And those two things are like this to me. They're inextricably linked. >> A hundred percent because if you need it, they need to be together, right? You want your internal to also be happy because they want to be able to develop these solutions and provide these automation opportunities for our teams, right? And so with the customers, they're constantly seeing these great features come out, right? We can, you know, with AIML today, we're now able to detect fraud significantly. What we would've, what we could've done a couple years ago. And, and developers are excited to be able to do that, right? To be able to learn all these new tools and new technologies. >> What's interesting Wells is you guys are like an edge application. Obviously everyone's got banking in their hand. FinTech obviously money's involved. So there's people interested in getting that money. >> Yeah. >> Security hackers or whatnot. So when you got speed and you got the consistency, I get that. As you look at securing the app, that becomes a big part of what, what's the conversations like there? >> Yeah. >> 'Cause that's the number one concern. And it's an Edge app. I got my mobile, I got my desktop. >> Yeah. >> Everything's in the cloud on premise. >> Yeah. And, and I think for us, security is number one. You know, we want to make sure that we are providing the best for our customers and that they feel safe. Banking, whatever financial service you're working with, you want to feel like you can trust that your money with those services. Right? So what we do is we make sure that our security partners are with us from day one. They're a part of the process. They're automating their pieces as well. We don't want to rely on humans to do a lot of the manual work and do the checking and the logging. You want it to be through automation and new tools, right? You want it to be done through trusted services. You don't, you know, security is right there with us. They're part of our technology organization. They are in the technology org. So they're the ones that are helping us get to that next generation to provide, you know, more secure processes and services for customers. >> And that's key for trust. >> Yes. >> And trust is critical to reduce churn and to, you know, increase the customer lifetime value. But, but people, I mean, especially with the amount of generations that are alive today in banking, you need to be able to deliver that trust intrinsically to any customer. >> Yes, a hundred percent. And you want to be able to not only trust the service but yourself that you can do it. You know, when you go into your app and you make a payment, or when you go in and you want to send, you know, you want to send money to a different, you know, a different bank account, you want to be able to know that what you just did is secure and is where you plan to send it. And so being able to create that environment and provide those services is, is everything right for our customers. >> What are some of the state-of-the-art kind of techniques or trade craft around building apps? 'Cause I mean, basically you're digitally transformed. I mean, you guys are technology first. >> Yeah. >> The app is the company. >> Yeah. >> That's, that's the bank. How do you stay current? What's some of the state of the art things that you guys do that wasn't around just a few years ago? >> Yeah, I mean, right now just using, we're using tools like Terraform and Ansible. We're making sure that those two are hand in hand working well together. So when we work on provisioning, when we, during provisioning where it's all, you know, it's automated, fully end to end, you know, AI ops, right? Being able to detect reoccurring issues that are happening. So if you have a incident we want to learn from that incident and we want to be able to create, you know, incident tickets without having to rely on a human to find that, you know, that problem that was occurring and self-healing, right? All of this is starting to evolve and bringing in the, the proper alerting tools, bringing in the pro, you know, the right automation tools to allow that self-healing to work. That's, you know, these are things that we didn't have, you know, year, decade ago. This is all coming out now as we're starting to progress and, and really take innovation and, you know, automation itself.... >> What's the North star internally when you guys say, hey, you know, down five years down the road, bridge to the future, we're transforming, we've continued to innovate. Scale is a big deal. Data, data sovereignty, all these things are coming up. And what's the internal conversation like when you talk about a future state? >> Yeah, I think right now we're on our cloud transformation journey, right? We're moving right now. We have workloads into our two CSPs or public cloud. Also providing a better service for infrastructure and being able to provide services internally at a faster space, right? So moving into the public cloud, making sure everything's virtualized, moving away from hard, you know, physical hardware or physical servers. That's kind of the journey that we're on right now. Right? Also, machine learning. We want to be able to rely on these, you know, bots. We want to be able to rely on, on things learning from what we're doing so that we don't make the same mistakes again. >> Where would you say the most value or the highest ROI that you've gotten from automation today? Where is that in the organization? >> There's so much, but what I mean because of all of the work that we're doing, there's a lot that I could list, but what I will say is that the ability to allow self-healing in our environments without causing issues is a very big return. Automating failovers, right? I think a lot of our financial institutions have made that a priority where they want to make sure that their applications are active, active and also that when things do go wrong, there is something in place to make sure that that incident actually doesn't, you know, take down any problems. I think it's just also investing in people. Right now, the market is hot and we want to make sure that people feel like they're being able to contribute, they're using the latest and greatest tools. They're able to upskill within our own environments at the firm. And I think our organization does an amazing job of prioritizing people. And so we see the return because we're prioritizing people. And I think, you know, a lot of institutions are trying, you know, people first, people first. But I can say that at Wells, because we are actually driving this, we're allowing, you know, we're enforcing that. We want our engineers to get the certifications. We're providing, you know, vouchers so that people can get those clouds certifications. It's when you do that and you put people first, everything kind of comes together. And I think, you know, a lot of what we see in our industry, it's not really the technology that's the problem, it's process because you're so, you know, we're working at large scales. Our environments are massive. So, you know, my three years at Wells have seen a significant amount of change that has really driven us to be.... >> On that point better. How about changing of the roles? IT, I mean, back in the day, IT serves the business, you know, IT is the business now, right? As, as you've been pointing out. What does the roles change of as automation scales in, is it the operator? I mean, we know what's going on with dev's devs are doing more IT in the CICD pipe lining. >> Yep. >> So we see that velocity check, good cloud native development. What's the op scene look like? It seems to be a multi-tool role. >> Yeah. >> Where the versatility of the skill set... >> Yep. >> ...is the quick learner. >> Yep, able to adapt. >> And yeah, what's your view on this new persona that's emerging from this new opportunity? >> Yeah, and I think it's a great question because if you think about where we're going, and even the term DevOps, right? It means so many things to different people. But literally when you think about what DevOps is allowing our developers and our operations to work together on one team, it's allowing, you know, our operation engineers aren't, you know, years ago, ops engineers were not doing the development work. They were relying on somebody to do the development work and they were just supporting making sure our systems were always available, right? Our engineers are ops are now doing the development work. They're able to contribute and to get, they're writing their own playbooks. They're able to take them into production and ensure that they're, being used correctly. We are change driven execution organization. Everything is driven through change and allowing our ops engineers or production score engineers to write their own playbooks, right? And they know what's happening in the environment. It's powerful. >> Yeah. You're seeing DevOps become a job title. >> Yeah (laughs). >> Used to be like a function of philosophy... >> Yeah, yeah. >> ... and then SRE's... >> SRE's. >> SRE are like how many servers do you have? I don't know, a cloud, what's next? (all laugh) >> What's next? Yeah, I think with SREs it's, you know, it's important that if you have site reliability engineers, you're working towards, you know, those non-functional requirements... >> Yeah. >> ...making sure that you're handling those key components that are required to ensure that our systems, our applications and our integrations, you know, are up there and they're meeting the standards that we set for those other faults. >> And, and I think Red Hat Ansible nailed it here because infrastructure is code. We get that infrastructure has configuration as code, but OPS says code really is that SRE outcome. SRE also came from the Google background, but that means infrastructure's just doing, it's thing. >> Yes. >> The ops is automated. >> Yes. >> That's an interesting concept. >> Yeah, because it's not, you know, it's still new, right? A lot of organizations used to see, and they probably still see operations as being the, you know, their role is just to make sure that the lights are on and they have specific access so they, you know, they're not touching code, but the people that are doing the work and know the environment should really be the ones under creating the content for it. So yeah, I mean it's crazy what's happening now. >> So I got an analogy that's going to be banking analogy, but for tech, you know, back in the automation, Oh, going to put my job out of business, ATMs are going to put the teller out of business as more tellers now than there are before the ATMs. So that metaphor applies into tech where people are like, "What am I auto? What's automating away? Is it my job?" And so actually people know it's not. >> Yeah. >> But what does that free up? So if you assume, if you believe that's good, you say, okay, all the grunt work and the low level on differentiated heavy lifting gets automated away. >> Yeah. >> Great. What does that free up the talent to do? >> Yeah, so when you, and that's great that you bring it up because I think people fear, you know, of automation, especially people that weren't doing automation in the past and now their roles are now they're able to automate those roles out. They're fearful that they don't have a space, a role anymore. But that's not the case at all. What we prioritize is now that those new engineers have this new skill set, apply them. Start using it to be a part of this transformation, right? We're moving from, we went from physical to virtual to now, you know, we're moving into the public, moving into the cloud, right? And that, that transformation, you need people who are ramping up their skill sets, you know, being a part of one of the tools that I own is terraform at Wells that, you know, right now our priority is we're trying to ramp up the organization to learn terraform, right? We want people to learn, you know, this new syntax, this new, you know, HCL and it's, you know, people have been automating some of the stuff that they're doing in their day to day and now trying to learn something new so that they can contribute to this new transformation. >> So new functionality, higher value services? >> Yes, yeah. >> It brings tremendous opportunity for those folks involved in automation. >> Yes. >> or on so many levels. >> Yep. >> Last question, Noor for you is what, you know, as we are rounding out calendar year 2022, entering into 2023, that patience is, that we talked about is still not coming back. What's next for Wells as a technology company that does banking? >> I mean, you name it, we're working on it, because we want to be able to deliver the best for our customers. And I think right now, you know, our digital transformation strategy and, and moving into the public cloud and getting our applications re-architected so that we are moving into microservice driven apps, right? We're moving these workloads into the public cloud in a seamless way. We're not lifting and shifting so that we're not causing more problems into the environment. Right. And I think our, our, our goal is right, Like I was saying earlier, people and evolving with the technology that's coming out. We're not, you know, we are a part of the change and we are happy to be a part of that change and making those changes happen. >> People first. >> Awesome, awesome stuff. >> Automation first sounds outstanding and I will never look at Wells Fargo as a bank again. >> Yeah. (laughter) >> Perfect. Perfect. >> Yeah, that's awesome. >> It's been such a pleasure having you on the program, talking about how transformative Wells has been and continues to be. >> Yeah. >> We appreciate your insights and your time. >> Thank you. >> Thank you so much. It was lovely being her. Pleasure here. Thank you guys. >> For our guest and John Furrier, I'm Lisa Martin. You've been watching theCUBE all day, I'm sure, live from Chicago at Ansible Fest 2022. We hope you have a wonderful rest of your day and John and I will see you tomorrow morning.