API-driven platform for automated and reference-based machine learning workflows and deployments

Abstract

A computer-implemented method operates on serializable or de-serializable programmatic objects representing deployments. Each deployment object can be programmatically applied to or associated with a collection of remote (cloud, or in-datacenter) compute resources ("target resources") from another machine ("client machine"). The client machine does need direct network access to the target resources and instead makes network requests to an API server that can connect to the target resources, directly or indirectly. Users leverage deployment APIs to construct a deployment object that is then transmitted securely through an API server, which conducts access checks. The deployment APIs allow users to reference "deployment metadata" (for example, the versioned build image) by name to facilitate reusability, reduce errors, and allow for administrator-curated deployment configurations. Additionally, the deployment APIs of an embodiment allow users to reference data integrations, datasets, user-defined functions, and machine learning models to ensure consistent workflow execution.

Description

ATTORNEY DOCKET NO. PATENT APPLICATION 088835.0120 1 of 40 API-DRIVEN PLATFORM FOR AUTOMATED AND REFERENCE-BASED MACHINE LEARNING WORKFLOWS AND DEPLOYMENTS BENEFIT CLAIM

[0001] This application claims the benefit under 35 U.S.C. § 119 of U.S. provisional application 63 / 659212, filed June 12, 2024, the entire contents of which are hereby incorporated by reference for all purposes as if fully set forth herein. COPYRIGHT NOTICE

[0002] A portion of the disclosure of this patent document contains material that is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent file or records, but otherwise reserves all copyright or rights whatsoever. © 2023 Exploratory Sciences, Inc. TECHNICAL FIELD

[0003] One technical field of the present disclosure is techniques for the automatic deployment of computer program applications, especially machine-learning systems. Another technical field of the present disclosure is machine learning model validation. BACKGROUND

[0004] The approaches described in this section are approaches that could be pursued, but not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated, it should not be assumed that any of the approaches described in this section qualify as prior art merely by virtue of their inclusion in this section.

[0005] Deployments are a crucial aspect of modern computing. A deployment is a daemon, job, server, or web application that runs on remote compute resources. Deployments may run in either “development” or “production” environments, and essentially allow for processes to run in an automated fashion. For example, a “job” is a process that typically has a defined start (which may reoccur based on a chronological schedule, that is, a “cronjob”) and end (when the steps in the process have completed) and allows for a set of computational processes to occur (once defined) without any human intervention. A common application for jobs is that of data- processing pipelines, often referred to as “extract-transform-load” (or “ETL”). A user mightATTORNEY DOCKET NO. PATENT APPLICATION 088835.0120 2 of 40 define a set of steps in order to transform “raw” data into data that is ready for analysis, and then set up a job to replicate those steps, say, each morning, when new raw data is deposited.

[0006] Other types of deployments involve additional complexity, especially around providing network access (from other compute resources) to a deployment. For example, a web application typically involves a combination of “backend” (or server) APIs and a “frontend” (graphical user interface, or “GUI”), where user browsers connect directly to the GUI, which itself translates visual interactions (like clicking a button) into API calls to the backend server. In such a case, it is crucial that user browsers can connect to the GUI application over HTTP (while direct network access by users, to the backend servers, may be restricted); often, additional security is required to ensure that only certain users can access the GUI, and that permissible behavior within the GUI is further restricted, depending on the user. For example, an analytical dashboard might be developed to offer a nuanced view into a company’s profit- and-less expectations; in such a case, the GUI might only be accessible to executives and certain financial personnel and certain views within the GUI (which might provide more sensitive information) may be restricted such that only certain users can interact with them.

[0007] The explosion of cloud computing has been both followed and facilitated by the development of software frameworks that standardize and solidify the processes for defining, running, and monitoring deployments. Key to this growth has been the idea of “containers” or operating-system-level virtualized computers, which have drastically improved software portability. However, containers themselves are purposefully modular, providing little in the way of cross-container functionality, such as ways to connect multiple containers into a single application. One way may be through orchestration using tooling like the Kubernetes framework, which Google open-sourced after using it to power its own production deployments for more than a decade. Kubernetes can be installed onto compute resources to enable running containers in a variety of different templates, with support for a variety of deployment types, in a way that is fairly agnostic to underlying compute resources, allowing for meaningful portability of deployments across different cloud services like AMAZON WEB SERVICES or GOOGLE CLOUD PLATFORM. For example, Kubernetes offers a “service” construct that provides network capabilities to a running container, and an “ingress” construct that allows outside network requests to reach a running service via DNS (and which can also be used to restrict or further control inbound network requests).

[0008] Successful execution of container-based computing concepts and orchestration frameworks like Kubernetes, however, is predicated on professional skills that have little to doATTORNEY DOCKET NO. PATENT APPLICATION 088835.0120 3 of 40 with the math of data science, skills which can deviate significantly even from what is traditionally thought of as the realm of software engineering. Such deployment skills include an incredible amount of configuration, typically defined via a structured-text format such as “YAML,” which affects the behavior of orchestration frameworks, including hardware specifications (for example, CPU, memory, GPU), network routing, and security. SUMMARY

[0009] The appended claims may serve as a summary of the invention. BRIEF DESCRIPTION OF THE DRAWINGS

[0010] In the drawings:

[0011] FIG.1 illustrates an example block diagram for serialization.

[0012] FIG. 2A and FIG. 2B illustrate an example overview for access controls: RBAC and network security middleware.

[0013] FIG.3 illustrates an example block diagram for object loading.

[0014] FIG. 4 illustrates a computer-implemented process of automated deployments, in one embodiment.

[0015] FIG. 5 illustrates a computer system with which one embodiment could be implemented. DETAILED DESCRIPTION

[0016] In the following description, for the purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the present invention. It will be apparent, however, that the present invention may be practiced without these specific details. In other instances, well-known structures and devices are shown in block diagram form in order to avoid unnecessarily obscuring the present invention.

[0017] The text of this disclosure, in combination with the drawing figures, is intended to state in prose the algorithms that are necessary to program the computer to implement the claimed inventions, at the same level of detail that is used by people of skill in the arts to which this disclosure pertains to communicate with one another concerning functions to be programmed, inputs, transformations, outputs and other aspects of programming. That is, the level of detail set forth in this disclosure is the same level of detail that persons of skill in theATTORNEY DOCKET NO. PATENT APPLICATION 088835.0120 4 of 40 art normally use to communicate with one another to express algorithms to be programmed or the structure and function of programs to implement the inventions claimed herein.

[0018] Embodiments are described in sections below according to the following outline: 1. General Overview 2. Structural & Functional Overview 3. Implementation Example – Hardware Overview *

[0019] 1. GENERAL OVERVIEW

[0020] In an embodiment, a computer-implemented method operates on serializable or de- serializable programmatic objects representing deployments. Each deployment object can be programmatically applied to or associated with a collection of remote (cloud, or in-datacenter) compute resources (“target resources”) from another machine (“client machine”). The client machine does need direct network access, which is often prohibited for security reasons, to the target resources and instead makes network requests to an API server that can connect to the target resources, directly or through an intermediary.

[0021] Users leverage the deployment APIs of an embodiment (“deployment APIs”), which can implement the functions of section 2.4 of the disclosure in U.S. Patent Pub. No. US 20230108808 A1, published April 6, 2023 (application 17 / 979833, filed November 3, 2022) to construct a deployment object that is then transmitted securely through the API server of an embodiment, which conducts the requisite access checks. The reader of this document is presumed to have read, understood, and be capable of implementing the subject matter of the aforementioned patent publication. The deployment APIs allow users to reference “deployment metadata” (for example, the versioned build image) by name to facilitate reusability, reduce errors, and allow for administrator-curated deployment configurations. Additionally, the deployment APIs of an embodiment allow users to reference data integrations, datasets, user- defined functions, and machine learning models to ensure consistent workflow execution.

[0022] 2. STRUCTURAL & FUNCTIONAL OVERVIEW

[0023] 2.1 DEPLOYMENT APPLICATION LAYER

[0024] An embodiment provides an application layer (“deployment application layer”) that logically sits between users and their remote resources, including any orchestration frameworks like Kubernetes. The deployment application layer provides a database model and database API server that together: accept input from the deployment APIs; validate and sanitize incoming metadata; persist deployment metadata, in a modular way, to enable a software-basedATTORNEY DOCKET NO. PATENT APPLICATION 088835.0120 5 of 40 approach to reusable deployment metadata; automatically structure the deployment metadata (“formatted deployment metadata”) in the format expected by the available orchestration framework (for example, Kubernetes); manage the creation and removal of deployments, as per the supplied deployment metadata, via the available orchestration framework; put strict access controls around all deployment actions in the platform, and ensure that each deployment receives its own least-privilege identity (“deployment identity”); and, offer the ability to query the available deployments over HTTP, with the CLI and GUI of an embodiment providing programmatic and graphic interfaces, respectively, over this capability.

[0025] When the deployment APIs submit a request through the deployment application layer to create or recreate a deployment, the deployment APIs receive the formatted deployment metadata, with any secrets redacted (“redacted formatted deployment metadata”), in the response data, assuming the action was successful. The redacted formatted deployment metadata is then automatically saved to Git, into a repository of the user’s choice and under a standardized organization.

