Machine-Learning Model (MLM) build technique is provided. Build instructions are normalized into a cloud-independent format. Each cloud identified in the instructions is assigned a specific adapter. The adapter translates the normalized format into a cloud-specific format and the adapters interact with configuration Application Programming Interfaces (APIs) of the specific cloud to process the instructions in the cloud-specific format. As the adapters interact with the corresponding APIs, output feedback from the APIs is live streamed within an interface to a developer that provided the instructions for monitoring the builds simultaneously being configured on multiple clouds. When the build instructions complete with the APIs on the clouds, the user is presented an option to initiate an orchestrator that loads, initiates, and trains the MLM as a unique instance of the MLM on each cloud.

BACKGROUND

Development of Machine-Learning Models (MLMs) are fraught with challenges. The development steps are invoked manually by developers via a Command Line Interface (CLI) supplied by a Cloud Service Provider (CSP).

This lengthens the entire development process and makes the resulting MLM build unscalable when many development steps are needed with the build of when the same build is needed in a different configuration. For example when the same build is required for multiple different tenants, the manual development build steps must be repeated for each different tenant, such that all the steps run separately for each tenant.

Additionally, the manual build steps makes version tracking of the models more vulnerable to human errors because models are frequently updated. The dynamic nature of MLMs, especially in the retail domain, require frequent updates to the MLM (frequent deployments). Errors in model versioning within the production environment of machine-learning applications can lead to poor performance and monetary losses.

Further, the CLI is provided by the CSP, such that it likely only works with services of the same CSP. As a result, if a same MLM was to be deployed on multiple-different CSP environments (e.g., to compare performances and costs between the environments), the developers have to need to adjust the deployment method repetitively so as to adapt each build to the specific requirements of each CSP while using each CSP's CLI.

Moreover, frequently developers want to use mixed cloud services from different CSPs within a given build to improve performance and/or to save cost. Unfortunately, this is option is unavailable in the industry.

SUMMARY

In various embodiments, system and a method for multi-cloud Machine Learning Model (MLM) building are presented.

According to an aspect, a method for multi-cloud Machine Learning Model (MLM) building is presented. Input data is received from a developer for building a MLM on multiple clouds. The input data is translated into cloud-specific instructions for each different cloud. Application Programming Interfaces (APIs) of each cloud are interacted with and the corresponding cloud-specific instructions are processed through the APIs. Output feedback received from the APIs during the simultaneously interaction is streamed to an interface operated by the developer. An option is provided within the interface, which when activated by the developer within the interface causes each instance of the MLM to be initiated on each cloud.

DETAILED DESCRIPTION

FIG.1is a diagram of a system100for multi-cloud Machine Learning Model (MLM) building, according to an example embodiment. It is to be noted that the components are shown schematically in greatly simplified form, with only those components relevant to understanding of the embodiments being illustrated.

Furthermore, the various components (that are identified inFIG.1) are illustrated and the arrangement of the components is presented for purposes of illustration only. It is to be noted that other arrangements with more or less components are possible without departing from the teachings of multi-cloud Machine Learning Model (MLM) building presented herein and below.

System100presents a novel user-friendly Command Line Interface (CLI) that automatically deploys a Machine-Learning Model (MLM) to a single Cloud Service Provider (CSP) environment and/or multiple CSPs' environments. When starting a wizard during a MLM build, the user/developer is asked to input, one or more Cloud Provider (CP) names, a model name, a model version, a Uniform Resource Locator (URL) link to a code repository, and other information. Predefined configurations can be taken as output files from other services and used in the deployment wizard to avoid redundant user input (e.g., a cloud storage URL and cloud orchestrator URL, etc.). The technique is compatible across different CSP environments. A given MLM can be deployed to several CSP environments simultaneously. The process provides verbose user output feedback along with a current state of the build, so that the user/developer can easily identify and potential errors in the build process quickly and efficiently.

System100is implemented as three component pieces, I/O managers responsible for communication between the user and the CLI; adapters responsible for sending and receiving requests to and from the Application Programming Interface (API) of the CSP (each adapter responsible for interacting with a specific CSP and also can consume equivalent resource on different CSPs); and listeners responsible for communicating with the CSP and reflecting the current status of the build (development to the user/developer).

System100also provides live streaming of the current build status from each CP to the user. This allows the user to easily debug the build steps, since the status of each step is provided to the user in real time.

