Techniques for generating distributed interface components.

Abstract

Techniques are disclosed for efficient generation and maintenance of interface components in an Infrastructure as a Service (IaaS) environment. A system may receive a request to display a dashboard of components. A declarative metadata set for the components is generated and a versatile agent parses the declarative metadata set. The versatile agent may be replicated according to the parsed declarative definition to create multiple instances of the versatile agent that correspond to one or more determined interface components. The multiple instances of the versatile agent may then generate and maintain the interface components in real time. Generation of the components may be distributed across systems to prevent excessive data transfer and wasteful communication.

Description

[Technical field]

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS This application is a PCT application and claims the benefit of and priority under 35 U.S.C. §119(e) to U.S. Provisional Application No. 17 / 389,116, filed July 29, 2021, and entitled “TECHNIQUES FOR DISTRIBUTED INTERFACE COMPONENT GENERATION,” the contents of which are incorporated herein by reference in their entirety for all purposes. [Background technology]

[0002] background Cloud-based service providers offer a wide variety of services to their customers. Customers can implement a vast number of programs and services through their service providers. Many of these services are complex and require large amounts of data to function. Service providers may choose to provide a visual interface to access and monitor this information. A comprehensive modular digital interface may present customers with a simplified view of their active services. The modular digital interface displays data and interactive components that correspond to the customer's active services and may be customizable to display them in a format most desirable to the customer. Summary of the Invention [Problem to be solved by the invention]

[0003] To enhance the customer experience, interactive components of an interface can be generated and maintained. However, displaying and maintaining multiple individual components on multiple customized, personalized interfaces for multiple customers is resource intensive. Communication between the customer and the service provider is numerous and inefficient, leading to a significant waste of system resources. Depending on the number of customers utilizing these processes, the resource waste increases exponentially as each customer implements one or more personalized interfaces. The method of displaying and managing the individual components on the interface can be repetitive and inefficient, leading to further waste of resources and significant problems for the service provider system. [Means for solving the problem]

[0004] overview Aspects of the present disclosure include techniques for generating and maintaining modular interfaces with versatile component agents. The versatile component agents can provide streamlined digital components that are utilized to parse module-related declarative metadata to build interfaces. To efficiently distribute component management duties, multiple instances of versatile component agents, or "versatile agents," can be created. Versatile agent instances can also be further utilized in distributed systems. The versatile agents can be hosted within a component generation engine that is communicatively coupled to a server system. The server system stores and processes data on behalf of the service provider, while the component generation engine and associated versatile agents use the processed data to perform interface generation on behalf of the client.

[0005] An exemplary method includes receiving declarative metadata for displaying one or more visual components on an interface, parsing the declarative metadata to determine one or more visual components to be displayed on the interface, replicating a component agent for each particular visual component of the one or more visual components to be displayed on the interface to create a plurality of component agents, and generating one or more sets of rendering data, each particular set of the one or more sets of rendering data being generated by a particular component agent of the plurality of component agents corresponding to a particular visual component of the one or more visual components and executable to render the one or more visual components. The declarative metadata can be received by a client device from a server device. The server device can be configured to generate the declarative metadata. The generation of the declarative metadata by the server device may be triggered by a request from the client device for a component of the modular interface provided by the server device and / or a request from the client device for data related to the component of the modular interface. The request can be sent by the client device to the server device. The server device can simultaneously serve a plurality of client devices similar to the client device, each of the plurality of client devices individually requesting a component of the modular interface and / or data related to the component of the modular interface.

[0006] Aspects of the present disclosure further include distributed data sharing across separate devices. An exemplary method includes receiving declarative metadata, at least a portion of the declarative metadata corresponding to one or more visual components to be displayed on the interface, the method further includes parsing the declarative metadata to determine the one or more visual components, replicating a component agent for each visual component of the one or more visual components to create a plurality of component agents, and generating one or more sets of rendering data, each set of the one or more sets of rendering data generated by a component agent of the plurality of component agents and corresponding to a particular visual component of the one or more visual components, the rendering data being executable to render the one or more visual components. Aspects of the present disclosure further include executing the rendering data to cause the one or more visual components to be displayed on the interface.

[0007] Aspects of the present disclosure further include detecting and responding to an interaction with the displayed components. Exemplary methods include determining one or more interaction responses corresponding to the one or more visual components based at least in part on the declarative metadata, detecting input corresponding to an interaction with the one or more visual components displayed on the interface, and, in response, performing the one or more interaction responses. In some exemplary methods, the one or more interaction responses include at least a component update response that updates at least the displayed visual component of the one or more displayed visual components by updating at least one set of rendering data of the one or more sets of rendering data.

[0008] Another exemplary method further includes the above step of the component agents parsing the declarative metadata to determine the number of component agents to be replicated to create the multiple component agents.

[0009] Aspects of the present disclosure further include sharing data resources among the replicated multi-purpose agent instances to efficiently manage components and interfaces. An exemplary method includes the steps above and further includes transmitting, from a first component agent of the plurality of component agents, at least a portion of a set of rendering data generated by the first component agent to a second component agent of the plurality of component agents, wherein the set of rendering data generated by the second component agent is generated based at least in part on the portion of the set of rendering data transmitted by the first component agent.

[0010] Aspects of the disclosure relate to utilizing dashboard data to build declarative metadata for components of a dashboard. An example includes the above steps in which the declarative metadata for displaying one or more visual components on an interface corresponds to dashboard data that represents a particular configuration of one or more visual components in a dashboard interface. The dashboard data can be built from a catalog of components to display in the dashboard. An exemplary method includes receiving a list of a plurality of visual components, the plurality of visual components including one or more visual components, the method further includes receiving a selection of one or more visual components from the list of the plurality of visual components, generating dashboard data based on the selection of the one or more visual components, and generating declarative metadata based on the dashboard data. The selected components of the dashboard data can then be used to generate declarative metadata for building and displaying the dashboard.

[0011] Aspects of the disclosure relate to utilizing service metrics and measurements as part of a component for display on a dashboard interface. An example method includes the steps above and further includes receiving service data, the service data corresponding to one or more metrics of one or more services associated with one or more visual components, and one or more sets of rendering data are generated based at least in part on the declarative metadata and the service data.

[0012] Another aspect of the present disclosure comprises a system comprising one or more processors and a non-transitory computer-readable medium comprising instructions that, when executed by the one or more processors, cause the one or more processors to perform the method described above.

[0013] Another aspect of the disclosure comprises a non-transitory computer-readable medium including instructions that, when executed by one or more processors, cause the one or more processors to perform the above-described method.

[0014] These exemplary embodiments are mentioned not to limit or define the present disclosure, but to provide examples to aid in understanding the present disclosure. Additional embodiments are discussed in the detailed description, and further description is provided therein.

[0015] The features, embodiments, and advantages of the present disclosure will be better understood from the following detailed description when taken in conjunction with the accompanying drawings. [Brief description of the drawings]

[0016] [Figure 1] FIG. 1 is a block diagram of a distributed infrastructure-as-a-service system for generating visual components in accordance with certain embodiments of the present disclosure. [Diagram 2] FIG. 1 is a block diagram of a component facilitation system according to certain embodiments of the present disclosure. [Diagram 3]FIG. 2 is a block diagram of a client engine system according to certain embodiments of the present disclosure. [Figure 4] FIG. 2 is a block diagram illustrating interactions between a client engine system and subsystems of a component facilitation system according to certain embodiments of the present disclosure. [Diagram 5] FIG. 2 illustrates an example flowchart of a process for interface component generation using a versatile agent in accordance with certain embodiments of the present disclosure. [Figure 6] FIG. 2 illustrates an exemplary flow chart of a distributed system and process for interface component generation using versatile agents in accordance with certain embodiments of the present disclosure. [Figure 7] FIG. 1 is a block diagram of a distributed system including a dashboard library and a dashboard engine for generating interfaces in accordance with certain embodiments of the present disclosure. [Figure 8] FIG. 2 illustrates an example graphical interface for component utilization in accordance with certain embodiments of the present disclosure. [Figure 9] FIG. 1 is a block diagram illustrating one pattern for implementing a cloud infrastructure as a service system in accordance with at least one embodiment. [Figure 10] FIG. 2 is a block diagram illustrating another pattern for implementing a cloud infrastructure as a service system in accordance with at least one embodiment. [Figure 11] FIG. 2 is a block diagram illustrating another pattern for implementing a cloud infrastructure as a service system in accordance with at least one embodiment. [Figure 12] FIG. 2 is a block diagram illustrating another pattern for implementing a cloud infrastructure as a service system in accordance with at least one embodiment. [Figure 13] FIG. 1 is a block diagram illustrating an example computer system in accordance with at least one embodiment. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0017] Detailed Description In the following description, for purposes of explanation, specific details are set forth in order to provide a thorough understanding of particular embodiments. However, it will be apparent that various embodiments may be practiced without these specific details. The drawings and description are not intended to be limiting.

[0018] A service provider may offer services to which customers (e.g., subscribers) of the services offered may subscribe. Customers often utilize these services to store, manage, and update their data using server equipment owned by the service provider. For example, one service may store a customer's data in a database, another may allow a customer to access a virtual machine, and yet another may allow a customer to implement automated customer service for their clients. Customers utilizing these functions often require comprehensive digital interfaces to view and manage data related to the use of the individual services. For example, a food vendor may utilize a service provider's web hosting services to store and manage interactive menus of food items sold by the food vendor. The food vendor may also utilize a service provider's virtual processing environment to accept and process monetary payments for the vendor's goods. The food vendor may further utilize a service provider's data storage services to store business figures related to the vendor's sales. The services utilized by customers and the data generated therefrom may be numerous and complex. Each of these vendor services and their associated data may be represented by components on an interface that the vendor manages through the service provider.

[0019] Because the services utilized by a service provider vary for each connected customer, the service provider may want to provide customers with a modular, customizable interface to better personalize the customer experience. A modular interface is an interface that typically includes a shell (e.g., a static interface background) and one or more components (e.g., individual panels on a background that display interactive components related to the utilized service). A customizable interface is an interface that allows a customer to take and select the components that are displayed on a particular background. To enhance the customer experience, an interface may incorporate both of these features. The interface conveys relevant aspects of the services utilized by the customer at a single digital location. With an existing modular interface, a customer may select one or more predefined components to display in the shell. For example, a service provider may store several interface components that are pre-built based on predefined code that executes and displays on the shell to create the interface. Each individual component is modular and executes its code instructions independently of other interface components. A customer may have multiple interfaces of "dashboards" of components. For example, a customer may have separate dashboards for components related to business operations, data management operations, etc.

[0020] Independent execution of each interface component promotes modular functionality, but leads to repetitive, inefficient, and / or insecure performance by the interface and corresponding services. As an example, two components displaying the same or very similar information may fetch the same data independently, effectively doubling the utilization of server resources to display the components. If a food vendor places two components on an interface, one for sales revenue and one for sales margin, the two components will execute and display the information independently of each other. Thus, both components will retrieve the same sales data twice, duplicating resource expenditures. As another example, each individual interface component must contain separate code instructions to perform steps specific to that component. Because code instructions are a significant portion of the size of a component, utilizing multiple components with similar code will correspondingly increase resource utilization. When multiple components execute code on the same system to render the components, the system will experience significant resource waste.

[0021] Service providers offering interactive digital interfaces are subject to the above problems. The problems worsen as the number of customers increases, often causing the service provider's systems to slow down or malfunction. For example, a service provider offering cloud-based services to millions of customers typically needs to maintain tens of millions of individual modular components. The methods and processes described herein enable maintenance of digital interfaces by utilizing versatile agents in a distributed system. The versatile agents can be replicated any number of times to manage individual interface components with minimal input. For example, a component may contain only a declarative definition and parameters to implement the interface component. The versatile agents then parse the declarative definition, fetch customer data according to the parameters, and implement the component independently. Distributing the generation of components to client-side engines and the storage of data to a central system reduces costly data transfer and communication.

[0022] A versatile agent may be replicated in multiple instances to keep different components of the interface separate. Since the versatile agent has the ability to implement multiple different interface components based on the declarative definition, replicated instances of the versatile agent can simultaneously implement different interface components. Instances of the versatile agent can communicate and share data between other actors through a shared communication protocol. The versatile agent can also generate interactive interface components specified in the declarative definition. These components can be maintained and monitored by the versatile agent to respond to interactive input by the customer. Customer-specific parameters that supplement the declarative definition may allow the versatile agent to further customize how it handles interactions.

[0023] The implementation of a versatile agent and distributed system for generating and maintaining multiple interface components has a variety of advantages over previous interface generation methods: Removal of separate code instructions for each component reduces component implementation overhead. Because the versatile agent only needs to parse the declarative definitions to generate the components, the service provider utilizes system resources more efficiently and reduces data bloat during interface implementation. Additionally, the service provider's customers experience a more streamlined approach to generating personalized interfaces.