[0026] 2.2 DEPLOYMENT APIS

[0027] An embodiment offers a collection of deployment APIs that allow users to conveniently interact with the deployment application layer. The deployment APIs comprise: on the server side, network endpoints that serve HTTP or HTTP / 2 access to the deployment application layer; and, on the client side, the SDK of an embodiment (which may be implemented in Python or any other suitable languages), which provides libraries, classes, and functions (including a “builder” API) to allow for an extensible, software-based approach to interacting with the deployment application layer. Additional interfaces provide convenient, client-side access to the deployment APIs: the CLI of an embodiment, which is a cross-platform binary executable that runs on any OS and with minimal dependencies (only LLVM is required); and the GUI of an embodiment, which users access through their web browser (but which may also be offered as a “desktop client”).

[0028] An SDK of an embodiment allows users to engage the deployment application layer without leaving the environment in which they are doing their other programming work. This is especially important for data scientists (and related personnel) who predominantly do their work in Python. The deployment APIs allow for easy, automatic triggering of the deployment application layer as a result of external events, for example, via a button click from within a user-defined dashboard, or as a result of a commit into a remote Git repository.ATTORNEY DOCKET NO. PATENT APPLICATION 088835.0120 6 of 40

[0029] The GUI of an embodiment allows for visually structuring and editing deployment metadata, and provides “deployment provenance,” or the graph-based auditing view into a set of deployments, with visual representations of the relationships between deployments, in addition to highlighting the set of objects of an embodiment (data integrations, datasets, user- defined functionality, machine learning models, and more) that a deployment may rely on.

[0030] 2.3 DEPLOYMENT METADATA

[0031] The deployment application layer implements a database model that persists deployment metadata in such a way that enables both reusability and security.

[0032] For example, “images” (the compiled, binary files that, when run, become containers) are typically stored in a repository; a repository is described by its network host and, optionally, an additional network path. Each image is typically given a name, as well as a “tag” (basically, a version identifier). Thus, when a user or system needs to retrieve an image, they must provide these pieces of metadata. Such a setup leads to a few issues: the user or system retrieving the image must be able to provide all of this metadata; if this metadata changes, which can happen frequently, as, for example, image tags will often change with any new release of any of the software that is to be installed into the image, all parties who need to know this metadata must be kept up-to-date; this metadata is often reused in a variety of contexts, as a single image will often power many deployments; and, from a security perspective, any user or system who has access to any reference to the image metadata has the ability to change this metadata in order to alter the software the is actually run in the deployed context.

[0033] To make the management of deployment metadata a more sensible process, many organizations have turned to Git, that is, with a Git repository serving as the source of truth for all deployment metadata. In the aforementioned image example, this would mean that the image metadata would be described in a text file that itself would live in a Git repository; any user or system who needs access to the Image metadata would simply find the requisite file in the requisite repository, and any change to the image metadata would simply have to be reflected in this file. While Git versioning does offer many benefits, the aforementioned setup nonetheless fails to address several issues. A deployment is usually represented by its own set of configuration files; thus, the same image metadata may end up replicated across many files, and potentially across many Git repositories. This means that even the simple task of identifying the exact image metadata for a particular deployment can prove time-consuming. Furthermore, ensuring that consistent propagation of any changes to image metadata is aATTORNEY DOCKET NO. PATENT APPLICATION 088835.0120 7 of 40 nontrivial task, given that many files may need to be updated. And any user or system authorized to the Git repository that houses the image metadata can change this metadata in an unscrupulous manner, which provides an opportunity to introduce malicious software into the deployed context. Finally, executing these configuration files will require direct access to the target resources, which introduces additional security risks.

[0034] These issues in fact exist across many more axes, given that a single deployment is typically defined by many different components, each with its own metadata: image, hardware specifications (for example CPU, memory, GPU), the command to run upon initiation of the container, an optional schedule that would define a recurring and chronological execution of a container-based process; many more configurations can exist for a given orchestration framework, like Kubernetes. All this metadata must be queryable, must be kept up-to-date, and must be kept secure -- no small feat. As a result of this complexity, many organizations are forced to hire teams of “DevOps” (or related) personnel, who develop and maintain these configuration files. For an organizational perspective, this practically requires that DevOps personnel act as intermediaries to all deployments, which quite tangibly impedes data scientists and even software engineers from executing deployments in a truly self-service way.

[0035] It is with these motivations in mind that the deployment application layer is further described. Through abstracting images, “hardware profiles” (each a set of hardware specifications), “container arguments” (each of a set of arguments to be passed to the specified command that is run upon initiation of a container), and more, into reusable objects, the deployment application layer thoroughly alleviates the aforementioned issues.

[0036] The deployment application layer stores deployment metadata in such a way that, once created, it can simply be referenced by name. For example, an image with repository “image-store.internal.company.com,” name “my-image,” and tag “0.1.0” can be stored as something like “company-dev-image,” (its “object name of an embodiment”) requiring users and systems to know only that this image metadata can be retrieved by looking up the right object name of an embodiment; in other words, the database model stores the image metadata alongside the object name of an embodiment, and authorized users and systems are presented with the complete set of image metadata upon requesting the object name of an embodiment. Importantly, this layer of indirection means that updates to the image metadata can be processed once, through the deployment application layer, with the guarantee that any future requests for the image metadata will be met with up-to-date information (the CLI and GUI of an embodiment allow for easy editing of deployment metadata). Additionally, the fact thatATTORNEY DOCKET NO. PATENT APPLICATION 088835.0120 8 of 40 deployment metadata is defined, for each deployment, in the same Python SDK of an embodiment that is also responsible for defining data sets, user-defined functionality, and machine learning models, means that users can engage the deployment application layer without changing tools, environments, or even codebases.

