Skip to content

Discover Concepts

What is Discover

The Discover feature collects system information (CPU, memory, network, scheduled jobs, and so on), overall process information, process details of each running process and its dependencies, and external communication by each process from the host.

CHAI™ application uses an agentless method for the said discovery.

Host

A host is a physical or virtual machine that runs the processes which are to be containerized. The following host operating systems are supported (follow the full support matrix here):

  • Linux
  • Windows

Project

A project is a group of hosts.

  • The hosts run the applications which you can discover
  • You can add a maximum of 50 hosts to a project
  • The hosts can be a mix of Windows and Linux

Note:
In releases prior to 2.x, Project was referred to as Wave. Hosts are VMs and not an ESXi Layer

Discover Phases

The Discover process is divided into 2 phases:

  • Phase 1: Fetches the static information about the host (system information, process information)
  • Phase 2: Fetches the dynamic information about each selected process on the host (dependencies like .so files, config files, log files, network communication to other processes either on the same host or another) by attaching a probe to a running process

Note:
Both phases are supported on Linux. Only Phase 1 is supported for Windows.

Prerequisites

The host requires the prerequisites to be satisfied before starting discovery. This is a mandatory step without which the discover will not start.

Force Discover

Sometimes the discover may get stuck for unknown reasons and the results are not displayed on the UI. The force discover overrides the earlier discover process and triggers a fresh discover.

Non-Invasive Discover

Phase 2 discover is skipped for specific servers like IBM WebSphere, Oracle WebLogic, Apache Tomcat, and JBoss EAP where most of Phase 2 discovery information is fetched in Phase 1 itself. Thus you can proceed with Transform without X-ray.

  • Non-invasive discover is automatically performed
  • It is supported on all operating systems: Linux and Windows

Ignore List

During Phase 1 discover, all the running processes on the host are scanned for their properties and I/O. This may increase the overall processing time and thus is undesirable. You can define the ignore list of processes per host which can be safely ignored during discover Phase 1.

Application Ignore List

This is specifically for non-X-ray Java applications deployed on application servers like IBM WebSphere, Oracle WebLogic, Apache Tomcat, and JBoss EAP. If you already know the applications hosted on these Java servers, then one or more applications can be analyzed instead of all by defining an application ignore list.

Application

An application is a way to group processes running across multiple hosts in a project belonging to a multi-tier application. Think of an application as a bucket that holds discrete but connected processes.

Example

A multi-tier application where the following processes are running on multiple hosts:

  • Nginx: Reverse proxy
  • Nginx: Hosts React.js code as frontend
  • Apache Tomcat: Middleware
  • MySQL: Database

Report

A report is organized, detailed information of a project, hosts, and processes which includes:

  • Executive summary
  • About customer
  • Discovery findings
  • Host classifications
  • Container complexity calculations
  • Technology stacks
  • Application distributions
  • Topology
  • Containerization recommendations

Using this report, the application architect can decide the further containerization strategy.

Topology

Topology shows the connections between the hosts and the processes it runs in a project in a graphical manner.

Classify Host

You can classify host(s) based on 3 of the 6R's principles: Retire, Retain, or Rehost.

What is the 6R's Principle?

Reinvest

This strategy is typically used for applications that are strategic. Organizations are ready to invest additional efforts, time, and money to keep the application up to date and useful. The sub-categories of actions in this category are Rehost, Replatform, or Refactor.

Replatform

The replatform strategy involves moving applications almost as-is, but replacing some components to take advantage of the cloud. CHAI™ enables replatform in multiple ways. We enable application teams a choice of rationalizing the application environments used to host the applications to leaner and cost-effective options. This also helps in moving qualified services from Windows operating systems to Linux OS as applicable.

Refactor

This strategy calls for an overhaul of the application to adapt it to cloud-native architecture. It is valuable when you have a strong business need for cloud-native features, such as improved development agility, scalability, or performance. CHAI™ specializes in getting started on your refactoring journey that can lead to breaking up the application into independent services and transitioning to a microservices architecture. CHAI™ makes it possible to get started on this path depending on organizational skills and abilities.

Rehost

This strategy involves moving applications from the on-premises environment to the cloud without modification. It is commonly used to migrate large-scale legacy applications to meet specific business objectives such as an accelerated product launch timeline.

Retain

This doesn't involve migrating the application to the cloud. The business is heavily invested in the on-premises application and may have currently active development projects. Legacy operating systems and applications are not supported by cloud environments. The application is working well—no business case for the cost and disruption of migration. For industries which must adhere to strict compliance regulations that require data to be on-premises. For applications that require very high performance, the on-premises option may prove the better choice.

Retire

This doesn't involve migrating the application to the cloud. In many cases, during a migration project, you can identify applications that are redundant, and shutting them down can represent a cost saving. There may already be existing plans to decommission the application or consolidate it with other applications.