[0024] Maintaining interface components through versatile agents and their replicated instances means that the versatile agent actors only need to be fetched into memory once to initiate interface generation, saving valuable computing resources. Interaction between agent instances utilizing standard protocols also improves data communication, reducing inefficient resource consumption. Furthermore, implementing components through service provider controlled versatile agents removes a significant barrier to entry for interface generation by eliminating the need for customers to write and implement electronic code instructions. It also improves security by isolating malicious actors from direct access to the code, allowing service providers to securely specify the operating parameters of each versatile agent and each interface component.

[0025] Further distribution of component generation across multiple systems also offers significant advantages. The process of generating multiple interface components can be distributed across multiple systems to conserve resources. A service system may store a repository of components that clients can implement as part of their own interfaces. A component can correspond to a declarative definition that can be parsed by a generation engine residing on a client device. In this way, it is not necessary to pass the entire component and the component code over a communication channel to the engine, but only the annotated declarative definition.

[0026] The declarative definitions can be parsed in a client-side generation engine and combined with client-specific service data to generate annotated rendering data. The rendering data can be executed to display a complete dashboard interface to the customer. The service and client systems can work together to update the interface and interface components in real time. This distributed process reduces the data communicated to a minimal level, preserving existing resources, while preventing resource bottlenecks that would occur if the same system performed each of these steps.

[0027] FIG. 1 is a block diagram of a distributed infrastructure-as-a-service system for generating visual components according to certain embodiments of the present disclosure. The system 100 shown in FIG. 1 comprises systems and devices that are directly or indirectly connected to a network 160. The network 160 may be any communication entity or medium over which data may be transmitted. For example, the network 160 may be the Internet, an intranet, a cloud-based network, a local area network, a hardline connection, a wireless signal, a virtual network, or other medium for network communication between devices. Those skilled in the art will recognize various networks that may be used, some of which are described below.

[0028] Network 160 may be communicatively coupled to client engine system 120. The client engine system may be implemented by client device 110. Client device 110 may be any type of device operating in any manner necessary to perform the embodiments described herein, and there is no limit to the number of client devices that may comprise an embodiment. In various embodiments, client device 110 is a device operable by a client and / or customer to request, generate, display, and / or interact with component interfaces.

[0029] The client device 110 may implement the client engine system 120 as a digital program, application, or set of instructions executed on the client device 110. The client engine system 120 may be a system comprising software, hardware, or a combination of both operable to execute the processes and methods described herein according to various embodiments. The client engine system 120 may further comprise several subsystems. The subsystems described herein may refer to systems operating within a larger host system to execute more specific and specialized processes essential to the functionality of the host system.

[0030] The client engine system 120 may comprise a dashboard display subsystem 121. The dashboard display subsystem 121 may be a subsystem operable to display the dashboard and various dashboard components on an electronic display. The client engine system 120 may further comprise an input handling subsystem 122. The input handling subsystem 122 may be a subsystem operable to detect and respond to interactive inputs made by a client and corresponding to the dashboard to be displayed. In various embodiments, the input handling subsystem 122 may implement one or more input listeners as separate subsystems for detecting one or more types of input and / or input contexts. The client engine system 120 may further comprise a dashboard engine subsystem 123. The dashboard engine subsystem 123 may be a subsystem operable to parse one or more declarative definitions of components and generate rendering data for creating a digital dashboard. In various embodiments, the input handling subsystem 123 may implement one or more versatile agents for processing and creating dashboard components in parallel. A more detailed view of the client engine system 120 is shown in FIG. 3.

[0031] Network 160 may further be communicatively coupled to component facilitation system 140. Component facilitation system 140 may be implemented by server 130. Server 130 may be any type of device operating in any manner necessary to perform the embodiments described herein, and there is no limit to the number of server devices that may comprise an embodiment. In various embodiments, server 130 is a device operable by a service provider and / or administrator to store, transmit, receive, render, generate, and manage generation data associated with component-based interfaces.

[0032] The server 130 can implement the component facilitation system 140 as a digital program, application, or set of instructions executed on the server 130. The component facilitation system 140 can be a system comprising software, hardware, or a combination of both operable to execute the processes and methods described herein according to various embodiments. In various embodiments, the component facilitation system 140 utilizes data transmitted to and stored therein to cause rendering of the components on an interface displayable on a client device, such as the client device 110. The component facilitation system 140 can further comprise several subsystems / independent systems operating as part of the component facilitation system 140.

[0033] The catalog subsystem 141 may be a subsystem for storing and providing component data and / or plug-in information related to one or more renderable components. The catalog subsystem 141 may be configured to store, access, and / or utilize a list of components or data related to the components to operate the catalog. For example, the catalog subsystem 141 may host a catalog of components that may be included in a dashboard display. A client may specify a subset of components selected from the catalog to display as part of the dashboard.

[0034] The component facilitation system 140 may further comprise a service data subsystem 142. The service data subsystem 142 may be a subsystem configured to provide service data and metrics related to services utilized by clients to facilitate a dashboard. A service may be a service provided to a client as part of a commercial exchange between the client and a service provider. For example, a client may utilize one or more cloud-based services provided by a service provider. The service provider may store service data (i.e., metrics related to the operation of the service) in the service data subsystem 142. The service data may be retrieved, transformed, and / or otherwise utilized to display a dashboard including the service data.

[0035] The component facilitation system 140 may further comprise a dashboard creation subsystem 143. The dashboard creation subsystem 143 may be a subsystem operable to create a dashboard and implement components in the dashboard. For example, the dashboard creation subsystem 143 may be configured to receive a dashboard specification from the client engine system 120. The dashboard creation subsystem 143 may utilize the dashboard specification to create a new instance of a dashboard interface associated with the client.

[0036] The network 160 may further be communicatively connected to the data storage device 150. The data storage device 150 may comprise one or more electronic data storage memories to facilitate the embodiments described herein. The storage device may refer to any physical, electronic, and / or cloud-based storage device to facilitate the embodiments described herein. The data memory may be an internal memory, a storage memory or a medium that stores electronic data internally, externally, or separately from another system. For example, the data storage device 150 may store data or information related to a communication protocol between the client engine system 120 and the component facilitation system 140, thereby allowing the network 160 to interact with both entities. It will be understood that the data storage device 150 or any other storage device may be used in any manner necessary to facilitate the processes described herein.

[0037] FIG. 2 is a block diagram of a component facilitation system 140 according to certain embodiments of the present disclosure. Specifically, FIG. 2 illustrates the component facilitation system 140 and various subsystems included therein. The component facilitation system 140 can include a catalog subsystem 141. The catalog subsystem 141 can include a component cataloger 200. In various embodiments, the component cataloger can be a subsystem that catalogs a number of components to create a component list. The component list can correspond to a number of visual components that are displayed on a dashboard as part of an interface. For example, the component cataloger 200 can be communicatively coupled to a component manifest ingestion module and a number of plugins that store the components. The component cataloger can use the component manifest to identify a number of components in the plugins and create a component list. The component list can be a list of components received from a component repository.

[0038] The catalog subsystem 141 may further comprise a component repository 210. The component repository 210 may be a repository of components or component information implementable in a dashboard interface. In various embodiments, the component repository 210 receives a component list from the component cataloger 200. The component repository 210 or a similar entity may then identify and group one or more sets of declarative metadata associated with the visual components identified on the component list. For example, the component cataloger 200 may send a component list to the component repository 210 that specifies the components of a digital component "widget" to be generated for display on the dashboard interface. The component repository 210 may identify declarative metadata associated with the functionality of the digital component for further processing.

[0039] The component facilitation system 140 may include a service data subsystem 142. The service data subsystem 142 may include query instructions 220. The query instructions 220 may be instructions for receiving and / or processing queries for service data related to the dashboard. In various embodiments, the query instructions 220 may be configured to extract one or more requests for service data from the received service data queries.

[0040] The service data subsystem 142 may further comprise service data sharing instructions 230. The service data sharing instructions 230 may be a set of instructions for obtaining and transmitting service data related to services operable by the service provider. In various embodiments, the service data sharing instructions 230 receive an indication of the service data specified by the query instructions 220. The service data sharing instructions 230 may then responsively obtain one or more sets of service data related to the service. For example, the query instructions 220 may specify one or more metrics related to the operation of the service and to be displayed as part of a dashboard interface. The service data sharing instructions 230 may identify related services running at the service provider, obtain metrics related to the operation of the service, and transmit the service data back to the querying entity.

[0041] The component facilitation system 140 may include a dashboard creation subsystem 143. The dashboard creation subsystem 143 may include dashboard component display instructions 240. The component display instructions 240 may be a set of instructions that cause the display of a component on a visual dashboard interface or the creation of data to do the same. In various embodiments, the dashboard component display instructions 240 receive a display, such as display data generated by the query instructions 220. The dashboard component display instructions 240 may cause the display data to be transmitted to a device with a digital display, such as the client device 120. The display data may then be used to display the component on the digital display. In various embodiments, the dashboard component display instructions 240 generate the display data based on the component to be rendered.

[0042] The dashboard creation subsystem 143 may further comprise a dashboard library 250. The dashboard library 250 may be a storage or repository containing data for generating a portion of a particular interface / dashboard. In various embodiments, the dashboard library 250 includes one or more common components that can be displayed directly on an interface without having to be generated prior to display. In various embodiments, the dashboard library 250 includes one or more dashboard shells for generating a dashboard interface in which the components can be implemented. In various embodiments, dashboard data from the dashboard library 250 is sent to a client device, such as the client device 120, to generate a dashboard shell in which the components are implemented as they become available for display from the dashboard component display instructions 240.

[0043] The component facilitation system 140 may further comprise a rendering subsystem 260. The rendering subsystem 260 may be configured to render components for display on a dashboard as part of a server-side rendering configuration. For example, the rendering subsystem 260 may receive dashboard data generated by the dashboard creation subsystem 143. The rendering subsystem 260 may convert the dashboard data into rendering data that may be sent to a client device to display a rendered version of the dashboard interface. Further examples of interactions between the client device 120 and the subsystems of the component facilitation system 140 are described below with respect to FIG. 4.

[0044] 3 is a block diagram of a client engine system according to certain embodiments of the present disclosure. Specifically, FIG. 3 illustrates client engine system 120 and various subsystems included therein. Client engine system 120 may include dashboard display subsystem 121. Dashboard display subsystem 121 may be a subsystem within client engine system 120 that facilitates display of a dashboard interface on an electronic display of a client device, such as client device 110. In various embodiments, dashboard display subsystem 121 is configured to receive and utilize display data to cause the dashboard interface to be displayed.

[0045] The client engine system 120 may further comprise an input handling subsystem 122. The input handling subsystem 122 may be a subsystem within the client engine system 120 for detecting and handling input. In various embodiments, the input handling subsystem 122 facilitates the use of one or more input listeners to detect interactions and / or inputs from a user of the device. In various embodiments, the input handling subsystem 122 may generate data corresponding to the detected input and transmit the data to the system to cause an update of the corresponding component. For example, in response to detecting an input corresponding to a particular component displayed on the dashboard interface, the input handling subsystem may generate interaction metadata and transmit the interaction metadata to a module that causes a responsive update, such as update instructions 230.

[0046] The client engine system 120 may further comprise a local storage subsystem 300. The local storage subsystem 300 may be a storage device or repository that stores one or more data sets associated with a client device. In various embodiments, the local storage subsystem 300 includes data regarding one or more sets of information associated with the functionality of one or more components. The local storage subsystem 300 may store, transmit, and otherwise utilize this information to facilitate the generation of the components as described herein. For example, as part of the component generation process, the local storage subsystem 300 may transmit associated client data to the generation engine to complete the generation of the component. In an exemplary embodiment, the component may display an indication of a customer's benefits in a widget component on a dashboard interface. The benefits information is stored on the client side of the customer's device. The component may correspond to an incomplete declarative definition that requires client data for display. In this case, the required client data is the benefits data stored on the client side. As part of the generation process, the component generation engine may request the benefits data from the local storage subsystem 300 to complete the generation of the component.

[0047] The client engine system 120 may further comprise a dashboard engine subsystem 123. The dashboard engine subsystem may be a component generation engine that facilitates utilization of versatile agents for generating one or more components as part of the dashboard interface display process. The dashboard engine subsystem 123 may comprise an agent subsystem 310. The agent subsystem 310 may be a subsystem of the dashboard engine subsystem 123 that facilitates creation, maintenance, duplication, and / or deletion of one or more versatile agents for generating components for the dashboard interface.

[0048] The agent subsystem 310 can include a component agent 320. The component agent 320 can be a multi-purpose agent in an instantiated state or in a non-instantiated / stored state as described herein. In various embodiments, the component agent 320 includes data stored in the agent subsystem 310 that is invoked in response to receiving a declarative definition. For example, in response to the client engine system 120 receiving declarative metadata, such as metadata from the component facilitation system 140, the client engine system 120 instantiates the component agent 320 within the dashboard engine subsystem 123. In various embodiments, the component agent 320 receives and parses the declarative metadata to initiate a component generation process. The component agent 320 can include metadata parsing instructions 322. The metadata parsing instructions 322 can be instructions available to the component agent 320 to parse metadata, such as declarative metadata.