[0037] The current set of deployment metadata types includes several types that are agnostic to orchestration frameworks: images, hardware profiles, container arguments, “schedules,” and “security contexts.” Schedules are defined with one or more “crontab” schedules, plus: the ability to run against a “market calendar” (for example, only running on days that the New York stock exchange is open), the ability to run in some custom relation to a market calendar (for example, 10 minutes before the opening hour of the New York stock exchange), the ability to exclude certain user-supplied dates. Security contexts offer the opportunity to set various restrictions on the in-container access privileges (for example, restricting the ability to assume the “root” user, allowing only read-only access to files in the container, plus other options, including OS-specific options for both Linux and Windows containers). To reiterate, once any deployment metadata item has been defined, it can be used across one or more deployments. Here is an example command chain, via the Python SDK of an embodiment, that engages the “builder” on a server object in order to reference an existing image and hardware profile: server.deploy().image( name="data-science", project="development"

[0038] The current set of deployment metadata types also includes metadata types that are specific to the Kubernetes orchestration framework: “Init containers” allow for users to define reusable initialization containers that will be attached to, and run before, the target container (for example, for ensuring certain configuration files are present in the target container’s filesystem); “Sidecar containers” are run in such a way that they are coupled to the target container (a common application for this is for capturing logs from STDOUT and STDERR); and, “Node-Pod configurations” allow for the specification of Kubernetes specific metadata (for example, “affinities” and “tolerations,” which affect how Kubernetes maps to-be-executed containers to the available hardware.ATTORNEY DOCKET NO. PATENT APPLICATION 088835.0120 9 of 40

[0039] Deployment metadata is protected by the IAM framework of an embodiment, which allows for deployment metadata to be scoped to various levels of accessibility. For example, account-level defaults (such as an image that is used by an entire company) can be made accessible to all users of the instance of an embodiment, while “production-only” deployment metadata (such as a hardware profile corresponding to higher memory specifications that might lead to increased financial costs) can be made accessible to only certain users.

[0040] 2.4 OBJECT APIS

[0041] The deployment APIs of an embodiment allow users to reference data integrations, datasets, user-defined functions, and machine learning models (“reference objects”) to ensure consistent workflow execution. Reference objects can be serialized, persisted, retrieved, and deserialized via collection of “object APIs” that enable automated and recursive execution of the aforementioned actions (serialization, persistence, retrieval, and deserialization), with persistence and retrieval, data sanitization and validation, and access controls being implemented by means of an internal database of an embodiment and various database API servers (together, the “object application layer”).

[0042] The object APIs comprise: on the server side, network endpoints that serve up HTTP (and potentially, HTTP / 2) access to the object application layer; and, on the client side, the SDK of an embodiment (which may be implemented in Python or any other suitable languages), which provides libraries, classes, and functions (including a “builder” API) to allow for an extensible, software-based approach to defining, managing, and executing workflows based on, the relations between objects (“references”). Additional interfaces provide convenient, client-side access to the object APIs: the CLI of an embodiment, which is a cross-platform binary executable that runs on any OS and with minimal dependencies (only LLVM is required); and the GUI of an embodiment, which users access through their web browser (but which may also be offered as a “desktop client”).

[0043] The object application layer comprises a collection of services and data stores: the internal database of an embodiment that is responsible for relational storage of object metadata (“metadata database”); the database API server that provides secure, network access to, and sanitizes, validates, and processes incoming data for, and collects and processes outgoing data from, the metadata database (“metadata server”); a semi-structured internal database of an embodiment that can be used for flexible storage of arbitrary binary data (“cache of an embodiment”); and, a high-performance HTTP / 2 API server that provides secure, networkATTORNEY DOCKET NO. PATENT APPLICATION 088835.0120 10 of 40 access to, and sanitizes, validates, and processes incoming data for, and collects and processes outgoing data from, the cache of an embodiment (“tile store”).

[0044] An SDK of an embodiment allows users to engage the deployment application layer without leaving the environment in which they do their other programming work; this is especially important for data scientists (and related personnel) who predominantly do their work in Python. The deployment APIs allow for easy, automatic triggering of the deployment application layer as a result of external events, for example, via a button click from within a user-defined dashboard, or as a result of a commit into a remote Git repository.

[0045] A particular component of the SDKs of an embodiment is the “freeloader” library, a Python framework that provides analytical utility code, including modular software interfaces into validator APIs, to aid in the validation of machine learning and time series models.

[0046] 2.5 REFERENCE OBJECTS

[0047] A reference object comprises: metadata (“object metadata”), stored in the metadata database (and able to be represented in YAML for storage in Git); potentially, data (“object data”), which may be persisted either in a third-party data store or in the cache of an embodiment; and potentially, user-defined code (“object code”), which an embodiment will auto-package into Git, including all record-keeping around required dependencies. An “object reference,” therefore, is a named reference (scoped to an account, organization, and project) to the object metadata, object data, and object code that together can be reassembled into an in- memory object that can execute computational tasks (“in-memory object”).

[0048] FIG. 1 illustrates an example block diagram for serialization. The serialization of tiles 110, edges 120, and metadata 130 is visually depicted, at a high level, in FIG.1. Tiles 110 may be serialized to data 112 and metadata 116. Data 112 may be stored in an integrated third- party data store or system cache 114. Metadata 116 may be stored in an internal system database 118. The internal system database 118 can be represented in YAML for Git versioning. Edge 120 may be serialized to user-defined code 122 and metadata 126. The user- defined code 122 may be auto-packed, with versioned dependency records, into Git at operation 124. Metadata 126 may be stored in the internal system database 118. Metadata 130 may be stored in the internal system database 118.

[0049] An SDK of an embodiment enables the automatic serialization and (access-gated) persistence of in-memory objects (“object saving”). Object saving entails: serializing all object metadata into a network-transmissible data format (for example, JSON or Protobuf) and recursively converting each child, or referenced, in-memory object into an object reference, orATTORNEY DOCKET NO. PATENT APPLICATION 088835.0120 11 of 40 the subset of object metadata that is required to be able to reconstruct the referenced in-memory object (“object loading”). Specifically, the object metadata corresponding to the referenced in- memory object is retrieved via the metadata server. Any object data the referenced in-memory object relies on (for example, a stateful representation of weights of a machine learning model) is retrieved as per a referenced integration to a third-party data store, or via the tile store. Any object code the referenced in-memory object relies on will be automatically retrieved from Git, installed (including any required dependencies), and imported into the running process.

[0050] An object saving request, from an SDK of an embodiment to the metadata server, because of the previously described serialization procedures, may include one or more object references. Upon receipt of this collection of object references, the metadata server will check whether any of these object references refer to objects that have been scoped to a different access group (that is, a different project). If so, the metadata server will perform any additional access checks that are needed. In other words, the metadata server will always check that the identity that has made a request (whether for read or write) has the necessary permissions across the union of access groups of the parent object and any object references (with all access checks being delegated to the IAM server of an embodiment). Any object references will then be resolved to their primary key identifiers, or the unique identifiers in the metadata database that correspond to that particular object (that is, an object reference must correspond to an existing object). Finally, the parent object is saved into the metadata database, along with any foreign- key references for the parent object’s reference objects.

[0051] As object saving happens recursively, so does object loading. FIG. 3 illustrates an example block diagram for object loading. At operation 302, system SDK retrieves data 304 from the integrated third-party data store, or system cache. The retrieved data becomes local data 306. At operation 308, system SDK fetches metadata 310 in internal system database through database server API. The fetched metadata becomes local metadata 312. At operation 314, system SDK collects user-defined code 316 from Git, including dependency records. The collected code becomes source code 318. At operation 320, system SDK installs dependencies, which results in source code with dependencies 322. At operation 324, system SDK compiles source code. At operation 326, system SDK class interface converts local metadata 312, local data 306, and in-memory user-defined code objects 328 to in-memory system object 330.

[0052] Object loading of an embodiment is visually depicted, at a high level, in FIG. 3. Upon receiving an object loading request, the metadata server will sanitize any incoming payload data or query parameters and ensure the requesting identity has the requisite access toATTORNEY DOCKET NO. PATENT APPLICATION 088835.0120 12 of 40 the parent object. The metadata database will then resolve foreign-key object references into the full set of object metadata for each object reference, allowing for the metadata server to return a graph that holds the complete object metadata for the requested object. Before the complete object metadata is returned, the metadata server will always check that the identity who has made a request (whether for read or write) as the necessary permissions across the union of access groups of the parent object and any object references (with all access checks being delegated to the IAM server of an embodiment). Once an SDK of an embodiment receives the complete object metadata, it will: manage any additional network calls (for example, engaging an integration to a third-party data store) that are needed, install and compile any user-defined code (including any dependencies), and will assemble this all into an exact representation of the in-memory object that was originally saved.

[0053] Thus, a reference object, as the union of object metadata, object data, and object code, enables a unique means to a secure and distributed working arrangement, with the object application layer ensuring that all clients securely read and write objects in a consistent way. The result is a platform that enables not only secure and consistent collaboration but also secure and consistent deployments (with each deployment acting as, essentially, just another client of the object application layer).

[0054] 2.6 OBJECT TYPES

[0055] An embodiment implements a collection of object representations that share certain metadata properties (those fields required to support object references) but that encapsulate distinct behaviors that correspond to workflow patterns common in data science and in data- related computing more generally (“object types”). While the object application layer provides security, data validation, and persistence for each of the object types, the SDKs of an embodiment provide in-memory APIs that are used, in conjunction with the object application layer, to define and execute workflows.

[0056] Aside from managing the interactions with the object application layer, that SDKs of an embodiment provide out-of-the-box abstractions that drastically reduce the amount of “boilerplate” code required for common tasks, thus reducing the need for in-house “glue” code (and any associated maintenance), which in turn reduces both the total financial cost of enterprise deployments, as well as the “time to value” in being able to release new solutions. The upshot is a drastic increase in the time and financial resources available for the work that provides differentiated value to organizations: namely, data analysis and the implementationATTORNEY DOCKET NO. PATENT APPLICATION 088835.0120 13 of 40 of (human and automated) decision-making processes that leverage such analysis, as opposed to the more commoditized operational work that an embodiment automates.

[0057] The set of object types comprises integrations, tiles, edges, models, validators, and mosaics.

[0058] An embodiment offers built-in capabilities (“integrations”) around connecting to and engaging with various third-party platforms. In keeping with the reference-based approach of an embodiment, the integration framework of an embodiment works through offering straightforward means for securely persisting the connection parameters (for an instance of a third-party platform) into an internal database of an embodiment, such that these connection parameters can be referenced both by clients and by other objects of an embodiment, thus ensuring consistency in third-party platform access (particularly, when it comes to data persistence and retrieval) for multiple clients (human, or system) working in a distributed matter. The SDKs of an embodiment provide APIs for converting an “integration object reference” (that is, a reference to an integration) into a set of connection parameters, using those parameters to establish a live connection to a third-party platform, and leveraging the live connection to read data, persist data, executing calculations, and more. The SDKs wrap open- source clients to third-party platforms to reduce boilerplate or glue-code that users are required to develop and maintain, and the SDKs also offer a level of extensibility (including “unstructured,” or schema-less integration type) that allows users to define custom integrations that are fully compliant with the SDKs of an embodiment. Integration connection parameters are stored securely, and sensitive fields are encrypted in storage, either via the default option of a secure internal database of an embodiment (where sensitive fields are salted prior to encryption) or via an integration into a customer-provided secret store (for example, Hitachi vault). The SDKs of an embodiment take a “lazy” approach to retrieving the connection parameters from the backend, doing so only to instantiate a connection and discarding them as soon as the connection has been established.

[0059] A tile is a reference to a dataset. “Tile object metadata” contains an integration object reference, which may refer either to a third-party platform or the cache of an embodiment. As part of the object loading process for retrieving an existing tile, the SDKs of an embodiment will retrieve the tile object metadata from the object application layer, which provides the integration object reference that defines the location of the tile’s referenced dataset. The SDKs of an embodiment will then engage the integration object reference to retrieve the tile’s dataset. Tile object metadata includes all necessary information for engagingATTORNEY DOCKET NO. PATENT APPLICATION 088835.0120 14 of 40 the integration object reference (for example, query, file path). When saving a tile, a client can either specify an integration object reference or can pass an in-memory data object along with an integration object reference that an SDK of an embodiment will automatically save the in- memory data object into (while retaining the integration object reference for object loading purposes). If no integration object reference is specified, the in-memory data object will be saved into the cache of an embodiment.

[0060] An edge is a reference to user-defined code. “Edge object metadata” provides all the information needed to retrieve and compile user-defined code. As part of the IAM framework of an embodiment, every edge is scoped to a project, and every project maps to a Git repository. Specifically, every project maps to: a Git “provider” (for example, GitHub, GitLab, etc.), a Git server (the network host for the remote Git server), a Git repository (the network path on the network host), an optional folder path (within the repository), a default Git branch, and an optional collection of additional branches that are permissible to be specified at the edge level. The SDKs of an embodiment will publish all user-defined code into the Git location that is specified at the level of the edge’s project (with the ability to pass an edge-level Git branch that overrides the project-level default branch, so long as the edge-level branch is in the collection of additional branches specified at the project level). Certain user-defined code (functions or classes) is categorized as “library” code, which the SDKs of an embodiment will auto-package into a library format that allows for the reusability of this code, inside or outside of an embodiment. Library code comprises both functions and class definitions. The SDKs of an embodiment provide “annotations” (also known as “decorators” or “wrappers”) that invoke the runtime language’s abstract syntax tree in order to “lint” the wrapped code, such that all necessary “imports” (or references to third-party library capabilities) can be captured (both in object metadata, and as part of automated requirements versioning that the SDKs of an embodiment publish into Git). The mechanics of the auto-packaging of library code are also defined at the project level, where the following parameters are implemented: install (or “package”) name, import (or “library”) name, and import namespace (or a module prefix for import name, for example, “company.data”). “Script” code (including script files, or “notebooks”) can also be captured by the SDK of an embodiment, and the contents of a script can similarly be linted, such that dependencies can be automatically recorded (but scripts are stored simply in a folder or folder-path, as opposed to in a format that allows for the importability offered by the library code). As part of the object loading process for retrieving an existing edge, the SDKs of an embodiment will retrieve the edge object metadata from theATTORNEY DOCKET NO. PATENT APPLICATION 088835.0120 15 of 40 object application layer, which provides the location in Git where the user-defined code is found. The SDKs of an embodiment will then retrieve said source code and will install the required dependencies, before attempting to compile the source code. An edge can also be created directly from Git by providing the SDKs of an embodiment with the location in which the target source code can be found. The SDKs will then retrieve the target source code, install any provided dependencies, and then engage the typical edge-construction process. An edge also offers macro-like capabilities that wrap or extend user-defined code in order to enhance or extend their behavior: “failure handling” is an optional edge object reference that, in the event of an error in an SDKs execution of an edge’s underlying user-defined code, will be passed the available state (including any available error object) such that the receiving edge can, for example, send a message to notify another system of the error (before the SDK of an embodiment raises an error), or continue on with trying to execute in a different branch of logic; “save to” is an optional integration object reference that provides a means to automatically save output from the edge into the specified data store; and “runtime” is an optional integration object reference corresponding to a particular context manager (for example, for a SQL database) that will be opened (and closed) around the body of the edge’s underlying user-defined code. An edge may reference other edges (or other objects of an embodiment) directly in the user-defined source code. If the wrapped user-defined code implements a function, the “signature” (input and output variables, with types) will be captured in object metadata. If the wrapped user-defined code implements a class, the signature for each method of the class will be captured in object metadata.

[0061] A model is a reference to a machine learning or time series model. “Model object metadata” includes: the software framework (for example, “Scikit-Learn”) used for providing the model mechanics, the version of said framework, and the module path to the particular class or API (for example, “sklearn.ensemble.RandomForestClassifier”) that was used to define the model; an optional collection of tile object references corresponding to one or more datasets that represent any internal, serialized state that has been generated as part of model training (for example, “weights”); an optional edge object reference corresponding to user-defined code used to define the model (for example, a “pipeline” that might implement a custom model ensemble or a particular training procedure); an optional integration object reference corresponding to a particular “runtime” that may be required for either model training or testing (for example, “Spark”); and, an optional reference to a freeloader model, or an auto-serialized representation of a model from the freeloader framework (a component of the SDKs of anATTORNEY DOCKET NO. PATENT APPLICATION 088835.0120 16 of 40 embodiment). As part of the object loading process for retrieving an existing model, the SDKs of an embodiment will retrieve the model object metadata from the object application layer. Any additional required object loading steps (for example, loading a tile holding a reference to the “weights”) will be automatically executed such that the requesting client is returned a complete in-memory representation of the original model, as it was defined.

[0062] A validator is a collection of object references to data (tiles) and / or user-defined code (edges), along with proprietary code provided by the SDKs of an embodiment, which aids in the systematic evaluation of a machine learning or time series model. “Validator object metadata” includes: the software framework (for example, “freeloader”) used for providing the validator mechanics, the version of said framework, and the module path to the particular class or API (for example, “freeloader.validator.Validator”) that was used to define the validator; one or more optional tile object references corresponding to datasets that used for training and testing models; one or more optional edge object references corresponding to user-defined code used generating or further-processing training and / or test data (for example, a “pipeline” that might transform in-sample training data to add additional features); an optional integration object reference corresponding to a particular “runtime” that may be required for either model training or testing (for example, “Spark”); additional metadata corresponding to the data and / or data-processing (for example, a particular column to use as the “target,” or whether to build features in-sample or globally); an optional edge object reference corresponding to a user- defined execution method; and, additional metadata specifying the nature of the “splitter” to be used for separating train and test data (software framework, framework version, and API module path). As part of the object loading process for retrieving an existing validator, the SDKs of an embodiment will retrieve the validator object metadata from the object application layer; any additional required object loading steps (for example, loading a tile holding a reference to the training data) will be automatically executed such that the requesting client is returned a complete in-memory representation of the original validator, as it was defined.

[0063] A mosaic is a collection of object references that form, along with proprietary code provided by the SDKs of an embodiment, reusable templates that can be easily deployed. “Mosaic object metadata” includes: an optional collection of tile object references corresponding to one or more datasets that can form the basis of a “tile server” or that can be passed into a referenced edge (that is, as the “root” of an execution pipeline); an optional edge object reference that can form the basis of an “edge server” or that can be executed as its own pipeline (for example, in the context of a “scheduled job”); an optional model object referenceATTORNEY DOCKET NO. PATENT APPLICATION 088835.0120 17 of 40 that can form the basis of an “inference server”; an optional validator object reference that can form the basis of a “validator server”; optional edge object references for pre- and post- processing of data that is to be passed into or returned from an API server; an optional integration object reference corresponding to an external platform that any mosaic logs should be sent to (along with additional parameters for shaping this behavior in more detail); an optional collection of mosaic object references corresponding to one or more mosaics that should be automatically triggered upon successful completion of the parent mosaic (for example, a scheduled job that prepares analytical data and then triggers the deployment of a tile server that depends on said data); “failure handling” is an optional edge object reference that, in the event of an error in an SDKs execution any mosaic logic (the object loading process, including for any reference objects; or, the execution of a referenced edge or model), will be passed the available state (including any available error object) such that the receiving edge can, for example, send a message to notify another system of the error (before the SDK of an embodiment raises an error), or continue on with trying to execute in a different branch of logic; “save to” is an optional integration object reference that allows for overriding or “currying” the “save to” behavior for a referenced edge; “runtime” is an optional integration object reference that allows for overriding or “currying” the “runtime to” behavior for a referenced edge or model. Mosaics fit easily into templated deployment options provided by an embodiment, but users can also leverage mosaics in user-defined images, leveraging them, essentially, for templated object-collection templating and convenient object loading, and, an optional validator object reference can be specified to allow for consistent and automated model validation (when deploying a model), along with associated metadata to define the validation (for example execution method).

[0064] 2.7 DEPLOYMENT TYPES

[0065] An embodiment provides a collection of “deployment types” that offer a simplified approach to engaging the deployment APIs. The deployment types make use of the mosaic construct to ensure consistent and secure object loading in the deployed context.

[0066] The “daemon” allows a user to deploy an edge (script) as a continually running process, for example, a “consumer” in a publisher / subscriber distributed messaging framework. The daemon allows users to implement event-based processes in an embodiment.

[0067] The “job” allows a user to deploy an edge (function, class, or script) as a batch process, which should have a defined start and end. A scheduled Job will run as per theATTORNEY DOCKET NO. PATENT APPLICATION 088835.0120 18 of 40 specified schedule; an unscheduled Job can be triggered to run over HTTP. Whether scheduled or not, a job can trigger other mosaics to run upon successful completion of the job.

[0068] Certain deployment types are “networked,” meaning an embodiment will automatically create the resources need to ensure a secure network path to the deployment; this includes providing a human-readable (and customizable) network path (for example, “customer. ml.io / production / my-server”) as well as a proxy-level security check that forces all inbound requests to the deployment to pass both authentication and authorization checks before they are allowed to continue onto the deployment itself. Networked deployments offer powerful interoperability, wherein different systems, regardless of their implementation, can easily communicate with each other.

[0069] The “edge server” is a networked deployment, allowing a user to deploy an edge (function or class) as an API server (serving HTTP or HTTP / 2). In the case of a function edge, the edge API server constructs a “handler” (a function that can receive network requests, mapped to a route on the server) around the edge, with programmatic inference of the edge’s signature in order to ensure reasonable handling of any inbound request data; for a class edge, the process is similar, albeit replicated for each “public” method of the class, where each public method is given its own route (and associated handler). Essentially, the edge server construct allows users to almost convert arbitrary user-defined code instantaneously into a secure, network-accessible server.

[0070] The “tile server” is a networked deployment, allowing a user to deploy one or more tiles (datasets) as an API server (serving HTTP or HTTP / 2). The SDKs of an embodiment offer client-side APIs that users can leverage to define calculations (including the identity function or returning the entire dataset) on any of the supplied tiles; put differently, the SDKs of an embodiment allow users to engage common, cross-platform data frameworks (that is, arrow, Spark, SQL) in order to structure queries that will then be mapped to routes on the server. For each defined calculation, the tile API server constructs a “handler” (a function that can receive network requests, mapped to a route on the server) for each tile-calculation pair. When an inbound request is received, the handler will invoke the corresponding calculation on the corresponding tile, along with any data included in the request (for example, values to filter a particular column against). The tile API server will conduct a programmatic inference of the supplied tile(s) in order to make automated (but overridable) specifications around the resources required to run the deployment.ATTORNEY DOCKET NO. PATENT APPLICATION 088835.0120 19 of 40

[0071] The “inference server” is a networked deployment, allowing a user to deploy a model as an API server (serving HTTP or HTTP / 2). Incoming requests are passed to the “predict” method (which can be customized on the model object) of the model object, with results returned over the network. An inference server can reference a validator (along with additional metadata) to automatically run a validation each time the inference server is launched.

[0072] The “validator server” is a networked deployment, allowing a user to deploy a validator as an API server (serving HTTP or HTTP / 2). Incoming requests include as data a model object reference and validation metadata (including the execution method); in each request, the model described by the model object reference is loaded, and the specified execution method is then called on the validator object, with the loaded model and any other validation metadata passed as inputs; the validation will be published into an internal database of an embodiment, with results (or a tile object reference, for large results) returned in the response.

[0073] An embodiment provides deployment types specifically tailored to commonly used, open-source “dashboarding” frameworks, like Plotly Dash or Streamlit. These dashboard deployment types are networked and take advantage of Edge Object References in order to create references to the specific areas of user-defined code that should be executed in order to ensure a running dashboard application.

[0074] The thus described deployment types run on proprietary images (included by default in an embodiment) that leverage the SDKs of an embodiment to meet the needs of a particular deployment type. An embodiment also provides custom deployment types for jobs, API servers, and web apps, which allow users to engage the deployment APIs along with user- supplied images (which a user can easily register as part of deployment metadata), to take advantage of deployment APIs of an embodiment but with total freedom to structure the nature of the logic within the underlying image.

[0075] 2.8 IDENTITY AND ACCESS MANAGEMENT

[0076] All resources of an embodiment (objects and deployments) are protected under the IAM framework of an embodiment, which ensures that only authenticated and permissioned users can access these objects. The IAM framework of an embodiment implements a hybrid approach of role-based access control (RBAC) and attribute-based access control (ABAC) and offers hierarchical access groups for easy permission or de-permission of identities to resources, at different levels of access. FIG. 2A and FIG. 2B illustrate an example overviewATTORNEY DOCKET NO. PATENT APPLICATION 088835.0120 20 of 40 for access controls: RBAC and network security middleware. The role-based access control (RBAC) and network security middleware models of an embodiment are visually depicted at a high level in FIG.2A and FIG.2B.

[0077] A tile, edge, model, validator, or mosaic (or deployment) is scoped to a “project”; each project is scoped to an “organization,” and each organization is scoped to an “account.” Integrations and deployment metadata offer more flexibility around the breadth of access scope; their unique natures dictate that organization- and account-level scoping be made possible (for example, a “default” image, to which all users at a given company should have access, should not have to be redefined in every project). As networked deployments are, by design, accessible over HTTP or HTTP / 2, being able to provide gated access to external users and systems is important. More details follow, but networked deployments offer a unique circumstance wherein access can be provided at a more granular level than that of a project.

[0078] The IAM framework of an embodiment implements a middleware-based approach to authentication and authorization challenges, with the “IAM server” serving as a federated IAM provider that exposes network interfaces for executing authentication and authorization challenges.

[0079] An “identity” corresponds to a user, deployment, a platform component, or an external user or system. Each identity in an embodiment is represented by its own unique line item in an internal database of the embodiment.

[0080] Every route in the IAM server of an embodiment is protected by an authentication challenge, wherein a passed cookie or “access token” must be able to be resolved to a particular identity (scoped to a particular account). If an authentication challenge succeeds, the identity and account corresponding to the passed credentials are retained for use in subsequent steps in the request flow (for example, in authorization checks where the application processes request 218). If an authentication challenge fails 220a, the IAM server of an embodiment immediately responds with a 401 HTTP error 222. Routes in the IAM server of an embodiment are also protected by middleware-level authorization challenges. In other words, once a request 210 has passed the authentication challenge, it will have to pass an authorization challenge. If an authorization challenge fails 220b, the IAM server of an embodiment immediately responds with a 403 HTTP error 224.

[0081] An embodiment generates access tokens (“access token”) that allow for securely authenticating to the platform. An access token is an encrypted string containing a unique identifier as well as a secret value. Each access token is represented by its own record in theATTORNEY DOCKET NO. PATENT APPLICATION 088835.0120 21 of 40 database, where: the unique identifier servers as the primary key for the table, the secret value is stored hashed, an optional expiry timestamp can be set, and every row has a foreign-key reference to an identity (that is, each token must map to a real identity). An access token should be passed as a bearer token in the authorization header. In the event of an authentication challenge, the IAM server of an embodiment will first attempt to decrypt the passed value. If that succeeds, the IAM server of an embodiment will then: separate the token into identifier and secret, hash the secret, attempt to look up the identifier in the database, confirm the hashed secret matches the value in the database, and confirm whether the token has expired (if an expiry has been set). If all of these steps succeed, authentication is deemed successful, and metadata for the matching identity is stored in the request. Otherwise, a 401 HTTP error is returned. Database persistence of access tokens provides benefits over, for example, a “JSON web token” approach, including that access tokens are able to be easily audited and deleted.

[0082] The IAM server of an embodiment implements network interfaces that allow other components of the platform (like the object and deployment application layers) to execute authorization challenges via HTTP. For example, the route (which is protected by an authentication challenge) “ / authorization / organization / {organization} / project / {project}” will confirm whether the authenticated identity has been given access to the specified organization 204 and project 206, with the requested level of access being specified as a query parameter. This implementation enables a robust implementation of the zero trust security paradigm, where every request (whether from an SDK of an embodiment, CLI, or GUI) to any component of the platform (including platform internals, as well as networked deployments) must provide valid authentication credentials, and that the authenticated Identity must be explicitly permissioned to the target resource, and with the requisite level of access for the specified action.

[0083] An “access level” corresponds to one or more permissible actions. The available access levels can be well-approximated through the following list: “ADMIN”, “DELETE”, “WRITE”, “READ, “REQUEST”, “DEPLOY”, “MEMBER”, “METADATA”, “REGISTERED”, “CONFIG_WRITE”, “CONFIG_READ”, “BILLING”. Some access levels map conveniently to HTTP verbs. For example, a GET request often requires READ access to execute, while a PUT request often requires WRITE access. However, the resource in question ultimately ties into the necessary access level; for example, any POST or PUT on an identity action (for example, adding a user to a project 206) requires ADMIN access to the resource in question.ATTORNEY DOCKET NO. PATENT APPLICATION 088835.0120 22 of 40

[0084] From an IAM perspective, a “resource” is one of: account 202, organization 204, project 206, or deployment. A “permission” is a tuple of the form: (resource, access level). Permissions can be granted hierarchically. For example, a user granted the ability to create objects in a given organization 204 can create objects 208 in any of the projects 206 scoped to that organization 204.

[0085] Some access levels are allowed to be evaluated hierarchically, with respect to the resource. For example, in the aforementioned example, an identity being granted WRITE access to a given organization 204 also means that the identity is able to pass challenges for WRITE access to any project 206 within that organization 204. However, other access levels do not allow for being evaluated hierarchically, with respect to the resource. For example, CONFIG access (which pertains to deployment metadata) being granted at the level of the account 202 does not mean that CONFIG access has been granted at the level of any organization 204 within the account 202.

[0086] Additionally, some access levels include other access levels, that is, they are hierarchical with respect to the level. Table 1 details, for each access level, whether it is hierarchical with respect to the resource, as well as the set of access levels that are included by each access level, and Table 2 provides a description for each access level. HierarchicalATTORNEY DOCKET NO. PATENT APPLICATION 088835.0120 23 of 40 METADATA FALSE METADATA, CONFIG_READ, REGISTEREDAccess Level Description (Refer to Table 1 for Included Levels) d a a

[0087] The IAM framework of an embodiment adheres to the least-privilege security paradigm. For example, as is detailed in Table 1 and Table 2, the IAM framework of an embodiment provides a number of access levels (a set that may expand further over time) to allow for offering granular access, to offer controls for both internal platform activity as well as the selective sharing of resources with external users and systems. The REQUEST andATTORNEY DOCKET NO. PATENT APPLICATION 088835.0120 24 of 40 DEPLOY levels exist to allow external users and systems the ability to, respectively, make network requests to a networked deployment (without other platform access being provided), and make network requests to a specific endpoint in the deployment application layer that allows for redeploying an existing deployment. An example, for REQUEST access: sharing with a developer (who is not a user) access to a particular tile server. In other words, the developer is essentially given read-only access to a query (or collection of queries) without being granted direct access to the underlying data itself (for example, in the case that only aggregated or anonymized data can be shared). An example, for DEPLOY access: allowing a “CI” system (like GitHub actions) to automatically trigger a redeploy of an existing deployment, via a network request to the deployment application layer, whenever a particular area of a codebase has been modified. Thus, the IAM framework of an embodiment can offer exactly the minimum level of access required to engage with a deployment in particular ways, while still ensuring that no direct access to the resources underlying the deployment is provided.

[0088] Additionally, the IAM framework of an embodiment ensures that deployments themselves are granted only the minimum required access to the resources they need to run. This is achieved through inspection of the mosaic, that is, the collection of object references that are needed to execute the desired actions within the deployed context.

[0089] When an SDK of an embodiment is engaged to create a deployment, the SDK of an embodiment will walk the object tree of the to-be-deployed mosaic, noting the project of each reference object (excluding other Mosaics that are to be triggered); WRITE access will be requested for each such project (including the project that the mosaic itself resides in). Additionally, the library requirements for each reference object (as well as for the mosaic itself) will be recursively scanned, in the event that there is upstream code corresponding to one or more objects that may not be directly referenced on the in-memory mosaic or any of its children; as a consequence of a rigorous and referential database model, the deployment application layer is able to map a reference to a Git-based package dependencies to a corresponding project, if there is one; READ access will be requested for any project that the mosaic will need to be able to retrieve the source code for. Finally, for any other mosaic that is to be triggered upon completion of the parent mosaic, DEPLOY access will be requested for its project.

[0090] The set of access tuples of the form (project, access level) is the “mosaic deployment permission set” and the deployment application layer will ensure that the mosaic’sATTORNEY DOCKET NO. PATENT APPLICATION 088835.0120 25 of 40 developer (that is the identity who has engaged the deployment application layer in order to create the deployment) has been granted an equivalent or greater access level to each of the requested projects, otherwise the entire database transaction for deployment creation will fail, with the deployment application layer returning a 403.

[0091] As part of the deployment creation process (and under a database transaction), the deployment application layer will engage the IAM server of an embodiment in order to programmatically create a unique identity (“deployment identity”) that will be linked to the deployment in question (“deployment identity”); in the event that a deployment already exists, the existing deployment identity will be reused, however all permissions that the deployment identity had previously granted are removed. As previously described, the deployment application layer will attempt to grant the deployment identity access to the mosaic deployment permission set. For each deployment identity, the identity server of an embodiment will generate an access token (for which expiry can be controlled), which allows the deployment to communicate with the object application layer (or other parts of an embodiment) as needed. Any time the deployment is recreated, its existing access token is revoked and a new token is issued.

[0092] Under a database transaction, the deployment application layer will also engage the IAM server of an embodiment in order to programmatically generate a set of permissions that can be granted to other identities in order to allow for external users and systems to make network requests to the deployment (if it is networked), and make network requests to a specific endpoint in the deployment application layer that will allow for redeploying the existing deployment.

[0093] Once a networked deployment has been created, permissioned users are able to generate access tokens to be used in authentication and authorization challenges in the course of interacting with a networked deployment. In the case of an API server, the IAM server of an embodiment generates access tokens that can be used by external clients in order to connect with deployed mosaics; for each token that is generated, the IAM server of an embodiment generates a unique identity that is linked to the token, and this identity is granted REQUEST access to the particular deployment; in the case of a DEPLOY token, the process is identical, save for the access level. For dashboards, some extra steps provide additional convenience and security. Firstly, a user cannot directly generate an access token for a dashboard. Instead, for a dashboard, the IAM server of an embodiment will return a link to a particular route on the IAM server, for example, “https: / / company.ml.io / dashboard-access?token=$SECRET”; the “token”ATTORNEY DOCKET NO. PATENT APPLICATION 088835.0120 26 of 40 embedded in this link is actually a form that will be used to initiate a secure redirect to the target dashboard, the first time it is used. This process offers two key benefits: each link can only be used once, which adds important security given that dashboard links are often shared with non-technical users over insecure communication channels; and, in the secure redirect flow, a secure cookie is set in the dashboard-viewer’s browser, allowing for convenient browser-based security flows to take place. Access tokens to groups of deployments (for example, all deployments in a project) will be offered as well.

[0094] The IAM server’s implementation means that authentication and authorization challenges can be automatically deployed in front of any networked mosaic, at the proxy level, as part of the deployment process. For example, the routing specification (auto-generated by the deployment application layer) for a dashboard named “analytics” in the project “production” and organization “credit” would include a line item indicating that all inbound requests will be forced into making the following, intermediary request: GET “ / authorization / mosaics / credit / production / analytics?access_level=REQUEST”. In other words, there is an automatic redirect into the IAM server of an embodiment, ensuring that all networked deployments, regardless of their underlying implementations, are protected by robust authentication and authorization challenges, where only those requests earning a 200 from the intermediary request will be allowed by the reverse-proxy server to proceed on to the dashboard.

[0095] 2.9 FUNCTIONAL FLOW

[0096] FIG. 4 illustrates a computer-implemented process of automated deployments, in one embodiment. FIG. 4 and each other flow diagram herein is intended as an illustration at the functional level at which skilled persons in the art to which this disclosure pertains communicate with one another to describe and implement algorithms using programming. The flow diagrams are not intended to illustrate every instruction, method object, or sub-step that would be needed to program every aspect of a working program, but are provided at the same functional level of illustration that is normally used at the high level of skill in this art to communicate the basis of developing working programs.

[0097] At step 402 of FIG. 4, in an embodiment, an API server may receive, via one or more APIs, a request from a client machine for deployment on one or more target resources. At step 404, the API server may determine deployment metadata associated with the request. At step 406, the API server may validate the deployment metadata. At step 408, the API server may automatically structure the deployment metadata in a format suitable for the targetATTORNEY DOCKET NO. PATENT APPLICATION 088835.0120 27 of 40 resources. At step 410, the API server may transmit the structured deployment metadata to the target resources for deployment.

[0098] 3. IMPLEMENTATION EXAMPLE – HARDWARE OVERVIEW

[0099] FIG. 5 is a block diagram that illustrates an example computer system with which an embodiment may be implemented. In the example of FIG. 5, a computer system 500 and instructions for implementing the disclosed technologies in hardware, software, or a combination of hardware and software, are represented schematically, for example as boxes and circles, at the same level of detail that is commonly used by persons of ordinary skill in the art to which this disclosure pertains for communicating about computer architecture and computer systems implementations.

[0100] Computer system 500 includes an input / output (I / O) subsystem 502, which may include a bus and / or other communication mechanisms for communicating information and / or instructions between the components of the computer system 500 over electronic signal paths. The I / O subsystem 502 may include an I / O controller, a memory controller, and at least one I / O port. The electronic signal paths are represented schematically in the drawings, for example, as lines, unidirectional arrows, or bidirectional arrows.

[0101] At least one hardware processor 504 is coupled to the I / O subsystem 502 for processing information and instructions. Hardware processor 504 may include, for example, a general-purpose microprocessor or microcontroller and / or a special-purpose microprocessor such as an embedded system or a graphics processing unit (GPU) or a digital signal processor or an ARM processor. Processor 504 may comprise an integrated arithmetic logic unit (ALU) or may be coupled to a separate ALU.

[0102] Computer system 500 includes one or more units of memory 506, such as a main memory, which is coupled to I / O subsystem 502 for electronically storing data and instructions to be executed by processor 504. Memory 506 may include volatile memory such as various forms of random-access memory (RAM) or another dynamic storage device. Memory 506 may also be used for storing temporary variables or other intermediate information during the execution of instructions to be executed by processor 504. Such instructions, when stored in non-transitory computer-readable storage media accessible to processor 504, can render computer system 500 into a special-purpose machine that is customized to perform the operations specified in the instructions.

[0103] Computer system 500 further includes non-volatile memory such as read-only memory (ROM) 508 or other static storage devices coupled to I / O subsystem 502 for storingATTORNEY DOCKET NO. PATENT APPLICATION 088835.0120 28 of 40 information and instructions for processor 504. The ROM 508 may include various forms of programmable ROM (PROM) such as erasable PROM (EPROM) or electrically erasable PROM (EEPROM). A unit of persistent storage 510 may include various forms of non-volatile RAM (NVRAM), such as FLASH memory, or solid-state storage, magnetic disk or optical disks such as CD-ROM or DVD-ROM and may be coupled to I / O subsystem 502 for storing information and instructions. Storage 510 is an example of a non-transitory computer-readable medium that may be used to store instructions and data, which, when executed by the processor 504, cause the execution of computer-implemented methods to execute the techniques herein.

[0104] The instructions in memory 506, ROM 508 or storage 510 may comprise one or more sets of instructions that are organized as modules, methods, objects, functions, routines, or calls. The instructions may be organized as one or more computer programs, operating system services, or application programs, including mobile apps. The instructions may comprise an operating system and / or system software; one or more libraries to support multimedia, programming, or other functions; data protocol instructions or stacks to implement TCP / IP, HTTP, or other communication protocols; file format processing instructions to parse or render files coded using HTML, XML, JPEG, MPEG or PNG; user interface instructions to render or interpret commands for a graphical user interface (GUI), command-line interface or text user interface; application software such as an office suite, internet access applications, design and manufacturing applications, graphics applications, audio applications, software engineering applications, educational applications, games or miscellaneous applications. The instructions may implement a web server, web application server, or web client. The instructions may be organized as a presentation layer, application layer, and data storage layer, such as a relational database system using a structured query language (SQL) or NoSQL, an object store, a graph database, a flat-file system, or other data storage.

[0105] Computer system 500 may be coupled via I / O subsystem 502 to at least one output device 512. In one embodiment, output device 512 is a digital computer display. Examples of a display that may be used in various embodiments include a touch screen display, a light- emitting diode (LED) display, a liquid crystal display (LCD), or an e-paper display. Computer system 500 may include another type (s) of output devices 512, alternatively or in addition to a display device. Examples of other output devices 512 include printers, ticket printers, plotters, projectors, sound cards or video cards, speakers, buzzers or piezoelectric devices or other audible devices, lamps or LED or LCD indicators, haptic devices, actuators, or servos.ATTORNEY DOCKET NO. PATENT APPLICATION 088835.0120 29 of 40

[0106] At least one input device 514 is coupled to the I / O subsystem 502 for communicating signals, data, command selections, or gestures to the processor 504. Examples of input devices 514 include touch screens, microphones, still and video digital cameras, alphanumeric and other keys, keypads, keyboards, graphics tablets, image scanners, joysticks, clocks, switches, buttons, dials, slides, and / or various types of sensors such as force sensors, motion sensors, heat sensors, accelerometers, gyroscopes, and inertial measurement unit (IMU) sensors and / or various types of transceivers such as wireless, such as cellular or Wi-Fi, radio frequency (RF) or infrared (IR) transceivers and Global Positioning System (GPS) transceivers.

[0107] Another type of input device is a control device 516, which may perform cursor control or other automated control functions such as navigation in a graphical interface on a display screen, alternatively or in addition to input functions. Control device 516 may be a touchpad, a mouse, a trackball, or cursor direction keys for communicating direction information and command selections to processor 504 and for controlling cursor movement on display 512. The input device may have at least two degrees of freedom in two axes, a first axis (for example, x) and a second axis (for example, y), that allows the device to specify positions in a plane. Another type of input device is a wired, wireless, or optical control device such as a joystick, wand, console, steering wheel, pedal, gearshift mechanism, or another type of control device. An input device 514 may include a combination of multiple different input devices, such as a video camera and a depth sensor.

[0108] In another embodiment, computer system 500 may comprise an Internet of Things (IoT) device in which one or more of the output device 512, input device 514, and control device 516 are omitted. Or, in such an embodiment, the input device 514 may comprise one or more cameras, motion detectors, thermometers, microphones, seismic detectors, other sensors or detectors, measurement devices or encoders and the output device 512 may comprise a special-purpose display such as a single-line LED or LCD display, one or more indicators, a display panel, a meter, a valve, a solenoid, an actuator or a servo.

[0109] When computer system 500 is a mobile computing device, input device 514 may comprise a global positioning system (GPS) receiver coupled to a GPS module that is capable of triangulating to a plurality of GPS satellites, determining and generating geo-location or position data such as latitude-longitude values for a geophysical location of the computer system 500. Output device 512 may include hardware, software, firmware, and interfaces for generating position reporting packets, notifications, pulse or heartbeat signals, or otherATTORNEY DOCKET NO. PATENT APPLICATION 088835.0120 30 of 40 recurring data transmissions that specify a position of the computer system 500, alone or in combination with other application-specific data, directed toward host 524 or server 530.

[0110] Computer system 500 may implement the techniques described herein using customized hard-wired logic, at least one ASIC or FPGA, firmware, and / or program instructions or logic that, when loaded and used or executed in combination with the computer system, cause or program the computer system to operate as a special-purpose machine. According to one embodiment, the techniques herein are performed by computer system 500 in response to processor 504 executing at least one sequence of at least one instruction contained in main memory 506. Such instructions may be read into main memory 506 from another storage medium, such as storage 510. Execution of the sequences of instructions contained in main memory 506 causes processor 504 to perform the process steps described herein. In alternative embodiments, hard-wired circuitry may be used in place of or in combination with software instructions.

[0111] The term “storage media” as used herein refers to any non-transitory media that store data and / or instructions that cause a machine to operate in a specific fashion. Such storage media may comprise non-volatile media and / or volatile media. Non-volatile media include, for example, optical or magnetic disks, such as storage 510. Volatile media include dynamic memory, such as memory 506. Common forms of storage media include, for example, a hard disk, solid-state drive, flash drive, magnetic data storage medium, any optical or physical data storage medium, memory chip, or the like.

[0112] Storage media is distinct from but may be used in conjunction with transmission media. Transmission media participate in transferring information between storage media. For example, transmission media include coaxial cables, copper wire and fiber optics, including the wires that comprise a bus of the I / O subsystem 502. Transmission media can also take the form of acoustic or light waves, such as those generated during radio-wave and infrared data communications.

[0113] Various forms of media may be involved in carrying at least one sequence of at least one instruction to processor 504 for execution. For example, the instructions may initially be carried on a magnetic disk or solid-state drive of a remote computer. The remote computer can load the instructions into its dynamic memory and send the instructions over a communication link such as a fiber optic or coaxial cable or telephone line using a modem. A modem or router local to computer system 500 can receive the data on the communication link and convert the data to a format that can be read by computer system 500. For instance, aATTORNEY DOCKET NO. PATENT APPLICATION 088835.0120 31 of 40 receiver such as a radio frequency antenna or an infrared detector can receive the data carried in a wireless or optical signal and appropriate circuitry can provide the data to the I / O subsystem 502 and place the data on a bus. I / O subsystem 502 carries the data to memory 506, from which processor 504 retrieves and executes the instructions. The instructions received by memory 506 may optionally be stored on storage 510 either before or after execution by processor 504.

[0114] Computer system 500 also includes a communication interface 518 coupled to bus 502. Communication interface 518 provides a two-way data communication coupling to a network link(s) 520 that are directly or indirectly connected to at least one communication network, such as a network 522 or a public or private cloud on the Internet. For example, communication interface 518 may be an Ethernet networking interface, integrated-services digital network (ISDN) card, cable modem, satellite modem, or a modem to provide a data communication connection to a corresponding type of communications line, for example, an Ethernet cable or a metal cable of any kind or a fiber-optic line or a telephone line. Network 522 broadly represents a local area network (LAN), wide-area network (WAN), campus network, internetwork, or any combination thereof. Communication interface 518 may comprise a LAN card to provide a data communication connection to a compatible LAN or a cellular radiotelephone interface that is wired to send or receive cellular data according to cellular radiotelephone wireless networking standards, or a satellite radio interface that is wired to send or receive digital data according to satellite wireless networking standards. In any such implementation, communication interface 518 sends and receives electrical, electromagnetic, or optical signals over signal paths that carry digital data streams representing various types of information.

[0115] Network link 520 typically provides electrical, electromagnetic, or optical data communication directly or through at least one network to other data devices, using, for example, satellite, cellular, Wi-Fi, or BLUETOOTH technology. For example, network link 520 may provide a connection through network 522 to a host computer 524.

[0116] Furthermore, network link 520 may provide a connection through network 522 or to other computing devices via internetworking devices and / or computers that are operated by an Internet Service Provider (ISP) 526. ISP 526 provides data communication services through a worldwide packet data communication network represented as internet 528. A server computer 530 may be coupled to internet 528. Server 530 broadly represents any computer, data center, virtual machine, or virtual computing instance with or without a hypervisor, orATTORNEY DOCKET NO. PATENT APPLICATION 088835.0120 32 of 40 computer executing a containerized program system such as DOCKER or KUBERNETES. Server 530 may represent an electronic digital service that is implemented using more than one computer or instance and that is accessed and used by transmitting web services requests, uniform resource locator (URL) strings with parameters in HTTP payloads, API calls, app services calls, or other service calls. Computer system 500 and server 530 may form elements of a distributed computing system that includes other computers, a processing cluster, server farm, or other organization of computers that cooperate to perform tasks or execute applications or services. Server 530 may comprise one or more sets of instructions that are organized as modules, methods, objects, functions, routines, or calls. The instructions may be organized as one or more computer programs, operating system services, or application programs including mobile apps. The instructions may comprise an operating system and / or system software; one or more libraries to support multimedia, programming, or other functions; data protocol instructions or stacks to implement TCP / IP, HTTP, or other communication protocols; file format processing instructions to parse or render files coded using HTML, XML, JPEG, MPEG or PNG; user interface instructions to render or interpret commands for a graphical user interface (GUI), command-line interface or text user interface; application software such as an office suite, internet access applications, design and manufacturing applications, graphics applications, audio applications, software engineering applications, educational applications, games or miscellaneous applications. Server 530 may comprise a web application server that hosts a presentation layer, application layer, and data storage layer such as a relational database system using a structured query language (SQL) or no SQL, an object store, a graph database, a flat-file system or other data storage.

[0117] Computer system 500 can send messages and receive data and instructions, including program code, through the network(s), network link 520 and communication interface 518. In the Internet example, a server 530 might transmit a requested code for an application program through Internet 528, ISP 526, local network 522 and communication interface 518. The received code may be executed by processor 504 as it is received, and / or stored in storage 510, or other non-volatile storage for later execution.

[0118] The execution of instructions as described in this section may implement a process in the form of an instance of a computer program that is being executed and consisting of program code and its current activity. Depending on the operating system (OS), a process may be made up of multiple threads of execution that execute instructions concurrently. In this context, a computer program is a passive collection of instructions, while a process may be theATTORNEY DOCKET NO. PATENT APPLICATION 088835.0120 33 of 40 actual execution of those instructions. Several processes may be associated with the same program; for example, opening up several instances of the same program often means more than one process is being executed. Multitasking may be implemented to allow multiple processes to share processor 504. While each processor 504 or core of the processor executes a single task at a time, computer system 500 may be programmed to implement multitasking to allow each processor to switch between tasks that are being executed without having to wait for each task to finish. In an embodiment, switches may be performed when tasks perform input / output operations when a task indicates that it can be switched, or on hardware interrupts. Time-sharing may be implemented to allow fast response for interactive user applications by rapidly performing context switches to provide the appearance of concurrent execution of multiple processes simultaneously. In an embodiment, for security and reliability, an operating system may prevent direct communication between independent processes, providing strictly mediated and controlled inter-process communication functionality.

[0119] In the foregoing specification, embodiments of the invention have been described with reference to numerous specific details that may vary from implementation to implementation. The specification and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive sense. The sole and exclusive indicator of the scope of the invention, and what is intended by the applicants to be the scope of the invention, is the literal and equivalent scope of the set of claims that issue from this application, in the specific form in which such claims issue, including any subsequent correction. ________________________________________________

Claims

ATTORNEY DOCKET NO. PATENT APPLICATION 088835.0120 34 of 40 CLAIMS What is claimed is:

1. A computer-implemented method of automated computer program application deployment comprising: using a server computing process, receiving, via one or more deployment application programming interfaces (APIs) of a software deployment application layer, one or more deployment object creation requests from a client machine to create and store a programmatic deployment object corresponding to a deployment of any of a daemon, job, server, or web application on one or more target compute resources that are logically separate from the server computer; in response to the one or more deployment object creation requests, creating and storing the deployment object in a storage device accessible to the server computing process, in association with deployment metadata, wherein the deployment object is serializable and deserializable; using the server computing process, receiving, via the one or more deployment APIs, a deployment request from the client machine for the deployment of any of the daemon, job, server, or web application on the one or more target compute resources, wherein the deployment request references an object name of the programmatic deployment object and an access token; using the server computing process, programmatically resolving the access token to a particular identity and determining that the deployment metadata is accessible to the particular identity; using the server computing process, importing, using a database model of the deployment application layer, the deployment metadata from the storage device; using the server computing process, programmatically validating the deployment metadata; using the server computing process, programmatically structuring the deployment metadata in one or more formats suitable for the respective target resources; and using the server computing process, transmitting the structured deployment metadata to the target compute resources in the respective formats for deployment.ATTORNEY DOCKET NO. PATENT APPLICATION 088835.0120 35 of 40 2. The computer-implemented method of claim 1, wherein the deployment application layer executes between the client machine and the target compute resources, the target compute resources comprising an orchestration framework, the deployment application layer comprising the database model and database API server that together: accept input from the deployment APIs; validate and sanitize the deployment metadata; automatically structure the deployment metadata in a format of the orchestration framework; assign a least-privilege identity to the deployment object.

3. The computer-implemented method of claim 1, further comprising: using the server computing process and the deployment application layer, receiving a query from the client device to query one or more available deployments over HTTP; responding to the query by providing CLI and GUI programmatic and graphic interfaces to query the available deployments.

4. The computer-implemented method of claim 1, further comprising, using the server computing process and the deployment application layer, controlling one or more deployment actions associated with the deployment in each target resource using one or more access controls and a respective deployment identity of each target resource.

5. The computer-implemented method of claim 1, further comprising: a deployment API submitting a request through the deployment application layer to create or recreate a deployment; in response thereto, the deployment application layer creating formatted deployment metadata with any secrets redacted and returning the formatted deployment metadata with any secrets redacted to the deployment API.

6. The computer-implemented method of claim 1, the deployment APIs comprising network endpoints configured to serve HTTP and / or HTTP / 2 access to the deployment application layer.

7. The computer-implemented method of Claim 1, further comprising automatically calling the deployment application layer in response to one or more externalATTORNEY DOCKET NO. PATENT APPLICATION 088835.0120 36 of 40 events comprising one or more of an interaction from a dashboard executing on the client machine or a commit to a remote repository.

8. The computer-implemented method of claim 1, further comprising: receiving a graphical command from a graphic user interface (GUI) to visually structure and edit the deployment metadata; and structuring and editing the deployment metadata according to the graphical command.

9. The computer-implemented method of claim 1, further comprising generating and transmitting rendering instructions for a graphical user interface (GUI) to the client machine, the graphical user interface comprising a graph-based auditing interface that displays relationships among the deployments and associated objects.

10. The computer-implemented method of claim 1, wherein the deployment metadata comprises a reusable programmatic object having an image metadata name and having as attributes an image name, tag or version identifier, hardware profile, and one or more container arguments.

11. The computer-implemented method of claim 13, wherein the deployment metadata further comprises one or more crontab schedules and one or more security contexts.

12. The computer-implemented method of claim 1, the deployment request further referencing reference objects comprising one or more of a data integration, a dataset, a function, a tile, an edge, a validator, a mosaic, or a machine learning model.

13. The computer-implemented method of Claim 12, further comprising the deployment application layer receiving from a deployment API an object saving request to persistently store a specified programmatic first object, and in response thereto: serializing all metadata of the object into a network-transmissible data format; recursively converting each in-memory object referenced in the first object into an object reference or into a subset of object metadata that can reconstruct the referenced in- memory object by:ATTORNEY DOCKET NO. PATENT APPLICATION 088835.0120 37 of 40 retrieving via a metadata server an object metadata corresponding to the referenced in-memory object; retrieving via a third-party data store or a tile store one or more items of object data the referenced in-memory object relies on; automatically retrieving, from a source code repository, any object code that the referenced in-memory object relies on and importing the object code into a running process.

14. The computer-implemented method of claim 13, wherein the network- transmissable data format is JSON or Protobuf.

15. The computer-implemented method of claim 13, wherein retrieving via the metadata server comprises: checking whether any of the object references refer to objects that have been scoped to a different access group, and in response, performing one or more additional access checks to verify that an identity that made the request has one or more necessary permissions across a union of access groups of a parent object and any object references; resolving the object references to their primary key identifiers or to one or more unique identifiers in a metadata database that correspond to that particular object; and saving the parent object into the metadata database with any foreign-key references for the parent object’s reference objects.

16. The computer-implemented method of claim 12, further comprising the deployment application layer receiving from a deployment API an object loading request to load a specified programmatic first object, and in response thereto: retrieving object data from an integrated third-party data store or system cache and storing the object data as local object data; fetching object metadata from a metadata database and storing the object metadata as local object metadata; collecting collects user-defined code and dependency records from a source code repository; installing one or more dependencies according to the dependency records; compiling the user-defined code and the one or more dependencies;ATTORNEY DOCKET NO. PATENT APPLICATION 088835.0120 38 of 40 converting the local object metadata, local object data, and user-defined code into a single in-memory system object.

17. The computer-implemented method of claim 12, further comprising the deployment application layer performing: using the metadata server: sanitizing incoming payload data or query parameters; verifying that a requesting identity has permission to access the parent object by checking permissions of the requesting entity across a union of access groups of the parent object and any object references; resolving one or more foreign-key object references into a full set of object metadata for each object reference; returning a graph comprising complete object metadata for the requested object.

18. The computer-implemented method of claim 1, the deployment comprising one or more of a daemon deployment configured for continuous execution; a job-based deployment configured for batch processing; a networked deployment generating secure network paths and human-readable endpoints; an edge server deployment providing API-based function hosting; a tile server deployment serving datasets via an API; an inference server deployment hosting models for API-based access; or a validator server deployment configured for validation services via an API.

19. One or more non-transitory computer-readable storage media storing one or more sequences of instructions which, when executed using one or more processors of a computer system executing a deployment application layer, cause the computer system to execute the computer-implemented methods of any of claims 1 to 18.

20. A computer system, comprising: one or more processors; one or more non-transitory computer-readable storage media that are communicatively coupled to the one or more processors and storing one or more sequences of instructions which,ATTORNEY DOCKET NO. PATENT APPLICATION 088835.0120 39 of 40 when executed using a deployment application layer, cause the one or more processors to execute the computer-implemented methods of any of claims 1 to 18.

Images