Rich Martin • 00:04
I’m super excited because, once again, I’m joined by our expert, Ankit Bansali, who is here to guide us through what this looks like and how this all fits together and works. Ankit, take a moment to introduce yourself.
Ankit Bhansali • 00:16
Thank you, Rich. My name is Ankit Bansali. I’m a Principal Solution Architect at iTentio and I talk to a lot of customers and prospects, and a lot of thought leaders around this space. Looking forward to having this conversation with you.
Rich Martin • 00:32
Appreciate that, Ankit. My name is Rich Martin. I direct technical marketing here, so I’m just your guide for this journey. I’m super excited because we’re really introducing really novel idea, I think. Maybe very unique to the industry, but it’s something that just fits so perfectly into our platform. So before we get started, we talked about last week, or in our previous episode on this series, is around how you can do compliance for applications and servers, right? And that became some unique, that poses some unique challenges. And so I definitely want anybody to go back and get more details from that particular discussion that Ankit and I had.
Rich Martin • 01:12
However, in this one, we’re adding more to it. In this case, it’s not just applications and operating systems, but it’s the entire infrastructure stack that supports that. And I think that’s really the unique part of this, Ankit, is you’ve spoken to a lot of customers. Like when we talk about applications, how do we think about what an application sits on top of in order for it to operate, or do we at all? Because a lot of these teams are kind of disparate and separated and siloed to a point, right?
Ankit Bhansali • 01:41
Very true, very true. That’s the most challenging part for organization is how do you have the ability and visibility into multiple stacks and team and how they function and how do you bring that value home that binds all that information together so you have a better source of truth when it comes to deploying applications in general.
Rich Martin • 02:05
Yeah, and so the interesting thing about this, and again, coming from the networking background, my vision on config compliance is really around like that third element in the stack, the network routers and switches. What are the configurations that I need to enable an application? And are those configurations in compliance to some sort of standard that our organization has? But in reality, I am just one piece of a bigger stack here, right? So from the application perspective, for me as a networking engineer, I really may not even have a concept of what that looks like. But in this case, an application is not just one thing, right, it’s probably more than that.
Ankit Bhansali • 02:47
Correct. And application, like you said, from a management perspective and who has been around and done things in different stacks or domains, you know it’s a composition of infrastructure, network services, runtime services, OS services, and each layer has its own set of team and tool that actually do that job. And it’s never been thought as a single interface because we never had a tool that actually gives them that confidence in provisioning something that is that much distributed and that much complicated.
Rich Martin • 03:22
Right. So from an application perspective, I might have multiple servers, right, that are holding different parts of that application that work together. Classic example, the front end web server and the back end, maybe some sort of database server, right? Correct. Configurations for all of that are necessary. And those configurations, just like the configurations for any other part of the stack, are critical not only to the function, but perhaps a security risk if not done correctly.
Ankit Bhansali • 03:52
100%, and then this also comes back to this whole distributed model and federated team model where you have multiple teams and people are already familiar with these nomenclature where there is an app dev team, there’s a net ops team, there’s a security team, there’s a platform team, right? This is with respect to teams on how they do the deployment. And at the same time, there are domain specific teams, which are network, cloud, app, identity, security, compliance, firewall, load balancer, right? So it becomes very cumbersome to have a blueprint on how to deploy an application, even though it’s the most common thing we do, especially with how many teams and distributed events there are that goes into doing that basic thing. And don’t even think about it from a day zero operation of provisioning, right? It’s all of these teams have their own dedicated day two operations, which are again, very much siloed. it’s again a very, there’s a tribal knowledge that people have on how to do things in these domains and teams.
Ankit Bhansali • 04:56
And again, there is a lack of coordination because there is a lack of truth from a deployment perspective because nobody has that ability to capture all those attributes and making it available to other team members from a single interface.
Rich Martin • 05:13
Right, and so what puts us in a unique position when our customers are using our platform and our product is a solution set is that an orchestrated workflow on our platform can touch all of these different infrastructure pieces, not have knowledge about what has been assigned as part of an application, and not only save that, but then as a holistic whole, take all of these things together that comprise the application and the stack that it needs, and ensure that everything’s in compliance, which is this is the unique and very interesting thing that we can start doing for our customers. Then on top of that, because of our platform and the way it works, offering that as a service that the application team can leverage themselves, so that not only requesting the application, which spins up everything under it from all those other teams using their automations, but also at the same time, being able to give them the options of running some compliance reporting and then testing. Anything that normally would probably be a disparate ticket-driven manual set of operations across all these different teams can now be something that can be orchestrated and automated so that that particular application team can utilize that, generate their own reports, ensure compliance from top to bottom. I think that’s super exciting, yeah.
Ankit Bhansali • 06:37
Yeah, and mind you, Rich, there’s a lot of work that goes into this whole process. You got to do plan, provision, configure, deployment, validate, monitor. So we are not undermining the efforts of people who actually deploy it. We are trying to show the value to organizations that all this work that happens during, let’s say, a single provisioning phase from a day zero operation, day one operation, is always left behind in disparate tools. And then when you go back in time and try to do day two operations, it becomes very cumbersome. And that’s why your day two services are not always as fast as you would think, is because of those challenges where people do not have the right information at hand, especially when you have a cross-domain distributed provisioning model.
Rich Martin • 07:25
Yeah, that’s absolutely true. I think that kind of takes us into our next points here. What do those services look like under the hood? So when we talk about all these different infrastructure stacks, to your point, we’re talking about different teams, different silos, different tools, all generating configurations that are all interrelated to this particular application. So when we start to build this solution in Itential, what are some of the points here that are necessary for us to do and some of the services that can now be offered to that application team?
Ankit Bhansali • 07:56
Correct, and there’s a lot of day-two services and even from a day-zero perspective. So depending on who you ask and what are the day-two operations, there are things that goes into this multi-stack layer, right? And I think when it comes to, let’s say, just changing your certification from a load balancer perspective, the ability to do VLAN migration for a customer, for this application in general, and the ability to add more pool members. And out of all of this, because you have all of this information available to you, guess what you can do in addition to this, especially on the security side and making sure from an auditor’s perspective. There is nothing out there that gives you that comprehensive and I was trying to break it down into an OSI layer when we were trying to capture thoughts on this webinar is there is nothing from a innovation standpoint that actually goes out and makes a statement that imagine if you could run compliance on an OSI layer concept, which is layer 1 to 7 where you can now have different kinds of compliance with different kinds of interfaces and technology whether it’s CLI, JSON, API or even something that’s proprietary from a lot of vendors. So you get this capability out of the box by just capturing this distributed data operations at the same time the adjacency brings security and auditing out of the box because you have this information at hand.
Rich Martin • 09:38
So even from the very beginning when you’re provisioning this new application or service you’re capturing all the initial service attributes that across that whole stack. From that point on to what you’re saying is day two and beyond being able to track all those resources in the platform, that’s not a simple thing to do. But then layer on on top of that, because we have the ability to identify all these different parts across the different infrastructure stacks. Now we can build config compliance and audit and build reports across all of that. So not only can every team identify the resources that are used for a particular application and ensure their compliance. More importantly, the application owner themselves are now given the keys to be able to do that themselves through our platform and how we interoperate both from orchestrated workflows and how our config manager application that supports CLI, API, servers, anything that you have in that stack can now be modeled and golden configurations built and tied back into these workflows in order to accomplish all of that.
Ankit Bhansali • 10:45
Yeah, very true, and I think that’s a very powerful capability providing that visibility, so you do not have to buy a lot of tool set to cover those grounds, and you’re investing not just in the process with the people you already have and the tools you already have, you’re trying to build a very comprehensive way as a single interface to help you monitor, run compliance, especially when things need to be audited from a single source, which is very unique, since we already integrate with a lot of tools stack around you.
Rich Martin • 11:19
Yeah, absolutely, well, enough talking about it, let’s see how this would actually operate in our platform, show us some examples of how this looks, and then give us some insight into some of the things that our customers would be thinking about as they deploy something like this. Absolutely. So what does it look like from this architecture standpoint? Absolutely.
Ankit Bhansali • 11:39
Yeah, and I mean, you’ve done this a lot of times, right? When you do an application, you go through a lot of process and steps. It has to be multi-domain, multi-scale, and each process has its own set of limitations and its ability to do compliance to make sure your application is deployed in a much more healthy way. You can do audit analysis so to maintain the health of the application. So you pointed out initially, especially with the stack. I think I can go ahead and share my screen and show you. the ability where you can see on how that model is going to look like.
Ankit Bhansali • 12:18
And then we can share our thoughts and tell me if this is comprehensive enough from a standard in terms of just doing the application deployment.
Rich Martin • 12:26
So before you go there, let’s just kind of recap what’s going on here, too. From our platform, we have various applications, in this case, Lifecycle Manager, Configuration Manager, and a set of workflows that can orchestrate all of these actions on an application or service. The resource model is kind of like the notepad that describes all of the different resources we want to capture. So when an application gets spun up, what are the different pieces of all those different infrastructure stacks from security, load balancer, servers, those configurations that need to be not only kept up with, but ultimately building the actions around it that help to keep those in compliance. And then eventually the kind of reporting that shows all of these things operating, not only operating together, identifying them, but identifying them as compliant or even non-compliant, if that’s the case.
Ankit Bhansali • 13:16
Correct. And we split provisioning in the first bucket where it goes through multi-stages, right? You’re going to provision and then you’re going to layer in data operations with whatever these teams have outlined as best practices. So that’s the capability and then bringing everything home in terms of capturing all the data, all the attributes that went through provisioning of this multi-layer application deployment process is what then housed in the Lifecycle Manager as an instance data. And that data is then used to make additional data operations and the decisions that go with those data operations.
Rich Martin • 13:57
Fantastic. Well, go ahead and take it away, Ankit, and show us what this looks like inside the platform. Perfect. Give us the grand tour.
Ankit Bhansali • 14:04
Absolutely. Okay. So Rich, this is what it looks like when we were talking to a lot of customers and how we were running compliance and provisioning and data operations on these disparate stacks, right? We tried to couple them together in a single stack because now what we thought is the customers are wanting a better experience and the ability to manage that information in a single place. So even though we integrate with multiple sources of truth, having that orchestrated services as a source based on the services and products you’re gonna offer is more valuable to organization from a management standpoint, because this gives you that additional visibility into the deployment process and your services in general. So what you’re looking right now at is a resource model, we like to call it, in terms of what are my attributes that are going to be captured during application deployment. And when you want to deploy an application, there’s a lot of layers of stacks that are involved, which is there’s infrastructure, which is part of compute, has its own networking.
Ankit Bhansali • 15:11
So you can see one portion here is calling about that infrastructure. What are the devices this application is directly related to? Usually this would be a separate activity. Yes, it can still be a separate activity, but capturing all of that data in a single source helps you maintain what has really happened during that provisioning and deployment, and all those disparate adjacent technologies that are connected to your application. So when things go out in terms of if there is an outage, you can actually see what are the components that were part of this application deployment.
Rich Martin • 15:48
Right, that’s interesting. Yeah, no, it’s interesting too. Because now you’re hitting on the networking piece, which is, you know, so if I’m the network engineer for this, for this organization, that would be the piece that I’m interested in. But now, now that I’m looking at the resource model more holistically, Some of the things that I might be configuring just in the network layer are also relevant for some of the other teams that I might not work with or even have visibility to. IP addresses, VLANs, things like that, those are necessary for things like some of the network services that are coming up, like DNS or load balancing or firewall. Now even in one place, each of us has our data, but then even I can see visually where we’re all coordinated together, or even if we’re not, correct?
Ankit Bhansali • 16:37
Correct, and this is the breakdown of these individual stacks. Like you said, it’s separate teams managing separate infrastructure on how they want to do. But at the end of the day, why do we have so much configuration in all of our infrastructure? It is to make sure that we offer a service, which is an application in this case, and that service remains healthy and all the adjacent technologies which are needed or the application service depends on, we make sure we want to capture those attributes. Load balancer is included here. We are also capturing not just the layer 7 of the application stack, but we are going from all the networking we could do from our layer 2, layer 3 concepts, and in addition to anything that’s specific to the compute infrastructure, what are the services that are running on compute, and what is this application comprised of? So now you can benefit by capturing all this information.
Ankit Bhansali • 17:36
You can benefit, when I say you, it’s the organization can benefit. indirectly in so many different ways because their teams can now get that visibility into how this application is actually running from an end-to-end perspective, and what are the things they can offer as an add-on services to other folks. Then this could be a self-service process where they don’t have to spend a lot of time rehashing the whole provisioning piece when they’re trying to modify. Because this will give you complete impact on what changes on this application service under all the disparate technologies and cross-domain systems that are involved. Okay. Yeah, so this is the resource model, gives you that breakdown. Again, it’s very flexible to build your own resource model.
Ankit Bhansali • 18:26
This is something which we came up with when we were trying to understand how a application is deployed in the stack. But again, it can be super fine-tuned to your organization’s need from a service perspective. Then we talk about how do we provision something, and how do we benefit out of having this information inside of the Itential Lifecycle Manager application. Rich, I went ahead and I provisioned a customer portal application. I already got a request. Let’s assume all my team did all the job they were supposed to do in disparate stages. There’s one thing I forgot to mention is, it is not a parallel process where you can start doing things.
Ankit Bhansali • 19:13
Not every technology can be deployed in parallel. But there are times you have to also go through a stage concept where you need to make sure there is reservation on compute before you can deploy something, and then on top of that, you can add more services. There’s a dependency on services too, which can be laid out in multi-stage process. If you look at this customer portal, and I’ll go through the history of things that happen on this provisioning part. If I go into. this thing where I got the request. When I got the request, we have identified what are the attributes that were part of this process during provisioning.
Ankit Bhansali • 19:54
Most of the time or almost all the time, provisioning is always going to be a one-time process, which is I want to provision a service, boom. That service can be decomposed on multiple smaller services, but that is still a one-time process. By capturing all this information, if you look, I have identified what are the things that were part of provisioning this application deployment from a compute standpoint, firewall standpoint, load balancer standpoint, and additional networking services that are adjacent to this application, which are very critical. All captured here with respect to the dataset. This is just by itself so powerful by capturing all this, because now you get that complete visibility in a single place without having to jump into multiple sources of record.
Rich Martin • 20:46
Yeah, and what’s interesting here, too, is like, this is what Itential has been doing for a long time. We want to leverage the different tools that these different teams are using across their infrastructure domains to, you know, in this case, to provision something net new. But what’s unique here is not only that, that’s quite great on its own. It stands alone on its own to be able to orchestrate that together. But now to tie all of these things, all of these elements together and say, this is OnKit’s customer portal application, and here’s all the pieces that go to it. Correct, correct.
Ankit Bhansali • 21:19
And going further, right, to your point, like, this is great from a understanding of all the pieces that went into application deployment. But like, how do I really take advantage of this information from a day to activity? So I’ll go back into customer portal, and I’ll show you actions. And this is where when we are talking to folks, right? They always have these day to actions that are available. But they’re always disparate and on demand, and they never have the ability to have all the information that is necessary to know in terms of before making a change. So these are the actions which people do.
Ankit Bhansali • 21:59
And you can talk about any other actions which you think people will go through is, what are the things they do on an app after the application is deployed, there’s going to be times where you got to change the firewall rule, there’s going to be time where you need to increase the pool members, because guess what, Super Bowl is coming. So there’s going to be a lot of traffic on that portal for for tickets or, or customer requests. What if you want to think about giving self service to, to all these disparate domain teams as a compliance service that just does compliance for infra network services, load balancer services, firewall. So it can be multiplied that many times that many technologies, certificate rotation, it’s a very common thing people do all the time on application. What if we made a self service, along with that, VLAN assignment on the networking side, how many times you have heard that there’s been an outage, and it’s somewhere in the network. But here we kind of get to see on what what layer of that outage is and what might have changed because we have recorded during the provisioning what are the attributes that went into that process in the first place.
Ankit Bhansali • 23:08
So if somebody is gonna do a reassignment, they can exactly know that somebody changed a VLAN from 100 to 200 or vice versa. Right. Or they wanna do some migration because that’s what the organization is doing on the networking side. They wanna migrate that app to a new VLAN. If you offered us a self-service on this customer portal changes, this becomes a much easier. It’s very limited from an impact concept. And it’s very awesome from a ability to have that insight on what’s going on under this main service, which is comprised of multi-domain, multi-services.
Rich Martin • 23:48
Yeah, and I think it’s interesting to mention here as well is that each one of these infrastructure teams has the ability to build these workflows that provide these types of services to that end user. in this case, the application owner, right? And so the part about this that continues to give you the control is the fact that these are processes that each one of those teams is already following now codified in a workflow using the tool sets and the engineering knowledge that is required to do this safely. And on top of that, enabling a compliance on top of that just in case, right? Because things change over time to your point about life cycle management. You start here, but over time things change for a variety of reasons, some good, some bad, some known, some unknown.
Rich Martin • 24:41
So with compliance, like any type of security, it’s a, you know, you can do an audit, but that’s a once in that particular moment reflection of what it looks like. If you’re relying on a compliance audit across any type of infrastructure, it doesn’t even matter what it is, operating system, application, server, you know, network, that they’re all in the same, they all have the same problem in the sense that what does it look like a year later? It’s not going to be the same configuration, most likely. There’s going to be some changes. And so how do we know that you’re still in compliance? Well, the application owner is probably the most response, that needs to be the most responsive to that. Correct.
Rich Martin • 25:20
Give them the tools just like you would give them the tools in a self-service portal. Give them the tools, not only to make the modifications to their application, because they’re the ones that know why. I love that example about, we need to increase the pool. We’re spinning things up. We need to put things in the pool. It’s, you know, these are retail focused applications. And this is, you know, the time of the year, the end of the year where it’s all going to ramp up if things are going great for us.
Rich Martin • 25:48
And so those are some of the changes that occur all the time. being able to track it, being able to identify it, being able to associate it together, being able to run compliance, and then putting those tools in the hands of that application team to go, hey, we can run compliance on every one of our applications. We get the reports. I mean, I’m just going to be selfish here. From a network engineering standpoint, the last thing I want to do is track down all this information just to go, yeah, that looks good. Your stuff is under compliance. I’m trying to look after everything else in the network.
Rich Martin • 26:19
If I can give them the tools that’s responsible for generating those reports. That’s fantastic from my perspective. And that’s exactly what we’re capable of doing here for every one of our customers.
Ankit Bhansali • 26:30
Right. And Rich, you hit on two things which is important. Like we are tracking all the interactions that have happened, ever happened on this application service. So you exactly know how the evolution or the life cycle of this application service has happened. And you can see what actions people have taken over a period of time. We are recording that. So you exactly know when was the last time this service was touched, what was changed and who changed it.
Ankit Bhansali • 27:01
And don’t forget the fact that there’s gonna be a always out of band changes on each of those layers. Right. Which is again, very hard to track. And it’s our known thing inside of infrastructure provisioning process that teams that make configuration changes, they always do not rely on a process. They make out of band changes to fulfill their current need based on the tickets that are assigned to them.
Rich Martin • 27:27
Let me boil it down to a real situation. Right. And I think you can apply this to every one of those technology teams, those domain teams. something’s broken, it’s three in the morning, it needs to get going, or even worse, it’s in the middle of the day and our customers are complaining and we’re all in there scrambling to try to get this thing fixed. The last thing, I’ll speak from a network engineer, if I know how to fix the problem, the last thing in my mind is opening up tickets, documenting it, even unfortunately, letting the rest of my team members know, right, what’s going on, I’m focused on fixing it. And as soon as I’m done fixing it, I probably have to have five or six more phone calls with other managers to explain what happened, why it happened, what I did. And at that point, that’s just one silo.
Rich Martin • 28:12
Imagine all those silos operating like that, making those changes, getting things up because they have to be up. And then that’s how things get out of skew. regardless of how good your processes are or how much automation you have. And so you need that over-the-top compliance aspect across all of it.
Ankit Bhansali • 28:31
Correct. So tracking the ability to see in terms of what changes happen on that service and on-demand compliance for out-of-band changes, that is dedicated for this service only. Because when this service goes down, you wanna make sure you have all the tools that help you troubleshoot faster. And this is the scenario where we will go through this flow, right? I did the application deployment. I can see, okay, what was the rule that was added to this thing? Maybe that caused the outage, right?
Ankit Bhansali • 28:58
Okay, this rule, I can see that we are tracking what changed if, especially with respect to this service, which is the customer portal application deployment, in this case, we can see a rule was added. If we go back, we can also see somebody also scaled up pool members. So you can see and track the history of changes on this application deployment. And somebody also ran a on-demand infrastructure compliance. And it looks like the score went up. So we are doing great from a auditing standpoint, because guess what? If you wanna ship a report, you can pretty much ship it right now to your auditor, saying my application, which is customer portal, is 100% in compliance, SOC 2 compliant, based on all the attributes, or NIST compliant, depending on how you wanna position the compliance piece.
Ankit Bhansali • 29:50
And we can also see what else happened on this service. Somebody did a VLAN reassignment. They changed from 100 to 200 on a VLAN site. So this gives you that additional flexibility to make changes much more securely and record every change that goes on this application service, especially from a day to activities. And I think from troubleshooting activities, this becomes a de facto way of tracking changes because to your point, if somebody goes out and make changes, they can also then run the compliance on that domain and stack and be assured that this does not impact the service. Imagine if we run compliance on all the layers, we are gonna hit a problem when things are reported as an outage because we will identify what has actually changed in which domain and we can reroute the ticket to the right team to go make a fix. Right.
Ankit Bhansali • 30:46
So there’s a lot of things that goes around from a banner. Yeah, yeah.
Rich Martin • 30:50
So that’s another good piece of this is the response. to remediate that problem, even if it requires manual remediation, you have all of the information accessible immediately. Imagine having to go through different logs, different systems, different tickets to try to find out what exactly happened in a certain window of time that may or may not have caused this issue. And of course, let’s get rid of the finger pointing because that tends to happen as well. Everybody points at the network. Well, it’s not the network, it was DNS, right? No, it wasn’t DNS, we didn’t make any changes.
Rich Martin • 31:28
We didn’t do anything. So you can track that. immediately in response to something and the recording of it within here as well. And again, over the top to that, is because changes can be made outside of out-of-band, out of the way this is being done through these workflows, you should also have a regimented scheduled compliance check going across all of this as well in order to ensure that any changes made out of band, we can at the very least identify when and where those changes were made and then track that back to potentially who made out-of-band changes when they should have. And was it justified, right? Was it a 3 a.m. We’ve got to get this thing going.
Rich Martin • 32:19
And now, you know, we’ve solved the mystery, so to speak. Correct. Of why this is.
Ankit Bhansali • 32:26
And it’s not just time-saving for like the organization, 100%, but there’s a better operating model, which gives you self-service. And you can, to your point, we can pinpoint exactly where things might have gone wrong and take a very informative action. So that is what this demo does from a lifecycle management perspective. Rich, is there any other topic you want to visit in this webinar?
Rich Martin • 32:55
Well, can we take a quick look at, just for the sake of the audience that may not be familiar with it, but anything in our config manager as well, to kind of show the fact that we do operate in a way that can do config compliance across this infrastructure stack. Which is also a unique part of our platform.
Ankit Bhansali • 33:13
Correct. And this confidence only comes because we have that capability. So let me go ahead and share my screen that takes you to Configuration Manager. Sure.
Rich Martin • 33:24
And while you’re doing that, I think it’s also kind of cool to understand that, you know, the compliance audit and reporting process, we’ve talked a lot about the changes to the infrastructure that could be, that could make something in and out of compliance. But when you have this standard, right, this template that defines that, that changes over time too, right? Because a lot of these policies that a lot of our customers have to adhere to, they add things all the time, right? They add things, hey, now we need to do this, or now we need to stop running this protocol. It’s been found to be insecure, that kind of thing.
Ankit Bhansali • 33:56
I mean, you know better than me, like change is as good as definition for a network than anything. There’s a constant change and constant new policies that people have to conform to, especially with the technology stack, the deployment, the vendor, the images that are deployed. So it’s always going to be a moving target. But the ability to make sure that you can make a change in an easy place, whether it’s in a template or trying to do some API compliance, is what you get out of the box from the capability side. So this is where you can see that I, let’s say I have a Linux template provided from my team, right? If the compute team had certain new regulations, they can come in here without having to learn anything brand new, and come in here and make changes. So next time when somebody runs compliance for compute for that application service, it pretty much picks up from a template perspective, which is true for a Linux example, which is true for a.
Ankit Bhansali • 35:06
IOSXR, if that was one of your switches as part of your application stack, or if it was Firewall or load balancer. And you can have these dedicated templates, which can be now associated with the application service and can be served on demand as a service from a consumption standpoint. But the engineering team gets full ownership because they don’t have to learn anything new because they know the best thing is just to make modification based on the configuration changes rather than trying to understand a new tool and a new process on how to run compliance with.
Rich Martin • 35:42
Right, right. So we talked about like all these teams being siloed. There’s another team that could be responsible just for updating these standards, right? And to your point, you make the change in one place, it becomes applicable to all those device types. And in the case, what we’re talking about with applications, it ties right back into the underlying infrastructure configuration for a particular application or set of applications, right? So this is where this really becomes meaningful as a kind of config compliance as a team sport, because it really is. It’s all of the infrastructure teams.
Rich Martin • 36:18
you know, making sure that there’s compliance across all of those different devices and services, but at the same time, the application teams, not just looking at the application side, are applications configured correctly, but at the same time, what about all the underlying infrastructure? So this is how we can have all of these teams kind of participating together to ensure at many levels that, you know, compliance is being driven, not just from one place, not just from one infrastructure team across everything, and really focusing on the application owner, because at the end of the day, we all exist to make sure applications and services can operate and run our businesses.
Ankit Bhansali • 37:00
Correct, and compliance isn’t optional anymore, right? With AI, and we read about the security threats and audits that happen, and how they need to happen that frequently, we can do real-time enforcement, right? And something that really matters. The risk of shadow IT, right? This brings visibility and gives complete control without slowing down the team’s capabilities in terms of skills and bringing value into this concept. We’re trying to make sure that the platform thinking is mainstream. Lifecycle models are definitely a way for teams to build this overarching interface that gives them that flexibility to control, observe, and collaborate with multi-teams and multi-toolset, and still provide organizations the value in terms of visibility, in terms of all the services, policies, and deployments, and give them reusable building blocks as infrastructure as product, rather than reinvent this every time, because we see a lot of folks trying to reinvent, because since the application deployment process wasn’t structured the first time around, every time a new application goes out, they start building new ways of doing things, because they did not even have that ability of a structured approach in the first place.
Rich Martin • 38:25
Yeah, those are great points, and thanks for that insight, given that you work with a lot of our customers who are actively trying to solve sometimes just one part of this problem, but now being able to tie it all together in the platform and offering them something new and much more comprehensive and much more useful to, ultimately, the application and service owners. This is something unique, and I think it’s super exciting that we really can’t wait to talk to our customers and prospects about.
Ankit Bhansali • 38:51
Absolutely. Absolutely.
Rich Martin • 38:53
Well, is there anything else you’d like to mention, Ankit, before we close this webinar out?
Ankit Bhansali • 39:00
Just a punchline is this lifecycle gives you the ability to execute the way you like things, provides that add-on visibility in terms of what you’re trying to achieve, brings compliance into picture, which is very critical for the health of the service. Traceability, like we said, tracking things is very important and we capture all those attributes for auditing reasons. And for me, the most important is cross-team alignment with cross-domain tools and vendors, which is the most unique way of how Itential brings everything together in a very seamless way as compared to tools outside of Itential.
Rich Martin • 39:42
Yep. Thanks for that. Those insights, really appreciate that. I want to thank everybody out there for tuning in. Once again, you could reach us here, itential.com, and we are happy to speak to you about this or any of the other use cases, functions, and features that we can solve for you and your organizations. Again, Ankit, thank you very much, sir.
Ankit Bhansali • 40:01
Thank you, Rich, for having me. Appreciate it.
Rich Martin • 40:04
Bye-bye. Bye-bye.