[0049] The component agent 320 may further include component generation instructions 324. The component generation instructions 324 may be instructions for generating a component based on the parsed declarative metadata. In various embodiments, the instantiated component agent may be replicated at least once for each component to be generated. In various embodiments, the component agent 320 may retrieve client information from a local storage device, such as the local storage subsystem 300, to drive the generation of the component. The component generation process is further described in FIG. 5. In various embodiments, the component generation instructions 324 of the component agent 320 may be configured to utilize the declarative metadata parsed by the component agent 320 to generate rendering data as part of a client-side rendering configuration. For example, the component agent 320 may parse metadata from a declarative definition and convert the metadata into rendering data that is executable to drive the display of a corresponding visual component of a dashboard interface. The component agent 320 may further include inter-agent communication instructions 326. The inter-agent communication instructions 326 may be instructions for communicating between two or more instantiated component agents as part of the component generation process.

[0050] The dashboard engine subsystem 123 may comprise a service communication subsystem 330. The service communication subsystem 330 may be a subsystem of the client engine system 120 that facilitates communication between one or more services and the client engine system 120. For example, one or more external services related to components, or data necessary to generate the components, may be received from the external services and utilized by the client engine system 120 to generate the one or more components.

[0051] 4 is a block diagram illustrating interactions between client engine system 120 and subsystems of component facilitation system 140 according to certain embodiments of the present disclosure. As shown in FIG. 4, distributed system 400 includes client engine system 120 communicatively coupled to client device 110. Client device 110 may be a device on which a user can specify, generate, view, and / or interact with dashboards. As shown in FIG. 4, within distributed system 400, client engine system 120 may be further communicatively coupled to subsystems of component facilitation system 140 for these purposes.

[0052] The client engine system 120 may be communicatively coupled to a catalog subsystem 141 of the component facilitation system 140. The client engine system 120 may be configured to send a catalog query 410 to the catalog subsystem 141. The catalog query 410 may be a query for a list of components that may be displayed as part of a dashboard interface. In response to receiving the catalog query 410, the catalog subsystem 141 may be configured to send catalog data 420 to the client engine system 120. For example, a user of the client device 110 may utilize the client engine system 120 to query a list of components that may be displayed as part of the user's personal dashboard interface. The catalog subsystem 410 may receive the query and return a list of components to be cataloged to the client engine 120. The client engine 120 may then select components from the component catalog for inclusion in the user's personal dashboard interface. In various embodiments, the catalog subsystem 410 is a widget catalog subsystem. The widget catalog subsystem can store and transmit to the client engine system 120 a list of available widgets for a user of the client device 110 to select, add to a widget component dashboard, configure, or otherwise utilize.

[0053] The client engine system 120 may further be communicatively coupled to a dashboard creation subsystem 143 of the component facilitation system 140. The client engine system 120 may be configured to send new dashboard data 430 corresponding to a desired dashboard configuration to the dashboard creation subsystem 143. In response to receiving the new dashboard data 430, the dashboard creation subsystem 143 may be configured to generate data regarding the configuration of the new dashboard. The dashboard creation subsystem 143 may be configured to send the generated data as updated dashboard data 440 to the client engine system 120. For example, a user of the client device 110 may create a "mock" dashboard that the user would like to see on the client device 110. The client may utilize the client engine system 120 to send the new dashboard data 430 to the dashboard creation subsystem 143, which generates the updated dashboard data 440. The updated dashboard data 440 may include declarative metadata for creating a functional dashboard that corresponds to the "mock" dashboard created by the user. The updated dashboard data 440 may be stored in the dashboard library 250 of the dashboard creation subsystem 250 before being sent to the client engine system 120. In various embodiments not shown in FIG. 4 , the dashboard creation subsystem 143 may utilize a rendering subsystem, such as the rendering subsystem 260, to generate rendering data based on the updated dashboard data 440 as part of a server-side rendering configuration system. In various embodiments, the updated dashboard data 440 includes a declarative definition corresponding to a widget definition, the widget definition including declarative metadata for rendering one or more widget components on a dashboard interface in a customized configuration specified by a user.

[0054] The client engine system 120 may further be communicatively coupled to a service data subsystem 142 of the component facilitation system 140. The client engine system 120 may be configured to send a service query 450 to the service data subsystem 142. The service query 450 may be a query for service data / metrics related to the performance and / or status of one or more services maintained by a service provider. In response to receiving the service query 450, the service data subsystem 142 may be configured to generate service data 460 regarding the performance of the one or more services specified by the service query 450. The service data subsystem 142 may be configured to transmit the generated service data 460 to the client engine system 120. For example, a user of the client device 110 may specify one or more performance metrics of the services utilized by the user that are sought as displayable elements of a dashboard interface. The one or more performance metrics may be combined with one or more components on the dashboard interface to show the performance of these services as part of the dashboard interface. The client may utilize the client engine system 120 to send the service query 450 to the service data subsystem 142, which generates the service data 460. In various embodiments, service data 460 includes widget data that can be utilized by a versatile agent to generate one or more widget components on a dashboard interface. For example, service data 460 can include widget data that can be inserted into one or more component widgets. A widget component can display a portion of the received widget data to display some aspect of the service within the widget component. In various embodiments, service data 460 can include metrics regarding the performance of the service and / or other service data.For example, service data 460 may include metrics, logging data, billing data, search data, etc. related to services operated by the service provider. In various embodiments, the service data relates to aspects of cloud-based services hosted on a cloud infrastructure operated by the service provider. Clients may access or utilize these cloud-based services, and the received service data may relate to aspect / performance data regarding these cloud-based services that the clients may access / use.

[0055] In various embodiments, the component agent 320 in the client engine system 120 can facilitate the display of a dashboard interface through communication with the components facilitation system 140 shown in FIG. 4. For example, a user of the client device 110 can query a list of components from the catalog subsystem 141. The catalog subsystem 141 can send catalog data corresponding to the list of components to be cataloged to the client engine system 120. The user can select a subset of components in a particular configuration to build a dashboard interface. The configuration is packaged as new dashboard data and sent to the dashboard creation subsystem 143. Based on the configuration specified by the dashboard data, the dashboard creation subsystem 143 can generate updated dashboard data in the form of declarative metadata. The declarative metadata can be sent to the client engine system 120 for rendering in a client-side rendering configuration or can be directly rendered in a server-side rendering configuration.

[0056] In a client-side rendering configuration, the declarative metadata is received by a client engine system and a component agent 320, such as a multi-purpose agent, parses the declarative metadata. A number of multi-purpose agents are replicated to build the components specified in the declarative metadata. Once rendering of the components is complete, one or more of the multi-purpose agents can query the service data subsystem 142 for service data to be displayed as part of the dashboard-defined component. The service data subsystem returns the service data to the multi-purpose agent. In an embodiment utilizing a server-side rendering configuration, the service data is sent directly to the dashboard creation subsystem to generate the rendering data.

[0057] Upon returning the client-side rendering configuration, the versatile agent utilizes both the declarative metadata and the service data received from the service data subsystem to generate executable rendering data for displaying the dashboard interface in the configuration specified by the user. The client engine system 120 can use the versatile agent to actively monitor the displayed dashboard components. For example, the versatile agent can periodically fetch new service data from the service data subsystem 142 to update the displayed components in real time. The versatile agent can also react to user input on the displayed components of the dashboard interface and respond accordingly. In various embodiments, the user can edit the configuration of the dashboard interface and the client engine system 120 can send the new dashboard data to the dashboard creation subsystem 143 to receive the updated dashboard data including the updated declarative definition of the new dashboard configuration.

[0058] FIG. 5 illustrates an example flowchart of a process for interface component generation using a versatile agent, according to certain embodiments of the present disclosure. Specifically, FIG. 5 illustrates an example flowchart of a process 500 for generating component renderings for displaying an interface utilizing multiple distributed component agents. The process 500 begins at step 510 by receiving declarative metadata for displaying one or more visual components on an interface. The declarative metadata may be received by the versatile agent as part of the component generation process. For example, the versatile agent may receive a declarative definition corresponding to a configuration of one or more components to be displayed in a dashboard interface. The versatile agent may receive the declarative definition from a separate system, such as a component facilitation system.

[0059] In various further embodiments, the declarative metadata includes static metadata and variable metadata of a particular component, where the static metadata corresponds to one or more known aspects of the particular component being rendered, and the variable metadata corresponds to one or more variable aspects of the particular component being rendered. The one or more variable aspects of the particular component may be aspects unknown to the system generating the declarative metadata and / or aspects that may change during the display period of the dashboard interface. For example, a dashboard component that tracks dynamic upload rates of virtual machines may include both static metadata and variable metadata. The static metadata may specify the particular virtual machine being tracked. The variable metadata may specify a dynamically updated upload rate of the virtual machine that is periodically updated on the displayed dashboard component. In various embodiments, service data received from a service data subsystem is used to implement the variable metadata during generation of the rendering data.

[0060] At step 520, the declarative metadata is parsed to determine one or more visual components. In various embodiments, the declarative metadata is sent to an instance of a versatile agent that parses the declarative definition. In various yet other embodiments, the versatile agent parses the metadata to determine one or more subsets of the declarative metadata that correspond to one or more visual components to be displayed on the interface. In various yet other embodiments, the declarative metadata may be a compilation of one or more declarative data subsets, one or more of which are individually parsable by the versatile agent to determine one or more corresponding visual components to be displayed on the interface.

[0061] At step 530, the component agents are cloned to arrive at a particular visual component of the one or more visual components displayed on the interface. In various embodiments, the component agents are cloned from an original multi-purpose agent that parsed the declarative metadata. In various embodiments, at least one multi-purpose agent is cloned for each visual component that is determined. In various still other embodiments, each cloned multi-purpose agent facilitates the generation of a corresponding visual component.

[0062] At step 540, one or more sets of rendering data executable to display one or more visual components are generated. In various embodiments, each of the replicated multi-use agents utilizes at least a subset of the declarative metadata to generate a corresponding subset of rendering data. For example, based on the analysis of the declarative metadata at step 520, one or more subsets of the declarative metadata may be received by a particular replicated multi-use agent. Each of the replicated multi-use agents may be delegated the subset of the declarative metadata for generating the corresponding visual component. The particular multi-use agent may generate the rendering data using the received subset of the declarative metadata. For example, the multi-use agent may receive the subset of the declarative metadata describing the visual component to be generated and a portion of the service data implementing the variable metadata in the subset of the declarative metadata. The multi-use agent utilizes the data to generate the corresponding subset of the rendering data as a set of rendering data.

[0063] The versatile agent can generate the component based on the declarative metadata from the client device and a subset of the local data. In various embodiments, in response to receiving the subset of the declarative metadata, the replicated versatile agent can query and / or obtain one or more data sets necessary to generate the component. For example, the versatile agent can determine one or more variable data sets that complete the declarative definition based on the received declarative metadata. The versatile agent can then obtain the variable data from a local data source, such as the local storage subsystem 300, and compile a complete declarative data set using the incomplete declarative metadata and the obtained variable data.

[0064] In various embodiments, the versatile agent can use the complete declarative data set to generate rendering data for rendering the visual component. The rendering data may be generated data that, when executed, causes the component to be rendered for placement in a visual interface. For example, the versatile agent can receive the complete declarative data set as input and output rendering data for rendering the component. The generating of the rendering data may include creating a mock or replica of the component by the versatile agent. For example, the versatile agent may use the complete declarative data set to generate a temporary representation of the visual component in a computer memory. The temporary representation may include any information that defines the visual component, such as a location on a digital screen, text or symbols within the component, dynamically updated fields, etc. The versatile agent can then use the temporary representation to generate rendering data for rendering the visual component according to the specifications of the temporary representation. For example, the rendering data may be data executable to create a rendered representation of the visual component in a computer memory according to the specifications generated in the temporary representation.

[0065] In various embodiments, the generation of rendering data by the multi-use agent instances may be performed in parallel. This means that each multi-use agent instance may generate a subset of the rendering data independently of the other multi-use agent instances. In various embodiments, each instance of the multi-use agent is communicatively coupled directly or indirectly to the other multi-use agent instances. The multi-use agents may then share data through a communication protocol, such as the service communication subsystem 330. Sharing data between the multi-use agent instances significantly improves resource utilization by reducing or eliminating redundant data sourcing processes. For example, a first multi-use agent instance may generate rendering data similar to that generated by a second multi-use agent. The first multi-use agent may send the rendering data to the second multi-use agent to prevent the second multi-use agent from using computing resources to generate the same data. In another example, the first multi-use agent may share data used to generate the rendering data to the second multi-use agent to prevent redundant queries for the same local data.

