 Sure. Yeah, thank you very much. Definitely, definitely happy to be here, happy to be covering this very exciting topic and have John with me as well. So I'm Gabriel Klandorf. I've been with ITRS Group for six years, spent in technology 15 or so. Lead Sales Engineer for the Americas, you know, looking at monitoring an IT for very large enterprises, you know, some are thousands of servers, tens of thousands, hundreds of thousands. It's a very big enterprise to States. John, you want to mention a little bit about your background? Sure. Yeah, I'm John Wagerman. I am a Solutions Architect here at ITRS. I'm based out of Omaha, Nebraska, and I just joined ITRS Group towards the end of last year. Prior to this role, I worked within the payments and financial services space in both systems and application engineering roles. So the trauma of late night triage sessions and getting woken up by false alerts is all still very fresh. And I'm very much enjoying being able to help organizations minimize those situations for their own people. Yeah, you were you were wearing the pager, you were really in the trenches for a while there. So happy to have your perspective and expertise with us. All right, I'm going to switch to our slides here. So just to cover the topics we're going to go through. So first off, just what is in an enterprise estate? What is in these hybrid environments? What types of technology are out there? There's lots of different things. What are they? Which is build a list? Given that, what types of tactics and tools and data collection do we need to build up a complete picture? How are we actually going to get visibility into all these devices, into all these systems, into all these applications and pull that all together? And then that last thing is how do we pull that all together? How do we get that single pane of glass? How can we get it all in one place? Or do we use multiple tools? Do we have them work together? Or can we get it on one screen? What do we do in that capacity? And for anyone who's catching this as a video or whatever, if you want to skip ahead to one of these sections, if it's more interesting, go ahead. So that's what we're going to go through. No code today, but definitely a buyer's guide and kind of a wide lay of the land of what we need to do to cover hybrid estates. So what comprises one of these large enterprises? What types of things are out there? And so once upon a time, back in the day of the dinosaurs, there were network devices, there still are, and there were mainframes. So these are a bit of antiquity, but it still is true today. Large firms often still have these kicking around, and we need to have visibility into them. So we need to, we need to certainly do the network stuff that probably many people have at the forefront of their minds, but mainframes are part of the picture as well. And we can't neglect some of the legacy elements that are still out there in these estates. We move forward closer to today, maybe in the 90s kind of dot com era, and we have, you know, off the shelf kind of physical servers, more smaller size, breaking down these monoliths into more commodity hardware with applications then coming in, right? Web servers, processing applications, databases, different things like that, running on those physical boxes. Now we add that into the estate, and we're just adding on and getting closer and closer to today. We bring in virtualization, wanting to go down that next level of granularity and modularity with the hardware, not having to worry about plugging in physical machines quite as much, abstracting that out, having those virtual servers, virtual hosts. So we bring that into the mix, and people will run these things in parallel. Some firms you'll see will have mainframes and physical and VM all right next to each other. So we get to the cloud and we say, okay, well, I don't want to run those VMs. I'd like to let someone else run them for me. I'm willing to let, you know, delegate that, let them take that over, and more and more, you know, over the open internet connectivity, more IoT, more devices out there, hardware out on the net potentially. So more and more of that outside of my firewall, outside of my estate connectivity as part of the picture here. And this is where we really start to get into the hybrid element of things. We've got VMs in the cloud, but then we add in other things, right? We've got containerization, again, just smaller and smaller by breaking down, you know, physical servers to VMs, VMs, containers aren't quite the same as VMs, but similar, they work similarly, and they're just that next level smaller, more of them. Having those either in the cloud or on-prem, we can have container environments and platforms on-premise as well. And then also, if I'm willing to abstract things away, using cloud services. So now I'm saying, hey, I'll use that Elastic Block Store. I'll use that RDBs, that cloud database service, things where I don't even have to worry about how it's running, the thing is just there for me in that topical service offering. So that's a piece of the picture now as well. We've got cloud services, we've got all these things just piling up this bigger and bigger picture. And then lastly, we move to, we brought in containers, it's not going to be long with containers before we bring in orchestration, right? If we go to microservices, we need something to be able to manage them. We need something to be able to run them all in concert, keep everything, keep the trains running on time, right? Manage the cloud container presence in clusters and whatnot, the on-prem ones, whatever it might be. It's another piece of the puzzle that we need to bring in here. So a lot of different technologies, really a wide gamut of disparate things we need to cover from physical stuff to virtual stuff to logical stuff to every different kind of technology that's in that estate honestly looks a little bit intimidating. So we're going to go through what all do we need to have and consider to be able to cover this. So given that, what are the data collection things we need to do? And John, I'm definitely going to rely on you heavily here, but let's take these just a layer at a time and go through them kind of point by point. The first one, network devices. It was true back when and it's true today. What options do we have to cover network stuff? Right, Gabe. So the base of any infrastructure is going to be these network devices. And there just aren't a lot of options here for monitoring. First is the big one, SNMP. The author of SNMP Mastery, Michael W. Lucas referred to it as four lies in one acronym. You'll love it or hate it or probably more accurately think it's okay or hate it. It's what we've been stuck with for a really long time and what we can expect to be using for a long time going forward. It's probably one of the least standardized standards out there, but it's a standard nonetheless. Virtually all devices support it to at least some degree. The good news is that because it's so ubiquitous, the options for monitoring it are numerous and they're generally going to be mature. Additionally, some device vendors have created their own command line interfaces, APIs, or protocols for monitoring. Probably the biggest one out there that we all know is Cisco's NetFlow. But there's others. You've got IPfix, JFlow from Juniper, 8p has NetStream, and there's numerous other ones. And most of the time, these all get better insight and are easier to work with than SNMP. But unless you choose devices that are compatible with one another, you're looking at adding a lot of complexity. And one thing to note here as we go through these, our intention isn't to provide a comprehensive list of every single way to monitor certain devices, but just a handful of popular options. Right. Building up what should be a talking points or considerations, the main categories of things. So here, it's basically get some basic coverage with SNMP. I can do that everywhere, or I can get possibly better visibility by going with something proprietary, but I have to do the coverage, I have to do the integration, or I have to collect the data from all the different vendor protocols, basically. Right. Okay. So let's add in those main frames. Again, they're, you know, a bit of a legacy item here, but they are still out there. Yeah. And main frames, they're still widely sold and used. Hopefully, we're not talking about monitoring the exact same devices, you know, in a basement that have been there for 30 years, but, you know, either way, new or old, main frames typically serve the purpose of running mission critical, high volume tasks very quickly. So tasks like batch jobs and transaction processing. And when it comes to monitoring main frames, not much changes on the hardware side. We will still usually have the SNMP option along with some vendor specific options. What we've added now are applications into the mix. And whether it's a commercial application or something built in house, APIs are a popular way to get application specific metrics, databases usually come into play here also. So querying those can give a lot of insight as can custom solution or scripts. Okay. So keeping the hardware coverage we have from the network devices, the tools and tactics we have there, and adding on logical monitoring and kind of app monitoring for the first time. Right. Okay. So if we break down the monolith and we have physical servers now at a smaller size, we bring in one of my favorite things. And this is where I get a bit biased. I have a perspective. I like agents. We bring in monitoring agents and agents really open up a lot of good visibility for us and a lot of coverage options. Yeah. And you're right. Agents are the big one here. Now, while there are some agents that will run on main frames, they become an almost universal option and we're talking about running the major server operating systems like Linux, Windows, Solaris, AIX, whatever. Whether monitoring a solution, whether a monitoring solution, whether it's a brand new open source startup or a long time well-established commercial offering, you can expect them to have a metric collection agent that's going to run on these OSs. Beyond agents, we also get the options for some OS specific monitoring like WMI or some non-agent alternatives like Puppet or Ansible. Okay. So getting that next level of visibility, really good granular hardware data from within the OS, knowing what the OS thinks it's scheduling of the apps and how that's running, agents really give us that next level of the picture. Okay. Then we switched to virtual machines and we've kept everything we have but added on this extra layer here. What is going on with these platform metrics? Yeah. So in the case of virtual machines, we now have a hypervisor, which is the operating system, firmware or software that actually manages those multiple servers running on a single machine. These for monitoring will typically have a standard API or software suite that will give you visibility into how the overall resources are being allocated, as well as some of the basic stats on the virtual machines themselves. And while this may eliminate the need to collect certain of those hardware metrics, we're almost always going to still need a solution from this list of application metric options, whether it be an agent or otherwise. Right. So we want visibility at the node level, what the what the metal hardware is doing that the virtualization platform can see, but also some stats from within the OS and that application and logical visibility as well, and then marrying those two together. We need to have both in tandem to really understand what's going on. Okay. So then we then we ship them off to the cloud and we've kept again, all the same stuff. We've swapped out the hypervisor here and we're focusing on just cloud metrics. What is what is the change there? Yeah. So as we start moving these VMs to the cloud, we don't have a lot of changes except for that we don't have that local hypervisor to query anymore. Now we have to rely on our cloud provider to give us that information. And the major cloud providers tend to give us a couple of options, either a free or low cost API that we can query to get basic machine information or more and more, we're seeing paid solutions that will expand that API and then also provide some comprehensive monitoring where you can get detailed dashboards and alerting. However, just like with our on-prem VMs, we're still going to need an option to get visibility onto what's happening inside with other applications. Okay. And this, this is a place where, you know, you'll see firms trying to figure this out that you want to use the cloud data that they're giving you and the provider is basically saying, hey, that virtual machine is there. It's running. That's all I can tell you. They don't know what the apps are, what it's supposed to be doing internally. So you want that agent within the cloud VM to do the rest of the work. And you really do want to do both. And there's a bit of a footnote here in that these machines tend to move a lot. They tend to be more dynamic. So we probably need to run our agents a bit differently in some sort of self-announcing mode or building them into our CICD pipelines or some way that the agents can be savvy to the dynamicness of the cloud, to the dynamism of the cloud. As machines come online, they automatically have the agent built into the image. They automatically connect to the modern platform and start broadcasting metrics in or something like that. Okay. So we've got cloud servers. We're building up the coverage here. And then we add in services. And wow, it looks like a lot of things change here, John. What happened? Yeah. So up until now, we've been adding a lot of layers that make monitoring more difficult. But now we're making it more difficult because we're losing a lot of these options that we may have been relying on previously. We no longer have access to the underlying hardware or even an OS. So those options are just completely gone. We're now left with whatever the cloud provider gives us and whatever options we've built into our applications. However, there's one thing we didn't mention earlier. And that's an option for most things web-based. And that's synthetic monitoring. This is where we can send external requests through our web app to perform tasks and let us monitor the user experience. Right. What do my users see? What is it like to be one of them? Definitely a really important way of testing things. And we've, yeah, okay. So we've abstracted away the hardware. I'm lazy. I didn't want to run it. So we've abstracted away the hardware. We lose visibility to it. But we've still got all that logical visibility that you mentioned. All right. And then we go to containers. And we still have given up that hardware stuff. But what else can we do here? And what's different when we go to containers? Yeah. And we've saved containers for last. They're difficult to place in this list because they can't exist both on-prem or in the cloud. But just like with cloud services, our options are pretty limited. We can usually get basic information on our containers from the container platform, whether it be the Docker CLI or API for our on-prem installs, or an API provided by our cloud provider, or in some cases, we're using both. The challenge, again, here is getting visibility inside of the container. So we're relying again on those API calls, database queries, scripts, or synthetic solutions to monitor your application health. Right. So again, that same model of platform metrics, asking the platform what's going on and then doing some app logical stuff. In here, sometimes we do in-app metrics. There's code injection things. There's stats V. We're kind of repurposing our app options. There's lots of things that can be done here. But those are the main categories, probably. Looking at this, this is a lot. John is pretty intimidating that there's all these different things, all these different kind of plugins and tactics and data capture methods we need. What can we do to even handle this? And I guess I'll start us off a little bit just to set a baseline of what a monitoring platform is. But really, how can we get this all in one place? Or can we get this all in one place? So at a very, very oversimplified level, a monitoring platform, I'm just going to give some basic building blocks, some basic parts here. There's collection. There's some place that we're fetching data. There might be agents, it might be other things, whatever it is, some manner in which we're gathering data together. It needs some processing. It might need to be indexed. It might need to be alerted on and threshold and rules and whatever. But there's some processing of it. It has to be saved somewhere. It has to be stored. We need some way of saving it. And somewhere, somehow, some human is going to see it. And so UI here is a bit open-ended. It could be Slack messages. It could be emails. But probably there's also an actual web interface or thick client interface, some UI to this platform. So that's a basic monitoring platform. If we break it down that way, given what we've said so far, all these different bits of techniques and data capture and different types of collection and different methodologies, my instinct would be to say, we're going to have many of these. And this is just a dumb first guess to say that maybe the physical servers have one platform. The database stuff has its own dedicated tool. There's a network tool that does scanning and discovery and mapping. Maybe I have something that's really good for cloud presence, or I use the cloud data, and that stands to the side as its own source of data. And then I've got some really dynamic, fast container visibility or something. I could see having multiple tools to cover this, but what does that get us, John? Is that what we want to do? Yeah, I certainly see some upsides with choosing multiple tools. We could pick the best in-class solution for each part of our estate. Networking can have their platform, and we don't have to worry if it's going to work for the database or storage teams because they can just go with whatever works best for them. And also, when you have multiple tools, if one of them goes down, we're not totally in the dark when it comes to visibility into our infrastructure. Right. Okay. So a little bit of failure isolation there. On the flip side, I always worry, and this is a particular focus I try to turn companies on to, operations, operation ability, kind of a made-up term. You could think of it as SRE, if you're thinking of it that way, culture of monitoring, if you want to call it that. Basically, how much are we enabling our staff to do prod support? How much are we enabling our staff to actually run ops, fix things, detect issues, work together? And a big piece of this, if people are living in different tools, if they're looking at different sets of information, there's a lot of finger pointing, a lot of disagreement, staff, they're not working off of the same data. They're not working off of the same reality. So it doesn't always lend itself to kind of figuring out what's wrong and moving forward very quickly. Also, lots of different UIs to live in. Staff workflows start to suffer a little bit. Can people actually get from A to B to Z to whatever to take something quickly? Or are they juggling between many different UIs and fetching data from other places to do their job? So a lot of thinking around, not necessarily a deal breaker, but just a lot of concern around how well are the staff actually going to be able to do their jobs and navigate through that tool of set. Also, dollars. If I've got many things I got to buy, it just kind of adds up, right? There's more money as I'm purchasing, you know, one item versus four items versus 10 items, the amount that I'm spending likely builds up. And even if I'm not buying them, even if it's a free tool, Prometheus or whatever might be out there, open source things, I still have to run them. I still have to manage them and administer them and maintain them. That's going to add up too. There's a cost of ownership implicit in that, the effort there and the cost of my staff to run these platforms. So definitely some pros and cons having disparate tools. The next obvious idea to me would be if we pick one, if we say, all right, this is the guy, we're looking at many monitoring different tools, we're going to pick this and everyone's going to want to use that tool, that platform, hopefully a pretty big one, but we're all going to converge to that. What does this get us, John? Are there pros there? Is that what you would want to do? Yeah, yeah, there's a lot of great options or a lot of great things with this option, you know, when there's an issue, everybody in engineering operations and leadership, they're all going to be on the same page looking at the same data in the same UI. It makes training easier, set up easier and gives us a lot of consistency. It would also would be nice to only have one vendor to rely on for support and we don't have to worry about any unsupported integrations we may have had to build if we had multiple tools. And speaking of integrations, if we go with a comprehensive solution, we can expect that it can cover just about everything we have to a reasonable extent. Right. If this is an enterprise level offering, one assumes it's a pretty wide ranging in its capabilities. Sure. On the flip side, I can imagine, right? You think you're a manager, you know, trying to go through this buying process and you've got 10 different audience members below you and they're all clamoring for different things. They've all got different constraints, requirements, wish list items that RFP is getting longer and longer. It's going to be harder and harder to find that one Goldilocks platform that's going to cover everything perfectly. So it just becomes a harder search, longer search. You have to do a bit more due diligence and whatnot to really try to fill out that full requirements list. On the flip side, or probably in conjunction, there'll be compromises and because it's going to be so hard to exactly give everyone exactly what they want, probably going to have to make some trade-offs. People get only 80% of what they want or it's good enough in certain areas. So it definitely gets us some really nice things, but there are costs to that. How do we pick a tool? And this is true if it's multiple tools, if it's one tool in general, what are we looking at? I think of that operation ability first and foremost, right? The job of this is to be able to do production support, to be able to do IT ops, be able to keep the lights on, make sure when stuff is broken, it's getting fixed quickly. We know that stuff is healthy or not and exactly how much. Really having that operational mindset of are things working, what's broken, are we fixing it? So that's first and foremost, I think. But certainly also integrations, what APIs are supported, what integrations come out of the box, what protocols are supported to make it easy to interface tools with each other, or to fetch data from some of our bespoke apps or to fetch data from this app that there isn't an out-of-the-box solution for. So being careful around integrations, what capabilities and options we have there. Data residency and this is becoming a bigger and bigger topic as the cloud is more and more prevalent as we're talking about hybrid, as we're talking about SaaS offerings. Where does the data live? How much is there? Do I get granular? How granular is it? Do I get access to full granularity or is it aggregated when I go to retrieve it? So if it lives within my walls, maybe I have to do a bit of management around how much I'm storing and when we want to start to aggregate the data down versus if it's out in the world, I don't have to worry about supporting the actual data store, but I'm running the hardware for it, but I don't have as much control over what we're saving. So where it lives, definitely a question and whether that matters to a firm or not. Also the data model, we're talking about different types of data collection and the platform may or may not be able to capture all of them. Certainly metrics, nearly everything can do that, metrics, sure. But even that has questions of if it's dynamic workloads, if it's containers that come and go, is there enough metadata for me to be able to understand how that workload relates to the same workload two hours ago that came and went? Can I map things together? Is there enough in the data model from a metadata perspective to make sense of everything? Not to mention what about logs? Does it store logs? Some things don't. What about traces? Does it store traces? Different kind of data to be capturing. We want to make sure we have a place for that. And then completely different network topology graphs or maps. When I do a scan and I've got dependency mapping and data flow mapping, that's a totally different type of data to be capturing as well. And then everything else that's out there and goes with all of this. So the data model, what we can save, how well we can save it, how it represents it, that's pretty important. And then lastly, the UI. Does it have visuals that are not just pretty, they're not just going to be eye catching and make our executives get excited to see them on a TV, but actually help people get that operations thing, help people make sense of the data, be able to visualize it well, be able to use it well, be able to do their job well, hopefully interact with it, hopefully have custom views, hopefully maybe even make changes against the underlying system. So UI that really enables, gives the user empowerment and is able to help them leverage the data as much as just show it. All right, so we've done many different tools and we've picked one tool. I guess the next best thing I can think of would be if we kind of picked one tool. If we kind of converge to one as the main standard, but we allowed for others to do some side jobs effectively. Maybe they would have a specialty in one area and we fetch that stuff in and bring that along for the ride. But we mostly have a primary and then the others kind of work sidecar or alongside by some sort of integration. John, does this make any sense to you? What does this do for us? Yeah, so with this one, we get the option to again choose best in class tools. Just like if we had the disparate tools. Of course, with the caveat that our chosen tool can export to our chosen data store, whether that be a time series database like Inflox or a traditional database like MySQL. But we get that nice modularity where we can insert, remove or change our tools a lot easier than if we just had the one. Along with that, we're not vendor trapped, which can potentially give us an upper hand when it comes time to negotiate or renegotiate contracts. Right, right, right. Yeah, definitely some good points there. Tool modularity, being able to swap things in and out, having each one do their job really well, but then only using them for the part that they're good at. Specialization, that all makes sense. And you can visualize this very easily. If you had some monitoring third-party platform, then you had maybe Prometheus for some collection, some cloud data coming in. Maybe there's a log tool, and it's all being kind of merged together. And then maybe a couple different UIs, the one that comes with the platform, maybe Grafana. And then maybe we do some reports or some data analysis, fetching stuff off the API or something like that. So I could easily see exactly what you're saying. Many different modular parts each specialized to their area. That does imply a mixed technology set. And that can be a blessing, like we just said, but that comes with a cost. I've got to know all those different tools. I've got to install them, administer them, manage them, run them. I need to get them to integrate with each other. So there's a lot of my own kind of DIY, roll up your sleeves and elbow grease to get that all to work together well and to keep that ship running in the way that you want. We also did say we're converging to one data model. We're saying that this platform, we're going to send all the data to this database, whatever it might be. Like you mentioned influx, there's different things out there, but we're going to merge everything into that. That does imply a constraint. That does imply that if that data model doesn't support certain types of data, we're going to lose it. I can't get those traces in there. If it doesn't do logs, if it doesn't do those network maps and topology diagrams, that's a challenge. So we have to really be careful about that data model. It's going to be a lot of due diligence and scrutiny. Does it cover everything we needed to? Does it have enough metadata and dynamicness for short-lived workloads and containers and things? So we have to be kind of extra, extra scrutinous there. And the last thing is support. That's kind of implied up here because we've got mixed technology bag, we've got always different things out there. Are they supported? Which ones are supported? Who do I go to? Where is it party A's responsibility versus party B's with that integration between two parts? There's a lot of questions around that. So we've said, okay, multiple different tools, multiple collection, one data store. The other option I guess I could think of would be multiple tools, letting them save their data however they want, but then trying to bring them together in the UI somehow, trying to just merge it all into one screen somehow. So PAD just, this is again, maybe a primary tool, but definitely a primary UI, my apologies, getting a little click happy here. One primary UI, but then I have all these different platforms, they run exactly the way they want, they can save the data the way they want. So there's no loss, it's all being captured in its own native kind of format. And then we try to bring it together after the fact. What are your thoughts on this, John? Does this look helpful? Yeah. I mean, again, we get to pick the right tool for the job, but we don't have to worry about whether it can export to, you know, that single chosen data store like in the last option. We don't have to risk that data flattening or manipulating our data just to make it conform to a single data store, because each tool gets to write to its own native location, meaning that we have access to all of the data as the product developer's intended. And when it comes to the UI, there's some really great options out there that are able to poll and receive data from a wide range of sources. Of course, the big one right now is Grafana. And say you have one tool that's writing to Influx, another to MySQL, and then another one shooting out web hooks. It's no problem for a lot of these tools to take that all in and give you a standardized and consistent single view of everything. Right. In a way, looking at this, we've kind of taken our constraint on the data store, like you said, away by bumping it up a layer. So now the UI is beholden to be able to talk to all these things and make sense of all these disparate data models. The data hasn't been converged to one model. It's different models and the UI has to handle it. So it's fine. We're just moving the constraint up a layer, which is fine. That may imply compromises on the data visualization. And what do we mean here? Grafana does do logs, but probably not as well as a dedicated logging tool. Right. That's just reality of how this works. If you've got a tool that's really good at network maps and graphs and diagrams, maybe it's mediocre on metrics, maybe it's not so good on log visibility, it still is going to shine in that one area. So when you're going to that one UI, it may not be able to do all things perfectly. And there is a trade-off there that there's a compromise in how well it can do all the different things we want it to. We also, Grafana is out there, there may be a limit. There is a limit to the number of UIs that can do this, that are these cross-connect multiple data source types of tools. There are some, but they're not infinite by any means. And the last thing is it's implied, Grafana has adapters. There's integrations work here. We have to make sure that the UI can talk to all those data sources, fetch them down, make sense of them, read the metadata, understand what's what, and really intelligently be able to visualize that stuff. So definitely some pros and cons there as well. So between a lot of these, it might be some firms go with one tool, some firms go with many tools, some firms integrate them, kind of merge all onto one in one place or another. A lot of different options here, and it's really just what fits a given enterprise, what makes sense in a given estate, which of these you're going to go with. But given that, we can then think also about other elements of the platform, i.e., am I going to run it or am I going to go sass? Am I going to run it somewhere else? And so we could think if I'm running it within my walls, or if I let somebody else run it, what are the trade-offs there? Which do we want to do? Looking at the on-prem version of this, there is a bit around cost and access. Now cost, it's going to cost me hardware to run the platform. I have to actually provide the resources to do it, but that's a one-time cost that I can ameliorate over time. Sometimes that's appealing. Sometimes a firm really wants that, especially for something like a monitoring tool that's always on, around the clock, lots of data to be stored, fetched, accessed all the time. If I'm putting it in the cloud, I might not have, if it's a SaaS solution, like I mentioned, I might not have access to full granularity and raw metrics. I might not want to access it as often as I would like to because it costs me to fetch data. Maybe we would do some reports that we're feeling like we're going to not do some reports due to the cost associated with fetching the data, where we would do them otherwise if it was free to access it. So definitely some implications around storage, ownership and running an access to the data. Also, just on ownership, if I've got it within my walls, if I've got it within my database or my systems, just warm fuzzies. Sometimes people just really like having and holding and owning all of their own information. That's a perfectly valid reason. Security here comes off the back of that with a question mark. Conventional wisdom would tell us that it's more secure on-prem. That's the norm, the default, that's what we've assumed, and you'll hear people just state that. We've been stating that for a while, but it's not set in stone by any means. The cloud providers are being more and more aggressive about trying to be secure. They're thinking more carefully about it. They're being more proactive about it, putting out better tooling to help with this. They do prompt us to be more secure. They set more things by default and disable certain things by default to try to force us into a secure way of running. And we have to turn things off if we want to open things back up, et cetera. So there's a lot that cloud environments are trying to do to be competitive, to be more secure. And so that conventional wisdom, it's there. Maybe that wins out. Maybe for a given type of firm, the cloud tooling and really adopting the cloud natively and really fully immersing in it and embracing it kind of whole hog. Maybe that winds up being just as secure or more secure. So it's a question mark. It could go either way, really, depending on a firm and their relationship to this stuff. The last thing here, connectivity legacy elements. Remember, we talked about mainframes. We talked about HPX machines or Solaris or AX. I would never want to not have visibility into those. I can't imagine not being able to see that stuff. So how am I going to reach those legacy elements? How am I going to have visibility of them? How am I going to fetch data from them, especially if my monitoring tool is in the cloud? That means that it needs to make an inbound request against my firewall through to one of my servers. That's a bit squeamish. If the monitoring platform, at least some element, maybe it's half, is on-prem, it's already close and local. And so there is still that connectivity there, but it's already within the same firewall. It's already within my on-prem environment. It can reach those legacy elements without that questionable connectivity need. So a bit easier, perhaps, to do that visibility of the legacy elements and have that connectivity if it's on-prem. Now, some firms might be completely cloud-native, in which case, maybe this doesn't apply. If it's all new stuff, if it's all cloud servers and microservices, then no worries. So it depends on the environment again. But when we look at the cloud stuff, John, what does that do for us? If you think about hosting the platform, the cloud? Sure. So unless you're running multiple tier four data centers, the cloud is almost always going to be the most reliable option and is going to give you the best of time. Scalability is a big one for monitoring. Large-scale monitoring solutions usually require some serious resources, things like big and fast storage to handle databases that are performing an enormous number of IO operations. And a lot of networking resources to handle sometimes thousands of messages a second. If you need to increase resources, it's a whole lot easier to do it with a few clicks on the cloud rather than a complete overhaul of your on-prem storage arrays. And finally, the cloud makes accessibility anytime, anywhere a much more viable option. You think of managers and leadership. They like to have access to the monitoring systems to either periodically check in or when they need to be running a triage call. Typically, they're not going to be the ones getting into the systems to fix them and requiring them to break out their laptop, boot it up and then connect to a VPN takes up a lot of time that could be spent trying to get to a resolution when they could have just pulled it up on their phone. Right. Okay. And then if we move on to another consideration for monitoring platforms, simple versus complex, right? There's simpler tools out there. There's more complex advanced ones out there. What are the pros and cons of this? If we keep it simple, John, where does that take us? Yeah. So generally, the less complex a product is, the less you can expect to pay for it. Also, you can expect a straightforward product to give you straightforward information. For example, if you're monitoring a server that's eating a lot of memory, you can expect your alerts to be something like your RAM usage over 95%. You then log on to the server, find the problem and you fix it. Installations, administration, maintenance, configuration are all going to be easier with a less complex solution. On the downside, those straightforward alerts aren't going to tell you a whole lot about root cause. And if they're not configured well, can create a whole lot of unnecessary noise. And that if your solution didn't have a hierarchy and a VMware cluster goes down, now you have not only alerts for that cluster being down, but your inbox or text messages are full of hundreds more alerts for every single check on every virtual machine that was running on that cluster. Right. We all know that the alert floods haven't been haunted by those once or twice. Definitely. Okay. And the complex side of this is definitely the opposite in a way. We're looking for better insights. We're looking for less noise, kind of more compound alerts and event correlation. It's going to take a lot of different bits of data and bring it together either by machine learning or AI or some sort of tool, pattern recognition, whatever it might be, and try to give us a more complex, compound, but insightful alert, hopefully. And so that's that AI ops buzzword. This is very, very exciting. Everyone's kind of jumping on this all the time, but there is a headache to this. There is, that's a more involved tool. We got to feed it more data. It probably wants to be hooked into our change management. We probably need a really good system inventory and what servers are being upgraded when and looping that in. It needs to be fed a lot more to be able to do that. We have a more, it's machine learning system or algorithm at the core of it. That's a bigger thing to run, probably more hardware that we need to feed this thing. So a lot that we have to fuel this for it to do that and hopefully give us those better insights, which can be quite rewarding, not for a second saying they can't, but there's just a lot that goes into actually giving this what it needs for it to work. Ultimately, all of this is trying to cut down MTTR, reducing that meantime to resolution, getting things identified, discovered, fixed quicker. I always like to point out that it's meantime to resolution. So it's not just mean time to detection or meantime to identification or triage or whatever the metric people want to use, but actually closing the loop and having the staff member fix it, being able to take some action and resolve the problem. And hopefully one other layer of complex, not just AI ops and event correlation would be that the platform lets us take actions too. It lets us right click and run a stored procedure to free up some space or right click and relaunch that process or whatever it might be to resolve the underlying problem. And hopefully the platform, the next layer of that would be if the platform could automatically take those actions. And maybe this is a partnership of the monitoring tool and some CI CD stuff or some puppet chefs, some other deployment stuff. Or maybe it's right in the platform itself that the rules engine can say, hey, I see this process is down, I'm going to automatically try to restart it before I bother anyone at all. All right, I've tried twice, I can't get it back up, now I'll go alert someone and they can tell me what to do next. So definitely interactivity as well, and some other elements of that operations mindset to really make sure that this stuff is working. Both the AI ops and all that event correlation, better insights, niceness, but there's other things that we can do that are complex that could also be really rewarding. The last one here is build versus buy. And this one, nearly every firm talks about this, has a discussion about this. I see it all the time. People get excited. You want to have really good developer staff who when they hear about something, they're like, oh, I can build that. And there's that self-determination, there's that mojo that confidence and enthusiasm and energy of we can build this thing, which is great. It sounds super rewarding, but is it actually going to happen? Is it actually going to happen? Will it be completed? When will it be completed? How complete will it be? We actually get done everything we thought we were going to get done. All of those questions, can we be honest with ourselves about how well this will really work out if we take off on a charge and go try to put something together? And can we be honest with ourselves and really accurately capture all of the costs of this? Both the staff time and the money that goes into that, the costs of we have to wait for it to be built. So if we're trying to implement a monitoring solution, not only is there the install time and configuration time and implementation time, but now we've added a whole set of time just for development time that we've got to wait for things to be done before we can use them. And that might be in a staged rollout. Maybe some things are done ready before others. But still, there's a lot of hidden costs that can be a trap here. We can tailor it to ourselves. It can be super bespoke. We can make it exactly the way we want it. So that's a reward. That's kind of nice. But that implies maintenance headaches. That implies when that developer moves on eight years from now, who knows why this was built that way at that time? Who knows how to run this thing? The more bespoke we are, the more we need to keep institutional knowledge, keep that legacy knowledge and be able to manage it ourselves. And ultimately, there's no support there. It's all internal. That's kind of another hidden cost. How are we going to handle support? It might not just be the developer time up front, but the support time and maintenance time through the life cycle of this app and of this initiative. So can be done. Some firms do it very, very well. But there's a lot of pitfalls and traps to really try to think through very carefully and try to be honest with ourselves about before we embark on it. On the buy side, John, it can't be all roses. It can't be all grass is green or what's going on on the buy side. Yeah. So as you mentioned, Gabe, both options have a cost. You can expect a purchase solution to cost significantly more. But on the next side, it's a known hard cost. That's a lot easier to budget for than the guess work expenses of building a solution. Right. Dollars on a page, black and white, very, very conspicuous. Even if it's even if it's services, I mean, it's an add on like consulting services, professional services. We at least know what they are up front. So definitely. Okay. Right. You know, and also as with most companies, monitoring providers are very interested in acquiring new customers. To do this, we can reasonably expect that your paid solution is going to be consistently adding support for new technologies as they become widely adopted. So we can get a good level of future proofing and supports a big one. It's a lot easier to open up a ticket with your vendor than it is to convince the guy who built your solution eight years ago and then quit to help you out at some obnoxious freelance rate just to get you up and going again. Now, you know, the downside is while we do get a prebuilt product with a wide range of features and integrations, we are limited to what that vendor has to offer. It may not provide the coverage in certain areas that we were hoping for. And in just about all cases, we're going to have to make some compromises. Right. Sure. There's a corollary here being pre-built and you talked about the monitoring companies and businesses. They're selling enterprise tools. There's a hope that we know this is ready for scale. It's ready for, you know, the firm-wide enterprise use. It's already been, you know, tested, built and tested and being run on other big firms. Whereas when we build something, maybe we need to do a bit more testing around scaling and making sure that it'll actually work the way we want enterprise-wide and at scale. But nice. All right. So good pros and cons there too. So we're just about at time. We're going to do a bit of a recap, just some closing thoughts. Certainly, if people have questions that come to mind, start to put them into the chat channel now and then we'll try to address those. But before we turn to them, John, do you have any closing thoughts? Where's your head at with all this? Yeah, sure. You know, today we gave you a whole lot of questions and as much as I wish we could have, we really didn't give you any answers. And that's because there just aren't answers that are right for everybody. Gabe and I, we work with organizations every day who all have different needs. Sometimes we're able to meet a customer's need with a simple single on-prem solution. Other times we're forced to use multiple products with complex integrations that span both on-prem and sometimes multiple cloud providers. It all just depends, you know, what your organization's individual needs are. Our intention here is that you're leaving well equipped with the information that you need for the next time that you need to add or overhaul your own monitoring solution. Yeah, absolutely. A bit of a buyer's guide, a bit of a lay of the land. What consideration should we be thinking through? What questions should we be asking ourselves as we go through this? Just briefly and I'll open up the Q&A here. Maybe we have a question. I'll do the recap and then we'll go through all the questions people have. What collection coverage is needed? Right? We've gone through that. We know what's out there, at least in the course terms and broad strokes. How many tools to have? Is it definitely not infinity and definitely not zero? There's some happy medium that's the right blend for your company to have the right number of tools. How to pick tools What are the considerations that go into that? And how do we go through that choosing process? How do we go through that buying process? Do I want to host on-prem versus cloud? Cloud is a big buzzword. Everyone gets very excited about it. It has some great use cases. Certainly short-lived workloads bursting into the cloud scalability, but do we want to have this thing running there around the clock? Maybe, maybe not. So there's some considerations there. Building versus buying, lots of things to think through and try to be careful about. Try to be honest with ourselves and do some soul searching on. And then the complexity. Do we want more complex, less complex? Where do we want complexity? What does it cost us? And what's involved in getting that to work for us? You can certainly reach out to us, everyone. I'll just call us out and then we'll do the Q&A. Reach out to us at the company website. You can reach me. You can reach John. All right. So given this, someone's asking, can your tool ITRS monitor containers? Yeah. So we have container monitoring. That is something that we do. We do that both in our, well, the genius monitoring products is the one that I'm, you know, more expertise in. We have a whole solution around container monitoring and orchestration and how we get stuff off the container platform, exactly like we said, and then do app stuff on top of it. So that's the model there. OP5 monitor, if that's the product that the person's referring to, we're still kind of building that out a bit. You know, we know how to do it, but bringing it into that product, you know, is something on the to do. Are there any hybrid, hybrid, I assume it's hybrid models of DIY and buy, where we can buy something that will get us up and running, but gives us a lot of room to develop and expand. Phenomenal question. I can go with this one, Gabe. We do this, we do this all the time. So where we'll have, you know, a commercial product and, you know, maybe there's, you know, we talked about how there can be gaps, you know, with, you know, an all in one product or things like that. But sometimes there's an open source solution that's out there. And we frequently will build integrations to work with, you know, work with those open source, you know, projects that are out there, or maybe even one that you're already running. That's extremely common to mix, to mix that. And great question. We probably, probably should have put that in there as a hybrid option. Yeah. Well, all of these things can work in concert. We kind of implied that a bit that these are mix and match. And this is the person's totally getting it, thinking about mix and match. We're a firm that's very open to integration, very open to working with other tools. You know, we do everything well. But if you've got something like Corville that does that on the wire, really good network visibility, and you really like it, pull it in by all means. If you've got some in-house solution that instruments one app really well, and you want those metrics from wherever they are, there's plugins to fetch them from there. There's plugins to get them into the platform. So totally, this is a very, very valid way of kind of doing a hybrid solution, bringing different solutions together. What is I just doing about AIOps? So some of that interactivity piece I was talking about, the automation of taking action, we've had that in for quite a while. And that's, you know, I think just a subset or a limited part of the AIOps discussion at large. Another thing that we've had to do is kind of take our data model in-house. Historically, we've been letting, you know, people run it in tabular, like MySQL databases or Oracle databases. So we're building that into our data, our cluster data store that we own and run, getting the schema, getting the model down so we can work off of it. And the first thing that that allows us to do, keep lots of history, and then use it to project forward, start to do kind of smart rules that look on what the history of the metric was to kind of determine normal. That's the first, you know, first, first pass at it. There's going to be more things in that vein to come. But it was really just that we need to own the data model for us to be able to start to do smart things with it. How do you integrate with other vendor frameworks, products in case one wants to migrate? Yeah, that's a good question. And it really varies based on what the vendor product is. You know, different things are easier to migrate from and to and whatnot. We're pretty darn open to integrations. We're pretty darn open to the number of places we can collect data from. So, you know, very curious what that vendor tool is that the question is around. A lot of firms are coming off of something, right? And so having an ability to make that transition, have an initiative, have a project and smoothly move from A to B and still have coverage. It's pretty important. Sometimes you take it in a tiered approach, just get the basics in, then do some more advanced stuff, then switch this over, et cetera, et cetera. So you kind of build up a project, you know, roadmap for that. Is there an app store for plugins? It gave, so for this one, I can speak at least to one part of what we do. So our OP5 monitor product, as we develop it, we are very careful to ensure that it is 100% compatible with Nagios plugins, which is an open source project. And for that, I mean, there's an exchange for plugins there. Sometimes their plugins, Dell, for example, has a plugin that they write and they even support on their own. So there's plugins available. I mean, you search for Nagios plugins on GitHub, you get a ton of them, and those can just be dropped right into, right into our OP5 monitor product. Gabe, can you maybe give some information, maybe around some of our other products and how we handle plugins? Yeah. I mean, so look, there's a lot of plugins. I think it's like 200 plugins or something available out of the box. I'm just bringing the question up back here. So that's just, that's our app store in some sense. Those are all the plugins we list and make available. They're compiled into the agents. You've got access to them. You can turn them on at any time, just in your monitoring. Then we also offer supported integrations. So that's kind of like an app store where we're listing things that we've used those off the show, you know, JMX or, you know, some, the REST API querier to do an integration with MongoDB or whatever it might be, right, Nginx. And we post those publicly, supported, formal, done and dusted integrations. That's kind of an app store in a way. And then the last category of stuff is like, we've done consulting work. We have some solution we've done. It's not formally released and kind of productionized, but it still is darn helpful, right? And we can give that out to clients when it's pertinent and appropriate. So a couple different layers of where we have, you know, quote unquote plugins, where we have integrations, but definitely a lot of stuff is available just right out of the gate on our website or in the agents themselves or in the platform itself. What are your thoughts on auto discovery and spider diagrams? I trust Gino seems to lack it yet. This is something I, you know, I vocalize. Definitely, I, whoever this is, probably someone I know, maybe even corroborate, you know, and of the same mind. We're looking at it, you know, we do take it seriously. It hasn't been something we've done historically. And it is a place where we would say, you know, if you've got a tool that you really like for that, let's do both. Let's do our thing where we work really well and their thing where they work really well, especially like network scanning discovery and then diagrams, which is what that question, it sounded like was around. So I hope we add more of that in, but, you know, at the moment, that would be kind of the road forward with it. How does it provide countermeasures during live production faults? I do not know exactly what this person means. Maybe they can write it again with a bit more information. I don't know if they mean like hot standby of the monitoring platforms, that the monitoring platform is resilient to production faults, or if they mean the repair actions, the platform can run when there's an issue. So if something breaks and you've let us, you've configured it to the software knows to do it, it will automatically try to do some fixes first on its own before it even bothers you, before it even alerts or anything like that. Yeah, repair actions, that's exactly what they are. And we've got like three people jumping in on the same idea there, repair actions, right? And they're open-ended and configurable. It does take a little bit of input, right? The thing, the system is not going to know what to do if you don't tell it what to do. And not everybody wants to even enable that. There's authentication there, there's permissioning there, it's sensitive, right? To say, okay, the monitoring platform is going to be stopping and starting processes. That's a fairly privileged interaction, you know, action. So it is something where, you know, you configure it, you turn it on, you use it where you feel comfortable. Maybe a lot of the time you stay with the human and the loop model and have a human make that decision. But definitely repair actions, it's one of the, one of the things the product I think does pretty darn well by way of ease and speed of the support staff to be able to fix things and cutting down that MTTR versus just meantime to discovery or detection. Some concern from users who use old operating systems and running active console in their local machine, they have to restart a couple times a day. This sounds like a very specific question from an existing user. Is there a plan to have a web URL which have all the functionalities of AC like AppDynamics? Sure. And that's a good, it's a fair question, right? So the thick client will probably always be around. There'll be new generations of it. We're going to overhaul it. That's something we're already working on to make it, it needs to be overhauled and redone. But there's always going to be the desire for the power users to have a thick client where they can completely customize it, configure it, et cetera. We are adding in a web UI that's being done off of the back of that cluster data store that I talked about. In some sense, we needed to have a place that we were storing the data that we could do a web UI off of. So there is a web UI happening. It probably won't be exactly parody with the console. You might not have interaction, for example. But from a read-only perspective, from being able to investigate, see, chart, dashboard, et cetera, that's the direction that that's going. And most of the other tools that have web UIs, they tend to be read-only. So that's kind of in parody. And then the thick client probably would be the place where you'd have that power user stuff, really, really custom views, and then the interactivity, the ability to take action, et cetera. I realize that's a mouthful. All of those people, please, by all means, reach out to us. Reach out to your reps. If you're an existing customer, or if you're already talking to somebody at the company, you can reach out to me. I'll get you connected to the right people. We can progress those conversations further. I realize I'm answering stuff super, super quick just because we're pretty much at time, actually. So thanks for all the questions. I hope this was helpful. Definitely kind of a buyer's guide and overview. A lot of considerations here. Hybrid estates are their own animal. They are a beast. And it can be tricky to do this well, to think through everything and really get all the right stuff into a solution. Appreciate everyone joining. Great questions. Thanks a lot for the folks who chimed in there. Certainly happy to talk about them more moving forward. But from that, I think we'll call it a wrap. Thank you very much.