System100also provides automatic version tagging in a cloud repository by either creating a new tag (version) for a deployed model or by using an existing tag (existing version). This gives the user an improved version control to the deployed models and recoverability to quickly deploy a previous version if something is wrong with a current model version.

System100allows the deployment wizard to simultaneously deploy multiple MLMs to multiple CPs environments, such that the user can compare performances and costs between different CPs.

Essentially, system100permits deployment of MLMs to a single CP environment or to multiple different CPs' environments with a single development build configuration or with multiple build configurations (by running the wizard for each of the multiple build configurations, which significantly reduces the effort required).

As used herein, the terms “user,” “developer,” and/or “analyst,” may be used interchangeably and synonymously herein and below. This refers to an individual who is operating a developer-operated device and interacting (providing input and receiving feedback) with the novel MLM build interface for purposes of configuring/building a cloud hosted or multi-cloud hosted MLM used by retailer services of a given retailer and offers to retailer customers via a retailer service interface.

The term and phrase “resource” and/or “cloud resource” refers to hardware (computing devices, memory, processor, storage, etc.) and/or software (applications, programs, functions, etc.) hosted in a cloud environment. A “service” is an organized collection of one or more resources designed to perform operations based on input data (manually supplied or automatically obtained through another service or a resource) and provide output based on the input data.

A “hosted environment,” a “cloud environment,” and/or a “cloud” refers to a collection of one or more hardware servers that logically cooperate as a single referenced environment over a network connection to process the resources and the services.

It is within the above-noted context that system100is discussed with reference toFIG.1.

System100comprises a build cloud/server110, a developer-operated device120, a plurality of CP servers (environments)130, and retailer customer devices140.

Cloud/Server100comprises a processor111and a non-transitory computer-readable storage medium112. Medium112comprises executable instructions for Input/Output (I/O) managers113, a listeners114, CP adapters115, a build wizard116, and a CLI117. Processor111obtains or is provided the executable instructions from medium112causing processor111to perform operations discussed herein and below with respect to113-117.

Each developer-operated device120comprises a processor121and a non-transitory computer-readable storage medium122. Medium112comprises executable instructions for a MLM build interface. Processor121obtains or is provided the executable instructions from medium122causing processor121to perform operations discussed herein and below with respect to123.

Each CP server130comprises a processor131and a non-transitory computer-readable storage medium132. Medium132comprises executable instructions for cloud resources133, configuration APIs134, and retailer services with MLMs135. Processor131obtains or is provided the executable instructions from medium132causing processor131to perform operations discussed herein and below with respect to131-135.

Each retailer customer device140comprises a processor141and a non-transitory computer-readable storage medium142. Medium142comprises executable instructions for a retailer service interface143. Processor141obtains or is provided the executable instructions from medium142causing processor141to perform operations discussed herein and below with respect to143.