[0066] FIG. 6 illustrates an exemplary flow chart of a distributed system and process for interface component generation using a versatile agent, according to certain embodiments of the present disclosure. Specifically, FIG. 6 illustrates a distributed system implementing a multi-agent facilitation process 600 for displaying and monitoring component interfaces as part of the system's client-side rendering configuration. The distributed system includes a client engine system 120 and a component facilitation system 140 for executing the process 600. The process 600 begins at step 610, where the client engine system 120 generates a request to display a component dashboard. The request to display the component dashboard may be sent from a client requesting display of the component dashboard on an electronic display of a client device. For example, a customer may use a client device 110 running the client engine system 120 to send a request to view a dashboard of components to a service provider's server 130 running the component facilitation system 140. In various embodiments, the request to display the component dashboard includes a client indicator, where the client indicator corresponds to a stored dashboard configuration. In various embodiments, the request to display the component dashboard includes a component manifest that lists a number of desired components for display on the dashboard.

[0067] In step 615, the component facilitation system 140 receives the request from the client engine system 120 and determines the component plug-ins to satisfy the requested dashboard. The component facilitation system 140 can utilize a client-specific component manifest to determine the component plug-ins to satisfy the requested dashboard. In various embodiments, the manifest can be received from the client engine system 120 as part of the request to display the component dashboard. In various embodiments, the component facilitation system 140 stores the component manifest in an internal memory and retrieves the manifest based on the dashboard indicators received from the client engine system 123. Based on the manifest, one or more plug-ins can be identified. A plug-in can be a software package that includes one or more component definitions or functions. Some plug-ins can be stored in the internal memory or can be accessible by the internal memory of the component facilitation system 140. A plug-in can correspond to declarative data for rendering a component on a dashboard interface.

[0068] At step 620, based on the determined component plugin, the component facilitation system 140 generates declarative metadata for component generation. The declarative metadata may be generated based on declarative data obtained from the determined component plugin or based on declarative data obtained from a computer memory that stores declarative data based on the determined component plugin. For example, based on the component manifest, one or more sets of declarative data obtained from the component plugin may be combined to form a set of declarative metadata. The declarative metadata may include one or more sets of static metadata and one or more sets of variable metadata for generating a client-specific visual component.

[0069] In step 625, the client engine system 120 receives the declarative metadata from the component facilitation system 140 and parses the declarative metadata to determine one or more visual components. This may be similar to steps 510 and 520 of process 500. In step 630, based on the determined one or more visual components, the client engine system 120 replicates the component agent into one or more instances of the component agent. This may be similar to step 430 described in process 400. In step 635, the client engine system 120 generates a request for service data used to facilitate the dashboard interface. The request is sent to the component facilitation system 140, which tracks and records metrics regarding the performance of the service.

[0070] In step 640, the component facilitation system 140 obtains service data for completing the visual component. The component facilitation system 140 can use the request generated in block 635 to identify services running on the service provider system and extract metric data that is sent to the client engine system 120.

[0071] In step 645, the client engine system 120 receives the service data from the component facilitation system 140 and generates rendering data for rendering the complete component on a dashboard interface. For example, the client engine system 120 and the versatile agent replicated therein can use the declarative metadata and the service data to compile one or more instances of the complete component and generate rendering data for the complete component.

[0072] In step 650, client engine system 120 utilizes the generated rendering data to display an interface including the component dashboard. In various embodiments, client engine system 120 has previously received a shell dashboard on which the dashboard interface is implemented. The shell dashboard is implemented in real time by the interface data as it is generated. For example, component facilitation system 140 can generate one or more sets of interface data in parallel with the rendering data being generated by client engine system 120 in a client-side rendering configuration. In a server-side rendering configuration, the dashboard components are displayed as they are received from component facilitation system 140 and executed by client engine system 120.

[0073] At step 655, client engine system 120 monitors the displayed interface in real time to determine any changes or interactions with the interface. Monitoring the interface in real time may enable real-time updates of the interface. For example, client engine system 120 may monitor the interface to detect user interactions with the interface. The user interactions may cause a particular component on the dashboard to be updated. Client engine system 120 may cause the component to be updated in response to determining the interaction. For example, if an interaction with the interface causes a widget component to be updated, the component engine may interact with component facilitation system 140 to cause the component to be regenerated or updated. At step 660, component facilitation system 140 simultaneously with client engine system 120 monitors the displayed interface in real time to determine any changes or interactions with the component. By simultaneously monitoring the interface, both systems may operate in response to interactions with the interface rather than in response to communications with the other system.

[0074] 7 is a block diagram of a distributed system including a dashboard library and a dashboard engine for generating an interface according to certain embodiments of the present disclosure. Specifically, FIG. 7 illustrates a block diagram of an example interface structure and entities that facilitate display of the interface. The block diagram shown in FIG. 7 may illustrate an illustrative flow for creating a dashboard interface according to embodiments described herein. As shown in FIG. 7, there are several plugins 700A-700N that contain data and / or information related to components that may be displayed on the dashboard interface.

[0075] The plug-ins 700A-700N are communicatively coupled to the component catalog generator 200, which receives data from the plug-ins 700A-700N to generate a component catalog for implementing the interface. The component catalog can be created using the plug-ins 700A-700N and several manifests of components for display, such as a manifest received from a client device as part of a dashboard request. The component catalog generator 200 can be communicatively connected to a component repository 210, which retrieves the component catalog and retrieves one or more component data sets corresponding to the component catalog. The retrieved one or more component data sets can be compiled into declarative metadata. The declarative metadata can include some static data retrieved directly from the plug-ins and fields of variable data that are filled by local data stored on the client device. In various embodiments, each of the aforementioned entities can be stored in a component facilitation system.

[0076] The component repository 210 can be communicatively coupled to a dashboard engine subsystem 123 that receives declarative metadata from one or more retrieved components. The dashboard engine subsystem 123 may be stored in a client engine system separate from the component facilitation system described above. The dashboard engine subsystem 123 can be configured to utilize the declarative metadata from the component repository 210 to generate one or more components.

[0077] The dashboard subsystem 123 may comprise one or more agent instances 710A-710N. The one or more agent instances may be versatile agents that can parse declarative metadata and replicate and generate rendering data for components. The dashboard subsystem 123 may further comprise a storage device 720. The storage device 720 may be a storage device that includes data for generating an instance of the versatile agent 710. The storage device 720 may be a local storage device, such as the local storage subsystem 300, that includes local data for supplementing incomplete declarative metadata. For example, the agent instance 710 may parse the received declarative metadata and determine to replicate the agent instances 710A-710N. Each of the agent instances 710A-710N may be delegated components for rendering. Each individual agent instance 710 may supplement a subset of the declarative metadata with local data from the storage device 720 to create a complete set of declarative data. The agent instance may then generate rendering data based on the complete declarative data.

[0078] The dashboard subsystem 123 may be communicatively coupled to one or more rendering subsystems 730. The one or more rendering subsystems 730 may be internal or external services for facilitating generation of one or more dashboard components. For example, the rendering subsystem may be an external rendering subsystem, such as the rendering subsystem 260 of the component facilitation system 140, operable as part of a server-side rendering arrangement. In various embodiments incorporating a client-side rendering arrangement, the rendering is performed by agent instances 710A-710N of the dashboard engine subsystem 123.

[0079] The dashboard subsystem 123 may be communicatively coupled to the service data subsystem 142. The service data subsystem 142 may send service data to the dashboard engine subsystem 123 to complete the declarative metadata received by the dashboard engine subsystem 123 to form a complete component. For example, a service may run on behalf of a client independent of the dashboard display process to host virtual machines for the client's customers. The service may query to obtain service data to fill fields and send back to the dashboard engine subsystem 123 in response. In the above example, the virtual machine service may send information such as the current upload speed, download speed, maintenance status, etc. of the virtual machine.

[0080] The dashboard library 250 can store one or more dashboard configurations for instantiating a dashboard interface. The dashboard library 250 can include information related to one or more custom modular dashboard configurations associated with a client or user. In various embodiments, without limitation, in parallel with any of the aforementioned processes, the dashboard library 250 can receive data related to a request to display a particular client's dashboard or an updated client dashboard. The dashboard library 250 can then initiate the generation of a dashboard interface shell implemented by the generated one or more components. The dashboard library 250 can be communicatively coupled to a console application 740 running on a client device hosting the dashboard interface. The dashboard library 250 can send data to the console application 740 comprising a dashboard shell corresponding to a particular customer. In response, the console application 740 can cause a dashboard interface 751 to be generated on the host interface 750 of the console application visible to the user via an electronic display. The dashboard interface 751 can be populated with components 753 as they become available and are displayed by executing the display data.

[0081] In this manner, the dashboard library 26=50 and the agent instances 710A-710N can be utilized to generate a dashboard interface 751 on the host interface 750 of the console application 740. In various embodiments, the shell components are placed on the dashboard interface 751 while the component generation process is pending, indicating to the client that one or more components will be placed on the dashboard interface 751 in the future. The dashboard interface 751 can further comprise a global control component 752. The global control component 752 can be a separate component that is essentially part of the dashboard interface 751 without requiring component generation. The global control component 752 can be a component that the client can interface with to change some aspect of the dashboard interface. For example, the global control component 752 can change one or more visual aspects of the dashboard interface, such as brightness levels, shading levels, etc. In another example, the global control component 752 can change one or more functional aspects of the dashboard interface, such as input protocols, update protocols, etc.

[0082] The components 753A-753N may be displayed on the dashboard interface 751 as they are generated. For example, a first component may be rendered before a second component. The first component may then be displayed on the dashboard interface before the second component while the second component is still being rendered. The components 753A-753N may be interactive components. An interactive component may be modified in some way or perform some function when an interaction with the component is detected. For example, as shown in FIG. 7, the component 753A is highlighted with a border to indicate that a client has interacted with the component 753A using a digital interface. The agent instances 710A-710N may actively monitor and update their corresponding components in real time using local data accessible by the dashboard engine subsystem 123.

[0083] In various embodiments, the console application 740 may further comprise a component editing interface 760. The component editing interface 760 may be an interface through which a client can modify some aspects of the current component 753 or create a new component. The component editing interface 760 may be real-time interactive, meaning that declarative metadata may be generated and edited in real-time as a client interacts with the component through the component editing interface 760. For example, as shown in FIG. 7, the plug-in A 700A may include some data related to the functionality of the component being edited in the component editing interface 760. Data may be retrieved and / or transformed in real-time from the plug-in A 700A to generate a replica of the component in the component editing interface 700.

[0084] FIG. 8 illustrates an exemplary graphical interface for component utilization in accordance with certain embodiments of the present disclosure. Specifically, FIG. 8 illustrates an example of a dashboard interface generated in accordance with embodiments described herein. As shown in FIG. 8, a host interface 750 can display a component dashboard in which several components are implemented. The host interface 750 can include a global control component 752. The host interface 750 can include several visual components, such as component 800. As shown in FIG. 8, component 800 is a widget-type component that displays the operating status of a virtual machine.

[0085] The host interface 750 may further comprise a new component 810. The new component 810 may be a placeholder component for creating a new component on the host interface 750. For example, a new component editing process may be initiated by interacting with the new component 810 on a digital display. The new component editing process may include initiating a component editing interface 760 for the new component 810. As shown in FIG. 8, the component editing interface 760 may execute and display to the client a selection for generating a new component. For example, as shown in FIG. 8, a potential new component may be an "active server location" widget component for displaying an active server location. The potential new component is displayed as a duplicate of the component to be generated according to the declarative metadata corresponding to the potential new widget. For example, the duplicate includes static data such as the title and location of some fields of information about the component, and variable data such as some servers targeted for display information that the client may specify.

[0086] An exemplary embodiment for implementing the interface shown in FIG. 8 is described below. A user of a client device 110 implementing a client engine system 120 on which the interface may be displayed may specify display of a dashboard "My Virtual Machine Dashboard". The user may interact with a new component 810 to request creation of a new component via an edit interface 760. In response to detecting an interaction with the new component 810, the client engine system 120 may query the catalog subsystem 141 of the component facilitation system 140 to obtain and transmit a list of cataloged components. One such component from the cataloged components may be displayed as a duplicate component on the component edit interface 760.

[0087] When a user specifies the creation of a new component 810, the client engine system can send dashboard data corresponding to the new configuration to the dashboard creation subsystem 143 of the component facilitation system 140. The dashboard creation subsystem 143 parses the dashboard data and accesses some of the plug-ins 700 to obtain declarative metadata related to the new dashboard configuration. The dashboard creation subsystem 143 can then send the declarative metadata to the client engine system 120. The client engine system 120 can utilize a multi-purpose agent to parse the declarative definition and generate multi-purpose agent copies of some of the components to be displayed as part of the "My Virtual Machine Dashboard". Some of the multi-purpose agents can query the service data subsystem 142 of the component facilitation system 140 to obtain service data related to the components to be displayed. For example, a particular multi-purpose agent corresponding to the new component 810 can query the service data subsystem 142 for service data related to the server status of the servers operated by the service provider and utilized by the client. The service data subsystem 142 can send this information back to the particular multi-purpose agent.

[0088] The versatile agent can use the declarative definitions received from the dashboard creation subsystem 143 and the service data received from the service data subsystem 142 to generate rendering data for components to be displayed on the dashboard interface. The rendering data can then be executed and implemented into a shell interface to display the interface shown in FIG.

