CSDM classification of a Load Balancer itself?

[ahbrook]

Hey everyone! I'm continuing my efforts of trying to classify our systems, applications, and so on according to the CSDM. I'm looking through what was originally loaded into ServiceNow as "services" (cmdb_ci_service) and seeing if they would fit better in other categories. 

Our environment has 2 A10 Thunder Application Delivery Controller Environments. One is for production, and one is for test. I don't know the exact makeup of this hardware/software.  In the scope of ITSM, our infrastructure folks often get tickets asking to set up systems to use the load balancers, and of course sometimes they have incidents related to them. 

What would be the best way to represent them directly? I know they fall under Infrastructure/Networking/Load Balancing in terms of services and service offerings. But I am less sure if they'd get their own Business Application or Application Service Instance - or if this would fit into one of the other new CSDMv5 service instances.

To further complicate things, we have other load balancers in our records. These include the NetScaler devices that the A10s replaced and the cloud-based load balancers we use up in our AWS environments. I don't know if these would lump together in some way or not. 

[MBannis]

My first question would be whether the A10s, NetScalers, and AWS load balancers already exist in your CMDB as discovered CIs. If not, I'd start there.

From a CSDM perspective, I would generally not model a load balancer as a Business Application. A load balancer is typically infrastructure that provides a networking capability rather than a business-facing application.

If your organization provides Load Balancing as a shared capability, I'd typically represent that through a Technical Service / Technical Service Offering, with the A10, NetScaler, and AWS ELB/NLB resources related as the supporting infrastructure CIs.

The applications that consume the load balancer would then be represented as Application Services and/or Business Applications, with relationships showing their dependency on the load-balancing infrastructure. If you're using Service Mapping, those dependencies will often be discovered automatically.

Ultimately there can be multiple valid modeling approaches in CSDM, but my starting point would be:

• Load balancers = Infrastructure CIs
• Load Balancing = Technical Service / Technical Service Offering
• Business applications consuming the load balancers = Business Applications / Application Services

That keeps the infrastructure capability separate from the applications that depend on it.

[ahbrook]

This matches up with my instincts, and why I was hesitant to make a decision without checking what other people thought.

Unfortunately, we only have ITSM and IntegrationHub Pro - we do not have ITOM or any flavor of tool that could do service mapping or discovery, and these particular components aren't managed in SCCM and can't use the Service Graph Connector. 

Now, if there was a control program that managed the load balancers as a central device, would that be a business application? I ask more for other things that straddle the edge, like vSphere ESX or Ansible Automation Platform.

Also: On page 39 of the CSDM v5 white paper, it calls out "Connection Service Instances" as a new type of Service Instance, but also specifies that those are only conceptual and are not implemented in ServiceNow as of yet. My instinct says the load balancers would support that kind of instance (or a network service instance), but we aren't in a world where that is available just yet outside of automated tools. I was hoping to align with whatever that future state might look like. 

[MBannis]

That's a great question, and personally I'd separate the platform being managed from the tool used to manage it.

For example:

• An A10, F5, NetScaler, AWS ELB, etc. is infrastructure and would generally remain a CI supporting a Technical Service.
• If there is a centralized management platform used to administer those devices, then I could absolutely see that management platform being modeled as a Business Application (assuming it meets your organization's definition of an application and is managed through the application lifecycle).

I tend to use the same thought process for things like vSphere and Ansible:

• VMware vCenter is typically a Business Application because it is a software product with owners, support teams, lifecycle management, upgrades, licensing, etc.
• The ESXi hosts themselves are infrastructure CIs.
• Ansible Automation Platform could similarly be a Business Application, while the servers, execution nodes, managed endpoints, and underlying infrastructure remain CIs supporting various technical services.

Regarding Connection Service Instances in CSDM v5, I had a similar reaction when reading that section. Conceptually, load balancing, network connectivity, DNS, messaging, and similar shared capabilities feel like strong candidates for that future model. However, because the construct is not yet implemented in the platform, I'd personally avoid creating custom structures in anticipation of it.

Instead, I'd model based on today's supported tables and patterns:

• Load Balancers = Infrastructure CIs
• Load Balancing = Technical Service / Technical Service Offering
• Applications consuming the load balancer = Application Services and Business Applications

If ServiceNow later introduces a fully implemented Connection Service Instance model, I suspect that approach would be much easier to migrate toward than if you started creating custom representations today.

One rule of thumb I often use is:

"Could I reasonably imagine a product owner, roadmap, lifecycle, licensing costs, upgrade schedule, and application support team for this thing?"

If the answer is yes (vCenter, Ansible, ServiceNow, SCCM, etc.), it's usually a strong candidate for a Business Application.

If the answer is "this is a shared infrastructure component that provides a capability to other systems" (load balancers, switches, firewalls, DNS servers, ESXi hosts, etc.), I typically keep it in the infrastructure and technical service layers.