Make smart workload placement decisions with the right discovery data

Despite constant reminders, system administrators, engineers, developers, and managers consistently forget to document changes. This trait is problematic when making workload placement decisions, especially in a hybrid environment. With incomplete information, you end up making best available data (BAD) decisions. 

So how do you avoid making a BAD decision? There are two possible strategies. The first is to throw the BAD data over the wall to someone else and let them make the BAD decision.

The second option is to marshal an auto-discovery tool and repeatable processes to discover and document the missing data so you can make an informed decision. While this option is clearly more beneficial to the organization, this strategy requires some effort.

Uncover what lies beneath

Understanding how the application interacts with other systems and the dependencies of that application on those other systems is critical to making  workload placement decisions. But, there’s more going on than what you see on the surface. Just like with an iceberg, you see 20 percent of the picture when you look at the application’s performance data, but after looking beneath the surface you find that 80 percent of the performance reflects the dependencies the application has on other systems.

Discovery is the process of chipping away at the iceberg to extract the information you need, but can’t easily see, to make an informed decision. The below list will help you uncover the data you need to make decisions about where to place your target workloads.

Examine your documentation

The first data source to examine is the documentation. You need to dig through the clutter to identify and obtain the information you need to make a decision. Look at the contractual, security, compliance, architectural, and design documents. Validate the service level agreement requirements and how the metrics are measured. Review the application and its place in the IT roadmap and the IT strategic plan. While checking the IT roadmap, don’t forget to check what is coming down the road from security and compliance organizations. You’ll need to plan for adhering to any updates to these requirements.

RELATED CONTENT  | Infographic 
Seven steps to IT discovery /

Use a discovery tool to examine performance and relationship data

While you are digging through documentation and talking with the security, compliance, architectural, and quality teams, use an auto-discovery tool to do an assessment of the current state of the application. You need a tool that maps the communications of the servers running the application with other servers. 

When doing application discovery, we prefer using agentless discovery tools rather than an agent. Agents introduce performance and relationship data that have to be weeded out to get a clear picture of the application, its relationships, and its dependencies.

Examine the application performance data, both from the servers (CPU, memory, I/O traffic, services) and the infrastructure (bandwidth consumption, load balancer utilization, SAN IOPs, ports/protocols, IP addresses). Be sure your assessment/discovery tool can see your network, all the types of computing systems you have (mainframe, mid-range, RISC, X86), and your storage. 

An auto-discovery tool should graphically display all the systems supporting the application, especially any that aren’t in the application documentation. While it’s possible that traffic going to an unknown IP address indicates a security issue, the more common reason is that this communication was set up to fix an issue but never documented. 

When you have the relationship data, compare the data flows to the application architecture and make sure they match. If they don’t match, changes in the application need to be researched, documented, and understood.

A number of the application relationships represent common services, such as authentication, patching, monitoring, and auditing that impact workload placement, only to the extent that you need to ensure they’re in place in the environment. For instance, if you’re migrating to the cloud, you need to provide these services, whether by standing up virtual servers or by purchasing the services from the cloud service provider. 

Another relationship pattern to document is your business continuity system. Backup and disaster recovery have the potential to trigger major unplanned costs when you assess your application primarily on data replication and storage costs. Make sure you also capture the costs of the systems and storage required to meet your RPO (recovery point objective) and RTO (recovery time objective) requirements. 

Identify risk and compliance issues

Discovery data also provides an opportunity to verify that you’re meeting all your compliance auditing requirements. How to handle audit logs, and the costs of doing so, whether in the cloud or on premises, forms part of your cost analysis.

Auditing and backup are part of your operational costs. You need to document staffing and the training staff required to support each of the workload placement options. If you’re placing the workload on premises, whether in your corporate data center or in a colocation facility, you’ll need to capture the associated costs. These can include physical security, building operations and maintenance, floor or rack space rental, and power. Do you require one point of presence or two? Can you use one power provider, or do you need separate providers on independent grids?

Your information gathering will simultaneously identify risks. These can range from discovering that a required software component is running on a 10-year-old SPARC II workstation running Solaris 7 to discovering the default password for your system is “Password.”  As you identify the risks, capture both how likely it is to occur and the impact if it does. Don’t be surprised if you’re asked to provide the cost to fix it and the potential cost impact if the risk becomes a reality.

Use discovery data to drive decision-making

The above discovery data will give you a complete understanding of the application architecture, performance characteristics, disaster recovery plan, security requirements, hardware options, and costs associated with placement options. With this knowledge, you’ll be able to make informed decisions about where to place your application workloads and provide staff with the knowledge they need to effectively manage and support the application.