[0089] As mentioned above, Infrastructure as a Service (IaaS) is one particular type of cloud computing. IaaS can be configured to provide virtualized computing resources over a public network (e.g., the Internet). In the IaaS model, cloud computing providers can host infrastructure components (e.g., servers, storage devices, network nodes (e.g., hardware), deployment software, platform virtualization (e.g., hypervisor layer), etc.). In some cases, IaaS providers can also provide various services (e.g., billing, monitoring, logging, load balancing, and clustering, etc.) that accompany these infrastructure components. Thus, these services can be policy-driven, so that IaaS users can potentially implement policies that drive load balancing to maintain application availability and performance.

[0090] In some cases, IaaS customers can access resources and services over a wide area network (WAN) such as the Internet, and can use the cloud provider's services to install the remaining elements of their application stack. For example, a user can log into an IaaS platform and create virtual machines (VMs), install an operating system (OS) on each VM, deploy middleware such as databases, create storage buckets for workloads and backups, and even install enterprise software on the VMs. The customer can then use the provider's services to perform a variety of functions such as balancing network traffic, troubleshooting application issues, monitoring performance, and managing disaster recovery.

[0091] In most cases, the cloud computing model requires the participation of a cloud provider, which may be, but does not have to be, a third-party service that specializes in providing (e.g., providing, renting, selling) IaaS. An entity may also choose to deploy a private cloud and become its own infrastructure service provider.

[0092] In some examples, IaaS deployment is the process of placing a new application, or a new version of an application, onto a prepared application server, etc. This may also include the process of preparing the server (e.g., installing libraries, daemons, etc.). This is often managed by the cloud provider below the hypervisor layer (e.g., servers, storage, network hardware, and virtualization). Thus, the customer may be responsible for handling things like (OS), middleware, and / or application deployment (e.g., self-service virtual machines (e.g., that can be spun up on demand)).

[0093] In some instances, IaaS provisioning may even refer to obtaining computers or virtual hosts for use and installing the necessary libraries or services on them. In most cases, deployment does not include provisioning, so provisioning may need to be performed first.

[0094] In some cases, there are two distinct challenges with IaaS provisioning. First, there is the initial challenge of provisioning an initial set of infrastructure before anything can run. Second, there is the challenge of evolving the existing infrastructure after everything has been provisioned (e.g., adding new services, modifying services, removing services, etc.). In some cases, these two challenges can be addressed by allowing the configuration of the infrastructure to be defined declaratively. In other words, the infrastructure (e.g., which components are required and how they interact) can be defined by one or more configuration files. Thus, the overall topology of the infrastructure (e.g., which resources depend on which resources and how each works together, etc.) can be described declaratively. In some cases, once the topology is defined, workflows can be generated to create and / or manage the various components described in the configuration files.

[0095] In some examples, the infrastructure may have many elements that are interconnected. For example, there may be one or more virtual private clouds (VPCs) (e.g., a potentially on-demand pool of configurable and / or shared computing resources), also known as a core network. In some examples, there may also be one or more inbound / outbound traffic group rules and one or more virtual machines (VMs) that are provisioned to define how the network's inbound and / or outbound traffic is configured. Other infrastructure elements such as load balancers, databases, etc. may also be provisioned. The infrastructure may evolve in stages as more infrastructure elements are desired or added.

[0096] In some cases, continuous deployment techniques may be used to enable deployment of infrastructure code across various virtual computing environments. Additionally, the described techniques enable infrastructure management within these environments. In some examples, a service team may write code that is desirable to deploy to one or more, but often many, different production environments (e.g., across various different geographic locations, possibly even across the globe). However, in some examples, the infrastructure to which the code will be deployed must first be set up. In some cases, provisioning may be done manually, and a provisioning tool may be utilized to provision resources and / or a deployment tool may be utilized to deploy the code after the infrastructure has been provisioned.

[0097] FIG. 9 is a block diagram 900 illustrating an example IaaS architecture pattern according to at least one embodiment. A service operator 902 can be communicatively coupled to a secure host tenant 904, which can include a virtual cloud network (VCN) 906 and a secure host subnet 908. In some examples, the service operator 902 can use one or more client computing devices, which can be portable handheld devices (e.g., iPhone, mobile phone, iPad, computing tablet, personal digital assistant (PDA)) or wearable devices (e.g., Google Glass head mounted display), running software such as Microsoft Windows Mobile, and / or various mobile operating systems such as iOS, Windows Phone, Android, BlackBerry8, PalmOS, and other Internet, email, short message service (SMS), Blackberry, or other communication protocols in effect. Alternatively, the client computing devices can be general purpose personal computers, including, for example, personal computers and / or laptop computers running various versions of Microsoft Windows, Apple Macintosh, and / or Linux operating systems. The client computing device may be a workstation computer running any of a variety of commercially available UNIX or UNIX-like operating systems, including, but not limited to, various GNU / Linux operating systems such as Google Chrome OS.Alternatively, or in addition, the client computing device may be any other electronic device, such as a thin-client computer, an Internet-enabled gaming system (e.g., a Microsoft Xbox game console with or without a Kinect® gesture input device), and / or a personal messaging device capable of communicating over a network with access to the VCN 906 and / or the Internet.

[0098] The VCN 906 may include a local peering gateway (LPG) 910 that may be communicatively coupled to a secure shell (SSH) VCN 912 via an LPG 910 that is included in the SSH VCN 912. The SSH VCN 912 may include an SSH subnet 914, which may be communicatively coupled to a control plane VCN 916 via an LPG 910 that is included in the control plane VCN 916. The SSH VCN 912 may also be communicatively coupled to a data plane VCN 918 via the LPG 910. The control plane VCN 916 and the data plane VCN 918 may be included in a service tenant 919, which may be owned and / or operated by the IaaS provider.

[0099] The control plane VCN 916 may include a control plane demilitarized zone (DMZ) tier 920 that serves as a perimeter network (e.g., a portion of an enterprise network between the enterprise intranet and an external network). DMZ-based servers have limited responsibility and may help prevent breaches. Additionally, the DMZ tier 920 may include one or more load balancer (LB) subnets 922, a control plane app tier 924 that may include an app subnet 926, a control plane data tier 928 that may include a database (DB) subnet 930 (e.g., a front-end DB subnet and / or a back-end DB subnet). The LB subnet 922 included in the control plane DMZ tier 920 may be communicatively coupled to the app subnet 926 included in the control plane app tier 924 and an Internet gateway 934 that may be included in the control plane VCN 916, and the app subnet 926 may be communicatively coupled to the DB subnet 930 included in the control plane data tier 928, as well as a service gateway 936 and a network address translation (NAT) gateway 938. The control plane VCN 916 may include a service gateway 936 and a NAT gateway 938 .

[0100] The control plane VCN 916 can include a data plane mirrored app layer 940 that can include an app subnet 926. The app subnet 926 included in the data plane mirrored app layer 940 can include a virtual network interface controller (VNIC) 942 on which a compute instance 944 can run. The compute instance 944 can communicatively couple the app subnet 926 of the data plane mirrored app layer 940 to the app subnet 926 that can be included in the data plane app layer 946.

[0101] The data plane VCN 918 can include a data plane app layer 946, a data plane DMZ layer 948, and a data plane data layer 950. The data plane DMZ layer 948 can include a LB subnet 922, which can be communicatively coupled to an app subnet 926 of the data plane app layer 946 and an Internet gateway 934 of the data plane VCN 918. The app subnet 926 can be communicatively coupled to a service gateway 936 of the data plane VCN 918 and a NAT gateway 938 of the data plane VCN 918. The data plane data layer 950 can also include a DB subnet 930, which can be communicatively coupled to the app subnet 926 of the data plane app layer 946.

[0102] The internet gateways 934 of the control plane VCNs 916 and data plane VCNs 918 may be communicatively coupled to a metadata management service 952, which may be communicatively coupled to the public internet 954. The public internet 954 may be communicatively connected to NAT gateways 938 of the control plane VCNs 916 and data plane VCNs 918. The service gateways 936 of the control plane VCNs 916 and data plane VCNs 918 may be communicatively coupled to cloud services 956.

[0103] In some examples, a service gateway 936 in the control plane VCN 916 or the data plane VCN 918 can make application programming interface (API) calls to cloud services 956 without traversing the public Internet 954. API calls from the service gateway 936 to the cloud services 956 can be one-way: the service gateway 936 can make an API call to the cloud services 956, and the cloud services 956 can send the requested data to the service gateway 936. However, the cloud services 956 may not be able to initiate the API call to the service gateway 936.

[0104] In some examples, the secure host tenant 904 can be directly connected to the service tenant 919 or can be otherwise separate. The secure host subnet 908 can communicate with the SSH subnet 914 through the LPG 910, which can allow bidirectional communication through otherwise separate systems. Connecting the secure host subnet 908 to the SSH subnet 914 can give the secure host subnet 908 access to other entities in the service tenant 919.

[0105] The control plane VCN 916 can enable users of a service tenant 919 to set up or provision desired resources. The desired resources provisioned in the control plane VCN 916 can be deployed or used in the data plane VCN 918. In some examples, the control plane VCN 916 can be separate from the data plane VCN 918, and a data plane mirror app layer 940 of the control plane VCN 916 can communicate with a data plane app layer 946 of the data plane VCN 918 via a VNIC 942, which can be included in the data plane mirror app layer 940 and the data plane app layer 946.

[0106] In some examples, a user or customer of the system may make a request, such as, for example, a create, read, update, or delete (CRUD) operation, via the public internet 954, which may communicate the request to a metadata management service 952. The metadata management service 952 may communicate the request to the control plane VCN 916 via an internet gateway 934. The request may be received by a LB subnet 922 included in the control plane DMZ layer 920. The LB subnet 922 may determine that the request is valid, and in response to this determination, the LB subnet 922 may send the request to an app subnet 926 included in the control plane app layer 924. If the request is validated and a call to the public internet 954 is required, the call to the public internet 954 may be sent to a NAT gateway 938, which may make the call to the public internet 954. Memory that may be desirable to be stored with the request may be stored in the DB subnet 930.

[0107] In some examples, the data plane mirror app layer 940 can facilitate direct communication between the control plane VCN 916 and the data plane VCN 918. For example, it may be desirable to apply configuration changes, updates, or other suitable modifications to resources included in the data plane VCN 918. Through the VNIC 942, the control plane VCN 916 can communicate directly with the resources included in the data plane VCN 918, thereby enabling it to perform configuration changes, updates, or other suitable modifications to the resources included in the data plane VCN 918.

[0108] In some embodiments, the control plane VCN 916 and the data plane VCN 918 can be included in the service tenant 919. In this case, a user or customer of the system may not own or operate either the control plane VCN 916 or the data plane VCN 918. Instead, an IaaS provider may own or operate the control plane VCN 916 and the data plane VCN 918, both of which may be included in the service tenant 919. This embodiment may allow for network isolation that may prevent a user or customer from interacting with the resources of other users or other customers. This embodiment also allows a user or customer of the system to store databases privately without having to rely on the public Internet 954, which may not have the desired level of threat protection for storage.

[0109] In another embodiment, the LB subnet 922 included in the control plane VCN 916 may be configured to receive signals from the service gateway 936. In this embodiment, the control plane VCN 916 and the data plane VCN 918 may be configured to be called by the IaaS provider's customers without calling the public Internet 954. The IaaS provider's customers may desire this embodiment because databases used by the customers may be stored in a service tenant 919 that is controlled by the IaaS provider and may be isolated from the public Internet 954.

[0110] 10 is a block diagram 1000 illustrating another example pattern of an IaaS architecture in accordance with at least one embodiment. A service operator 1002 (e.g., service operator 902 of FIG. 9 ) can be communicatively coupled to a secure host tenant 1004 (e.g., secure host tenant 904 of FIG. 9 ), which can include a virtual cloud network (VCN) 1006 (e.g., VCN 906 of FIG. 9 ) and a secure host subnet 1008 (e.g., secure host subnet 908 of FIG. 9 ). The VCN 1006 can include a local peering gateway (LPG) 1010 (e.g., LPG 910 of FIG. 9 ), which can be communicatively coupled to a secure shell (SSH) VCN 1012 (e.g., SSH VCN 912 of FIG. 9 ) via the LPG 910 included in the SSH VCN 1012. The SSH VCN 1012 can include an SSH subnet 1014 (e.g., SSH subnet 914 in FIG. 9 ), and the SSH VCN 1012 can be communicatively coupled to a control plane VCN 1016 (e.g., control plane VCN 916 in FIG. 9 ) via an LPG 1010 included in the control plane VCN 1016. The control plane VCN 1016 can be included in a service tenant 1019 (e.g., service tenant 919 in FIG. 9 ), and the data plane VCN 1018 (e.g., data plane VCN 918 in FIG. 9 ) can be included in a customer tenant 1021, which can be owned or operated by a user or customer of the system.