During a development session between a developer-operated device120and build cloud110, a developer interacts with build cloud110via MLM build interface123for purposes of building, configuring, and loading a MLM for use in one or more retailer services135. Initially, MLM build interface123renders a single screen for access to CLI117from build cloud110. The developer inputs the following data related to the MLM that is being configured or built: one or more CP names (each CP name is pre-mapped to the corresponding CP server), MLM name (name for the MLM being built and configured), MLM version, code resource repository URL (link to the CP's corresponding cloud resources133), resource requirements (minimums and/or maximums; e.g. memory requirement, network bandwidth requirement, simultaneous network connections, etc.) by code resource name or identifier or files or file links (URLs) that define the resource requirements, etc. Use of predefined files with the resource requirements allows for more portability between CP servers130but the developer may also individually input resource names with resource requirements as well.

Based on the initial input data provided by the developer through the MLM build interface123, the CLI interface117initiates an instance of an I/O manager113. The instance of the I/O manager113normalizes the developer input into CP independent formats with generic resource names along with the resource requirements. The instance of the I/O manager113then initiates an instance of a specific CP adapter115and provides that CP adapter115with the developer input data in the independent format with the generic resource names and resource requirements. Each instance of a specific CP adapter115corresponds to a CP (CP server130) identified by the developer in the input data.

For each instance of the CP adapter115and instance of a listener114is activated on build cloud110. Each instance of each CP adapter115interacts with a specific CP server's configuration APIs134for purposes of processing the user input in the cloud-specific APIs134using the cloud-specific resources133. Each instance of CP adapter115translates the independent form and generic resource names into a cloud-specific API format utilizing resources cloud-specific resource names. The format of the resources requirements for a given cloud resource may also require translation by a specific instance of the CP adapter115.

The instances of the CP adapters115process the user input with each of the corresponding configuration APIs134for each of the corresponding cloud resources133. Each listener monitors the API calls and API call feedback output and streams that feedback output back to the CLI117. As the streamed feedback output is received from the interactions between the CP adapters115and the configuration APIs134, CLI117activates build wizard116. Build Wizard generates a split screen rendered within the MLM build interface123, the left-side screen comprising the CLI117, the right-side screen comprising a Graphical User Interface (GUI) that streams the feedback output from the configuration APIs134so that the developer can see the build processes being executed and the status in real time from all of the CP servers. Any error will be readily available with the GUI portion of the split screen in the MLM build interface123.

When the configuration and build processing steps have completed successfully, the build wizard116changes the GUI portion of the spilt screen to show and option for the developer to initiate the orchestration service, which will link, initiate, and train the build on the CP servers130.

In an embodiment, before the instances of the CP adapters115engage their corresponding configuration APIs134, build wizard116archives the commands with the tagged version number in a versioning service, such that the build for the model can be readily obtained and automatically processed when new CPs are requested or more instances of the MLM is needed on any of the existing CPs that are running the MLM within any given retailer service135.

System100presents a streamlined and portable set of interfaces (build wizard116and CLI117) and processes I/O managers113, listeners114, and CP adapters115which allow a developer to build a MLM generically in a stable generic and independent format and allow the build to be processed and instantiated automatically on one or multiple different CPs (CP servers130). The versioning is handed automatically via the build wizard116, the translation to CP-specific configuration APIs134for CP-specific resources is handled by instances of specific CP adapters115, and real-time processing feedback between the build configuration commands being executed by the configuration APIs134(as provided by the CP adapters115) is lived-streamed in a split screen of the MLM build interface via a GUI (left side of the split screen comprises a rendering of the CLI117). Once the build steps are completed, the GUI includes an orchestration option for the developer to initiate and train the MLM. Once training is complete, the MLM is available for use within its designated retailer service135associated to customers of the retailer using retailer service interface143via retailer customer devices140.

System100substantially improved development of MLM builds for developers, removes redundant tasks, improves error detection during any given build, and allows a MLM build to be deployed simultaneously on multiple CP servers130.

In an embodiment, the CLI interface117is rendered within the MLM build interface123as a GUI. In an embodiment, menu options and selection for resource names, default properties/settings, etc. can be presented as selectable options by the user during the build session through the GUI.

In an embodiment, the cloud providers can be any custom cloud provider, Microsoft® Azure®, Amazon® Web Services®, and/or Google® Cloud Platform®.

In an embodiment, the build wizard116may provide options within screens rendered to the MLM build interface123for the developer to load a previous MLM build and its settings or input data instructions, permit the developer to selectively change, delete or add settings, and automatically initiate the build processing.

The above-referenced embodiments and other embodiments are now discussed with reference toFIGS.2-3.

FIG.2is a diagram of a method200for multi-cloud Machine Learning Model (MLM) building, according to an example embodiment. The software module(s) that implements the method200is referred to as a “MLM build service.” The MLM build service is implemented as executable instructions programmed and residing within memory and/or a non-transitory computer-readable (processor-readable) storage medium and executed by one or more processors of one or more devices. The processor(s) of the device(s) that executes the MLM build service are specifically configured and programmed to process the MLM build service. The MLM build service has access to one or more network connections during its processing. The connections can be wired, wireless, or a combination of wired and wireless.

In an embodiment, the device that executes the MLM build service is cloud110. In an embodiment, the device that executes MLM build service is server110.

In an embodiment, the MLM build service is all of, or some combination of I/O managers113, listeners114, CP adapters115, build wizard116, CLI117, and/or MLM build interface123.

At210, the MLM build service receives input data from a developer for building a MLM on multiple clouds. The input data comprises cloud resource configuration settings and cloud names for each of the clouds.

In an embodiment, at211, the MLM build service receives the input data through a CLI117rendered within a screen of an interface123to the developer.

In an embodiment, at212, the MLM build service receives a portion of the input data as a link to a file or a reference to the file. The file comprising a portion of the configuration settings and/or cloud names.

In an embodiment, at213, the MLM build service presents the input data within the interface123to the developer as existing input data associated with an existing MLM. The MLM build service receives modifications to the existing input data as the input data from the developer through the interface123.

In an embodiment, at214, the MLM build service receives the input data in a cloud-independent, generic, or intermediary format.

At220, the MLM build service translates the input data into cloud-specific instruction for each of the different clouds.

In an embodiment of214and220, at221, the MLM build service initiates an adapter115for each cloud, each adapter115when initiated translates the cloud-independent format to the corresponding cloud-specific format.

At230, the MLM build service simultaneously or concurrently interacts with APIs134and processes the corresponding cloud-specific instructions with each cloud.

In an embodiment of221and230, at231, the MLM build service provides, via or by each adapter to the corresponding APIs134, API calls for the corresponding cloud-specific instructions.

At240, the MLM build service streams output feedback received from the APIs134during230to interface123, which is being operated by the developer.

In an embodiment of231and240, at241, the MLM build service initiates a listener114for each adapter115, each listener114monitors, records, and stream the corresponding API calls and the corresponding output feedback provided by the corresponding APIs134in real time to the interface123.

In an embodiment of241and at242, the MLM build service streams, by each listener114, the corresponding API calls and the corresponding output feedback to a GUI screen associated with the interface123.

At250, the MLM build service provides an option within the interface123which when activated by the developer within the interface123causes each instance of the MLM to be initiated on each cloud.

FIG.3is a diagram of another method300for multi-cloud Machine Learning Model (MLM) building, according to an example embodiment. The software module(s) that implements the method300is referred to as a “cloud-independent MLM build wizard.” The cloud-independent MLM build wizard is implemented as executable instructions programmed and residing within memory and/or a non-transitory computer-readable (processor-readable) storage medium and executed by one or more processors of one or more devices. The processor(s) of the device(s) that executes the cloud-independent MLM build wizard are specifically configured and programmed to process the cloud-independent MLM build wizard. The cloud-independent MLM build wizard has access to one or more network connections during its processing. The network connections can be wired, wireless, or a combination of wired and wireless.

In an embodiment, the device that executes the cloud-independent MLM build wizard is cloud110. In an embodiment, the device that executes the cloud-independent MLM build wizard is server110.

In an embodiment, the data-driven cloud-independent MLM build wizard is all of, or some combination of I/O managers113, listeners114, CP adapters115, build wizard116, CLI117, MLM build interface123, and/or method200.

The cloud-independent MLM build wizard presents another and, in some ways, enhanced processing perspective from that which was discussed above with the method200of theFIG.2.

At310, the cloud-independent MLM build wizard provides a MLM build interface123to a device120operated by a developer.

At320, the cloud-independent MLM build wizard renders a CLI within a first portion of the MLM build interface123to a MLM build that is being initiated within multiple clouds provided by multiple cloud providers.

In an embodiment, at321, the cloud-independent MLM build wizard obtains a portion of the input data based on a reference to a file or a link to the file provided by the developer through the MLM build interface123.

At330, the cloud-independent MLM build wizard translates the input data into cloud-specific build instructions for each of the clouds.

At340, the cloud-independent MLM build wizard processes the corresponding cloud-specific instructions via APIs134associated with the corresponding clouds.

At350, the cloud-independent MLM build wizard streams output feedback received from the APIs134to a second portion of the MLM build interface123in real time.

In an embodiment, at351, the cloud-independent MLM build wizard streams the output feedback to a GUI rendered screen of the second portion of the MLM build interface123.

In an embodiment of351and at352, the cloud-independent MLM build wizard renders the CLI117in a second screen of the first portion of the MLM interface123, the first portion is adjacent to the GUI screen providing a split screen view within the MLM build interface123.

At360, the cloud-independent MLM build wizard presents an option within the second portion of the MLM build interface123that when activated by the developer causes an instance of the MLM to be activated on each of the clouds using cloud resources of each corresponding cloud.

In an embodiment, at361, the cloud-independent MLM build wizard presents the option as a single command that initiates an orchestration service on each of the clouds to load, initiate, and train each instance of the MLM on each cloud using the corresponding cloud resources.

In an embodiment, at370, the cloud-independent MLM build wizard loads the input data and a reference to the MLM build within a version control system.

In an embodiment of370and at371, the cloud-independent MLM build wizard receives an instruction through the MLM build interface123supplied by the developer to load the MLM build based on the reference.

In an embodiment of371and at372, the cloud-independent MLM build wizard loads the input data from the version control system within the MLM build interface123for modifications by the developer and iterates back to330with the modified input data as the input data to330.