Simply just, you know, enabling their logs or collecting metrics does not automatically make a system observable. And a lot of teams realize that when something really breaks and they are not able to figure out in time, what do they even use to investigate those issues? They're like, hey. We do have these metrics. We've actually enabled these logs, but how do we even make sense of it? Welcome, Khushboo, to another episode of our podcast. Thank you for joining us today. For listeners meeting you for the first time, can you share your background and what's your role as a Principal Cloud Architect at Oracle looks like day to day? Yes. Of course. Thank you so much for having me on the podcast. I'm really excited to be here and share my views. I completed my master's degree in Telecommunications Engineering from University of Maryland, College Park. And right right after that, back in 2018, I joined as an Associate Cloud Solutions Engineer at Oracle. And then I progressed to become a Principal Cloud Architect, that happened last year. But from the beginning, it has been a customer facing role. So I've been interacting with different organization and enterprises that are either moving to Oracle Cloud or already on it, and just want to learn more about how they can more of their business use cases on our cloud platform. So overall, my role is about understanding what an organization is trying to achieve and then helping them decide how the technology or the service that we provide can support that. Sometimes that would mean introducing a service to them, talking about features, capabilities, and sometimes it could mean just helping their team work through an architecture, actually deploy things on our cloud platform, help them with troubleshooting or when they are facing any operational challenges. Over the past five years, specifically, I've focused on the observability and management services that we offer on Oracle Cloud Platform, where I help organizations understand what is happening in their cloud environment. Whatever telemetry or operational data that they collect, how do they even use it to investigate issues, what are the right services they should adopt for their monitoring requirements, and, you know, how much is gonna cost them, best practices around retention, and so forth. So, on a typical day, I may be meeting a new customer still, like, in the evaluation stage, or I might be talking to an existing customer just understanding, like, where they are and what are the practical next steps that I can take to help them move forward with their decisions. Wow. So you've got a, a pretty busy pretty busy role. One question I'm sure one comment you hear probably from all of your clients is, you know, we need a cloud strategy. What do you think they typically mean when, when they say that? I think that when organizations come and say they need a strategy, first of all, could encompass different type of questions that they may have. Generally, organizations have different teams focused on different part of their stack, and every team would kind of just be concerned about their side of things and how to best use this particular service operationally. How do we work with it? So it could be very granular, but very general questions about strategy are how do we even move a workload to cloud? How would it work when it is on the cloud platform? Which services do you offer that makes our business use case possible on your platform? And eventually, what will it cost? I think cost is something that's kind of always tied to all Yeah. Strategy questions. No discussion goes without, you know, pricing. So, I believe these are all important questions that the customers are asking because that's really where they are tying things to business outcomes they are looking for. And so would you say that cost is one of the biggest drivers in moving to the cloud for organizations, or is it something else like ease of access or and just data availability? It's also about the effort that they have to keep putting in to maintain certain things on their own versus, you know, us providing them certain things through our platform where they don't have to worry about the rest of the layers of the stack. So ease is definitely one reason. Cost because, of course, you can scale as you go. You don't really have to, you know, to have this much physical infrastructure and then keep expanding. So definitely cost is something, but I feel that organizations still need to be conscious about their plans. Cost is something that that is determined by how efficient you are with the way you are using any cloud platform today. Yeah. I mean, I, I think that tracks with kind of what we've seen as well. Cost is certainly a driving factor, but there's many aspects to the overall cloud migration that organizations are, are trying to, to achieve or, you know, their objectives change. Right? So, with much of this industry, we, Corsica, typically recommend against just a full lift and shift of your environment, you know, from an on prem environment to, to the cloud. I'm assuming you probably have run into that more often than, than we have even in in your role. Is that typically a strong approach for those clients, or do you typically kind of steer your clients in a in a different direction? So I would not say that it's, you know, automatically a wrong approach, lift and shift. What matters is, you know, what the organization is trying to achieve. If they just really want to very quickly, you know, leave the data center and reduce migration risk because especially when organizations have, like, their legacy setup and they are too concerned about data loss and modifications. It could be the right approach to just begin with. The problem is that when the move is, you know, treated as the finish and final strategy because we have to think also from their perspective of modernization. You have to take into account that maybe not on day one, but eventually you want to probably also modernize the way your application works because otherwise, you are trying to bring same type of technical debt, manual processes, and limitations that you had before to a new platform as well, which can effectively provide you more capabilities to resolve those issues. Even if you just go with lift and shift, it's still worthy of, you know, having those simultaneous discussions that, okay, what are the other things that we can do better in order to optimize and modernize their application stack once they are on cloud. So good for just taking the first step, making sure that the data is not lost, then eventually, of course, think about modernization perspective as well. So in that same thread, with the migration from, from on prem to, to cloud, whether it's a lift and shift, whether it's some sort of optimization sort of running in parallel to the move, are there any architectural decisions that can't be undone? Or have you ever run into a situation where a client tried to move and, and didn't really plan it out or think through it properly and, as a result, created a lot of pain for them? Generally, just having looked at different components that come into play when we are even getting somebody started on cloud. I would say that the networking foundation is extremely important and there are certain ways that how do we design a cloud environment, what are the basic building blocks like, what are the compartments that you're creating, how you're designing your different, you know, sandbox environments for different teams. Those are certain things that I feel are important to think about from day one, especially the network. It is easy to design. Like, it's like, okay, you click a couple of things and you are spinning up your cloud networks and you're doing all the subnetting. But if you are not thinking those future growth environment like how you might grow the address ranges, then those things could be difficult to, you know, plan for once you've already done everything. That's why we always encourage our customers to get as much education as possible. We do like a lot of one on one sessions focused on different areas and some of these things, like I said, are building blocks that how do you even create your compartments, how do you think about security, who should be able to access what in your tenancy, and then how do you design your network, what are your long term needs. So answering those questions during enough discovery sessions and then getting educated on all these topics, I think, play a critical role so that we are not making mistakes that are otherwise, you know, difficult to fix later on because we won't be able to, like, you know, backtrack and make all those changes once they've already been put in place. Yeah. And I'm assuming some of those decisions as well probably have an impact on the overall cost of the, the, you know, solution that you're, you're standing up as, as well. We've certainly seen it. I'm sure you have as well where a client will spin up a maybe it's a virtual machine, maybe it's some type of service, not fully understanding the cost or the pricing structure. Next thing you know, they get a very large bill that they were not expecting because they didn't think through or plan out that migration effectively. And it sounds like from what I'm, I'm hearing from you, the solution to that is more planning sessions, more discussions around the architecture of the platform itself so that you stand it up right the first time. Even if there's going to be iterations moving forward, you at least have a solid foundation from which you can you can kind of build. But that brings up a a question, I think, that I would have for you, which is meetings tend to take time. All of this seems to just take a, a lot of time. Executives want speed. How do you balance, you know, speed with, with governance in a in a migration or, you know, a standing up of a new environment like this? One thing that I commonly see is that when we are interacting with organizations, they have those team members from their side. They have their own responsibilities towards their organization to accomplish as well. So I do see that a lot of them are in rush, and they would come to us because they actually want to, you know, speed up the whole process, and then they want to go back to their day to day work. For that, like, some strategies that we use are offering reusable templates that could be run that have, like, infrastructure as code technology behind it, like Terraform and stuff that they can our customers can take and just run-in their cloud environment. And the idea behind these templates or reference architectures that we provide is that a lot of things, networking, access policies, security monitoring, things that a person should start from when they are building their cloud environment are already kind of packaged in those scripts in compliance with whatever the security benchmark would say or what best practices we recommend because they are not like, you know, building everything from scratch. We always like one on one workshop style sessions as well where we would guide our customers and walk them through what do you do in the environment because that's all also like part of educating them about how to work through the process because ultimately they are the owners of their environment. So I think it's a combination. It becomes by sharing these knowledge content, these resources that they can take and deploy pretty quickly. The second part is enabling them and making them understand so that once again, we don't want people just to be, like, clicking a few buttons and quickly provisioning whatever they want and then never think about it. We, we want to discuss that, hey. This is why you may need this service. This is what you can accomplish, and this is how much it's going to cost you. We also discuss, like, best practices around that. This is how you can control it. This is how you can watch for it. That would be how we try to balance speed and autonomy both because we want the customer to feel empowered and educated enough to be able to use all these things on their own in the long term. Do you think that there's any operational capabilities that are typically treated as an afterthought in these types of cloud migrations? So something that people might not generally think about is that, okay, how this workload or environment in general would even be operated after they are now on cloud. Teams may just focus on getting the application moved and making sure it is running, but once it is there, operation team still needs to understand what the application depends on, how they will know when something is wrong, and who is responsible for responding to that. So I also see, like, confusion, you know, between the teams and then blame games that, oh, they did this. They were responsible for monitoring this, and they would just, you know, miss out some important steps. They won't be thinking about what will we do if, if something really goes wrong, who is responsible for that, and what sort of monitoring should we have set up from the first day itself in order to know what really to do if something stops working tomorrow. Sort of in the same vein, I know that you had mentioned that you, you spend a lot of time in observability as well as AI and, and things of that nature. And so I, I kinda wanna take a, a look at the observability piece because I'm sure that needs to be designed from, from day one. It needs to be intentional and not just an afterthought, right, to the overall solution or design of, of what you're implementing. And if teams are truly approaching observability from day one, you know, how does that change the initial approach to the cloud architecture? Yeah. So I keep arguing that observability should be designed from day one. Simply just, you know, enabling their logs or collecting metrics does not automatically make a system observable. And a lot of teams realize that when something really breaks and they are not able to figure out in time, what do they even use to investigate those issues? They're like, hey. We do have these metrics. We actually enable these logs, but how do we even make sense of it? So, after getting so many of those questions, I started saying this quite openly that it has to be like a component of your day one design and not something that you think about when something is already broken and now you are not able to figure out where do I look for the reason and the root cause. So, of course, I do see environments where telemetry is being generated, but teams are not organizing it. They are not using the right products to synthesize that data. Data is generally, like, not centralized or retained appropriately. Their retention policies are pretty off. They have lost the necessary data, which they actually needed to troubleshoot something. Several reasons for considering observability for first day and thinking about it as an equally important strategy like other things that you would think about when you are designing your application. So the design generally and the architecture behind observability would totally depend on what the team is going to operate because the workloads can be different. It could be an application. They could be responsible for just databases or just the core infrastructure components. So every team takes responsibility of different things. But whatever they are responsible for, they need to think that which workloads are most critical and what kinds of failures are likely. And then what telemetry will help them detect and investigate those failures. So some of these questions are what they need to answer. That also brings us generally to a discussion where we tell them that, okay, which service would be the most useful for them. And when you even look at the wider observability industry, so many standalone products and then all the cloud platforms giving their own products for observability Yep. Then the teams really need to think about what is the best approach for us. Sometimes organizations are already tied to a certain observability tool and sometimes they are more open and they are just sort of discussing that, okay, this would satisfy all our monitoring needs versus this may not be as good for us. And then once again, the price point discussion comes into picture, what would be more cost effective. So I think all these questions would then become part of the architecture decision. And eventually, they can think about retaining their telemetry with whichever product they are going with and also ownership from their own side, which team is actually be, you know, going to be answerable for certain things. So, yes. Too many questions as around observability, but I think all of them are equally important. So let's kinda pivot a little bit to, to AI and specifically more AI ops because I know that AI has obviously been the biggest change in the industry in, in a very long time, and it's just happened so fast. Where do you see AI genuinely improving cloud operations today? And are there any areas where maybe it's still more of a, a promise rather than reality? Based on my own hands-on experience, the clearest value that I see is just helping teams understand operational data faster. For example, what I have myself tested out is that, okay, our AI assistant can explain complex log messages in plain language. I'm able to get that summary way faster. And then it's also pinpointing that, hey, this is most likely where the issue occurred. So that's something which I feel carries a lot of value because a lot of times when we are going through, like, lot of telemetry, of log messages, especially because generally we have lots of logs coming from, you know, variety of resources. So just being able to understand that, okay, what these hundreds or thousands of logs are trying to tell us very quickly is a good starting point, especially when errors themselves are kind of, you know, difficult to understand. Once you get used to all certain errors, you already know what it really means. But when you see something new, then having an AI assistant, of course, help understanding that is something that speeds up the process a little bit. And then if it can pinpoint you to where this issue is coming from, then you know which workload to check. And of course, know like every product is, you know, providing different level of capabilities. So, in the industry, some products already have the capability to generate queries or widgets for your dashboards and generate queries from natural language instead of learning conversion search language for every different product. So, depending on how a team would like to use things, I think all of these are pretty useful for engineers speeding up their process of investigation when something goes down and they have the pressure to kind of bring it up as soon as possible. There I think we still need to be a bit cautious is moving from using AI for assistance to taking autonomous actions. So, the agentic approach in observability is something that I would still be, you know, cautious about because I think that there are those sort of capabilities you can investigate alerts or follow, books, suggest likely root causes. Somebody I remember asked me, hey. Can we also remediate things automatically with your tool? And we didn't have it, at least not back then. But I would be cautious there because following an agent to change a production environment or resolve a query, especially without having human in the loop, could be a risky thing. And we really need to think through before these things are actually used without any human oversight. So Well, now that was gonna be my next question because tying AI into the observability stack to trim alerts or really surface the items or trends that are occurring. I mean, have you seen any use cases for that? I think so far, I've just mostly seen people taking advantage of the assistance to kind of understand the log data because we have to, again, think about the cost perspective. When we tell people about the AI assistant, we also have to kind of, let people know that AI also has its associated cost. So, these capabilities might be, you know, very openly available and the products are rolling them out in different formats, but we have to consider that in addition to, like, paying for the product, you're probably, like, going to pay a little bit extra for all the tokens and actions that are being exchanged behind every operation. Everyone is going to price it out differently. I cannot speak for each and every tool, but generally, what I have seen is that, okay, the team would be a little bit cautious. So, I'm not very sure that how far every organization is going how fast they are adopting everything. But some use cases that I have seen is that, okay, people are more open to at least using an AI assistant to understand what the logs and the other telemetry are trying to tell them, but it's good to see that they are still trying to do their own investigation after that point. That's so far that I have observed. Fair enough. Well, you know, I appreciate you you being here today. I do have kind of one, I'll call it final question to kinda leave our listeners with, with something. But for all of our listeners, if you could have them remember one thing about building a sustainable cloud strategy, what would you want that to be? Okay. That's a difficult one. I think I would want people to just remember that they should be making every cloud decision intentionally. Do not, like, adopt a service architecture or operating model simply because it is available on the platform. It is pitched to you or it is popular. You're seeing that a lot in posts and people putting out projects using that. So don't just make that the reason as to why you go for that particular product or service or architecture overall. So be clear about what is the problem related to your business, your organization you're trying to resolve, and whether your organization can even support that choice over time. Teams can have their own gaps. Learning anything new, getting accustomed to any new product is a learning curve for people who ultimately who have to, you know, operate it. And I think that type of clarity automatically helps prevent unnecessary costs, complexity, and technical debt as the environment grows. That would be my one thing that your listeners can take. Well, that's great. Really appreciate it. And, thank you for, for taking the time and, and joining us today on the podcast. Hope you have a great rest of your day. Yep. Likewise. So good to talk to you. Thank you so much. Yes.