[0111] The control plane VCN 1016 may include a control plane DMZ layer 1020 (e.g., control plane DMZ layer 920 of FIG. 9 ) that may include a LB subnet 1022 (e.g., LB subnet 922 of FIG. 9 ), a control plane app layer 1024 (e.g., control plane app layer 924 of FIG. 9 ) that may include an app subnet 1026 (e.g., app subnet 926 of FIG. 9 ), and a control plane data layer 1028 (e.g., control plane data layer 928 of FIG. 9 ) that may include a database (DB) subnet 1030 (e.g., similar to DB subnet 930 of FIG. 9 ). The LB subnet 1022 included in the control plane DMZ tier 1020 can be communicatively coupled to an app subnet 1026 included in the control plane app tier 1024 and to an Internet gateway 1034 (e.g., Internet gateway 934 in FIG. 9 ) that may be included in the control plane VCN 1016, and the app subnet 1026 can be communicatively coupled to a DB subnet 1030 included in the control plane data tier 1028, as well as a service gateway 1036 (e.g., service gateway in FIG. 9 ) and a network address translation (NAT) gateway 1038 (e.g., NAT gateway 938 in FIG. 9 ). The control plane VCN 1016 can include the service gateway 1036 and the NAT gateway 1038.

[0112] The control plane VCN 1016 can include a data plane mirror app layer 1040 (e.g., data plane mirror app layer 940 of FIG. 9 ), which can include an app subnet 1026. The app subnet 1026 included in the data plane mirror app layer 1040 can include a virtual network interface controller (VNIC) 1042 (e.g., VNIC of 942) on which a computing instance 1044 (e.g., similar to the computing instance 944 of FIG. 9 ) can run. The computing instance 1044 can facilitate communication between the app subnet 1026 and the app subnet 1026 of the data plane mirror app layer 1040, which can be included in the data plane app layer 1046 (e.g., data plane app layer 946 of FIG. 9 ), via the VNIC 1042 included in the data plane mirror app layer 1040 and the VNIC 1042 included in the data plane app layer 1046.

[0113] An Internet gateway 1034 included in the control plane VCN 1016 can be communicatively coupled to a metadata management service 1052 (e.g., metadata management service 952 of FIG. 9), which can be communicatively coupled to a public Internet 1054 (e.g., public Internet 954 of FIG. 9). The public Internet 1054 can be communicatively coupled to a NAT gateway 1038 included in the control plane VCN 1016. A service gateway 1036 included in the control plane VCN 1016 can be communicatively coupled to cloud services 1056 (e.g., cloud services 956 of FIG. 9).

[0114] In some examples, the data plane VCN 1018 can be included in a customer tenant 1021. In this case, the IaaS provider can provide a control plane VCN 1016 for each customer, and the IaaS provider can set up a unique computing instance 1044 included in a service tenant 1019 for each customer. Each computing instance 1044 may enable communication between the control plane VCN 1016 included in the service tenant 1019 and the data plane VCN 1018 included in the customer tenant 1021. The computing instance 1044 may enable resources provisioned in the control plane VCN 1016 included in the service tenant 1019 to be deployed or otherwise used in the data plane VCN 1018 included in the customer tenant 1021.

[0115] In another example, a customer of the IaaS provider may have a database that resides in a customer tenant 1021. In this example, the control plane VCN 1016 may include a data plane mirror app layer 1040, which may include an app subnet 1026. The data plane mirror app layer 1040 may reside in the data plane VCN 1018, but the data plane mirror app layer 1040 may not reside in the data plane VCN 1018. That is, the data plane mirror app layer 1040 may be accessible to the customer tenant 1021, but the data plane mirror app layer 1040 may not reside in the data plane VCN 1018 or may be owned or operated by the customer of the IaaS provider. The data plane mirror app layer 1040 may be configured to make calls to the data plane VCN 1018, but may not be configured to make calls to any entities included in the control plane VCN 1016. A customer may desire to deploy or otherwise use resources in the data plane VCN 1018 that are provisioned in the control plane VCN 1016, and the data plane mirror app layer 1040 can facilitate the customer's desired deployment or other use of the resources.

[0116] In some embodiments, the IaaS provider's customer can apply filters to the data plane VCN 1018. In this embodiment, the customer can determine what the data plane VCN 1018 can access, and the customer can limit access from the data plane VCN 1018 to the public Internet 1054. The IaaS provider may not be able to apply filters or control the data plane VCN 1018's access to external networks or databases. Applying customer filters and controls to the data plane VCN 1018 contained in the customer tenant 1021 can help isolate the data plane VCN 1018 from other customers and the public Internet 1054.

[0117] In some embodiments, cloud services 1056 may be called by the service gateway 1036 to access services that may not be on the public internet 1054, on the control plane VCN 1016, or on the data plane VCN 1018. The connection between the cloud services 1056 and the control plane VCN 1016 or the data plane VCN 1018 may not be live or continuous. The cloud services 1056 may be on another network owned or operated by the IaaS provider. The cloud services 1056 may be configured to receive calls from the service gateway 1036 or may be configured not to receive calls from the public internet 1054. Some cloud services 1056 may be isolated from other cloud services 1056, and the control plane VCN 1016 may be isolated from cloud services 1056 that may not be in the same region as the control plane VCN 1016. For example, the control plane VCN 1016 may be located in “Region 1” and cloud service “Deployment 6” may be located in Region 1 and Region 2. If a call to Deployment 6 is made by a service gateway 1036 included in a control plane VCN 1016 in Region 1, the call may be sent to Deployment 6 in Region 1. In this example, the control plane VCN 1016, or Deployment 6 in Region 1, may not be communicatively coupled to or in communication with Deployment 6 in Region 2.

[0118] 11 is a block diagram 1100 illustrating another example pattern of an IaaS architecture in accordance with at least one embodiment. A service operator 1102 (e.g., service operator 902 of FIG. 9 ) can be communicatively coupled to a secure host tenant 1104 (e.g., secure host tenant 904 of FIG. 9 ), which can include a virtual cloud network (VCN) 1106 (e.g., VCN 906 of FIG. 9 ) and a secure host subnet 1108 (e.g., secure host subnet 908 of FIG. 9 ). The VCN 1106 can include an LPG 1110 (e.g., LPG 910 of FIG. 9 ) that can be communicatively coupled to an SSH VCN 1112 via an LPG 1110 included in the SSH VCN 1112 (e.g., SSH VCN 912 of FIG. 9 ). SSH VCN 1112 can include an SSH subnet 1114 (e.g., SSH subnet 914 in FIG. 9 ), which can be communicatively coupled to a control plane VCN 1116 via an LPG 1110 included in the control plane VCN 1116 (e.g., control plane VCN 916 in FIG. 9 ) and to a data plane VCN 1118 via an LPG 1110 included in the data plane VCN 1118 (e.g., data plane 918 in FIG. 9 ). The control plane VCN 1116 and the data plane VCN 1118 can be included in a service tenant 1119 (e.g., service tenant 919 in FIG. 9 ).

[0119] The control plane VCN 1116 may include a control plane DMZ tier 1120 (e.g., control plane DMZ tier 920 of FIG. 9 ) that may include a load balancer (LB) subnet 1122 (e.g., LB subnet 922 of FIG. 9 ), a control plane app tier 1124 (e.g., control plane app tier 924 of FIG. 9 ) that may include an app subnet 1126 (e.g., similar to app subnet 926 of FIG. 9 ), and a control plane data tier 1128 (e.g., control plane data tier 928 of FIG. 9 ) that may include a DB subnet 1130. The LB subnet 1122 included in the control plane DMZ tier 1120 may be communicatively coupled to an app subnet 1126 included in the control plane app tier 1124 and an Internet gateway 1134 (e.g., Internet gateway 934 of FIG. 9 ) that may be included in the control plane VCN 1116, and the app subnet 1126 can be communicatively coupled to a DB subnet 1130, a service gateway 1136 (e.g., service gateway of FIG. 9 ) and a network address translation (NAT) gateway 1138 (e.g., NAT gateway 938 of FIG. 9 ) included in the control plane data tier 1128. The control plane VCN 1116 may include the service gateway 1136 and the NAT gateway 1138.

[0120] The data plane VCN 1118 can include a data plane app layer 1146 (e.g., data plane app layer 946 of FIG. 9 ), a data plane DMZ layer 1148 (e.g., data plane DMZ layer 948 of FIG. 9 ), and a data plane data layer 1150 (e.g., data plane data layer 950 of FIG. 9 ). The data plane DMZ layer 1148 can include a LB subnet 1122, which can be communicatively coupled to a trusted app subnet 1160 and an untrusted app subnet 1162 of the data plane app layer 1146, and an Internet gateway 1134 included in the data plane VCN 1118. The trusted app subnet 1160 can be communicatively coupled to a service gateway 1136 included in the data plane VCN 1118, a NAT gateway 1138 included in the data plane VCN 1118, and a DB subnet 1130 included in the data plane data layer 1150. The untrusted app subnet 1162 can be communicatively coupled to a service gateway 1136 included in the data plane VCN 1118 and a DB subnet 1130 included in the data plane data layer 1150. The data plane data layer 1150 can include a DB subnet 1130 that can be communicatively coupled to a service gateway 1136 included in the data plane VCN 1118.

[0121] The untrusted app subnet 1162 may include one or more primary VNICs 1164(1)-(N) that may be communicatively coupled to tenant virtual machines (VMs) 1166(1)-(N). Each tenant VM 1166(1)-(N) may be communicatively coupled to a respective app subnet 1167(1)-(N), which may be included in a respective container egress VCN 1168(1)-(N), which may be included in a respective customer tenant 1170(1)-(N). Each secondary VNIC 1172(1)-(N) may facilitate communication between the untrusted app subnet 1162 included in the data plane VCN 1118 and the app subnet included in the container egress VCN 1168(1)-(N). Each container egress VCN 1168(1)-(N) may include a NAT gateway 1138 that may be communicatively coupled to the public Internet 1154 (e.g., public Internet 954 of FIG. 9 ).

[0122] An Internet gateway 1134 included in the control plane VCN 1116 and included in the data plane VCN 1118 can be communicatively coupled to a metadata management service 1152 (e.g., metadata management system 952 of FIG. 9 ), which can be communicatively coupled to the public Internet 1154. The public Internet 1154 can be communicatively coupled to a NAT gateway 1138 included in the control plane VCN 1116 and included in the data plane VCN 1118. A service gateway 1136 included in the control plane VCN 1116 and included in the data plane VCN 1118 can be communicatively coupled to cloud services 1156.

[0123] In some embodiments, the data plane VCN 1118 can be integrated with customer tenants 1170. This integration can be beneficial or desirable for the IaaS provider's customers, such as when support is needed when running code. The customer may provide code for execution that may be disruptive, communicate with other customer resources, or cause other undesirable effects. In response, the IaaS provider can decide whether to run code provided to the IaaS provider by the customer.

[0124] In some examples, a customer of an IaaS provider may grant the IaaS provider temporary network access and request functionality to be added to the data plane layer app 1146. The code that executes the functionality may be executed in the VMs 1166(1)-(N), and the code may not be configured to run elsewhere on the data plane VCN 1118. Each VM 1166(1)-(N) may be connected to one customer tenant 1170. Each container 1171(1)-(N) contained in a VM 1166(1)-(N) may be configured to execute code. In this case, double isolation may exist (e.g., code execution in a container 1171(1)-(N), the container 1171(1)-(N) may be contained in at least one VM 1166(1)-(N) that is included in the untrusted app subnet 1162), which may help prevent erroneous or unwanted code from damaging the IaaS provider's network or damaging another customer's network. Containers 1171(1)-(N) may be communicatively coupled to customer tenants 1170 and may be configured to send or receive data from customer tenants 1170. Containers 1171(1)-(N) may not be configured to send or receive data from any other entities in data plane VCN 1118. Once code execution is complete, the IaaS provider may kill or otherwise destroy containers 1171(1)-(N).

[0125] In some embodiments, trusted app subnet 1160 may execute code that may be owned or operated by the IaaS provider. In this embodiment, trusted app subnet 1160 may be communicatively coupled to DB subnet 1130 and configured to perform CRUD operations within DB subnet 1130. Untrusted app subnet 1162 may be communicatively coupled to DB subnet 1130, but in this embodiment, untrusted app subnet 1162 may be configured to perform read operations in DB subnet 1130. Containers 1171(1)-(N) that may be included in each customer's VMs 1166(1)-(N) and that may execute code from the customer may not be communicatively coupled to DB subnet 1130.

[0126] In other embodiments, the control plane VCN 1116 and the data plane VCN 1118 may not be directly communicatively coupled. In this embodiment, there may not be direct communication between the control plane VCN 1116 and the data plane VCN 1118. However, communication may occur indirectly through at least one method. The LPG 1110 may be established by an IaaS provider that may facilitate communication between the control plane VCN 1116 and the data plane VCN 1118. In another example, the control plane VCN 1116 or the data plane VCN 1118 may make a call to a cloud service 1156 through the service gateway 1136. For example, a call from the control plane VCN 1116 to the cloud service 1156 may include a request for a service that may communicate with the data plane VCN 1118.

[0127] 12 is a block diagram 1200 illustrating another example pattern of an IaaS architecture, according to at least one embodiment. A service operator 1202 (e.g., service operator 902 of FIG. 9 ) can be communicatively coupled to a secure host tenant 1204 (e.g., secure host tenant 904 of FIG. 9 ), which can include a virtual cloud network (VCN) 1206 (e.g., VCN 906 of FIG. 9 ) and a secure host subnet 1208 (e.g., secure host subnet 908 of FIG. 9 ). VCN 1206 can include an LPG 1212 (e.g., LPG 910 of FIG. 9 ) that can be communicatively coupled to an SSH VCN 1212 (e.g., SSH VCN 912 of FIG. 9 ) via an LPG 1210 included in SSH VCN 1212. SSH VCN 1212 can include SSH subnet 1214 (e.g., SSH subnet 914 in FIG. 9 ), which can be communicatively coupled to control plane VCN 1216 via LPG 1210 included in control plane VCN 1216 (e.g., control plane VCN 916 in FIG. 9 ) and can be communicatively coupled to data plane VCN 1218 via LPG 1210 included in data plane VCN 1218 (e.g., data plane 918 in FIG. 9 ). Control plane VCN 1216 and data plane VCN 1218 can be included in service tenant 1219 (e.g., service tenant 919 in FIG. 9 ).

[0128] The control plane VCN 1016 may include a control plane DMZ layer 1220 (e.g., control plane DMZ layer 920 of FIG. 9 ) which may include a LB subnet 1222 (e.g., LB subnet 922 of FIG. 9 ), a control plane app layer 1224 (e.g., control plane app layer 924 of FIG. 9 ) which may include an app subnet 1226 (e.g., app subnet 926 of FIG. 9 ), and a control plane data layer 1228 (e.g., control plane data layer 928 of FIG. 9 ) which may include a DB subnet 1230 (e.g., DB subnet 1030 of FIG. 10 ). The LB subnet 1222 included in the control plane DMZ layer 1220 can be communicatively coupled to an app subnet 1226 included in the control plane app layer 1224 and can be communicatively coupled to an Internet gateway 1234 (e.g., Internet gateway 934 of FIG. 9 ) that can be included in the control plane VCN 1216, and the app subnet 1226 can be communicatively coupled to a DB subnet 1230 included in the control plane data layer 1228 and can be communicatively coupled to a service gateway 1236 (e.g., service gateway of FIG. 9 ) and a network address translation (NAT) gateway 1238 (e.g., NAT gateway 938 of FIG. 9 ). The control plane VCN 1216 can include the service gateway 1236 and the NAT gateway 1238.

[0129] The data plane VCN 1218 can include a data plane app layer 1246 (e.g., data plane app layer 946 of FIG. 9), a data plane DMZ layer 1248 (e.g., data plane DMZ layer 948 of FIG. 9), and a data plane data layer 1250 (e.g., data plane data layer 950 of FIG. 9). The data plane DMZ layer 1248 can include a LB subnetwork 1222 that can be communicatively coupled to a trusted app subnetwork 1260 (e.g., trusted app subnetwork 1060 of FIG. 10) and an untrusted app subnetwork 1262 (e.g., untrusted app subnetwork 1062 of FIG. 10) of the data plane app layer 1246, and an Internet gateway 1234 included in the data plane VCN 1218. The trusted app subnet 1260 can be communicatively coupled to a service gateway 1236 included in the data plane VCN 1218, and can be communicatively coupled to a NAT gateway 1238 included in the data plane VCN 1218, and to a DB subnet 1230 included in the data plane data layer 1250. The untrusted app subnet 1262 can be communicatively connected to the service gateway 1236 included in the data plane VCN 1218 and the DB subnet 1230 included in the data plane data layer 1250. The data plane data layer 1250 can include the DB subnet 1230, which can be communicatively coupled to the service gateway 1236 included in the data plane VCN 1218.

[0130] The untrusted app subnet 1262 can include primary VNICs 1264(1)-(N), which can be communicatively coupled to tenant virtual machines (VMs) 1266(1)-(N) that reside in the untrusted app subnet 1262. Each tenant VM 1266(1)-(N) can execute code within a respective container 1267(1)-(N), and can be communicatively coupled to an app subnet 1226 that can be included in a data plane app layer 1246 that can be included in a container egress VCN 1268. Each secondary VNIC 1272(1)-(N) can facilitate communication between the untrusted app subnet 1262 included in the data plane VCN 1218 and the app subnet included in the container egress VCN 1268. The container egress VCN can include a NAT gateway 1238 that can be communicatively coupled to the public Internet 1254 (e.g., public Internet 954 of FIG. 9 ).

[0131] An Internet gateway 1234 included in the control plane VCN 1216 and included in the data plane VCN 1218 can be communicatively coupled to a metadata management service 1252 (e.g., metadata management system 952 of FIG. 9 ), which can be communicatively coupled to the public Internet 1254. The public Internet 1254 can be communicatively coupled to a NAT gateway 1238 included in the control plane VCN 1216 and included in the data plane VCN 1218. A service gateway 1236 included in the control plane VCN 1216 and included in the data plane VCN 1218 can be communicatively coupled to cloud services 1256.

[0132] In some examples, the pattern illustrated by the architecture of block diagram 1200 of FIG. 12 may be an exception to the pattern illustrated by the architecture of block diagram 1000 of FIG. 10 and may be desirable for an IaaS provider's customer when the IaaS provider cannot communicate directly with the customer (e.g., in a disconnected area). Each container 1267(1)-(N) contained in each customer's VM 1266(1)-(N) is accessible in real time by the customer. The containers 1267(1)-(N) may be configured to make calls to a respective secondary VNIC 1272(1)-(N) contained in the app subnet 1226 of the data plane app layer 1246, which may be contained in a container egress VCN 1268. The secondary VNIC 1272(1)-(N) may send the call to a NAT gateway 1238, which may send the call to the public Internet 1254. In this example, containers 1267(1)-(N) that a customer can access in real time can be isolated from control plane VCN 1216 and can be isolated from other entities included in data plane VCN 1218. Containers 1267(1)-(N) may be isolated from resources from other customers.

[0133] In another example, a customer can use container 1267(1)-(N) to invoke cloud service 1256. In this example, the customer can execute code within container 1267(1)-(N) that requests a service from cloud service 1256. Container 1267(1)-(N) can send the request to secondary VNIC 1272(1)-(N), which can send the request to a NAT gateway that can send the request to public Internet 1254. Public Internet 1254 can send the request via Internet gateway 1234 to LB subnet 1222 included in control plane VCN 1216. In response to determining that the request is valid, the LB subnet can send the request to app subnet 1226, which can send the request to cloud service 1256 via service gateway 1236.

[0134] It should be understood that the IaaS architectures 900, 1000, 1100, 1200 depicted in the figures may have components other than those depicted. Additionally, the embodiments depicted in the figures are only some examples of cloud infrastructure systems that may incorporate embodiments of the present disclosure. In other embodiments, the IaaS systems may have more or fewer components than depicted, may combine two or more components, or may have a different configuration or arrangement of components.

[0135] In certain embodiments, the IaaS system described herein may include a suite of application, middleware, and database services products that are delivered to customers in a self-service, subscription-based, elastically scalable, reliable, highly available, and secure manner. One example of such an IaaS system is Oracle Cloud Infrastructure (OCI), offered by the present assignee.

[0136] 13 illustrates an exemplary computer system 1300 in which various embodiments may be implemented. The system 1300 may be used to implement any of the computer systems described above. As shown, the computer system 1300 includes a processing unit 1304 that communicates with a number of peripheral subsystems via a bus subsystem 1302. These peripheral subsystems may include a processing accelerator 1306, an I / O subsystem 1308, a storage subsystem 1318, and a communication subsystem 1324. The storage subsystem 1318 includes a tangible computer-readable storage medium 1322 and a system memory 1310.

[0137] The bus subsystem 1302 provides a mechanism that allows the various components and subsystems of the computer system 1300 to communicate with each other as intended. Although the bus subsystem 1302 is shown diagrammatically as a single bus, alternative embodiments of the bus subsystem may utilize multiple buses. The bus subsystem 1302 may be any of several types of bus structures including a memory bus or memory controller, a peripheral bus, and a local bus using any of a variety of bus architectures. For example, such architectures may include an Industry Standard Architecture (ISA) bus, a Micro Channel Architecture (MCA) bus, an Enhanced ISA (EISA) bus, a Video Electronics Standards Association (VESA) local bus, and a Peripheral Component InterConnect (PCI) bus. It may be implemented as a mezzanine bus manufactured in accordance with the IEEE P1386.1 standard.

[0138] The processing unit 1304 may be implemented as one or more integrated circuits (e.g., conventional microprocessors or microcontrollers) and controls the operation of the computer system 1300. One or more processors may be included in the processing unit 1304. These processors may include single-core processors or multi-core processors. In particular embodiments, the processing unit 1304 may be implemented as one or more independent processing units 1332 and / or 1334 with a single-core processor or a multi-core processor included in each processing unit. In other embodiments, the processing unit 1304 may be implemented as a quad-core processing unit formed by integrating two dual-core processors into a single chip.

[0139] In various embodiments, the processing unit 1304 may execute various programs in response to program code and may maintain multiple simultaneously executing programs or processes. At any time, some or all of the program code being executed may reside in the processor 1304 and / or in the memory subsystem 1318. Through appropriate programming, the processor 1304 may provide the various functions discussed above. The computer system 1300 may further include a processing accelerator 1306, which may include a digital signal processor (DSP), special purpose processor, or the like.

[0140] The I / O subsystem 1308 can include user interface input devices and user interface output devices. User interface input devices can include keyboards, pointing devices such as mice or trackballs, touch pads or touch screens integrated into displays, scroll wheels, click wheels, dials, buttons, switches, keypads, audio input devices with voice command recognition systems, microphones, and other types of input devices. User interface input devices can include, for example, motion sensing and / or gesture recognizers such as a Microsoft Kinect® motion sensor, allowing a user to control and interact with input devices such as a Microsoft Xbox® 360 game controller through a natural user interface using gestures and voice commands. User interface input devices can also include eye gesture recognizers such as a Google Glass® blink detector that detects eye activity from a user (e.g., "blinking" while taking a picture and / or selecting a menu) and translates eye gestures as input to an input device (e.g., Google Glass®). Additionally, the user interface input devices may include voice recognition sensing devices that allow a user to interact with a voice recognition system (eg, the Siri® navigator) through voice commands.

[0141] User interface input devices may include, but are not limited to, three-dimensional (3D) mice, joysticks or pointing sticks, game pads and graphic tablets, as well as audio / visual devices such as speakers, digital cameras, digital video cameras, portable media players, webcams, image scanners, fingerprint scanners, barcode readers 3D scanners, 3D printers, laser range finders, and eye-tracking devices. Additionally, user interface input devices may include medical imaging input devices such as, for example, computed tomography, magnetic resonance imaging, position emission tomography, and medical ultrasound machines. User interface input devices may also include audio input devices such as, for example, MIDI keyboards, digital musical instruments, and the like.

[0142] User interface output devices may include non-visual displays such as a display subsystem, indicator lights, or audio output devices. The display subsystem may be a flat panel device such as one using a cathode ray tube (CRT), liquid crystal display (LCD) or plasma display, a projection device, a touch screen, etc. In general, use of the term "output device" is intended to include all possible types of devices and mechanisms for outputting information from computer system 1300 to a user or to another computer. For example, user interface output devices include, but are not limited to, various display devices that visually convey text, graphics, and audio / video information, such as monitors, printers, speakers, headphones, automobile navigation systems, plotters, voice output devices, and modems.

[0143] Computer system 1300 may include a storage subsystem 1318 that comprises software elements shown as currently located in system memory 1310. The system memory 1310 may store program instructions that are loadable and executable on the processing unit 1304, as well as data generated during the execution of these programs.

[0144] Depending on the configuration and type of computer system 1300, the system memory 1310 may be volatile (such as random access memory (RAM)) and / or non-volatile (such as read only memory (ROM), flash memory, etc.). RAM typically contains data and / or program modules that are immediately accessible to and / or currently being operated on and executed by the processing unit 1304. In some implementations, the system memory 1310 may include a number of different types of memory, such as static random access memory (SRAM) or dynamic random access memory (DRAM). In some implementations, a basic input / output system (BIOS), containing the basic routines that help to transfer information between elements within the computer system 1300, such as during start-up, may typically be stored in ROM. By way of example and not limitation, the system memory 1310 also illustrates application programs 1312, program data 1314, and an operating system 1316, which may include client applications, a web browser, a mid-tier application, a relational database management system (RDBMS), and the like. By way of example, operating systems 1316 may include various versions of Microsoft Windows®, Apple Macintosh®, and / or Linux operating systems, various commercially available UNIX® or UNIX-like operating systems (including, but not limited to, various GNU / Linux operating systems, Google Chrome® OS, etc.), and / or mobile operating systems such as iOS, Windows® Phone, Android® OS, BlackBerry® 10 OS, and Palm® OS operating systems.

[0145] The storage subsystem 1318 may also provide a tangible computer-readable storage medium for storing the basic programming and data constructs that provide the functionality of some embodiments. Software (programs, code modules, instructions) that, when executed by the processor, provide the functionality described above may be stored in the storage subsystem 1318. These software modules or instructions may be executed by the processing unit 1304. The storage subsystem 1318 may also provide a repository for storing data used in accordance with the present disclosure.

[0146] Storage subsystem 1300 may also include a computer readable storage medium reader 1320 that can be further connected to a computer readable storage medium 1322. Together, and optionally in combination with system memory 1310, computer readable storage medium 1322 can comprehensively represent remote, local, fixed, and / or removable storage devices, as well as storage media for containing, storing, transmitting, and retrieving computer readable information on a temporary and / or more permanent basis.

[0147] The computer readable storage medium 1322 containing the code or portions of code may include any suitable medium known or used in the art, including, but not limited to, storage media and communication media, such as volatile and non-volatile, removable and non-removable media implemented in any manner or technology for storing and / or transmitting information. This may include tangible computer readable storage media, such as RAM, ROM, Electronically Erasable Programmable ROM (EEPROM), flash memory or other memory technology, CD-ROM, digital versatile disk (DVD), or other optical storage, magnetic cassette, magnetic tape, magnetic disk storage or other magnetic storage, or other tangible computer readable medium. This may also include intangible computer readable media, such as a data signal, data transmission, or any other medium that can be used to transmit the desired information and that can be accessed by the computing system 1300.

[0148] As an example, the computer readable storage medium 1322 may include hard disk drives that read or write to non-removable non-volatile magnetic media, magnetic disk drives that read or write to removable non-volatile magnetic disks, and optical disk drives that read or write to removable non-volatile optical disks such as CD-ROMs, DVDs, Blu-Ray® disks, or other optical media. The computer readable storage medium 1322 may include, but is not limited to, Zip® drives, flash memory cards, Universal Serial Bus (USB) flash drives, Secure Digital (SD) cards, DVD disks, digital video tapes, and the like. The computer readable storage medium 1322 may also include solid state drives (SSDs) based on non-volatile memory such as flash memory-based SSDs, enterprise flash drives, SSDs based on volatile memory such as solid state RAM, dynamic RAM, static RAM, such as solid state ROM, DRAM-based SSDs, magnetoresistive RAM (MRAM) SSDs, and hybrid SSDs that use a combination of DRAM and flash memory-based SSDs. The disk drives and their associated computer-readable media may provide non-volatile storage of computer-readable instructions, data structures, program modules, and other data for the computer system 1300.

[0149] The communication subsystem 1324 provides an interface to other computer systems and networks. The communication subsystem 1324 serves as an interface for transmitting and receiving data from the computer system 1300 to and from other systems. For example, the communication subsystem 1324 may enable the computer system 1300 to connect to one or more devices via the Internet. In some embodiments, the communication subsystem 1324 may include radio frequency (RF) transceiver components for accessing wireless voice and / or data networks (e.g., using cellular technology, advanced data network technologies such as 3G, 4G, or EDGE (Enhanced Data Rates for Global Evolution)), WiFi (IEEE 802.11 family standard, or other mobile communication technologies, or any combination thereof), global positioning system (GPS) receiver components, and / or other components. In some embodiments, the communication subsystem 1324 may provide a wired network connection (e.g., Ethernet) in addition to or instead of a wireless interface.

[0150] In some embodiments, the communications subsystem 1324 may also receive incoming communications in the form of structured and / or unstructured data feeds 1326, event streams 1328, event updates 1330, etc., on behalf of one or more users who may use the computer system 1300.

[0151] As an example, the communications subsystem 1324 may be configured to receive data feeds 1326 in real time from users of social networks and / or other communications services, such as web feeds, such as Twitter® feeds, Facebook® updates, Rich Site Summary (RSS) feeds, and / or real-time updates from one or more third party information sources.

[0152] Additionally, the communications subsystem 1324 may be configured to receive data in the form of a continuous data stream, which may include an event stream 1328 of real-time events and / or event updates 1330, which may be continuous or essentially unlimited with no apparent end. Examples of applications that generate continuous data may include, for example, sensor data applications, financial tickers, network performance measurement tools (e.g., network monitoring and traffic management applications), clickstream analysis tools, automobile traffic monitoring, and the like.

[0153] The communications subsystem 1324 may also be configured to output structured and / or unstructured data feeds 1326, event streams 1328, event updates 1330, etc. to one or more databases that may be in communication with one or more streaming data source computers coupled to the computer system 1300.

[0154] The computer system 1300 may be one of a variety of types, including a handheld portable device (e.g., an iPhone® mobile phone, an iPad® computing tablet, a PDA), a wearable device (e.g., a Google Glass® head mounted display), a PC, a workstation, a mainframe, a kiosk, a server rack, or other data processing system.

[0155] Due to the ever-changing nature of computers and networks, the description of the computer system 1300 shown in the figure is intended as a specific example only. Many other configurations are possible, with more or fewer components than the system shown in the figure. For example, customized hardware may also be used, or particular elements may be implemented in hardware, firmware, software (including applets), or a combination thereof. Additionally, connections to other computing devices, such as network input / output devices, may be used. Based on the disclosure and teachings provided herein, one of ordinary skill in the art will appreciate other approaches and / or methods for implementing various embodiments.

[0156] Although specific embodiments have been described, various modifications, variations, alternative constructions, and equivalents are within the scope of the disclosure. The embodiments are not limited to operating in any particular data processing environment, but may freely operate in multiple data processing environments. Furthermore, while the embodiments have been described using a particular sequence of transactions and steps, it will be apparent to those skilled in the art that the scope of the disclosure is not limited to the sequence of transactions and steps described. Various features and aspects of the above-described embodiments may be used individually or in combination.

[0157] Furthermore, while embodiments have been described using a particular combination of hardware and software, it should be appreciated that other combinations of hardware and software are within the scope of the present disclosure. The embodiments may be implemented using only hardware, only software, or a combination thereof. The various processes described herein may be implemented on the same processor or any combination of different processors. Thus, where a component or module is described as being configured to perform a particular operation, such configuration may be achieved, for example, by designing electronic circuitry to perform the operation, by programming a programmable electronic circuit (such as a microprocessor) to perform the operation, or any combination thereof. Processes may communicate using a variety of techniques, including, but not limited to, conventional techniques for inter-process communication, with different pairs of processes using different techniques and the same pair of processes using different techniques at different times.

[0158] Accordingly, the specification and drawings are to be regarded in an illustrative rather than a restrictive sense. It will be apparent, however, that additions, subtractions, deletions, and other modifications and alterations may be made without departing from the broader spirit and scope of the appended claims. Accordingly, although certain disclosed embodiments have been described, they are not intended to be limiting. Various modifications and equivalents are intended to be within the scope of the following claims.

[0159] Use of the terms "a," "an," "the," and similar referents in the context of describing the disclosed embodiments (particularly in the context of the claims that follow) should be construed to cover both the singular and the plural, unless otherwise indicated herein or clearly contradicted by context. The terms "comprise," "have," "include," and "contain" should be construed as open-ended terms (i.e., meaning "including but not limited to"), unless otherwise noted. The term "connected" should be construed as being partially or wholly contained within, attached to, or connected to, even if there is something intervening. The recitation of ranges of values ​​herein is merely intended to serve as a shorthand method of individually referring to each individual value falling within the range, unless otherwise stated herein, and each individual value is incorporated into the specification as if it were individually set forth herein. All methods described herein can be performed in any suitable order, unless otherwise indicated herein or clearly contradicted by context. Any examples provided herein, or the use of exemplary language (e.g., "such as"), are intended merely to better illustrate the embodiments and do not impose limitations on the scope of the disclosure unless otherwise claimed. No language in the specification should be construed as indicating any non-claimed element as essential to the practice of the disclosure.

[0160] Disjunctive language, such as the phrase "at least one of X, Y, or Z," is intended to be understood in context as generally used to indicate that an item, term, etc. can be either X, Y, or Z, or any combination thereof (e.g., X, Y, and / or Z), unless specifically stated otherwise. Thus, such disjunctive language is generally not intended to, and should not, imply that a particular embodiment requires that at least one of X, at least one of Y, or at least one of Z, respectively, be present.

[0161] Preferred embodiments of the present disclosure are described herein, including the best mode known for carrying out the present disclosure. Variations of these preferred embodiments will become apparent to those skilled in the art upon reading the foregoing description. Those skilled in the art should be able to adopt such variations as necessary, and the present disclosure may be carried out in ways other than as specifically described herein. Accordingly, this disclosure includes all modifications and equivalents of the subject matter recited in the claims appended hereto as permitted by applicable law. Moreover, unless otherwise indicated herein, this disclosure encompasses any combination of the above-described elements in all possible variations thereof.

[0162] All references cited in this specification, including publications, patent applications, and patents, are herein incorporated by reference to the same extent as if each reference was individually and specifically indicated to be incorporated by reference and was set forth in its entirety herein.

[0163] In the foregoing specification, aspects of the disclosure have been described with reference to specific embodiments thereof, but those skilled in the art will recognize that the disclosure is not limited thereto. Various features and aspects of the above disclosure can be used individually or in combination. Moreover, the embodiments can be utilized in any number of environments and applications beyond those described herein without departing from the broader spirit and scope of the specification. Thus, the specification and drawings should be regarded as illustrative rather than restrictive. Various modifications and equivalents include relevant suitable combinations of the features disclosed in the embodiments.

Claims

1. 1. A method comprising: a client device receiving declarative metadata, at least a portion of the declarative metadata corresponding to one or more visual components displayed on an interface; The method comprises: analyzing the declarative metadata by the client device to determine the one or more visual components; the client device replicating a component agent on the client device for each visual component of the one or more visual components to create a plurality of component agents on the client device; generating one or more sets of rendering data, each set of the one or more sets of rendering data generated by a respective component agent of the plurality of component agents of the client device and corresponding to a particular visual component of the one or more visual components, the rendering data being executable to render the one or more visual components.

2. The method of claim 1 , further comprising executing the one or more sets of rendering data to cause the one or more visual components to be displayed on an interface.

3. determining, based at least in part on the declarative metadata, one or more interactive responses corresponding to the one or more visual components; detecting an input corresponding to an interaction with one or more visual components displayed on the interface; 3. The method of claim 2, further comprising: executing the one or more interactive responses accordingly.

4. 4. The method of claim 3, wherein the one or more interactive responses include at least a component update response that causes an update of at least a displayed visual component of the displayed one or more visual components by updating at least one set of rendering data of the one or more sets of rendering data.

5. The method of any one of claims 1 to 4, wherein the component agent analyzes the declarative metadata to determine a number of component agents to be replicated to create the plurality of component agents.

6. The method of claim 5 , further comprising retrieving the component agent from a computer memory in response to receiving the declarative metadata.

7. 5. The method of claim 1, further comprising transmitting, from a first component agent of the plurality of component agents, at least a portion of a set of rendering data generated by the first component agent to a second component agent of the plurality of component agents, wherein the set of rendering data generated by the second component agent is generated based at least in part on the portion of the set of rendering data transmitted by the first component agent.

8. The method of any one of claims 1 to 4, wherein the declarative metadata for displaying the one or more visual components on an interface corresponds to dashboard data representing a particular configuration of the one or more visual components within a dashboard interface.

9. receiving, by the client device, a list including at least the one or more visual components; receiving, at the client device, a selection of the one or more visual components from the list; 10. The method of claim 8, further comprising: the client device generating the dashboard data based at least in part on the selection of the one or more visual components; and a server device configured to simultaneously generate the declarative metadata based at least in part on the dashboard data.

10. The method of any one of claims 1 to 4, further comprising the client device detecting an update to the one or more visual components, and the server device being configured to simultaneously generate updated declarative metadata in response to the client device detecting the update to the one or more visual components, at least a portion of the updated declarative metadata corresponding to the one or more updated visual components and displayed on the interface.

11. the plurality of component agents are implemented by the client device; the server device is configured to generate the updated declarative metadata; The method comprises: the client device further comprising: monitoring the one or more visual components to detect the updates to the one or more visual components; and the server device configured to simultaneously monitor the one or more visual components to detect the updates; The method comprises: sending, at the client device, input data to the server device in response to the client device detecting the update of the one or more visual components; The method of claim 10 , further comprising the client device receiving the updated declarative metadata from the server device.

12. The method of any one of claims 1 to 4, further comprising receiving service data corresponding to one or more metrics of one or more services associated with the one or more visual components, wherein the one or more sets of rendering data are generated based at least in part on the declarative metadata and the service data.

13. A computer program product that causes a processor to execute a method according to any one of claims 1 to 12.

14. A memory storing the computer program according to claim 13; and a processor for executing the computer program.

15. A client device according to claim 14, A system comprising: a server device communicatively connected to the client device.

Images