 Hey everyone, thanks for joining us today. Welcome to this event of building your cloud center of excellence with Hitachi Ventara. 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 Prambala Subramanian, the SBP and CTO at Hitachi Ventara. 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 cloud ops with you. Pleasure to be here. Yeah. Pram, 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 runs. With that as a background for this conversation, if you think about the cloud operations, there was a lot of lift and shift happening in the market where people lifted their workloads or applications and moved them on to the cloud where they created cloud significantly as an infrastructure. And the way they started to manage it was again the same form as they were managing there on from infrastructure. And they call it INO, infrastructure on operations. That's kind of the way traditionally cloud was managed. In the last few years, we've seen 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're codifying your infrastructure and applications already code and your data is also codified as data services. With now that context applied, 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 in 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 exacerbates the situation is multi-cloud 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 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 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 English class and that creates some complexity. So bringing all of this together and managing is really becoming more complex for our customers and obviously as a part of this we will talk about some of the ideas that we can bring 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 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 the 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're 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 levers 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 that 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 the solution that you're using from Hitachi Ventura. Absolutely. 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 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 a cloud environment, we are talking about an auto-scaled ecosystem having that financial transparency and the metrics associated with that. These become very, very critical to ensure that we have a successful presence in the multi-cloud environment. Talk a little bit about the solution that you're using with Hitachi and the challenges that it is eradicated. Yeah, so end of the day, right? We need to focus on our core competence. 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 how it 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 Hitachi manages it for us, right? So it's a perfectly complementary relationship where they act as two partners and Hark is a solutionist, extremely useful in driving that. And I'm anticipating that it will become more important with time as the complexity of cloud and cloud associated 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 existing 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 top two or three things that you would say on cloud operations that people need to understand so that they can manage that complexity and allow their business to be driven and complimented by technology. Yeah, 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 of migration, modernization and management as a single continuum to the cloud. Now, there is no lift and shift and there is no hey, somebody else definitely 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 workloads is a single continuum and it's not pre-separate activities, right? That's number one. 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 this is become a bit common nowadays, right? The challenge is because we think cost in the cloud as an afterthought. Consider this example. In previous world, you buy hard value, 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 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 workloads. In the last one again, and 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 the infrastructure. It's codified. So your code should be managing it. Now think of how it happens, right? That's where we're going as an evolution for this. Everything is code. That's great advice, great tips for the audience there. Manoj, let's bring you back into the conversation. You know, we can talk about skills gaps in many different facets of technology. The SRE role, relatively new skill set, we're hearing a lot about it. SRE led DevSecOps is probably even more so of a new skill set. If I'm an IT leader or an application leader, how do I ensure that I have the right skill set within my organization to be able to manage my cloud operations, to dial down that complexity so that I can really operate successfully as a business? Yeah, so unfortunately, there is no perfect answer, right? It's such a scarce skill set that any day, any of the portfolio company CTOs, if I go and talk and say, hey, here's a great SRE team member, they will be more than willing to fight with each other to get the person next, right? It's that scarce skill set. So a few things we need to look at it. One is, how can I build it with it, right? So nobody gets born as an SRE. 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 the common guideline and common objective that we're driving towards it. So that skill set 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 the beginning. Really kind of weaving these companies together on this journey to redefine cloud operations and build that, as we talked about at the beginning of the conversation, really building a cloud-centered excellence that allows the organization to be competitive, successful and really deliver what the end user is expecting. Sorry, I made something to it, I think. Sure. Yeah, one of the common things that I tell customers when we talk about SRE and to Manoj's point is, don't think of SRE as a skill set, which is the common way to raise the industry tries to solve the problem. SRE is a mindset, right? Everybody in a- Well said, well said. Yeah. So everybody in a company should think of him or her as a site reliability 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, A, I talked to L1 and L1 contrast all, they go to L2 and then to L3. So we're trying to move away from an issue escalation model to what we call as the issue routing or incident routing model, right? Move away from incident escalation to an incident routing model so you get to root to the right folks. So again, to sum it up, SRE should not be solved as a skill 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 handle of it. I love that. I've actually never heard that before, but it makes perfect sense to think about the SRE as a mindset rather than a skill set that will allow organizations to be much more successful. Krav, I wanted to get your thoughts as enterprises 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 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 Dev 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 and 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 laying 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 hard 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, sorry, try to put features into the same backlog for improving stability, availability, and 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 you're 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 skill set because this is not an individual thing you have to do. This is the company that is embarking on how to prioritize my backlog beyond just user features. Right, great point. Last question for both of you is the same. Top kind of takeaway things that you want me to remember if I'm an IT leader at an organization and I am planning on redefining CloudOps for my company, Manoj will start with you and then Prem, go 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 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 the 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, wizardry, the new tech, et cetera. But end of the day, if the customers are not happy, if there is no ROI, everything else, it's just garnish on top of that. Now it's all about the customer experience, right? That's so true. Prem, what are your thoughts on the top things that I need to be taking away if I am a leader planning to redefine my CloudOps company? Absolutely, and I think from a company standpoint, I think Manoj summarized it extremely, right? There is this ROI and there is this customer experience. From my end, again, I'll suggest two more things as a takeaway, right? One, Cloud cost is not an afterthought. It's essential for us to think about it up front. Number two, do not deeming migration, modernization and operations, they are once free. If you migrate a wrong workload onto the Cloud, you're going to be stuck with it for a long time. An example of a wrong workload, Lisa, for everybody 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 to run in production, it's better off running in a data center when my cost is capped, it's then 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 that cause pain when I want to manage it in the longer run. But 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 Ventura and GTC 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 Ventura. Thanks for watching.