The intent of this article, is to show how to use different Service Mapping strategies, in order to speed up application services discovery.
The requirement to map the application services, is to explain our CSDM Model to the customer. There, customer will understand, the concepts of application services, business services, business application, and more.
Application services concept
A service instance is a set of interconnected applications and hosts which are configured to offer a service to the organization. Application services can be internal, like an organization email system or customer-facing, like an organization website.
Other important aspect must be considered when speed up application services creation, in large scale are:
- Performance
- Process
We will address these topics in another article.
The application services in these cases were all on-premise.
Introduction
When implementing a top-down discovery strategy for application services, the goal is simple: create service maps quickly and accurately. However, as anyone who's worked in this field knows, it’s not as straightforward as it seems. While you technically only need a service name and a URL to get started, several factors behind the scenes can either speed up or slow down the process.
In this article, I’ll share some field-tested strategies to streamline the application service discovery process, based on my experience in the industry.
Below, the link to some of Service Mapping discovery strategies:
Some factors
The Challenge: No "Auto-Magic" Discovery
At first glance, it seems like top-down discovery is simple. You identify the service name and get the associated URL—and that's it. But in reality, this process requires deeper consideration. It's about ensuring you have the right tools, knowledge, and collaboration to move efficiently through the discovery process. Here are some factors that can impact how quickly you can create accurate service maps.
Some factors that contributes to decide best strategy and speed up mapping services:
Factor #1: Understanding Service Name Conventions
Factor #2: Network and Infrastructure Complexity
Factor #3: Collaboration Between Teams
Factor #4: Continuous Validation and Feedback
At the first part of this articles, let’s focus on “Understanding Service Name Conventions”.
Factor #1: Understanding Service Name Conventions
One of the most common hurdles in the discovery process is understanding how application service names are structured. This can be particularly tricky when customers have inconsistent or unfamiliar naming conventions.
The Issue:
Sometimes, customers don't recognize the names of services as they are listed on load balancers or processes. For example, an app’s URL might be labeled under a generic term or a name that’s not immediately recognizable as the actual service.
How to Speed It Up:
- Clarify Naming Conventions: Work with customers to establish clear and consistent service naming conventions across environments. Without a standard, mapping services can become time-consuming and error-prone.
- Cross-Reference with Existing Data: Look for existing sources like load balancers, monitoring tools, or network configurations that can provide a clearer understanding of the naming patterns.
Herein below, some experiences from the field:
The service naming dictionary can be a spreadsheet, integration with a legacy solution (Ex: Product Portfolio, Application Monitoring Solution, Load Balancer, etc…).
We also, can take advantage of service graph connectors (Integration Hub), to get this data into CMDB.
Example 1: Aligning Load Balancer Names with Application Services
- Scenario: A customer has a load balancer entry named app-prod-lb01, but users refer to the service as "OrderProcessing". Also, customer does not have where to get all Application services URLs.
- Solution: Cross-reference URLs load balance, adding http endpoints in CMDB records, and define user-defined service names. Implement a service naming, that maps technical names, customer understands.
- How to connect the dots (URLs and Service Names)?
- In this case, the idea was to get Application URLs and environment, from Load Balancers, and map the Application Service from URL, ie, the dictionary was based on App URL.
- Example: (Order Processing – URL- https://orderprocessing.com.br )-Application Name: orderprocessing_prd.
Details on logical architecture is as follow below:
Figure 1 – Obtain URLs from LB, to define correct name convention
Example 2: Using a Portfolio Naming Convention
- Scenario: Customer mapped critical services, with main URLs, based on OOTB patterns. Issue, however, they was not be able to speed up the application services, because they did not have all URLs and service names.
- Solution: Use Portfolio naming convention, from an spreadsheet, to get all application services names and URLs, based on a portfolio naming convention, customer had.
- How to connect the dots (URLs and Service Names)?
- In this case, the idea was to get URLs, environment and correct service names, using csv file, to load the correct application service names, and URLs. Using excel functions, customer can reach correct results.
- Example: (Order Processing – URL- https://Mobrechargep.com.br )-Application Name: Mobrecharge_prd.
The strategy used was “Map multiple application services from a CSV file using classic Service Mapping”.
Although this method is manual, it can speed up the application service names.
Example 3: Accelerating Discovery via API Calls
- Scenario: Customer mapped some application services, with their URLs, but correct naming convention was placed in Kubernetes environment.
- Solution: Cross-reference URLs from K8S, adding http endpoints in CMDB records, and define user-defined service names. Implement a service naming, that maps technical names, customer understands.
- How to connect the dots (URLs and Service Names)?
- In this case, the idea was to get URLs, and correct service names, using csv file, to load the correct application service names, and URLs.
- Example: (Order Processing – URL- https://<IP:Port>/ https://cashback-points )-Application Name: cashback-points.
Details on logical architecture is as follow below:
Figure 2 – Obtain URLs from K8S, to define correct name convention
