 Hi, this is your host Apil Bhartiya and welcome to another episode of Tia Pahila's Talk. Today we have with us, once again, Keshav Suru, vice president of Customer Experience at Sios Technology Keshav, it's great to have you back on the show. Yeah, it's good to be here and it's been a while, we definitely have some catching up to do and I'm happy to be a part of this show today. And today's focus is going to be on the importance of support for high availability before we jump into the topic. Let's just really talk about the importance of high availability in today's modern world. Yeah, that's a great starting point. Let's start with that foundation. It's key to understand high availability before we can jump in and say that support for it is actually valid. So when we talk about high availability, we're talking about making sure that mission critical systems, applications and services are available for customers when they need it for the business's purposes, really seeking to accomplish the goals and the mission of that business. Without that availability, right, without systems being up and applications being up and functional, responsive, without access to data in the event of an outage, an unplanned outage, a data center disaster or a natural disaster, all of those things that we've come to rely on, they disappear. So high availability and high availability best practices are those practices, software services, architecture and infrastructure that lead to creating highly available resilient systems for mission critical applications and services. What are some of the, you have seen of kind of patterns, some challenges which are associated with building high availability strategy, building culture and getting best out of those tools that are available. So when you think about high availability, applications, databases, the data, a lot of the challenges that you will face are start with, really start with what your definition, what are your goals and requirements, right? So most of customers think of four or four nines of availability and then start looking at how do you architect a system for those particular goals, what are the applications that you need to have highly available, what are their interactions, how do clients connect to those systems, then all the way through that architecture, planning it out. Some of the biggest challenges that I see are planning out the architecture according to best practices and then going through and implementing and understanding where HA software is needed and then where your team may need to be augmented by high availability experts, so experts that provide support or services. And so a lot of that is where you can see customers that have challenges with implementing an HA strategy, you can look back and see, okay, it starts with how did they understand their own requirements and then what kind of architecture did they develop and did they go it alone to try to do all of those pieces or did they consult some experts who have expertise in these areas for constructing highly available systems for deploying high availability software to increase the application availability, database availability and handling the replication of data and data availability between servers and systems and data centers. And once again, it's sticking to the modern word. We also see a lot of cultural movement happening. The silos from old data center days are kind of collapsing, but we do talk about DevOps, DevSecOps, SREs, platform engineering. SREs side reliability is something that's considered to ensure the reliability. So when it comes to high availability strategy, which teams are target, whose problem or whose responsibility is it within teams? You know, that's a great question. And in our experience, we do see a lot of the silos, right? In fact, just a recent customer issue that we can kind of use as an example of what you describe as whose responsibility is it. It's actually the entire businesses responsibility for high availability. And I'll give you a great example. So we had a recent issue where the IT team had made some changes or for the storage team, it made some changes to storage. And then of course, not knowing that that storage change impacts the characteristics and performance of the database using that storage. Of course, then you have the database team and they're investigating the issues related to database performance and availability. And that also impacts the application team. So you have all of those challenges within just your IT infrastructure, right? So each one of those teams has to really think beyond their silo to recognize that high availability impacts networking, compute resources, storage resources, your application, your database. And then I'd raise it up one more level and say it's also the responsibilities of IT managers. It's also the responsibility of the business as a whole to make sure that those teams are staffed and that they're doing their best to make sure those silos don't exist, right? And that's a big challenge, right? You have a critical outage where it's actually the application team that reports the issue and then think about the delays that you incur when we think in terms of it's someone else's responsibility, not it's a responsibility across all of the teams. Maybe your application team realizes that their application is down. They engage with the high availability vendor, but you're waiting on someone with permissions to actually reboot the server. You get into a cloud environment where you have a team that may have permissions to reboot the system, but they don't have permissions on the cloud infrastructure. You have an application team that can start and stop the application, but they don't know how to manage the database. So it really becomes a collective effort of the entire organization seeking to make sure they are resilient. And as we talked about the challenges and the team, let's not talk about the importance of working with a player who has all the not only experience, but tools to help these teams. So basically the importance of support. Let's talk about just support in general, the importance of support in general first, kind of like we did with what's high availability and why does that matter. If we think about it in general in the world we live in and you're well aware and your audience will be extremely aware systems are complex now, right? There aren't any simple systems, very few simple systems and the complexity of systems is something that continues to increase, right? People are busy. It's not their primary job to understand all the inner workings of every system. Just like we mentioned before with silos, silos develop because people say my job is to focus on storage. So a lot of times users aren't necessarily the experts in a particular software package. They're doing that. They're using that software to accomplish another job. We look at software in general and there are numerous use cases for software, numerous workflows to get from point A to point B and then of course it's software, it's hardware, it's people involved so you're likely going to run into issues or perhaps bugs, software errors and need help around that. So just when you think about the general idea of why someone would want support, you multiply and magnify that need when you think of these are your business's most critical applications, databases and data and they are equally complex in a high availability environment. They touch multiple components within the infrastructure. Your IT team is always going to be busy. I don't know if I've ever met an IT person who says I've got plenty of time, just waiting on the next disaster. I have a lot of time on my hands to kill. People are busy and if you start thinking about your high availability systems, databases and applications, you tend to have DBAs, you tend to have application experts, you tend to have storage experts or AWS certified architects. You very rarely find that you also have a high availability. I'm an expert in this high availability software. You may have infrastructure experts, but people have other jobs and they have other things that they need to accomplish for the business. Right? And then we think about use cases and workflows. We see a lot of different customers use our software and the way they use it is always going to sometimes will surprise you and there are always different ways they tend to use it or tend to integrate it into their environment and into their workflow. So having a team that understands the complexity of high availability systems, that understands it's not your primary job to know all the ins and outs of the high availability software, a team that understands the complexities of architecting for best practices and then knows different use cases scenarios, has years upon years of seeing use cases, seeing problems, seeing errors and then having a team that's dedicated to helping you when you run into an issue. That's why support is so critical for something that is so important as high availability. When it comes to support, of course, support does not mean spoon feeding. Can you also talk about that even if there is of course provide like CIOs that can go and help team? How teams should prepare themselves so that they're better prepared and no pun intended for the support there? Right, right. So I like to think of that as is offering people how to get the most out of your support, right? And there are a number of different ways, but for the purpose of kind of making it easy, let's start with the four ends. I'd say the first in is notes. Teams can prepare by keeping good notes and details about the architecture. We like to call them run books. And so having a plan that lays out how how systems are architected together, how they work, what are their versions, what applications are involved, what teams are involved, having a run book that details notes for when you need to do an activity, you'd be surprised how valuable it is to have just a an ordered list of steps to take when you're getting ready to do a plan maintenance and then how destructive it can be when that team doesn't have that plan, right? So something that's very critical. You want to know what are the steps you're going to take to maintain that? So I'd start with notes, good notes, good details. The second thing to get the best or the most out of your support is notice. The second end is notice. You want to give your support team as much notice about changes in your environment, about maintenance plans. Of course, in high availability, the reason you have the software is to handle the unplanned disasters, right? But you don't want to create a disaster simply by not giving the team enough notice. That notice helps those support teams align with what are your plans? They can check those plans, make sure that you have taken good notes that you have a run book, they can talk to you about best practices. And so when you give your support team that advanced notice, it helps them help you to be better prepared when you need to call in. The third end, I'd say is news. And this was kind of a weird one. But I chose news because you want to share any news about your organization or about the environment with the support team. And then you want to follow their news about their software, about their product, about what they've learned, about their best practices, or even if they publish, if they publish webinars or episodes like the one we're recording where they can learn more about the best practices in high availability. It's a fast paced world we live in where things change a lot. So keeping your support organization aware of personnel changes and keeping yourself aware of the industry. What are some new best practices? What are things that your support team has learned? What are the new products that they have released that you should be thinking about and taking advantage of? A lot of times we had a call earlier today where a customer was just not aware that there was a new release and they didn't realize all the benefits they could get in stability, performance, and just some new features that are available in that release. So third end is news. And then the fourth one I'd say, if you want to get the best out of any support organization, is I chose no as the fourth one. It's a say no to skipping steps. It's high availability is critical. You want to say no to taking shortcuts. You want to say no to not involving your support organization in advance as often as you can. And definitely when you're getting ready to do some major milestone or maintenance, those teams have a wealth of information about the space, about best practices, architecture, interrelated systems, overcoming challenges within silos and architecting for best practices. So you want to use those. And then there are some other items around getting the most out of support that just didn't fit into the four ends. And so we'll say things like you want to make sure that you respond timely to communication, whether that's assembling all of the rules and responsibilities for a call when you're in the middle of unplanned outage, or if that's simply responding to a case that you've entered, keeping that lines of communication open and going. That really helps you get the most out of the team, because when they're working on your issue, they're making you their highest focus and they want to get that customer satisfied. And one of the hardest things to do is have a customer go quiet for a period of weeks and then jump back into the conversation as if it were only a few minutes later. So I'd say those are kind of the key points on how to get the most out of your support. As much as we like that, hey, the support will be optimum. But what if the support is not as good as a client may expect? Obviously we all want to have great customer experience whenever we contact a business and especially in high availability, you want to make sure that if you're in an unplanned outage or planned outage, you want to feel like you're getting the proper attention from your support organization. But we do realize we're all human and sometimes someone has a bad day or perhaps you are not getting what you expect out of the organization. So one of the key things there starts before you need support, which is making sure that you have selected a reputable high availability organization and that you understand what their support agreements are. So you want to make sure that you're choosing someone that provides the level of support that meets your SLAs. You want to make sure that you fully understand what their support agreements are. A common disconnect that you can see around is if the support organization doesn't provide 24 by 7, but you have that expectation. So you want to know that going in before you choose it. The second thing you want to do when you're choosing an HA software vendor is understand what are your levers for escalating when you don't feel like you're getting the proper level of support. And that could be to a support director or a senior support member. You want to understand what the support is like after the sale, right? Do you still have access to the sales rep and you can talk to them? And then you want to do kind of a follow-up. You want to start with what would you like to see different? It's very easy to drift into blame and complaining, but if you really want, if you're not getting the best out of your support organization, you want to lead them towards a path that helps you and them see the way forward, right? I'd love to see more responsiveness. Then you want to start with the question of, you know, what are your expectations in terms of responsiveness and then how can you work together to close that gap, right? Another thing is just making sure you're communicating and understanding one another. We had an encounter with a customer that escalated pretty high to us and the interesting fact is there was just a misunderstanding between teams. That was just a result of a language barrier. And so having a conversation with the team, understanding the language differences and then communicating with one another to get those resolved, a lot of the what if you feel like you're not getting the most out of your support can be handled just through communicating in a de-escalated manner and getting to a place of mutual understanding and then establishing a path forward where you can kind of close those gaps and get to alignment. And then of course, Sios is always here if you're using another support organization and finding that the support or the product that you're using is not up to your standards. Our organization is 24 by 7 and has award-winning support representatives available. Keshav, thank you so much for taking time out today and talk about high availability, the important support, and then the important support for high availability, how teams can prepare themselves to get most of it. Thanks for all those great insights and as usual, I would love to talk to you again soon. Let's make sure that there's not that much gap between our discussions. Thank you. Absolutely. Thank you. It's a pleasure being here.