US20180173526A1 - Application lifecycle management system - Google Patents
Application lifecycle management system Download PDFInfo
- Publication number
- US20180173526A1 US20180173526A1 US15/385,171 US201615385171A US2018173526A1 US 20180173526 A1 US20180173526 A1 US 20180173526A1 US 201615385171 A US201615385171 A US 201615385171A US 2018173526 A1 US2018173526 A1 US 2018173526A1
- Authority
- US
- United States
- Prior art keywords
- automation
- user
- guest
- virtual machine
- graph
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/60—Software deployment
- G06F8/61—Installation
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/70—Software maintenance or management
- G06F8/77—Software metrics
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
- G06F9/45533—Hypervisors; Virtual machine monitors
- G06F9/45558—Hypervisor-specific management and integration aspects
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/70—Software maintenance or management
- G06F8/71—Version control; Configuration management
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
- G06F9/45533—Hypervisors; Virtual machine monitors
- G06F9/45545—Guest-host, i.e. hypervisor is an application program itself, e.g. VirtualBox
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
- G06F9/45533—Hypervisors; Virtual machine monitors
- G06F9/45558—Hypervisor-specific management and integration aspects
- G06F2009/45562—Creating, deleting, cloning virtual machine instances
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
- G06F9/45533—Hypervisors; Virtual machine monitors
- G06F9/45558—Hypervisor-specific management and integration aspects
- G06F2009/4557—Distribution of virtual machine instances; Migration and load balancing
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
- G06F9/45533—Hypervisors; Virtual machine monitors
- G06F9/45558—Hypervisor-specific management and integration aspects
- G06F2009/45575—Starting, stopping, suspending or resuming virtual machine instances
Definitions
- the present disclosure is directed to a computerized method and system for automating actions specified by a user to configure and provision simple or complex applications in a well-defined and orchestrated sequence or a managed sequence of steps on a distributed system of virtual machines and networks in a cloud environment, and in addition, for enabling automated failure monitoring and mitigating actions specified by a user to be automatically performed in the event of a failure on the guest system.
- Software-based services can be offered to users through the use of virtual machines provided on a cloud.
- a user through a web client can access the cloud via the Internet, and request these software-based services provided through the execution of an application(s) on a virtual machine(s).
- applications become increasingly complex requiring more processing power and memory, it becomes more problematic when the components of such applications are distributed across different virtual machines in a guest system and/or a failure or other issues occur in the provision of these applications to a user.
- the configuration and launch of such complex distributed systems is quite involved; the virtual networks, virtual machines instances and the applications themselves needed to be correctly configured and launched in a precise and coordinated series of steps.
- An application failure or other failure may result in the termination of the application executing on virtual machine(s) of a guest system. In such a case, an administrator may need to expend significant resources, including time, to identify the causes for such a failure after the fact.
- the failure is not only frustrating to the end user, but may also result in the loss of productivity and data.
- a computerized method and system which enable a user to define automation actions and causal relationships between the automation actions to derive an automation graph(s) associated with an execution of an application.
- the virtual machine When a guest system and its virtual machine(s) are launched to implement the application, the virtual machine is configured to automatically implement the actions defined or specified by the user (also referred to as “user-defined automation actions”) via a guest agent on the virtual machine according to the automation graph over a lifecycle of the virtual machine of guest system.
- user-defined automation actions also referred to as “user-defined automation actions”
- a computer-implemented method, computer system and a tangible memory medium with executable code are provided to automate actions for one or more applications executed via a platform using at least one virtual machine in a guest system.
- Each virtual machine includes a guest operating system, a guest agent and an application to be executed on the virtual machine.
- the computer-implemented method, computer system and tangible memory medium are configured to implement the operations of: storing in a memory user-defined automation actions and causal relationships between the user-defined automation actions from which an automation graph is derived for the application to be executed on the virtual machine on the guest system; launching the guest system and the virtual machine via the platform; and executing the user-defined automation actions via the guest agent of the virtual machine according to the automation graph after the guest system and the virtual machine are launched.
- the platform can be implemented on a cloud computing architecture.
- the guest system and the virtual machine are launched by the platform in response to a request sent over the Internet (e.g., via a web browser).
- the platform can execute for the guest system the stages of Initialization, VM Launch, Configuration, Application Launch, Running, Reboot, Stop and Shutdown.
- the user-defined automation actions are executed by the guest agent in or over one or more of the stages of Configuration, Application Launch, Running, Reboot, Stop and Shutdown.
- the automation graph can be a directed acyclic graph including a plurality of graph nodes having payloads that correspond to respective ones of the user-defined automation actions to be executed.
- the payloads of the graph nodes are executed in a sequential order according to the user-defined causal relationships.
- the plurality of graph nodes can include at least one conditional node having a plurality of direct predecessor nodes.
- the guest agent of the virtual machine executes a payload of the conditional node when execution of a payload of at least one of the plurality of direct predecessor graph nodes has been completed even if execution of one or more of the other direct predecessor graphical nodes has failed or is not completed.
- the user-defined automation actions can have associated therewith two automation graphs to be executed on two different virtual machines.
- Each of the two automation graphs including a plurality of graph nodes with payloads corresponding to respective ones of the user-defined automation actions.
- the virtual machines execute the payloads of the graph nodes of the two automation graphs in synchronization with each other, such as through the use of step-by-step messaging therebetween.
- the computer-implemented method, computer system and a tangible memory medium with executable code can further implement the operations of: providing a user interface for a user to input information corresponding to the user-defined automation actions and causal relationships; and deriving the automation graph based on the inputted user-defined automation actions and causal relationships.
- the inputted information can correspond to a graph adjacency list with a happens-before relationship and a payload for each automation action.
- FIG. 1 illustrates an example cloud computing architecture in accordance with an embodiment of the present disclosure.
- FIG. 2 illustrates an example of a platform instantiating a guest system with virtual machine(s) having a guest agent that executes user-defined automation actions during the life cycle of the guest system, in accordance with an embodiment of the present disclosure.
- FIGS. 3-6 illustrate functional step-by-step diagrams of an example cloud deployment of a service requested by a user through a web client.
- FIG. 7 illustrates a high level diagram of an example of a guest system lifecycle.
- FIG. 8 illustrates an example user interface through which a user can input and define automation actions and causal relationships from which an automation graph, such as a directed acyclic graph (DAG), of automation actions is derived (or constructed) for use in automating and controlling actions on a virtual machine of a guest system when launched to execute an application.
- an automation graph such as a directed acyclic graph (DAG)
- DAG directed acyclic graph
- FIG. 9 illustrates a simple example of a directed acyclic graph of automation actions with five steps.
- FIGS. 10A and 10B illustrate an example of a directed acyclic graph of automation actions with long running steps.
- FIG. 11 illustrates an example of a directed acyclic graph of automation actions with a “reluctant” node to address the situation in which a fatal failure occurs in the guest system.
- FIG. 12 illustrates an example of a directed acyclic graph of automation actions with condition execution.
- FIG. 13 illustrates an example of a directed acyclic graph of automation actions with “eager nodes” that may be used to mitigate the situation in which a non-fatal failure occurs on the application, virtual machine, or guest system.
- FIG. 14 illustrates a process by which automation actions and their causal relationships are defined by a user to derive an automation graph associated with an execution of an application, and implemented by a guest agent when a guest system and its virtual machine(s) are launched to execute the application or the application components.
- a computerized system and method are provided with a centralized automation system to address the technical problems of making existing application(s) execute on the cloud in a convenient and reliable manner.
- the centralized automation system e.g., a platform on a cloud computing architecture, manages applications provided through a guest system and its virtual machine(s), such as a distributed guest system with one or more virtual machines.
- the guest system in general, can contain multiple applications, such as from different vendors that need to be configured and integrated dynamically by the automation system.
- the platform provisions systems for users on demand, and then allows users to use the applications (e.g., system applications) through a web browser.
- the applications and topology are defined by users themselves.
- the computerized system and method provide a scheme used to define and then execute the automation action steps.
- the guest applications typically are fairly complex, such as for example distributed simulation environments. These applications can utilize many networked (clustered) machines to process large simulation models in real time.
- the method or system also provides the user with the flexibility to define and automate failure monitoring and mitigation for application(s) executed on the virtual machine(s) of a distributed guest system.
- a user is provided with a user interface through which to configure automation actions for the application(s) in a declarative way for operation on a virtual machine of a guest system.
- the user can define or state a set of automation actions and their causal relationships, e.g., “happens after” relationships, with each other.
- the automation system can automatically extract the maximum level of concurrency by deriving (or constructing) an automation graph.
- the automation graph can, for example, take the form of a Directed Acyclic Graph (DAG) representation of the interrelated automation actions.
- DAG Directed Acyclic Graph
- the automation system such as a platform (e.g., commercial off the shelf (COTS) Platform), can execute the actions specified by the user on a guest system every time a guest system and its virtual machine(s) are launched.
- COTS commercial off the shelf
- the status and outcome of each automation action (also referred to as an “automation action step”) is logged and reported to interested users. Automation actions are retried on failure.
- the user-defined automation actions are managed centrally in the platform, and executed remotely on ephemeral cloud machines using a guest agent, e.g., a secure guest agent component, which is installed in each virtual machine image used by the guest system.
- Automation actions across different machines can be coordinated in two ways: (1) synchronization barriers—where automation graphs on separate machines wait for each other before continuing; and (2) automation step-to-step messaging (e.g., a step on one machine can wait for a signal from another on a different machine).
- the automation system is also active during the entire guest system lifecycle, such as follows: application configuration, content load and application launches are automated (during startup); the automation system monitors or watches for specific failures and automates their mitigation (during runtime); and the automation system automates content persistence (during shutdown).
- application configuration, content load and application launches are automated (during startup); the automation system monitors or watches for specific failures and automates their mitigation (during runtime); and the automation system automates content persistence (during shutdown).
- the above are a few non-limiting exemplary categories of user-defined automation actions and their relationships that can be defined by the user for an application, and are executed during a lifecycle of a guest system and its virtual machine(s) when executing the application or components thereof. Examples of such a computerized system and method are described in greater detailed below with reference to the figures, in accordance with various embodiments of the present disclosure.
- FIG. 1 illustrates an example of a cloud computing architecture 10 for providing cloud-based services to a user through the execution of an application using virtual systems or machines.
- the architecture 10 includes a user web client(s) 20 , third party client(s) 30 , and a cloud 100 through which the services are offered and provided to the user web client 20 .
- the clients 20 and 30 can be implemented on a computer system(s) that includes a processor (e.g., CPU), memory to store applications and data, input device, output device, and network interface device (e.g., transmitter and receiver circuitry).
- the third party may interact with the cloud 100 as part of the provisioning of services to the user.
- the cloud 100 includes a platform 110 , which is a persistent distributed application.
- the user through the user web client(s) 20 can request and access the services and their applications on the cloud 100 via a portal 180 , which, in this example, is a thin web application that allows online user access to the platform 110 .
- the platform 110 is a web services application that has as one of its primary functions to provision guest systems 130 , using API calls to the cloud 100 Infrastructure-as-a-Service 120 (IaaS) providers, via cloud driver 116 .
- the platform 110 can include a central content store for storage and revision control, storage for metadata, storage for reusable software (e.g., system application(s)), and storage for guest agent software.
- each guest system 130 can include one or more virtual machines 140 which execute application(s) or components thereof to provide the requested services to the user.
- the guest systems 130 can be defined by users using blue prints (templates), and are instantiated by the platform 110 using the topology and virtual machine images specified in the blueprints.
- the guest systems 130 are ephemeral, meaning that the platform 110 provisions and manages them on demand.
- the platform 110 may run on data centers 150 in the cloud 100 , and manages all states in the architecture 10 .
- the data centers 150 may be connected across a network(s) 152 , and include at least a processor(s) (e.g., CPUs), memory, and network interface device(s).
- the platform 110 functions include:
- the platform 110 is a Simulation-as-a-Service cloud platform that provisions simulation systems on the cloud 100 on demand, and includes a Model Repository 112 and a Simulation Environment Controller 114 which interacts with the application(s) or components thereof on the virtual machines 140 of the guest systems 130 to provide simulation services to users.
- the platform 110 further includes a platform application program interface (API) 118 through which the user web clients 20 can access the platform 110 via the portal 180 .
- API platform application program interface
- the guest systems 130 implement on or across one or more virtual machines a dynamic simulation (DYNSIM) application, which includes a Learning Management System node (LMS) 142 , DYNSIM SimExecutive Node (SE) 144 , InTouch HMI Node (UI) 146 , and three Calculation Engines (E) 148 (also referred to as guest simulation cluster).
- LMS Learning Management System node
- SE DYNSIM SimExecutive Node
- UI InTouch HMI Node
- E Calculation Engines
- the user may access the virtual machine(s) 140 of the guest system 130 via a remote desktop session to run, for example, a design process for a steam control system in a petroleum refinery.
- the user can access the LMS 142 as a website, and the UI 146 as a HTMLS remote desktop session.
- the Infrastructure-as-a-Service (IaaS) 120 of the architecture 10 is a network utility program for accessing, monitoring, and managing infrastructures of the data centers 150 in the cloud 100 , to perform functions such as compute (virtualized or bare metal), storage, networking, and networking services (e.g. firewalls).
- compute virtualized or bare metal
- storage virtualized or bare metal
- networking e.g. firewalls
- FIG. 2 illustrates an example of the platform 110 instantiating a virtual machine 140 in the guest system 130 , which includes virtual machine executable application (or software) 202 , a guest agent 204 , and a guest operating system (OS) 206 .
- the concurrent and distributed platform 110 application is currently being executed in a particular one of the cloud data centers 150 of FIG. 1 , and thus, the memory of the data center 150 currently includes the virtual machine executable application 202 , in accordance with exemplary embodiments of the present disclosure.
- the platform 110 enables inter-process communication and dynamic object creation in the guest system 130 .
- the platform 110 instantiates the virtual machine 140 in the guest system 130 .
- the guest agent 204 automatically executes actions defined by a user at one or more stages over the lifecycle of the application 202 or the virtual machine 140 of the guest system 130 according to user-defined automation actions or the corresponding automation graph(s) using an algorithm 230 .
- the guest agent 204 applies the automation action step as specified by the user according to an automation graph or the like, and returns the results to the platform driver (e.g., 116 in FIG. 1 ).
- the platform driver runs through the automation sequence until complete or a fatal failure occurs.
- the guest OS 206 is an operating system capable of being executed in the guest system 130 , and which supports the virtual machine executable application 202 , and the guest agent 204 .
- the platform 106 includes a data store 220 , which stores and maintains user-defined automation actions/automation graph(s) data 222 , content data 224 (e.g., project specific content), metadata 226 (e.g., a URL to the content data 224 or specific content in the content data 224 , or to other data maintained on the platform 110 ) and other data, which are used by the guest system 130 to provide requested services to the user.
- content data 224 e.g., project specific content
- metadata 226 e.g., a URL to the content data 224 or specific content in the content data 224 , or to other data maintained on the platform 110
- other data e.g., a URL to the content data 224 or specific content in the content data 224 , or to other data maintained on the platform 110 .
- the user-defined automation actions/automation graph(s) data 222 includes information corresponding to the user-defined automation actions (e.g., a payload) and their causal relationship to each other (e.g., predecessor, descendent, etc.) and/or derived automation graph(s), and are used to initiate and control the automation of actions (as specified by the user) in the guest system 130 , when the guest system 130 and its virtual machine 140 is launched.
- the automation graph can take the form of a directed acyclic graph (DAG).
- Examples of the virtual machine executable application 202 may include an executable software program that provides a service to the user, such as, in this example, a dynamic process simulation.
- a first example project-specific function to which the executable application 202 may be applied may be a project to design a process for a steam control system in a petroleum refinery.
- Example content data 224 may include data required to design a process for a steam control system, such as for example, steam source data, valve data, piping data, and the like. It should be understood that the application 202 may provide other types of services or functions to a user.
- the platform 110 When the platform 110 creates the virtual machine 140 , it records information about the virtual machine 140 in a registry 210 , which is a database that stores information, such as the virtual machine identifier and address, and reference identities of other objects that reference the virtual machine 140 .
- the reference identities in the registry enable other application program(s), in response to an application request, to locate the virtual machine 140 .
- FIGS. 3-6 illustrate high level diagrams of the operations in an example deployment of a service requested by a user, such as through the user web client 20 of FIG. 1 .
- a high level cloud-based architecture 300 is shown of nodes 320 of the portal (e.g., 180 in FIG. 1 ) and nodes 340 of the platform (e.g., 110 of FIG. 1 ), which is in an always-on and ready state to receive a request, e.g., a launch command, from a user via a web client to initiate service on the cloud.
- load balancing 310 is performed across the portal nodes 320
- platform balancing 330 is performed across the platform nodes 340 .
- FIG. 1 a high level cloud-based architecture 300 is shown of nodes 320 of the portal (e.g., 180 in FIG. 1 ) and nodes 340 of the platform (e.g., 110 of FIG. 1 ), which is in an always-on and ready state to receive a request, e.g.
- the user via the user web client logs onto the portal through an available portal node 320 , and sends a request to an available platform node 340 to launch a guest system 450 on the cloud.
- the guest system 450 is provisioned by the platform node 340 , and a custom URL 560 is created for the user's application(s).
- a guest system can include virtual machine(s) with guest agent that is configured to implement user-defined automation actions over the lifecycle of the user's application(s) or virtual machine according to an automation graph derived from automation actions and their causal relationships as defined by a user.
- the platform node 340 continues to provision many guest systems 450 on the cloud. The user can terminate the session, as desired, to terminate the guest system(s) 450 .
- FIG. 7 illustrates a high level diagram 700 of an example of a guest system lifecycle.
- the automation system of the present disclosure works within the guest system lifecycle. Users can define automation actions and their causal relationships to derive a corresponding automation graph(s) that is triggered and executed by the platform at any or each stage of the lifecycle using a guest agent in the virtual machine of the guest system.
- an example lifecycle may involve processes or services, such as Net Runner 710 , Cluster Runner 730 , Group Runner 750 and Node Runner 770 .
- the Net Runner 710 is at the stage NetworksAvailable
- the Cluster Runner 730 is at the stage RunCluster
- the Group Runner 730 is at the stage NodeRunning
- the Node Runner 770 is at the stage Running.
- Guest system nodes e.g., virtual machines
- Node Runner 770 can go through the following high-level lifecycle stages:
- the automation system of the present disclosure allows a user to define and automate desired actions to be performed during one or more stages in a lifecycle of the guest systems, e.g., stages 3 through 8 such as after VM Launch.
- FIG. 8 illustrates an example of a user interface 800 through which a user can input and define automation actions and causal relationships between the actions from which an automation graph is derived.
- the automation graph can be used to automate and control actions (e.g., operations, functions, etc.) in a guest system when a virtual machine is launched to execute the application on the machine.
- the user interface 800 can receive user input via an input area 810 , such as (i) Name of the Action, (ii) Relationship to other actions (e.g., precursor or preceding action, descending action, or other causal relationships), and (iii) Payload indicating the automation action to be taken.
- the input area 810 may include graphical elements (e.g., graphical input box(es), pulldown boxes, etc.) through which a user can define automation actions and causal relationships therebetween to derive an automation graph.
- graphical elements e.g., graphical input box(es), pulldown boxes, etc.
- a user can input and define an automation action and their relationship to other actions one at a time by continuing the input process via the command CONTINUE or the like.
- the user interface 800 can also include a viewing area 820 which shows a set of automation actions and causal relationships between actions defined by a user.
- the user-defined automation actions can be defined in JavaScript Object Notation (JSON), and correspond to the example of a simple five-step automation graph 900 which is shown in FIG. 9 .
- the automation graph in FIG. 9 includes action steps represented by graph nodes “a”, “b”, “c”, “d” and “e” as shown in the Initial State.
- the action step “a” is first executed.
- the actions steps “b” and “c” are then executed in parallel.
- the action step “d” is executed, which is followed by the execution of action step “e” which completes the automation graph.
- the viewing area 820 may concurrently or separately display the user-defined automation actions in graphical form (e.g., FIG. 9 ).
- the user can also edit the automation graph or particular steps via an EDIT command, which can allow the user to directly or to indirectly (e.g., through another window or interface) edit information in the viewing area 820 .
- the automation system of the present disclosure is able to provide various technical improvements to existing computer systems and technology, such as: (1) central, failure tolerant, management of distributed, coordinated automation; (2) a simple user interface for writing complex automation that is executed across clusters of machines; and (3) maximum concurrency, derived automatically by the automation system.
- the user can define automation graphs that trigger, for example, in stages 3-8 (e.g., config, app launch, . . . shutdown of FIG. 7 ) of the lifecycle of a guest system.
- the platform executes the automation graph sequence centrally in the platform itself.
- the automation graph steps are executed on each guest system node with the help of a pre-installed guest agent.
- the guest agent applies the automation action step, and returns the results to the platform driver.
- the platform driver runs through the automation sequence until complete or a fatal failure occurs.
- the automation graph can be a directed acyclic graph (DAG) of individual automation action steps.
- DAG directed acyclic graph
- Such a graph is straightforward for the user to construct, by specifying, for example, “happens-before” relationships (e.g., precursor causal relationships) between individual automation action steps.
- a user interface can be provided which allows a user to define automation action steps and their causal relationships to each other to construct automation graphs without requiring substantial computer programming knowledge or skills.
- the user can define automation action steps and (i) their causal relationships to each other within an automation graph associated with an application or (ii) their causal relationships to each other between automation graphs for different applications or application components.
- the user can construct automation graph(s) to perform automation actions at any desired stage in the lifecycle of the guest system, after the guest system and its virtual machine(s) are launched.
- Non-limiting examples of automation action steps include:
- FIGS. 10A and 10B illustrate an example of automation graph(s) 1000 with automation actions having long running action steps in an initial state and an execution state after 1.1 seconds, respectively.
- the graph 1000 includes a first automation subgraph with the action steps represented by graph nodes “a”, “b”, “c”, “d”, “e”, “f” and “g”, and a second automation subgraph with the action steps represented by nodes “h”, “i”, “j” and “k”.
- the step “c” has a 1000 ms delay.
- the step “g” has a 50 ms delay.
- the step “i” has a 5000 ms delay.
- the execution follows the graph flow, namely that a node only executes its payload when all of its precursors have successfully completed. As shown in FIG.
- the two separate automation subgraphs in FIG. 10A may be implemented on the same or different virtual machines in the guest system, and may execute in synchronization. That is, the two automation graphs on separate machines can wait for each other before continuing their execution.
- the guest agent of the virtual machines can communicate with each other via step-to-step messaging reflecting the execution state of their respective automation graphs. For example, an action step on one virtual machine can wait for a signal from another action step on a different machine before continuing.
- FIG. 11 illustrates an example using the automation graph(s) 1000 in FIG. 10A to show the situation in which a fatal failure occurs in the guest system.
- a guest agent which executes the action steps in the automation graph, is configured to sense and handle fatal errors during execution.
- a fatal failure is recognized and declared at the action step “g”. Any automation action step's logic can declare a fatal failure.
- the graph executor application or software on the guest agent stops execution for all nodes of the automation graph, and raises the event to the platform.
- Graph nodes can be configured to conditionally pass on normal “action” execution messages or “no-action” messages. Down-stream nodes will then skip execution when they receive no-action inputs, and pass the no-action messages on to downstream nodes. This allows decisions to be made by the nodes at runtime. For instance, nodes can measure conditions and decide to cause skipped execution downstream. Automation graphs can be configured to make runtime decisions. The automation graph will still complete execution, even though some graph nodes did not execute.
- downstream nodes of an automation graph can be configured to react in one of two ways to action inputs: (1) as a “reluctant” node that is reluctant to execute, meaning that any no-action input signal will cause a node to skip execution, or (2) as an “eager” node that is eager to execute, meaning that the node will execute its payload when any input signal is an action. Examples of these types of node configurations are described below with reference to FIGS. 12 and 13 .
- FIG. 12 illustrates an example of an automation graph 1200 of automation actions with conditional execution.
- the graph 1200 includes action steps represented by graph nodes “a” through “s”.
- node “m” logic decides to skip its own and downstream node execution.
- the downstream nodes react to either a “no-action” or “action” signal.
- node “m” is configured to skip execution, and passes on no-action signals. All nodes are reluctant to execute in the graph 1200 .
- FIG. 13 illustrates an example of an automation graph 1300 with “eager” nodes that may be used to mitigate the situation in which a non-fatal failure occurs in the guest system.
- the graph 1300 includes action steps represented by graph nodes “a” through “s”.
- the graph node “m” is again configured to simulate skipped execution.
- the graph nodes “o” and “r” execute eagerly because they receive at least one action signal. Accordingly, the user can continue to implement automation actions according to the automation graph in the event of “non-fatal” failures on the guest system.
- FIG. 14 illustrates a process 1400 by which automation actions and causal relationships between each other are defined by a user to derive an automation graph, and implemented on a guest system executing one or more applications or components thereof through virtual machine(s), in accordance with an embodiment of the present disclosure.
- the process 1400 can be implemented on a platform on the cloud using data centers, such as in the example system architecture 10 of FIGS. 1 and 2 .
- a user interface is provided by the platform for a user to input and define automation actions and causal relationships between each other for an application(s) or components thereof to be executed on a virtual machine(s).
- the user interface can be provided as a web service or application to a user.
- the platform receives the user-defined automation actions and causal relationships, and derives (or constructs) an automation graph for the application(s) or components thereof.
- the user-defined automation actions and the causal relationships and/or the automation graph are stored in relations to the application(s) or components thereof.
- the platform launches a guest system with a virtual machine(s) including a guest agent and the application.
- the guest agent executes the user-defined automation actions in the virtual machine(s) according to the automation graph, after the guest system and the virtual machine is launched (e.g., over a lifecycle of the virtual machine/guest system).
- the guest system is a distributed guest system with a plurality of virtual machines
- the virtual machines may be configured to communicate with each other on a step-by-step basis while implementing their respective automation graphs through their guest agents so that automation actions can be implemented in a synchronized manner.
- step-by-step messaging can also be performed between virtual machines on different guest systems to implement their respective automation graphs in a synchronized manner.
- the automation system can be implemented on any suitable networked computer system or architecture other than a cloud-based one which uses virtualization to provide application-based services to a user or other entity.
Abstract
Description
- The present disclosure is directed to a computerized method and system for automating actions specified by a user to configure and provision simple or complex applications in a well-defined and orchestrated sequence or a managed sequence of steps on a distributed system of virtual machines and networks in a cloud environment, and in addition, for enabling automated failure monitoring and mitigating actions specified by a user to be automatically performed in the event of a failure on the guest system.
- Software-based services can be offered to users through the use of virtual machines provided on a cloud. A user through a web client can access the cloud via the Internet, and request these software-based services provided through the execution of an application(s) on a virtual machine(s). However, as applications become increasingly complex requiring more processing power and memory, it becomes more problematic when the components of such applications are distributed across different virtual machines in a guest system and/or a failure or other issues occur in the provision of these applications to a user. The configuration and launch of such complex distributed systems is quite involved; the virtual networks, virtual machines instances and the applications themselves needed to be correctly configured and launched in a precise and coordinated series of steps. An application failure or other failure may result in the termination of the application executing on virtual machine(s) of a guest system. In such a case, an administrator may need to expend significant resources, including time, to identify the causes for such a failure after the fact. Furthermore, the failure is not only frustrating to the end user, but may also result in the loss of productivity and data.
- Accordingly, there is a need for a technical improvement to existing computer systems and technology that would provide a user with the flexibility to define and automate failure monitoring and mitigation for an application executed on virtual machine(s) of a guest system. There is also a need for a technical improvement to existing computer systems and technology that would allow a user to coordinate and control the timing of actions to be performed on different virtual machines that execute different applications or components thereof, such as on a distributed guest system. There is also a need for a technical improvement to existing computer systems and technology, which will provide a user with the flexibility of incorporating additional functionality and control across a lifecycle of an application(s) provided to one or more users through the cloud without having to directly modify or update the underlying application(s).
- To address these and other issues, a computerized method and system are provided which enable a user to define automation actions and causal relationships between the automation actions to derive an automation graph(s) associated with an execution of an application. When a guest system and its virtual machine(s) are launched to implement the application, the virtual machine is configured to automatically implement the actions defined or specified by the user (also referred to as “user-defined automation actions”) via a guest agent on the virtual machine according to the automation graph over a lifecycle of the virtual machine of guest system. In this way, it is possible to automate various actions over a lifecycle of a virtual machine, such as automate application configuration, automate content load and application launches during startup, monitor or watch for specific failures and automate their mitigation, and automate content persistence during shutdown. Furthermore, it is possible to automate actions across different machines, such as in a distributed guest system, by providing synchronization barriers—where automation graphs on separate machines wait for each other before continuing, and by providing automated step-to-step messaging (e.g., a step on one machine can wait for a signal from another on a different machine).
- In accordance with an exemplary embodiment, a computer-implemented method, computer system and a tangible memory medium with executable code are provided to automate actions for one or more applications executed via a platform using at least one virtual machine in a guest system. Each virtual machine includes a guest operating system, a guest agent and an application to be executed on the virtual machine. The computer-implemented method, computer system and tangible memory medium are configured to implement the operations of: storing in a memory user-defined automation actions and causal relationships between the user-defined automation actions from which an automation graph is derived for the application to be executed on the virtual machine on the guest system; launching the guest system and the virtual machine via the platform; and executing the user-defined automation actions via the guest agent of the virtual machine according to the automation graph after the guest system and the virtual machine are launched.
- The platform can be implemented on a cloud computing architecture. The guest system and the virtual machine are launched by the platform in response to a request sent over the Internet (e.g., via a web browser). The platform can execute for the guest system the stages of Initialization, VM Launch, Configuration, Application Launch, Running, Reboot, Stop and Shutdown. The user-defined automation actions are executed by the guest agent in or over one or more of the stages of Configuration, Application Launch, Running, Reboot, Stop and Shutdown.
- The automation graph can be a directed acyclic graph including a plurality of graph nodes having payloads that correspond to respective ones of the user-defined automation actions to be executed. The payloads of the graph nodes are executed in a sequential order according to the user-defined causal relationships. Furthermore, the plurality of graph nodes can include at least one conditional node having a plurality of direct predecessor nodes. The guest agent of the virtual machine executes a payload of the conditional node when execution of a payload of at least one of the plurality of direct predecessor graph nodes has been completed even if execution of one or more of the other direct predecessor graphical nodes has failed or is not completed.
- The user-defined automation actions can have associated therewith two automation graphs to be executed on two different virtual machines. Each of the two automation graphs including a plurality of graph nodes with payloads corresponding to respective ones of the user-defined automation actions. The virtual machines execute the payloads of the graph nodes of the two automation graphs in synchronization with each other, such as through the use of step-by-step messaging therebetween.
- The computer-implemented method, computer system and a tangible memory medium with executable code can further implement the operations of: providing a user interface for a user to input information corresponding to the user-defined automation actions and causal relationships; and deriving the automation graph based on the inputted user-defined automation actions and causal relationships. The inputted information can correspond to a graph adjacency list with a happens-before relationship and a payload for each automation action.
-
FIG. 1 illustrates an example cloud computing architecture in accordance with an embodiment of the present disclosure. -
FIG. 2 illustrates an example of a platform instantiating a guest system with virtual machine(s) having a guest agent that executes user-defined automation actions during the life cycle of the guest system, in accordance with an embodiment of the present disclosure. -
FIGS. 3-6 illustrate functional step-by-step diagrams of an example cloud deployment of a service requested by a user through a web client. -
FIG. 7 illustrates a high level diagram of an example of a guest system lifecycle. -
FIG. 8 illustrates an example user interface through which a user can input and define automation actions and causal relationships from which an automation graph, such as a directed acyclic graph (DAG), of automation actions is derived (or constructed) for use in automating and controlling actions on a virtual machine of a guest system when launched to execute an application. -
FIG. 9 illustrates a simple example of a directed acyclic graph of automation actions with five steps. -
FIGS. 10A and 10B illustrate an example of a directed acyclic graph of automation actions with long running steps. -
FIG. 11 illustrates an example of a directed acyclic graph of automation actions with a “reluctant” node to address the situation in which a fatal failure occurs in the guest system. -
FIG. 12 illustrates an example of a directed acyclic graph of automation actions with condition execution. -
FIG. 13 illustrates an example of a directed acyclic graph of automation actions with “eager nodes” that may be used to mitigate the situation in which a non-fatal failure occurs on the application, virtual machine, or guest system. -
FIG. 14 illustrates a process by which automation actions and their causal relationships are defined by a user to derive an automation graph associated with an execution of an application, and implemented by a guest agent when a guest system and its virtual machine(s) are launched to execute the application or the application components. - A computerized system and method are provided with a centralized automation system to address the technical problems of making existing application(s) execute on the cloud in a convenient and reliable manner. The centralized automation system, e.g., a platform on a cloud computing architecture, manages applications provided through a guest system and its virtual machine(s), such as a distributed guest system with one or more virtual machines. The guest system, in general, can contain multiple applications, such as from different vendors that need to be configured and integrated dynamically by the automation system. In a cloud computing architecture, the platform provisions systems for users on demand, and then allows users to use the applications (e.g., system applications) through a web browser. The applications and topology (number of sub-networks and virtual machines) are defined by users themselves. Application owners, who want to host their applications on the platform, configure the basic building blocks that users use in their system blueprints. These building blocks are “machine images” with the application software pre-installed, and “automation action steps” that allow the software to be configured and executed automatically. The computerized system and method provide a scheme used to define and then execute the automation action steps. The guest applications typically are fairly complex, such as for example distributed simulation environments. These applications can utilize many networked (clustered) machines to process large simulation models in real time. The method or system also provides the user with the flexibility to define and automate failure monitoring and mitigation for application(s) executed on the virtual machine(s) of a distributed guest system.
- In accordance with the present disclosure, a user is provided with a user interface through which to configure automation actions for the application(s) in a declarative way for operation on a virtual machine of a guest system. Specifically, the user can define or state a set of automation actions and their causal relationships, e.g., “happens after” relationships, with each other. Thereafter, the automation system can automatically extract the maximum level of concurrency by deriving (or constructing) an automation graph. The automation graph can, for example, take the form of a Directed Acyclic Graph (DAG) representation of the interrelated automation actions. Once the automation actions are defined by a user for an application, the automation system, such as a platform (e.g., commercial off the shelf (COTS) Platform), can execute the actions specified by the user on a guest system every time a guest system and its virtual machine(s) are launched. The status and outcome of each automation action (also referred to as an “automation action step”) is logged and reported to interested users. Automation actions are retried on failure.
- The user-defined automation actions are managed centrally in the platform, and executed remotely on ephemeral cloud machines using a guest agent, e.g., a secure guest agent component, which is installed in each virtual machine image used by the guest system. Automation actions across different machines can be coordinated in two ways: (1) synchronization barriers—where automation graphs on separate machines wait for each other before continuing; and (2) automation step-to-step messaging (e.g., a step on one machine can wait for a signal from another on a different machine). The automation system is also active during the entire guest system lifecycle, such as follows: application configuration, content load and application launches are automated (during startup); the automation system monitors or watches for specific failures and automates their mitigation (during runtime); and the automation system automates content persistence (during shutdown). The above are a few non-limiting exemplary categories of user-defined automation actions and their relationships that can be defined by the user for an application, and are executed during a lifecycle of a guest system and its virtual machine(s) when executing the application or components thereof. Examples of such a computerized system and method are described in greater detailed below with reference to the figures, in accordance with various embodiments of the present disclosure.
-
FIG. 1 illustrates an example of acloud computing architecture 10 for providing cloud-based services to a user through the execution of an application using virtual systems or machines. Thearchitecture 10 includes a user web client(s) 20, third party client(s) 30, and acloud 100 through which the services are offered and provided to theuser web client 20. Theclients cloud 100 as part of the provisioning of services to the user. - The
cloud 100 includes aplatform 110, which is a persistent distributed application. The user through the user web client(s) 20 can request and access the services and their applications on thecloud 100 via a portal 180, which, in this example, is a thin web application that allows online user access to theplatform 110. Theplatform 110 is a web services application that has as one of its primary functions to provisionguest systems 130, using API calls to thecloud 100 Infrastructure-as-a-Service 120 (IaaS) providers, viacloud driver 116. Theplatform 110 can include a central content store for storage and revision control, storage for metadata, storage for reusable software (e.g., system application(s)), and storage for guest agent software. When launched, eachguest system 130 can include one or morevirtual machines 140 which execute application(s) or components thereof to provide the requested services to the user. Theguest systems 130 can be defined by users using blue prints (templates), and are instantiated by theplatform 110 using the topology and virtual machine images specified in the blueprints. Theguest systems 130 are ephemeral, meaning that theplatform 110 provisions and manages them on demand. - The
platform 110 may run ondata centers 150 in thecloud 100, and manages all states in thearchitecture 10. Thedata centers 150 may be connected across a network(s) 152, and include at least a processor(s) (e.g., CPUs), memory, and network interface device(s). Theplatform 110 functions include: -
- Provisioning virtual networks and
guest systems 130 andvirtual machines 140, and launching guest applications and guest agents inguest systems 130, which may be configured in a runtime template; - Monitoring guest applications and dealing with their failures;
- Managing user, user group, and resource authorization;
- Building and updating machine images as a background task, from recipes as defined by application role definitions;
- Providing a software application through which users can specify automation actions and their causal relationships to derive automation graph(s) through which a guest agent on a virtual machine 140 (of a guest system 130), when launched to execute a guest application, automates and controls these actions over the lifecycle of the guest application,
virtual machine 140 orguest system 130; and - Facilitating messaging (e.g., step-by-step messaging) between
virtual machines 140 in thesame guest system 130 and/or indifferent guest systems 130.
When the data center(s) 150 executes via its processor(s) the concurrent and distributed platform application stored in the memory, the processor and memory of the data center(s) 150 perform the method of virtual machine image storage, of runtime provisioning including the implementation of user-defined automation actions via a guest agent, and of other functions, operations or steps described herein in accordance with the various embodiments of the present disclosure.
- Provisioning virtual networks and
- In this example, the
platform 110 is a Simulation-as-a-Service cloud platform that provisions simulation systems on thecloud 100 on demand, and includes aModel Repository 112 and aSimulation Environment Controller 114 which interacts with the application(s) or components thereof on thevirtual machines 140 of theguest systems 130 to provide simulation services to users. Theplatform 110 further includes a platform application program interface (API) 118 through which theuser web clients 20 can access theplatform 110 via theportal 180. Theguest systems 130, in this example, implement on or across one or more virtual machines a dynamic simulation (DYNSIM) application, which includes a Learning Management System node (LMS) 142, DYNSIM SimExecutive Node (SE) 144, InTouch HMI Node (UI) 146, and three Calculation Engines (E) 148 (also referred to as guest simulation cluster). The user may access the virtual machine(s) 140 of theguest system 130 via a remote desktop session to run, for example, a design process for a steam control system in a petroleum refinery. The user can access theLMS 142 as a website, and theUI 146 as a HTMLS remote desktop session. - The Infrastructure-as-a-Service (IaaS) 120 of the
architecture 10 is a network utility program for accessing, monitoring, and managing infrastructures of thedata centers 150 in thecloud 100, to perform functions such as compute (virtualized or bare metal), storage, networking, and networking services (e.g. firewalls). -
FIG. 2 illustrates an example of theplatform 110 instantiating avirtual machine 140 in theguest system 130, which includes virtual machine executable application (or software) 202, aguest agent 204, and a guest operating system (OS) 206. The concurrent and distributedplatform 110 application is currently being executed in a particular one of thecloud data centers 150 ofFIG. 1 , and thus, the memory of thedata center 150 currently includes the virtual machineexecutable application 202, in accordance with exemplary embodiments of the present disclosure. Theplatform 110 enables inter-process communication and dynamic object creation in theguest system 130. Theplatform 110 instantiates thevirtual machine 140 in theguest system 130. Theguest agent 204 automatically executes actions defined by a user at one or more stages over the lifecycle of theapplication 202 or thevirtual machine 140 of theguest system 130 according to user-defined automation actions or the corresponding automation graph(s) using analgorithm 230. Theguest agent 204 applies the automation action step as specified by the user according to an automation graph or the like, and returns the results to the platform driver (e.g., 116 inFIG. 1 ). The platform driver runs through the automation sequence until complete or a fatal failure occurs. Theguest OS 206 is an operating system capable of being executed in theguest system 130, and which supports the virtual machineexecutable application 202, and theguest agent 204. - The platform 106 includes a
data store 220, which stores and maintains user-defined automation actions/automation graph(s)data 222, content data 224 (e.g., project specific content), metadata 226 (e.g., a URL to thecontent data 224 or specific content in thecontent data 224, or to other data maintained on the platform 110) and other data, which are used by theguest system 130 to provide requested services to the user. The user-defined automation actions/automation graph(s)data 222 includes information corresponding to the user-defined automation actions (e.g., a payload) and their causal relationship to each other (e.g., predecessor, descendent, etc.) and/or derived automation graph(s), and are used to initiate and control the automation of actions (as specified by the user) in theguest system 130, when theguest system 130 and itsvirtual machine 140 is launched. The automation graph can take the form of a directed acyclic graph (DAG). - Examples of the virtual machine
executable application 202 may include an executable software program that provides a service to the user, such as, in this example, a dynamic process simulation. A first example project-specific function to which theexecutable application 202 may be applied may be a project to design a process for a steam control system in a petroleum refinery.Example content data 224 may include data required to design a process for a steam control system, such as for example, steam source data, valve data, piping data, and the like. It should be understood that theapplication 202 may provide other types of services or functions to a user. - When the
platform 110 creates thevirtual machine 140, it records information about thevirtual machine 140 in aregistry 210, which is a database that stores information, such as the virtual machine identifier and address, and reference identities of other objects that reference thevirtual machine 140. The reference identities in the registry enable other application program(s), in response to an application request, to locate thevirtual machine 140. -
FIGS. 3-6 illustrate high level diagrams of the operations in an example deployment of a service requested by a user, such as through theuser web client 20 ofFIG. 1 . InFIG. 3 , a high level cloud-basedarchitecture 300 is shown ofnodes 320 of the portal (e.g., 180 inFIG. 1 ) andnodes 340 of the platform (e.g., 110 ofFIG. 1 ), which is in an always-on and ready state to receive a request, e.g., a launch command, from a user via a web client to initiate service on the cloud. In thearchitecture 300, load balancing 310 is performed across theportal nodes 320, and platform balancing 330 is performed across theplatform nodes 340. As shown inFIG. 4 , the user via the user web client logs onto the portal through an availableportal node 320, and sends a request to anavailable platform node 340 to launch aguest system 450 on the cloud. As shown inFIG. 5 , theguest system 450 is provisioned by theplatform node 340, and acustom URL 560 is created for the user's application(s). As previously described, a guest system can include virtual machine(s) with guest agent that is configured to implement user-defined automation actions over the lifecycle of the user's application(s) or virtual machine according to an automation graph derived from automation actions and their causal relationships as defined by a user. As shown inFIG. 6 , theplatform node 340 continues to provisionmany guest systems 450 on the cloud. The user can terminate the session, as desired, to terminate the guest system(s) 450. -
FIG. 7 illustrates a high level diagram 700 of an example of a guest system lifecycle. The automation system of the present disclosure works within the guest system lifecycle. Users can define automation actions and their causal relationships to derive a corresponding automation graph(s) that is triggered and executed by the platform at any or each stage of the lifecycle using a guest agent in the virtual machine of the guest system. As shown inFIG. 7 , an example lifecycle may involve processes or services, such asNet Runner 710,Cluster Runner 730,Group Runner 750 andNode Runner 770. In this example, theNet Runner 710 is at the stage NetworksAvailable, theCluster Runner 730 is at the stage RunCluster, theGroup Runner 730 is at the stage NodeRunning, and theNode Runner 770 is at the stage Running. - Guest system nodes (e.g., virtual machines), as shown in the
Node Runner 770, can go through the following high-level lifecycle stages: -
- 1. Initialization (Init)
- 2. Virtual Machine (VM) Launch
- 3. Configuration (Config)
- 4. Application (App) Launch
- 5. Running
- 6. Reboot
- 7. Stop
- 8. Shutdown
- Accordingly, the automation system of the present disclosure allows a user to define and automate desired actions to be performed during one or more stages in a lifecycle of the guest systems, e.g., stages 3 through 8 such as after VM Launch.
-
FIG. 8 illustrates an example of auser interface 800 through which a user can input and define automation actions and causal relationships between the actions from which an automation graph is derived. The automation graph can be used to automate and control actions (e.g., operations, functions, etc.) in a guest system when a virtual machine is launched to execute the application on the machine. Theuser interface 800 can receive user input via aninput area 810, such as (i) Name of the Action, (ii) Relationship to other actions (e.g., precursor or preceding action, descending action, or other causal relationships), and (iii) Payload indicating the automation action to be taken. Theinput area 810 may include graphical elements (e.g., graphical input box(es), pulldown boxes, etc.) through which a user can define automation actions and causal relationships therebetween to derive an automation graph. A user can input and define an automation action and their relationship to other actions one at a time by continuing the input process via the command CONTINUE or the like. - By way of example, the
user interface 800 can also include aviewing area 820 which shows a set of automation actions and causal relationships between actions defined by a user. In this example, the user-defined automation actions can be defined in JavaScript Object Notation (JSON), and correspond to the example of a simple five-step automation graph 900 which is shown inFIG. 9 . The automation graph inFIG. 9 includes action steps represented by graph nodes “a”, “b”, “c”, “d” and “e” as shown in the Initial State. During operation, the action step “a” is first executed. The actions steps “b” and “c” are then executed in parallel. Next, the action step “d” is executed, which is followed by the execution of action step “e” which completes the automation graph. Theviewing area 820 may concurrently or separately display the user-defined automation actions in graphical form (e.g.,FIG. 9 ). The user can also edit the automation graph or particular steps via an EDIT command, which can allow the user to directly or to indirectly (e.g., through another window or interface) edit information in theviewing area 820. - Accordingly, the automation system of the present disclosure is able to provide various technical improvements to existing computer systems and technology, such as: (1) central, failure tolerant, management of distributed, coordinated automation; (2) a simple user interface for writing complex automation that is executed across clusters of machines; and (3) maximum concurrency, derived automatically by the automation system.
- The user can define automation graphs that trigger, for example, in stages 3-8 (e.g., config, app launch, . . . shutdown of
FIG. 7 ) of the lifecycle of a guest system. The platform executes the automation graph sequence centrally in the platform itself. The automation graph steps are executed on each guest system node with the help of a pre-installed guest agent. The guest agent applies the automation action step, and returns the results to the platform driver. The platform driver runs through the automation sequence until complete or a fatal failure occurs. - The automation graph can be a directed acyclic graph (DAG) of individual automation action steps. Such a graph is straightforward for the user to construct, by specifying, for example, “happens-before” relationships (e.g., precursor causal relationships) between individual automation action steps. Thus, a user interface can be provided which allows a user to define automation action steps and their causal relationships to each other to construct automation graphs without requiring substantial computer programming knowledge or skills. The user can define automation action steps and (i) their causal relationships to each other within an automation graph associated with an application or (ii) their causal relationships to each other between automation graphs for different applications or application components. The user can construct automation graph(s) to perform automation actions at any desired stage in the lifecycle of the guest system, after the guest system and its virtual machine(s) are launched. Non-limiting examples of automation action steps (e.g., actions) include:
-
- Write a configuration file,
- Replace certain registry keys,
- Read configuration files and replace certain variables,
- Clone content from a remote content store,
- Launch a program,
- Restart a service,
- Watch a file, or
- Other passive actions (e.g., monitoring) or active actions.
After the user defines the causal relationships between the automation action steps, the platform is configured to extract the maximum parallelism from the graph, and execute it on the guest systems via a guest agent.
-
FIGS. 10A and 10B illustrate an example of automation graph(s) 1000 with automation actions having long running action steps in an initial state and an execution state after 1.1 seconds, respectively. Thegraph 1000 includes a first automation subgraph with the action steps represented by graph nodes “a”, “b”, “c”, “d”, “e”, “f” and “g”, and a second automation subgraph with the action steps represented by nodes “h”, “i”, “j” and “k”. The step “c” has a 1000 ms delay. The step “g” has a 50 ms delay. The step “i” has a 5000 ms delay. The execution follows the graph flow, namely that a node only executes its payload when all of its precursors have successfully completed. As shown inFIG. 10B , after 1.1 seconds, the action steps “d” and “i” are still executing in the guest system, and the action step “g” has completed execution in the guest system. The action step “e”, with the precursors “d” and “g”, is still waiting to execute; and the action steps “j” and “k”, with the precursor “i”, are still waiting to execute. - The two separate automation subgraphs in
FIG. 10A may be implemented on the same or different virtual machines in the guest system, and may execute in synchronization. That is, the two automation graphs on separate machines can wait for each other before continuing their execution. To synchronize the execution of the automation graphs on different virtual machines, the guest agent of the virtual machines can communicate with each other via step-to-step messaging reflecting the execution state of their respective automation graphs. For example, an action step on one virtual machine can wait for a signal from another action step on a different machine before continuing. -
FIG. 11 illustrates an example using the automation graph(s) 1000 inFIG. 10A to show the situation in which a fatal failure occurs in the guest system. In operation, a guest agent, which executes the action steps in the automation graph, is configured to sense and handle fatal errors during execution. In this example, a fatal failure is recognized and declared at the action step “g”. Any automation action step's logic can declare a fatal failure. When a fatal failure is declared, the graph executor application or software on the guest agent stops execution for all nodes of the automation graph, and raises the event to the platform. - In most practical applications, there is a need to model cases where parts of an automation graph are executed conditionally. Graph nodes can be configured to conditionally pass on normal “action” execution messages or “no-action” messages. Down-stream nodes will then skip execution when they receive no-action inputs, and pass the no-action messages on to downstream nodes. This allows decisions to be made by the nodes at runtime. For instance, nodes can measure conditions and decide to cause skipped execution downstream. Automation graphs can be configured to make runtime decisions. The automation graph will still complete execution, even though some graph nodes did not execute. Accordingly, downstream nodes of an automation graph can be configured to react in one of two ways to action inputs: (1) as a “reluctant” node that is reluctant to execute, meaning that any no-action input signal will cause a node to skip execution, or (2) as an “eager” node that is eager to execute, meaning that the node will execute its payload when any input signal is an action. Examples of these types of node configurations are described below with reference to
FIGS. 12 and 13 . -
FIG. 12 illustrates an example of anautomation graph 1200 of automation actions with conditional execution. Thegraph 1200 includes action steps represented by graph nodes “a” through “s”. In this example, the graph, node “m” logic decides to skip its own and downstream node execution. The downstream nodes react to either a “no-action” or “action” signal. In the following example, node “m” is configured to skip execution, and passes on no-action signals. All nodes are reluctant to execute in thegraph 1200. -
FIG. 13 illustrates an example of anautomation graph 1300 with “eager” nodes that may be used to mitigate the situation in which a non-fatal failure occurs in the guest system. As with thegraph 1200 inFIG. 12 , thegraph 1300 includes action steps represented by graph nodes “a” through “s”. In this example, the graph node “m” is again configured to simulate skipped execution. The graph nodes “o” and “r” execute eagerly because they receive at least one action signal. Accordingly, the user can continue to implement automation actions according to the automation graph in the event of “non-fatal” failures on the guest system. -
FIG. 14 illustrates aprocess 1400 by which automation actions and causal relationships between each other are defined by a user to derive an automation graph, and implemented on a guest system executing one or more applications or components thereof through virtual machine(s), in accordance with an embodiment of the present disclosure. Theprocess 1400 can be implemented on a platform on the cloud using data centers, such as in theexample system architecture 10 ofFIGS. 1 and 2 . - At
step 1402, a user interface (UI) is provided by the platform for a user to input and define automation actions and causal relationships between each other for an application(s) or components thereof to be executed on a virtual machine(s). The user interface can be provided as a web service or application to a user. - At
step 1404, the platform receives the user-defined automation actions and causal relationships, and derives (or constructs) an automation graph for the application(s) or components thereof. - At
step 1406, the user-defined automation actions and the causal relationships and/or the automation graph are stored in relations to the application(s) or components thereof. - At
step 1408, the platform launches a guest system with a virtual machine(s) including a guest agent and the application. - At
step 1410, the guest agent executes the user-defined automation actions in the virtual machine(s) according to the automation graph, after the guest system and the virtual machine is launched (e.g., over a lifecycle of the virtual machine/guest system). If the guest system is a distributed guest system with a plurality of virtual machines, the virtual machines may be configured to communicate with each other on a step-by-step basis while implementing their respective automation graphs through their guest agents so that automation actions can be implemented in a synchronized manner. Likewise, step-by-step messaging can also be performed between virtual machines on different guest systems to implement their respective automation graphs in a synchronized manner. - It should be understood that systems and methods described above are provided as an example. The automation system can be implemented on any suitable networked computer system or architecture other than a cloud-based one which uses virtualization to provide application-based services to a user or other entity.
- It will be appreciated that the development of an actual, real commercial application incorporating aspects of the disclosed embodiments will require many implementation specific decisions to achieve the developer's ultimate goal for the commercial embodiment. Such implementation specific decisions may include, and likely are not limited to, compliance with system related, business related, government related and other constraints, which may vary by specific implementation, location and from time to time. While a developer's efforts might be complex and time consuming in an absolute sense, such efforts would nevertheless be a routine undertaking for those of skill in this art having the benefit of this disclosure.
- It should also be understood that the embodiments disclosed and taught herein are susceptible to numerous and various modifications and alternative forms. Thus, the use of a singular term, such as, but not limited to, “a” and the like, is not intended as limiting of the number of items.
- Although specific example embodiments of the invention have been disclosed, persons of skill in the art will appreciate that changes may be made to the details described for the specific example embodiments, without departing from the spirit and the scope of the invention.
Claims (19)
Priority Applications (4)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US15/385,171 US20180173526A1 (en) | 2016-12-20 | 2016-12-20 | Application lifecycle management system |
EP17206209.3A EP3340034A1 (en) | 2016-12-20 | 2017-12-08 | Application lifecycle management system |
CN201711379415.4A CN108205463B (en) | 2016-12-20 | 2017-12-20 | Application lifecycle management system |
US16/727,083 US11487536B2 (en) | 2016-12-20 | 2019-12-26 | System for automating user-defined actions for applications executed using virtual machines in a guest system |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US15/385,171 US20180173526A1 (en) | 2016-12-20 | 2016-12-20 | Application lifecycle management system |
Related Child Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US16/727,083 Continuation US11487536B2 (en) | 2016-12-20 | 2019-12-26 | System for automating user-defined actions for applications executed using virtual machines in a guest system |
Publications (1)
Publication Number | Publication Date |
---|---|
US20180173526A1 true US20180173526A1 (en) | 2018-06-21 |
Family
ID=60813585
Family Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US15/385,171 Abandoned US20180173526A1 (en) | 2016-12-20 | 2016-12-20 | Application lifecycle management system |
US16/727,083 Active US11487536B2 (en) | 2016-12-20 | 2019-12-26 | System for automating user-defined actions for applications executed using virtual machines in a guest system |
Family Applications After (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US16/727,083 Active US11487536B2 (en) | 2016-12-20 | 2019-12-26 | System for automating user-defined actions for applications executed using virtual machines in a guest system |
Country Status (3)
Country | Link |
---|---|
US (2) | US20180173526A1 (en) |
EP (1) | EP3340034A1 (en) |
CN (1) | CN108205463B (en) |
Cited By (45)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US10303522B2 (en) * | 2017-07-01 | 2019-05-28 | TuSimple | System and method for distributed graphics processing unit (GPU) computation |
US20190190778A1 (en) * | 2017-12-20 | 2019-06-20 | Hewlett Packard Enterprise Development Lp | Distributed lifecycle management for cloud platforms |
US10447648B2 (en) | 2017-06-19 | 2019-10-15 | Amazon Technologies, Inc. | Assignment of a POP to a DNS resolver based on volume of communications over a link between client devices and the POP |
US10469355B2 (en) | 2015-03-30 | 2019-11-05 | Amazon Technologies, Inc. | Traffic surge management for points of presence |
US10503613B1 (en) | 2017-04-21 | 2019-12-10 | Amazon Technologies, Inc. | Efficient serving of resources during server unavailability |
US10506029B2 (en) | 2010-01-28 | 2019-12-10 | Amazon Technologies, Inc. | Content distribution network |
US10511567B2 (en) | 2008-03-31 | 2019-12-17 | Amazon Technologies, Inc. | Network resource identification |
US10516590B2 (en) | 2016-08-23 | 2019-12-24 | Amazon Technologies, Inc. | External health checking of virtual private cloud network environments |
US10523783B2 (en) | 2008-11-17 | 2019-12-31 | Amazon Technologies, Inc. | Request routing utilizing client location information |
US10530874B2 (en) | 2008-03-31 | 2020-01-07 | Amazon Technologies, Inc. | Locality based content distribution |
US10542079B2 (en) | 2012-09-20 | 2020-01-21 | Amazon Technologies, Inc. | Automated profiling of resource usage |
US10554748B2 (en) | 2008-03-31 | 2020-02-04 | Amazon Technologies, Inc. | Content management |
US10592578B1 (en) | 2018-03-07 | 2020-03-17 | Amazon Technologies, Inc. | Predictive content push-enabled content delivery network |
US10616250B2 (en) | 2016-10-05 | 2020-04-07 | Amazon Technologies, Inc. | Network addresses with encoded DNS-level information |
US10623408B1 (en) | 2012-04-02 | 2020-04-14 | Amazon Technologies, Inc. | Context sensitive object management |
US10645149B2 (en) | 2008-03-31 | 2020-05-05 | Amazon Technologies, Inc. | Content delivery reconciliation |
US10645056B2 (en) | 2012-12-19 | 2020-05-05 | Amazon Technologies, Inc. | Source-dependent address resolution |
US10666756B2 (en) | 2016-06-06 | 2020-05-26 | Amazon Technologies, Inc. | Request management for hierarchical cache |
US10691752B2 (en) | 2015-05-13 | 2020-06-23 | Amazon Technologies, Inc. | Routing based request correlation |
US10728133B2 (en) | 2014-12-18 | 2020-07-28 | Amazon Technologies, Inc. | Routing mode and point-of-presence selection service |
US10742550B2 (en) | 2008-11-17 | 2020-08-11 | Amazon Technologies, Inc. | Updating routing information based on client location |
US10778554B2 (en) | 2010-09-28 | 2020-09-15 | Amazon Technologies, Inc. | Latency measurement in resource requests |
US10785037B2 (en) | 2009-09-04 | 2020-09-22 | Amazon Technologies, Inc. | Managing secure content in a content delivery network |
US10783077B2 (en) | 2009-06-16 | 2020-09-22 | Amazon Technologies, Inc. | Managing resources using resource expiration data |
US10797995B2 (en) | 2008-03-31 | 2020-10-06 | Amazon Technologies, Inc. | Request routing based on class |
US10831549B1 (en) * | 2016-12-27 | 2020-11-10 | Amazon Technologies, Inc. | Multi-region request-driven code execution system |
US10862852B1 (en) | 2018-11-16 | 2020-12-08 | Amazon Technologies, Inc. | Resolution of domain name requests in heterogeneous network environments |
US10931738B2 (en) | 2010-09-28 | 2021-02-23 | Amazon Technologies, Inc. | Point of presence management in request routing |
US10938884B1 (en) | 2017-01-30 | 2021-03-02 | Amazon Technologies, Inc. | Origin server cloaking using virtual private cloud network environments |
US10951725B2 (en) | 2010-11-22 | 2021-03-16 | Amazon Technologies, Inc. | Request routing processing |
US10958501B1 (en) | 2010-09-28 | 2021-03-23 | Amazon Technologies, Inc. | Request routing information based on client IP groupings |
US11025747B1 (en) | 2018-12-12 | 2021-06-01 | Amazon Technologies, Inc. | Content request pattern-based routing system |
US11038778B2 (en) * | 2018-12-11 | 2021-06-15 | Vmware, Inc. | Methods and systems that provision distributed applications that invoke functions provided by a distributed-function-as-a-service feature |
US11075987B1 (en) | 2017-06-12 | 2021-07-27 | Amazon Technologies, Inc. | Load estimating content delivery network |
US11108729B2 (en) | 2010-09-28 | 2021-08-31 | Amazon Technologies, Inc. | Managing request routing information utilizing client identifiers |
US11134134B2 (en) | 2015-11-10 | 2021-09-28 | Amazon Technologies, Inc. | Routing for origin-facing points of presence |
US11194719B2 (en) | 2008-03-31 | 2021-12-07 | Amazon Technologies, Inc. | Cache optimization |
US11290418B2 (en) | 2017-09-25 | 2022-03-29 | Amazon Technologies, Inc. | Hybrid content request routing system |
US11297140B2 (en) | 2015-03-23 | 2022-04-05 | Amazon Technologies, Inc. | Point of presence based data uploading |
US11303717B2 (en) | 2012-06-11 | 2022-04-12 | Amazon Technologies, Inc. | Processing DNS queries to identify pre-processing information |
US11336712B2 (en) | 2010-09-28 | 2022-05-17 | Amazon Technologies, Inc. | Point of presence management in request routing |
US11392675B2 (en) * | 2017-06-21 | 2022-07-19 | Amazon Technologies, Inc. | Request authorization using recipe-based service coordination |
US11457088B2 (en) | 2016-06-29 | 2022-09-27 | Amazon Technologies, Inc. | Adaptive transfer rate for retrieving content from a server |
US11507653B2 (en) * | 2018-08-21 | 2022-11-22 | Vmware, Inc. | Computer whitelist update service |
US11604667B2 (en) | 2011-04-27 | 2023-03-14 | Amazon Technologies, Inc. | Optimized deployment based upon customer locality |
Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20070021995A1 (en) * | 2005-07-20 | 2007-01-25 | Candemir Toklu | Discovering patterns of executions in business processes |
US8099480B1 (en) * | 2008-11-25 | 2012-01-17 | Google Inc. | Scalable workflow design for automated service management |
US20130191759A1 (en) * | 2012-01-19 | 2013-07-25 | International Business Machines Corporation | Systems and methods for detecting and managing recurring electronic communications |
US20150304175A1 (en) * | 2012-12-03 | 2015-10-22 | Hewlett-Packard Development Company, L.P. | Binding of application and infrastructure blueprints |
US20160004531A1 (en) * | 2013-03-15 | 2016-01-07 | Sanctum Solutions, Inc. | Interactive content development |
Family Cites Families (20)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5729746A (en) * | 1992-12-08 | 1998-03-17 | Leonard; Ricky Jack | Computerized interactive tool for developing a software product that provides convergent metrics for estimating the final size of the product throughout the development process using the life-cycle model |
US8225317B1 (en) | 2009-04-17 | 2012-07-17 | Symantec Corporation | Insertion and invocation of virtual appliance agents through exception handling regions of virtual machines |
US9134982B2 (en) * | 2010-01-10 | 2015-09-15 | Microsoft Technology Licensing, Llc | Automated configuration and installation of virtualized solutions |
US8910155B1 (en) | 2010-11-02 | 2014-12-09 | Symantec Corporation | Methods and systems for injecting endpoint management agents into virtual machines |
US20120144489A1 (en) | 2010-12-07 | 2012-06-07 | Microsoft Corporation | Antimalware Protection of Virtual Machines |
US9003402B1 (en) | 2010-12-15 | 2015-04-07 | Symantec Corporation | Method and system for injecting function calls into a virtual machine |
US8862933B2 (en) * | 2011-02-09 | 2014-10-14 | Cliqr Technologies, Inc. | Apparatus, systems and methods for deployment and management of distributed computing systems and applications |
CN102681899B (en) * | 2011-03-14 | 2015-06-10 | 金剑 | Virtual computing resource dynamic management system of cloud computing service platform |
US8656398B2 (en) * | 2011-05-03 | 2014-02-18 | Ericsson Television Inc | Synchronization of workflows in a video file workflow system |
US9210162B2 (en) * | 2012-05-02 | 2015-12-08 | Microsoft Technology Licensing, Llc | Certificate based connection to cloud virtual machine |
US9311119B2 (en) * | 2012-05-30 | 2016-04-12 | Red Hat, Inc. | Reconfiguring virtual machines |
US8825550B2 (en) | 2012-08-23 | 2014-09-02 | Amazon Technologies, Inc. | Scaling a virtual machine instance |
CN102915255A (en) * | 2012-09-27 | 2013-02-06 | 曙光信息产业(北京)有限公司 | Cloud computing service system and method for massive dataset parallel computation |
US9495395B2 (en) * | 2013-04-11 | 2016-11-15 | Oracle International Corporation | Predictive diagnosis of SLA violations in cloud services by seasonal trending and forecasting with thread intensity analytics |
US9218176B1 (en) * | 2014-06-13 | 2015-12-22 | International Business Machines Corporation | Software deployment in a distributed virtual machine environment |
US20160004628A1 (en) * | 2014-07-07 | 2016-01-07 | Unisys Corporation | Parallel test execution framework for multiple web browser testing |
US11265202B2 (en) * | 2015-12-04 | 2022-03-01 | Vmware, Inc. | Integrated automated application deployment |
US10387181B2 (en) * | 2016-01-12 | 2019-08-20 | International Business Machines Corporation | Pre-deployment of particular virtual machines based on performance and due to service popularity and resource cost scores in a cloud environment |
US10120738B2 (en) * | 2016-06-24 | 2018-11-06 | Vmware, Inc. | Hypervisor techniques for performing non-faulting reads in virtual machines |
US10210074B1 (en) * | 2018-06-07 | 2019-02-19 | Capital One Services, Llc | Performance testing platform that enables reuse of automation scripts and performance testing scalability |
-
2016
- 2016-12-20 US US15/385,171 patent/US20180173526A1/en not_active Abandoned
-
2017
- 2017-12-08 EP EP17206209.3A patent/EP3340034A1/en active Pending
- 2017-12-20 CN CN201711379415.4A patent/CN108205463B/en active Active
-
2019
- 2019-12-26 US US16/727,083 patent/US11487536B2/en active Active
Patent Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20070021995A1 (en) * | 2005-07-20 | 2007-01-25 | Candemir Toklu | Discovering patterns of executions in business processes |
US8099480B1 (en) * | 2008-11-25 | 2012-01-17 | Google Inc. | Scalable workflow design for automated service management |
US20130191759A1 (en) * | 2012-01-19 | 2013-07-25 | International Business Machines Corporation | Systems and methods for detecting and managing recurring electronic communications |
US20150304175A1 (en) * | 2012-12-03 | 2015-10-22 | Hewlett-Packard Development Company, L.P. | Binding of application and infrastructure blueprints |
US20160004531A1 (en) * | 2013-03-15 | 2016-01-07 | Sanctum Solutions, Inc. | Interactive content development |
Cited By (64)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US10554748B2 (en) | 2008-03-31 | 2020-02-04 | Amazon Technologies, Inc. | Content management |
US11909639B2 (en) | 2008-03-31 | 2024-02-20 | Amazon Technologies, Inc. | Request routing based on class |
US10797995B2 (en) | 2008-03-31 | 2020-10-06 | Amazon Technologies, Inc. | Request routing based on class |
US10771552B2 (en) | 2008-03-31 | 2020-09-08 | Amazon Technologies, Inc. | Content management |
US10645149B2 (en) | 2008-03-31 | 2020-05-05 | Amazon Technologies, Inc. | Content delivery reconciliation |
US11194719B2 (en) | 2008-03-31 | 2021-12-07 | Amazon Technologies, Inc. | Cache optimization |
US10511567B2 (en) | 2008-03-31 | 2019-12-17 | Amazon Technologies, Inc. | Network resource identification |
US11451472B2 (en) | 2008-03-31 | 2022-09-20 | Amazon Technologies, Inc. | Request routing based on class |
US11245770B2 (en) | 2008-03-31 | 2022-02-08 | Amazon Technologies, Inc. | Locality based content distribution |
US10530874B2 (en) | 2008-03-31 | 2020-01-07 | Amazon Technologies, Inc. | Locality based content distribution |
US11283715B2 (en) | 2008-11-17 | 2022-03-22 | Amazon Technologies, Inc. | Updating routing information based on client location |
US10742550B2 (en) | 2008-11-17 | 2020-08-11 | Amazon Technologies, Inc. | Updating routing information based on client location |
US11811657B2 (en) | 2008-11-17 | 2023-11-07 | Amazon Technologies, Inc. | Updating routing information based on client location |
US10523783B2 (en) | 2008-11-17 | 2019-12-31 | Amazon Technologies, Inc. | Request routing utilizing client location information |
US11115500B2 (en) | 2008-11-17 | 2021-09-07 | Amazon Technologies, Inc. | Request routing utilizing client location information |
US10783077B2 (en) | 2009-06-16 | 2020-09-22 | Amazon Technologies, Inc. | Managing resources using resource expiration data |
US10785037B2 (en) | 2009-09-04 | 2020-09-22 | Amazon Technologies, Inc. | Managing secure content in a content delivery network |
US11205037B2 (en) | 2010-01-28 | 2021-12-21 | Amazon Technologies, Inc. | Content distribution network |
US10506029B2 (en) | 2010-01-28 | 2019-12-10 | Amazon Technologies, Inc. | Content distribution network |
US10958501B1 (en) | 2010-09-28 | 2021-03-23 | Amazon Technologies, Inc. | Request routing information based on client IP groupings |
US11336712B2 (en) | 2010-09-28 | 2022-05-17 | Amazon Technologies, Inc. | Point of presence management in request routing |
US11632420B2 (en) | 2010-09-28 | 2023-04-18 | Amazon Technologies, Inc. | Point of presence management in request routing |
US10778554B2 (en) | 2010-09-28 | 2020-09-15 | Amazon Technologies, Inc. | Latency measurement in resource requests |
US11108729B2 (en) | 2010-09-28 | 2021-08-31 | Amazon Technologies, Inc. | Managing request routing information utilizing client identifiers |
US10931738B2 (en) | 2010-09-28 | 2021-02-23 | Amazon Technologies, Inc. | Point of presence management in request routing |
US10951725B2 (en) | 2010-11-22 | 2021-03-16 | Amazon Technologies, Inc. | Request routing processing |
US11604667B2 (en) | 2011-04-27 | 2023-03-14 | Amazon Technologies, Inc. | Optimized deployment based upon customer locality |
US10623408B1 (en) | 2012-04-02 | 2020-04-14 | Amazon Technologies, Inc. | Context sensitive object management |
US11729294B2 (en) | 2012-06-11 | 2023-08-15 | Amazon Technologies, Inc. | Processing DNS queries to identify pre-processing information |
US11303717B2 (en) | 2012-06-11 | 2022-04-12 | Amazon Technologies, Inc. | Processing DNS queries to identify pre-processing information |
US10542079B2 (en) | 2012-09-20 | 2020-01-21 | Amazon Technologies, Inc. | Automated profiling of resource usage |
US10645056B2 (en) | 2012-12-19 | 2020-05-05 | Amazon Technologies, Inc. | Source-dependent address resolution |
US11863417B2 (en) | 2014-12-18 | 2024-01-02 | Amazon Technologies, Inc. | Routing mode and point-of-presence selection service |
US10728133B2 (en) | 2014-12-18 | 2020-07-28 | Amazon Technologies, Inc. | Routing mode and point-of-presence selection service |
US11381487B2 (en) | 2014-12-18 | 2022-07-05 | Amazon Technologies, Inc. | Routing mode and point-of-presence selection service |
US11297140B2 (en) | 2015-03-23 | 2022-04-05 | Amazon Technologies, Inc. | Point of presence based data uploading |
US10469355B2 (en) | 2015-03-30 | 2019-11-05 | Amazon Technologies, Inc. | Traffic surge management for points of presence |
US11461402B2 (en) | 2015-05-13 | 2022-10-04 | Amazon Technologies, Inc. | Routing based request correlation |
US10691752B2 (en) | 2015-05-13 | 2020-06-23 | Amazon Technologies, Inc. | Routing based request correlation |
US11134134B2 (en) | 2015-11-10 | 2021-09-28 | Amazon Technologies, Inc. | Routing for origin-facing points of presence |
US10666756B2 (en) | 2016-06-06 | 2020-05-26 | Amazon Technologies, Inc. | Request management for hierarchical cache |
US11463550B2 (en) | 2016-06-06 | 2022-10-04 | Amazon Technologies, Inc. | Request management for hierarchical cache |
US11457088B2 (en) | 2016-06-29 | 2022-09-27 | Amazon Technologies, Inc. | Adaptive transfer rate for retrieving content from a server |
US10516590B2 (en) | 2016-08-23 | 2019-12-24 | Amazon Technologies, Inc. | External health checking of virtual private cloud network environments |
US11330008B2 (en) | 2016-10-05 | 2022-05-10 | Amazon Technologies, Inc. | Network addresses with encoded DNS-level information |
US10616250B2 (en) | 2016-10-05 | 2020-04-07 | Amazon Technologies, Inc. | Network addresses with encoded DNS-level information |
US11762703B2 (en) | 2016-12-27 | 2023-09-19 | Amazon Technologies, Inc. | Multi-region request-driven code execution system |
US10831549B1 (en) * | 2016-12-27 | 2020-11-10 | Amazon Technologies, Inc. | Multi-region request-driven code execution system |
US10938884B1 (en) | 2017-01-30 | 2021-03-02 | Amazon Technologies, Inc. | Origin server cloaking using virtual private cloud network environments |
US10503613B1 (en) | 2017-04-21 | 2019-12-10 | Amazon Technologies, Inc. | Efficient serving of resources during server unavailability |
US11075987B1 (en) | 2017-06-12 | 2021-07-27 | Amazon Technologies, Inc. | Load estimating content delivery network |
US10447648B2 (en) | 2017-06-19 | 2019-10-15 | Amazon Technologies, Inc. | Assignment of a POP to a DNS resolver based on volume of communications over a link between client devices and the POP |
US11392675B2 (en) * | 2017-06-21 | 2022-07-19 | Amazon Technologies, Inc. | Request authorization using recipe-based service coordination |
US10303522B2 (en) * | 2017-07-01 | 2019-05-28 | TuSimple | System and method for distributed graphics processing unit (GPU) computation |
US11290418B2 (en) | 2017-09-25 | 2022-03-29 | Amazon Technologies, Inc. | Hybrid content request routing system |
US11424981B2 (en) | 2017-12-20 | 2022-08-23 | Hewlett Packard Enterprise Development Lp | Distributed lifecycle management for cloud platforms |
US10587463B2 (en) * | 2017-12-20 | 2020-03-10 | Hewlett Packard Enterprise Development Lp | Distributed lifecycle management for cloud platforms |
US20190190778A1 (en) * | 2017-12-20 | 2019-06-20 | Hewlett Packard Enterprise Development Lp | Distributed lifecycle management for cloud platforms |
US10592578B1 (en) | 2018-03-07 | 2020-03-17 | Amazon Technologies, Inc. | Predictive content push-enabled content delivery network |
US11507653B2 (en) * | 2018-08-21 | 2022-11-22 | Vmware, Inc. | Computer whitelist update service |
US10862852B1 (en) | 2018-11-16 | 2020-12-08 | Amazon Technologies, Inc. | Resolution of domain name requests in heterogeneous network environments |
US11362986B2 (en) | 2018-11-16 | 2022-06-14 | Amazon Technologies, Inc. | Resolution of domain name requests in heterogeneous network environments |
US11038778B2 (en) * | 2018-12-11 | 2021-06-15 | Vmware, Inc. | Methods and systems that provision distributed applications that invoke functions provided by a distributed-function-as-a-service feature |
US11025747B1 (en) | 2018-12-12 | 2021-06-01 | Amazon Technologies, Inc. | Content request pattern-based routing system |
Also Published As
Publication number | Publication date |
---|---|
US20200133666A1 (en) | 2020-04-30 |
CN108205463B (en) | 2023-10-17 |
US11487536B2 (en) | 2022-11-01 |
CN108205463A (en) | 2018-06-26 |
EP3340034A1 (en) | 2018-06-27 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US11487536B2 (en) | System for automating user-defined actions for applications executed using virtual machines in a guest system | |
US10289438B2 (en) | Techniques for coordination of application components deployed on distributed virtual machines | |
US8862933B2 (en) | Apparatus, systems and methods for deployment and management of distributed computing systems and applications | |
CN111580861A (en) | Pattern-based artificial intelligence planner for computer environment migration | |
US20180113799A1 (en) | Model generation for model-based application testing | |
US10284634B2 (en) | Closed-loop infrastructure orchestration templates | |
Zhu et al. | If docker is the answer, what is the question? | |
Ibryam et al. | Kubernetes Patterns | |
US11599813B1 (en) | Interactive workflow generation for machine learning lifecycle management | |
US20190317849A1 (en) | Automatic correcting of computing cluster execution failure | |
Roman et al. | Big data pipelines on the computing continuum: tapping the dark data | |
US20220414547A1 (en) | Machine learning inferencing based on directed acyclic graphs | |
US20220414548A1 (en) | Multi-model scoring in a multi-tenant system | |
Dhakate et al. | Distributed cloud monitoring using Docker as next generation container virtualization technology | |
Bai | Programming Microsoft Azure Service Fabric | |
Giannakopoulos et al. | Recovering from cloud application deployment failures through re-execution | |
US20230032516A1 (en) | Common platform for implementing rpa services on customer premises | |
Kanso et al. | Designing a kubernetes operator for machine learning applications | |
US20240143367A1 (en) | Using rule engine for managing application programming interface objects in an operator framework | |
US20240144048A1 (en) | Using rule engine with backward chaining in a containerized computing cluster | |
Mironov | DevOps pipeline with Docker | |
US20240143368A1 (en) | Using rule engine with polling mechanism for configuration data of a containerized computing cluster | |
McKendrick | Kubernetes for Serverless Applications: Implement FaaS by effectively deploying, managing, monitoring, and orchestrating serverless applications using Kubernetes | |
US20240143369A1 (en) | Using rule engine with push mechanism for configuration data of a containerized computing cluster | |
Erbel | Scientific Workflow Execution Using a Dynamic Runtime Model |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: SCHNEIDER ELECTRIC SOFTWARE, LLC, MASSACHUSETTS Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:PRINSLOO, JOHAN;TARCHA, GEOFFREY;LI, ROY;AND OTHERS;SIGNING DATES FROM 20170104 TO 20170105;REEL/FRAME:040901/0594 |
|
AS | Assignment |
Owner name: SCHNEIDER ELECTRIC SOFTWARE, LLC, CALIFORNIA Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:INVENSYS SYSTEMS, INC.;REEL/FRAME:044901/0741 Effective date: 20161221 |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: RESPONSE TO NON-FINAL OFFICE ACTION ENTERED AND FORWARDED TO EXAMINER |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: FINAL REJECTION MAILED |
|
STCB | Information on status: application discontinuation |
Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION |