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 array 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 can present customers with a simplified view of their active services. The modular digital interface displays data and interactive components corresponding to the customer's active services and may be customizable to display them in the format most desirable for 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 created and maintained. However, displaying and maintaining multiple individual components on multiple customized, personalized interfaces for multiple customers is resource intensive. Communication between customers and service providers is frequent and inefficient, leading to a significant waste of system resources. Resource waste increases exponentially with the number of customers utilizing these processes, as each customer implements one or more personalized interfaces. Methods for displaying and managing individual components on an interface can be repetitive and inefficient, further wasting resources and causing 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. Multiple instances of versatile component agents, or "versatile agents," can be created to efficiently distribute component management duties. Versatile agent instances can also be utilized within 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 service providers, while the component generation engine and associated versatile agents use the processed data to perform interface generation on behalf of clients.

[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 can be triggered by a request from the client device for a component of a 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 to the server device by the client device. The server device can simultaneously service multiple client devices, similar to the client device, each of which individually requests 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 example method includes receiving declarative metadata, at least a portion of the declarative metadata corresponding to one or more visual components to be displayed on an interface, the method further including 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 display the one or more visual components on the interface.

[0007] Aspects of the present disclosure further include detecting and responding to interactions 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 interactions 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 one 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 agent 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 present disclosure relate to utilizing dashboard data to build declarative metadata for dashboard components. One example includes the steps described above, in which declarative metadata for displaying one or more visual components on an interface corresponds to dashboard data that represents a specific 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 multiple visual components, the multiple visual components including one or more visual components, the method further including receiving a selection of one or more visual components from the list of the multiple 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 present disclosure relate to utilizing service metrics and measurements as part of components for display on a dashboard interface. An example method includes the steps described 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 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 above-described method.

[0013] Another aspect of the present disclosure comprises a non-transitory computer-readable medium containing 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 explanation 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. [Figure 2] FIG. 1 is a block diagram of a component facilitation system according to certain embodiments of the present disclosure. [Figure 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. [Figure 5] FIG. 10 illustrates an exemplary flowchart of a process for interface component generation using a versatile agent, in accordance with certain embodiments of the present disclosure. [Figure 6] FIG. 1 illustrates an exemplary flowchart 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. 10 illustrates an exemplary 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. 1 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. 1 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. 1 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 exemplary computer system in accordance with at least one embodiment. DETAILED DESCRIPTION OF THE INVENTION

[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 illustrations and description are not intended to be limiting.

[0018] Service providers may offer services to which customers (e.g., subscribers) of the offered services can 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 customer data in a database, another may provide customers with access to virtual machines, and yet another may enable customers to implement automated customer service for their clients. Customers utilizing these capabilities often require comprehensive digital interfaces for viewing and managing data related to their use of 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 also 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 can be numerous and complex. Each of these vendor services and their associated data can be represented by a component on an interface managed by the vendor 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 further individualize the customer experience. A modular interface is typically an interface that includes a shell (e.g., a static interface background) and one or more components (e.g., individual panels on the background that display interactive components related to the utilized service). A customizable interface is an interface that allows customers to select and choose which components 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 in a single digital location. Existing modular interfaces allow customers to select one or more predefined components to display in the shell. For example, a service provider may store several pre-built interface components 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 with component "dashboards." For example, a customer may have separate dashboards for components related to business operations, data management activities, etc.

[0020] While independent execution of each interface component promotes modular functionality, it can lead to repetitive, inefficient, and / or unsafe performance by the interface and corresponding services. As one 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 (one for sales revenue and one for sales profit) on an interface, the two components execute and display information independently of each other. Thus, both components retrieve the same sales data twice, duplicating resource expenditures. In another example, each individual interface component must contain separate code instructions to perform procedures specific to that component. Because code instructions account for a significant portion of a component's size, utilizing multiple components with similar code correspondingly increases resource utilization. When multiple components execute code on the same system to render their components, the system experiences significant resource waste.

[0021] Service providers offering interactive digital interfaces are subject to the above-mentioned 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 for implementing the interface component. The versatile agents then parse the declarative definition, fetch customer data according to the parameters, and independently implement the component. Distributing component generation to a client-side engine and data storage to a central system reduces costly data transfer and communication.

[0022] A versatile agent may be replicated into multiple instances to maintain different components of the interface separately. Because a versatile agent has the ability to implement multiple different interface components based on a declarative definition, replicated instances of the versatile agent can simultaneously implement different interface components. Instances of a versatile agent can communicate and share data among other actors through a shared communication protocol. A 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 offers several advantages over previous interface generation methods: Removing individual code instructions for each component reduces component implementation overhead; Because the versatile agent only needs to parse the declarative definitions and generate the components, service providers utilize system resources more efficiently and reduce data bloat during interface implementation; and service provider customers experience a more streamlined approach to generating personalized interfaces.

[0024] Maintaining interface components through a versatile agent and its replicated instances means that the versatile agent actors only need to be fetched into memory once to initiate interface generation, saving valuable computing resources. Using a standard protocol for interaction between agent instances also improves data communication, reducing inefficient resource consumption. Furthermore, implementing components through a service-provider-controlled versatile agent eliminates the need for customers to write and implement electronic code instructions, removing a significant barrier to entry for interface creation. Insulating malicious actors from direct access to the code also improves security, 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 specific interfaces. A component can correspond to a declarative definition that can be parsed by a generation engine residing on the client device. In this way, the entire component and component code do not need to be passed to the engine over a communication channel, but only the annotated declarative definition.

[0026] The declarative definitions can be parsed by 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 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] 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. The system 100 shown in FIG. 1 includes systems and devices 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 a variety of 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 can implement the client engine system 120 as a digital program, application, or set of instructions executing on the client device 110. The client engine system 120 can be a system comprising software, hardware, or a combination of both operable to perform the processes and methods described herein according to various embodiments. The client engine system 120 can further comprise several subsystems. The subsystems described herein may refer to systems operating within a larger host system to perform more specific and specialized processes essential to the functionality of the host system.

[0030] The client engine system 120 may include a dashboard display subsystem 121. The dashboard display subsystem 121 may be a subsystem operable to display a dashboard and various dashboard components on an electronic display. The client engine system 120 may further include 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 displayed dashboard. 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 include 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 diagram 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 carry out 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 production data related to component-based interfaces.

[0032] Server 130 can implement component facilitation system 140 as a digital program, application, or instruction set executing on server 130. Component facilitation system 140 may be a system comprising software, hardware, or a combination of both operable to perform the processes and methods described herein according to various embodiments. In various embodiments, component facilitation system 140 utilizes data transmitted to and stored on a client device, such as client device 110, to cause the rendering of components on a displayable interface on the client device. Component facilitation system 140 can further comprise several subsystems / independent systems operating as part of 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. The services may be services provided to clients 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] Network 160 may further be communicatively connected to data storage device 150. Data storage device 150 may comprise one or more electronic data storage memories to facilitate the embodiments described herein. Storage device may refer to any physical, electronic, and / or cloud-based storage device to facilitate the embodiments described herein. Data storage device may be internal memory, storage memory, or a medium that stores electronic data internally, externally, or separately from another system. For example, data storage device 150 may store data or information related to a communication protocol between client engine system 120 and component facilitation system 140, thereby enabling network 160 to interact with both entities. It will be understood that 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 may include a component cataloger 200. In various embodiments, the component cataloger can be a subsystem that catalogs several components to create a component list. The component list can correspond to several visual components 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 several plugins that store the components. The component cataloger can use the component manifest to identify several 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] Component facilitation system 140 may include a service data subsystem 142. Service data subsystem 142 may include query instructions 220. Query instructions 220 may be instructions for receiving and / or processing queries for service data associated with the dashboard. In various embodiments, 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] Component facilitation system 140 may include dashboard creation subsystem 143. Dashboard creation subsystem 143 may include dashboard component display instructions 240. 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, dashboard component display instructions 240 receive a display, such as display data generated by query instructions 220. Dashboard component display instructions 240 may cause the display data to be sent to a device with a digital display, such as client device 120. The display data may then be used to display the component on the digital display. In various embodiments, dashboard component display instructions 240 generate the display data based on the component to be rendered.

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

[0043] Component facilitation system 140 may further include a rendering subsystem 260. Rendering subsystem 260 may be configured to render components for display on a dashboard as part of a server-side rendering configuration. For example, rendering subsystem 260 may receive dashboard data generated by dashboard creation subsystem 143. Rendering subsystem 260 may convert the dashboard data into rendering data that can be sent to a client device to display a rendered version of the dashboard interface. Further examples of interactions between client device 120 and the subsystems of 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 the 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 display the dashboard interface.

[0045] The client engine system 120 may further include 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 send the data to the system to cause updates of the corresponding components. For example, in response to detecting input corresponding to a particular component displayed on the dashboard interface, the input handling subsystem may generate interaction metadata and send 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 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, a component may display an indicator of a customer's benefits in a widget component on a dashboard interface. The benefits information is stored client-side on the customer's device. A 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 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 the use of versatile agents to generate 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 the creation, maintenance, duplication, and / or deletion of one or more versatile agents to generate components for the dashboard interface.

[0048] Agent subsystem 310 can include component agents 320. Component agents 320 may be multi-purpose agents that are instantiated or non-instantiated / stored, as described herein. In various embodiments, component agents 320 include data stored in agent subsystem 310 that is invoked in response to receiving a declarative definition. For example, in response to client engine system 120 receiving declarative metadata, such as metadata from component facilitation system 140, client engine system 120 instantiates component agents 320 within dashboard engine subsystem 123. In various embodiments, component agents 320 receive and parse the declarative metadata to initiate a component generation process. Component agents 320 can include metadata parsing instructions 322. Metadata parsing instructions 322 can be instructions usable by component agents 320 to parse metadata, such as declarative metadata.

[0049] Component agent 320 may further include component generation instructions 324. 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, component agent 320 may retrieve client information from a local storage device, such as local storage subsystem 300, to drive component generation. The component generation process is further described in FIG. 5. In various embodiments, component generation instructions 324 of component agent 320 may be configured to utilize the declarative metadata parsed by component agent 320 to generate rendering data as part of a client-side rendering configuration. For example, component agent 320 may parse metadata from a declarative definition and convert the metadata into executable rendering data for driving the display of a corresponding visual component in a dashboard interface. Component agent 320 may further include inter-agent communication instructions 326. 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] Dashboard engine subsystem 123 may include service communication subsystem 330. Service communication subsystem 330 may be a subsystem of client engine system 120 that facilitates communication between one or more services and 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 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 can 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 can be displayed as part of the user's personal dashboard interface. The catalog subsystem 410 may receive the query and return a list of cataloged components 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 may 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] Client engine system 120 may further be communicatively coupled to dashboard creation subsystem 143 of component facilitation system 140. Client engine system 120 may be configured to send new dashboard data 430 corresponding to a desired dashboard configuration to dashboard creation subsystem 143. In response to receiving the new dashboard data 430, dashboard creation subsystem 143 may be configured to generate data regarding the configuration of the new dashboard. Dashboard creation subsystem 143 may be configured to send the generated data to client engine system 120 as updated dashboard data 440. For example, a user of client device 110 may create a “mock” dashboard that the user wants to view on client device 110. The client may utilize client engine system 120 to send new dashboard data 430 to dashboard creation subsystem 143, which generates 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 declarative definitions corresponding to widget definitions, which include 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 the 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 to be displayed 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 used 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 use 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, component agent 320 in client engine system 120 can facilitate display of a dashboard interface through communication with component facilitation system 140, shown in FIG. 4 . For example, a user of client device 110 can query a list of components from catalog subsystem 141. Catalog subsystem 141 can send catalog data corresponding to the list of components to be cataloged to client engine system 120. A user can select a subset of components within a particular configuration to build a dashboard interface. The configuration is packaged as new dashboard data and sent to dashboard creation subsystem 143. Based on the configuration specified by the dashboard data, dashboard creation subsystem 143 can generate updated dashboard data in the form of declarative metadata. The declarative metadata can be sent to client engine system 120 for rendering in a client-side rendering configuration or can be rendered directly in a server-side rendering configuration.

[0056] In a client-side rendering configuration, declarative metadata is received by a client engine system, and a component agent 320, such as a multi-purpose agent, parses the declarative metadata. Several multi-purpose agents are replicated to build the components specified in the declarative metadata. Once the rendering of the components is complete, one or more multi-purpose agents can query the service data subsystem 142 for service data to be displayed as part of the components in the dashboard definition. 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, a 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 updated dashboard data including an updated declarative definition of the new dashboard configuration.

[0058] FIG. 5 illustrates an example flowchart of a process for interface component generation using a multi-purpose 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. 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 multi-purpose agent as part of the component generation process. For example, the multi-purpose agent may receive declarative definitions corresponding to the configuration of one or more components to be displayed in a dashboard interface. The multi-purpose agent may receive the declarative definitions from a separate system, such as a component facilitation system.

[0059] In various further embodiments, the declarative metadata includes static metadata and variable metadata for 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 life of the dashboard interface. For example, a dashboard component that tracks a virtual machine's dynamic upload rate may include both static metadata and variable metadata. The static metadata may specify the particular virtual machine being tracked. The variable metadata may specify the virtual machine's dynamically updated upload rate, which is periodically updated on the displayed dashboard component. In various embodiments, service data received from the 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 definitions. In various still 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 still other embodiments, the declarative metadata may be a compilation of one or more declarative data subsets, where the one or more declarative data subsets are individually parseable by the versatile agent to determine one or more corresponding visual components to be displayed on the interface.

[0061] At step 530, component agents are cloned to reach specific visual components of the one or more visual components displayed on the interface. In various embodiments, the component agents are cloned from the original multi-purpose agent that parsed the declarative metadata. In various embodiments, at least one multi-purpose agent is cloned for each visual component 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-purpose 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 declarative metadata may be received by a particular replicated multi-purpose agent. Each of the replicated multi-purpose agents may be delegated the subset of declarative metadata for generating the corresponding visual component. The particular multi-purpose agent may generate the rendering data using the received subset of declarative metadata. For example, the multi-purpose agent may receive the subset of declarative metadata describing the visual component to be generated and a portion of the service data implementing the variable metadata in the subset of declarative metadata. The multi-purpose agent utilizes the data to generate the corresponding subset of 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 local data. In various embodiments, in response to receiving the subset of declarative metadata, the replicated versatile agent can query and / or obtain one or more datasets necessary to generate the component. For example, the versatile agent can determine one or more variable datasets 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 dataset using the incomplete declarative metadata and the obtained variable data.

[0064] In various embodiments, the versatile agent can use the complete declarative dataset to generate rendering data for rendering the visual component. The rendering data may be generative 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 dataset as input and output rendering data for rendering the component. Generating 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 dataset to generate a temporary representation of the visual component in 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 in the temporary representation. For example, the rendering data may be executable data to create a rendered representation of the visual component in computer memory according to the specifications generated in the temporary representation.

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

[0066] FIG. 6 illustrates an example flowchart of a distributed system and process for interface component generation using versatile agents, 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 process 600. Process 600 begins at step 610, in which 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 client device 110 running client engine system 120 to send a request to view a dashboard of components to service provider server 130 running component facilitation system 140. In various embodiments, the request to display the component dashboard includes a client indicator, which corresponds to a stored dashboard configuration. In various embodiments, the request to display the component dashboard includes a component manifest that lists several 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 plugins to fulfill the requested dashboard. The component facilitation system 140 can utilize a client-specific component manifest to determine the component plugins to fulfill 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 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 plugins can be identified. A plugin can be a software package that includes one or more component definitions or functions. Some plugins can be stored in internal memory or can be accessible by the internal memory of the component facilitation system 140. A plugin 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, client engine system 120 receives the declarative metadata from 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, 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, client engine system 120 generates a request for service data used to facilitate the dashboard interface. This request is sent to component facilitation system 140, which tracks and records metrics related to 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 to be sent to the client engine system 120.

[0071] In step 645, client engine system 120 receives the service data from component facilitation system 140 and generates rendering data for rendering the complete component on a dashboard interface. For example, client engine system 120 and a versatile agent replicated therein can use the declarative metadata and 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, 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 interaction with the interface. The user interaction may cause a particular component on a dashboard to be updated. Client engine system 120 may cause the component to be updated in response to the interaction determination. 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 plug-ins 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 and generates 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 the component repository 210, which retrieves the component catalog and one or more component datasets corresponding to the component catalog. The retrieved one or more component datasets can be compiled into declarative metadata. The declarative metadata can include some static data retrieved directly from the plug-ins and variable data fields 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 the dashboard engine subsystem 123, which 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 include one or more agent instances 710A-710N. The one or more agent instances may be versatile agents capable of parsing declarative metadata and replicating and generating rendering data for components. The dashboard subsystem 123 may further include a storage device 720. The storage device 720 may be a storage device containing data for generating instances of the versatile agent 710. The storage device 720 may be a local storage device, such as the local storage subsystem 300, containing 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 can 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 the 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, 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 it back to the dashboard engine subsystem 123 in response. In the above example, the virtual machine service may send information such as the virtual machine's current upload speed, download speed, maintenance status, etc.

[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 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 executing on a client device that hosts 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 generate a dashboard interface 751 on the console application's host interface 750, which is visible to the user via an electronic display. The dashboard interface 751 can be populated with components 753 as they become available and displayed by executing display data.

[0081] In this manner, the dashboard library 26=50 and 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, 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 include a global control component 752. The global control component 752 may be a separate component that is inherently part of the dashboard interface 751 without requiring component generation. The global control component 752 may be a component that a 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 level, shading level, etc. In another example, the global control component 752 can change one or more functional aspects of the dashboard interface, such as input protocol, update protocol, etc.

[0082] 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. Then, while the second component is still rendering, the first component may be displayed in the dashboard interface before the second component. Components 753A-753N may be interactive components. Interactive components may be modified in some way or perform some function when interaction with the component is detected. For example, as shown in FIG. 7, component 753A is highlighted with a border, indicating that a client has interacted with component 753A using a digital interface. 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 can further include a component editing interface 760. The component editing interface 760 can be an interface through which a client can modify some aspects of a current component 753 or create a new component. The component editing interface 760 can be real-time and interactive, meaning that declarative metadata can 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 , plug-in A 700A can contain some data related to the functionality of the component being edited in the component editing interface 760. Data can be retrieved and / or transformed in real time from 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 utilizing components 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-style component that displays the operating status of a virtual machine.

[0085] The host interface 750 may further include 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 selections for creating a new component and display them on the client. For example, as shown in FIG. 8, a potential new component may be an "active server location" widget component for displaying the location of an active server. The potential new component is displayed as a duplicate of the component to be created 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 for which the client can specify display information.

[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 can specify the display of a dashboard, "My Virtual Machine Dashboard." The user can interact with a new component 810 and request the creation of a new component via the editing interface 760. In response to detecting the interaction with the new component 810, the client engine system 120 can 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 can be displayed as a duplicate component on the component editing 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 several 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 several 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 displayed components. 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 servers operated by a service provider and used by the client. The service data subsystem 142 can send this information back to the particular multi-purpose agent.

[0088] The versatile agent can generate rendering data for components to be displayed on the dashboard interface using the declarative definitions received from the dashboard creation subsystem 143 and the service data received from the service data subsystem 142. 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 a specific type of cloud computing. IaaS can be configured to deliver 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, and platform virtualization (e.g., hypervisor layer)). In some cases, IaaS providers can also offer various services (e.g., billing, monitoring, logging, load balancing, and clustering) that accompany these infrastructure components. Therefore, these services can be policy-driven, allowing IaaS users to 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 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 can be, but does not have to be, a third-party service that specializes in providing (e.g., providing, renting, or selling) IaaS. An entity can 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 can also include the process of preparing the server (e.g., installing libraries, daemons, etc.), which is often managed by the cloud provider below the hypervisor layer (e.g., server, storage, network hardware, and virtualization). Thus, the customer can 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 refer to obtaining computers or virtual hosts for use and even 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, IaaS provisioning presents two distinct challenges. First, there's the initial challenge of provisioning an initial set of infrastructure before anything can run. Second, there's 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 needed 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 they work together) 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 interconnected elements. For example, there may be one or more virtual private clouds (VPCs) (e.g., potentially on-demand pools 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 desirably deployed to one or more, but often many, different production environments (e.g., across various different geographic locations, possibly spanning the entire world). However, in some examples, the infrastructure onto which the code will be deployed must first be set up. In some cases, provisioning can be done manually, utilizing provisioning tools to provision resources and / or deployment tools 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, BlackBerry 8, PalmOS, and other enabled communication protocols. 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 VCN 906 and / or the Internet.

[0098] 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 included in SSH VCN 912. SSH VCN 912 may include an SSH subnet 914, which may be communicatively coupled to a control plane VCN 916 via an LPG 910 included in control plane VCN 916. SSH VCN 912 may also be communicatively coupled to a data plane VCN 918 via 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 functions 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, and a control plane data tier 928, which 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 to 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, which 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, which can be included in the data plane app layer 946.

[0101] The data plane VCN 918 may 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 may include a LB subnet 922, which may 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 may 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 may also include a DB subnet 930, which may 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 the 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 a cloud service 956 without traversing the public internet 954. API calls from the service gateway 936 to the cloud service 956 can be one-way: the service gateway 936 can make an API call to the cloud service 956, and the cloud service 956 can send the requested data to the service gateway 936. However, the cloud service 956 may not be able to initiate the API call to the service gateway 936.

[0104] In some examples, secure host tenant 904 can be directly connected to service tenant 919 or can be otherwise separate. Secure host subnet 908 can communicate with SSH subnet 914 through LPG 910, which can enable bidirectional communication through otherwise separate systems. Connecting secure host subnet 908 to SSH subnet 914 can give secure host subnet 908 access to other entities within 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 the data plane mirror app layer 940 of the control plane VCN 916 can communicate with the 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 a create, read, update, or delete (CRUD) operation, over 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 store 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 appropriate modifications to resources included in the data plane VCN 918. Via 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 appropriate 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 cannot own or operate either the control plane VCN 916 or the data plane VCN 918. Instead, an IaaS provider can own or operate the control plane VCN 916 and the data plane VCN 918, which can both be included in the service tenant 919. This embodiment can enable network isolation that can prevent users or customers from interacting with the resources of other users or other customers. This embodiment also allows users or customers of the system to store databases privately without having to rely on the public internet 954 for storage, which may not have the desired level of threat protection.

[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 customers of the IaaS provider without calling the public internet 954. Customers of the IaaS provider may desire this embodiment because databases used by the customers may be stored in the service tenant 919, which may be controlled by the IaaS provider and isolated from the public internet 954.

[0110] 10 is a block diagram 1000 illustrating another example pattern of an IaaS architecture, according to at least one embodiment. A service operator 1002 (e.g., service operator 902 in FIG. 9 ) can be communicatively coupled to a secure host tenant 1004 (e.g., secure host tenant 904 in FIG. 9 ), which can include a virtual cloud network (VCN) 1006 (e.g., VCN 906 in FIG. 9 ) and a secure host subnet 1008 (e.g., secure host subnet 908 in FIG. 9 ). VCN 1006 can include a local peering gateway (LPG) 1010 (e.g., LPG 910 in FIG. 9 ), which can be communicatively coupled to a secure shell (SSH) VCN 1012 (e.g., SSH VCN 912 in FIG. 9 ) via the LPG 910 included in the SSH VCN 1012. SSH VCN 1012 can include an SSH subnet 1014 (e.g., SSH subnet 914 in FIG. 9 ), and 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 ), which 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 to 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 942) on which a computing instance 1044 (e.g., similar to 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 in FIG. 9 ), which can be communicatively coupled to the public internet 1054 (e.g., public internet 954 in 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 in 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 for each customer, which is included in a service tenant 1019. 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 customer tenant 1021. In this example, control plane VCN 1016 may include data plane mirror app tier 1040, which may include app subnet 1026. While data plane mirror app tier 1040 may reside in data plane VCN 1018, data plane mirror app tier 1040 need not reside in data plane VCN 1018. That is, while data plane mirror app tier 1040 has access to customer tenant 1021, data plane mirror app tier 1040 may not reside in data plane VCN 1018 and may be owned or operated by the IaaS provider's customer. Data plane mirror app tier 1040 may be configured to make calls to data plane VCN 1018, but may not be configured to make calls to any entities included in control plane VCN 1016. A customer may wish 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 restrict 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 can be called by the service gateway 1036 to access services that may not reside on the public internet 1054, the control plane VCN 1016, or 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 reside on a separate 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, 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, according to at least one embodiment. A service operator 1102 (e.g., service operator 902 in FIG. 9 ) can be communicatively coupled to a secure host tenant 1104 (e.g., secure host tenant 904 in FIG. 9 ), which can include a virtual cloud network (VCN) 1106 (e.g., VCN 906 in FIG. 9 ) and a secure host subnet 1108 (e.g., secure host subnet 908 in FIG. 9 ). VCN 1106 can include an LPG 1110 (e.g., LPG 910 in 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 in FIG. 9 ). SSH VCN 1112 can include SSH subnet 1114 (e.g., SSH subnet 914 in FIG. 9 ), and SSH VCN 1112 can be communicatively coupled to control plane VCN 1116 via LPG 1110 included in control plane VCN 1116 (e.g., control plane VCN 916 in FIG. 9 ), and can be communicatively coupled to data plane VCN 1118 via LPG 1110 included in data plane VCN 1118 (e.g., data plane 918 in FIG. 9 ). Control plane VCN 1116 and data plane VCN 1118 can be included in 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 to an Internet gateway 1134 (e.g., Internet gateway 934 in 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 in FIG. 9 ), and a network address translation (NAT) gateway 1138 (e.g., NAT gateway 938 in 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] Data plane VCN 1118 may include a data plane app layer 1146 (e.g., data plane app layer 946 in FIG. 9 ), a data plane DMZ layer 1148 (e.g., data plane DMZ layer 948 in FIG. 9 ), and a data plane data layer 1150 (e.g., data plane data layer 950 in FIG. 9 ). Data plane DMZ layer 1148 may include LB subnet 1122, which may be communicatively coupled to trusted app subnet 1160 and untrusted app subnet 1162 of data plane app layer 1146 and to an Internet gateway 1134 included in data plane VCN 1118. Trusted app subnet 1160 may be communicatively coupled to service gateway 1136 included in data plane VCN 1118, NAT gateway 1138 included in data plane VCN 1118, and DB subnet 1130 included in 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 can 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 can be communicatively coupled to the public internet 1154 (e.g., public internet 954 in 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 a customer tenant 1170. This integration may be beneficial or desirable for an IaaS provider's customer, such as when support is needed during code execution. A customer may provide code to run that may be destructive, communicate with other customer resources, or cause other undesirable effects. Accordingly, the IaaS provider can decide whether to run code provided to the IaaS provider by the customer.

[0124] In some examples, an IaaS provider's customer may grant the IaaS provider temporary network access and request functionality to be added to the data plane layer app 1146. The code that performs the functionality may run in VMs 1166(1)-(N), and the code cannot 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 run code. In this case, double isolation may exist (e.g., code execution in container 1171(1)-(N) may be contained in at least one VM 1166(1)-(N) contained in the untrusted app subnet 1162), which may help prevent errant 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 can 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, although in this embodiment, the untrusted app subnet may be configured to perform read operations on 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 can occur indirectly through at least one method. The LPG 1110 may be established by an IaaS provider that can 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 can 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 can 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 in FIG. 9 ) can be communicatively coupled to a secure host tenant 1204 (e.g., secure host tenant 904 in FIG. 9 ), which can include a virtual cloud network (VCN) 1206 (e.g., VCN 906 in FIG. 9 ) and a secure host subnet 1208 (e.g., secure host subnet 908 in FIG. 9 ). VCN 1206 can include an LPG 1212 (e.g., LPG 910 in FIG. 9 ) that can be communicatively coupled to an SSH VCN 1212 (e.g., SSH VCN 912 in 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 ), and SSH VCN 1212 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 ) that 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 ) that 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 ) that may include a DB subnet 1230 (e.g., DB subnet 1030 of FIG. 10 ). LB subnet 1222 included in control plane DMZ tier 1220 can be communicatively coupled to app subnet 1226 included in control plane app tier 1224 and can be communicatively coupled to an Internet gateway 1234 (e.g., Internet gateway 934 in FIG. 9 ) that can be included in control plane VCN 1216, and app subnet 1226 can be communicatively coupled to DB subnet 1230 included in control plane data tier 1228 and can be communicatively coupled to service gateway 1236 (e.g., service gateway in FIG. 9 ) and network address translation (NAT) gateway 1238 (e.g., NAT gateway 938 in FIG. 9 ). Control plane VCN 1216 can include service gateway 1236 and NAT gateway 1238.

[0129] Data plane VCN 1218 may include a data plane app layer 1246 (e.g., data plane app layer 946 in FIG. 9 ), a data plane DMZ layer 1248 (e.g., data plane DMZ layer 948 in FIG. 9 ), and a data plane data layer 1250 (e.g., data plane data layer 950 in FIG. 9 ). Data plane DMZ layer 1248 may include LB subnet 1222, which may be communicatively coupled to trusted app subnet 1260 (e.g., trusted app subnet 1060 in FIG. 10 ) and untrusted app subnet 1262 (e.g., untrusted app subnet 1062 in FIG. 10 ) of data plane app layer 1246, and an Internet gateway 1234 included in data plane VCN 1218. Trusted app subnet 1260 can be communicatively coupled to service gateway 1236 included in data plane VCN 1218, and can be communicatively coupled to NAT gateway 1238 included in data plane VCN 1218, and to DB subnet 1230 included in data plane data layer 1250. Untrusted app subnet 1262 can be communicatively connected to service gateway 1236 included in data plane VCN 1218 and DB subnet 1230 included in data plane data layer 1250. Data plane data layer 1250 can include DB subnet 1230, which can be communicatively coupled to service gateway 1236 included in 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) residing 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, which can be included in a data plane app tier 1246, which can be included in a container egress VCN 1268. Each secondary VNIC 1272(1)-(N) can facilitate communication between the untrusted app subnet 1262, which is 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, which can be communicatively coupled to the public internet 1254 (e.g., public internet 954 in FIG. 9 ).

[0131] An internet gateway 1234 included in the control plane VCN 1216 and 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 in the data plane VCN 1218. A service gateway 1236 included in the control plane VCN 1216 and 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 in FIG. 12 may be considered an exception to the pattern illustrated by the architecture of block diagram 1000 in FIG. 10 and may be desirable for an IaaS provider's customers when the IaaS provider cannot communicate directly with the customer (e.g., in disconnected areas). Each container 1267(1)-(N) contained in each customer's VM 1266(1)-(N) is accessible in real time by the customer. Containers 1267(1)-(N) may be configured to make calls to respective secondary VNICs 1272(1)-(N) contained in app subnet 1226 of data plane app tier 1246, which may be contained in container egress VCN 1268. Secondary VNICs 1272(1)-(N) may send the calls to NAT gateway 1238, which may send the calls to 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) can be isolated from resources from other customers.

[0133] In another example, a customer can use containers 1267(1)-(N) to invoke cloud service 1256. In this example, the customer can execute code within containers 1267(1)-(N) that requests a service from cloud service 1256. Containers 1267(1)-(N) can send the request to secondary VNICs 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 to LB subnet 1222, which is included in control plane VCN 1216, via internet gateway 1234. 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 shown. Additionally, the depicted embodiments are only a few 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 service 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 upon which various embodiments may be implemented. System 1300 may be used to implement any of the computer systems described above. As shown, 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. Storage subsystem 1318 includes a tangible computer-readable storage medium 1322 and a system memory 1310.

[0137] Bus subsystem 1302 provides a mechanism that allows the various components and subsystems of computer system 1300 to communicate with each other as intended. While bus subsystem 1302 is shown schematically as a single bus, alternative embodiments of the bus subsystem may utilize multiple buses. 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 described above. The computer system 1300 may further include a processing accelerator 1306, which may include a digital signal processor (DSP), a 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, touchpads or touchscreens 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 users 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 the 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 (e.g., 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, gamepads, 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 reader 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, positional emission tomography, and medical ultrasound equipment. 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. System memory 1310 may store program instructions that are loadable and executable on 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 presently being operated on and executed by the processing unit 1304. In some implementations, the system memory 1310 may include several different types of memory, such as static random access memory (SRAM) or dynamic random access memory (DRAM). In some implementations, the 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 middle-tier application, a relational database management system (RDBMS), etc. By way of example, operating system 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 structures that provide the functionality of some embodiments. Software (programs, code modules, instructions) that, when executed by a 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 further connect 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 can include any suitable medium known or used in the art, including, but not limited to, storage and communication media such as volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storing and / or transmitting information. This can 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 device, magnetic cassette, magnetic tape, magnetic disk storage device, or other magnetic storage device, or other tangible computer-readable medium. This can 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 computing system 1300.

[0148] By way of example, the computer-readable storage medium 1322 may include a hard disk drive that reads from or writes to non-removable, non-volatile magnetic media, a magnetic disk drive that reads from or writes to a removable, non-volatile magnetic disk, and an optical disk drive that reads from or writes to a removable, non-volatile optical disk such as a CD-ROM, DVD, Blu-Ray® disk, or other optical media. The computer-readable storage medium 1322 may include, but is not limited to, a Zip® drive, a flash memory card, a Universal Serial Bus (USB) flash drive, a Secure Digital (SD) card, a DVD disk, a digital video tape, etc. The computer-readable storage medium 1322 may also include a solid-state drive (SSD) based on non-volatile memory such as a flash memory-based SSD, an enterprise flash drive, an SSD based on volatile memory such as solid-state RAM, dynamic RAM, static RAM, etc., such as solid-state ROM, a DRAM-based SSD, a magnetoresistive RAM (MRAM) SSD, and a hybrid SSD that uses a combination of DRAM and a flash memory-based SSD. 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 computer system 1300.

[0149] The communications subsystem 1324 provides an interface to other computer systems and networks. The communications subsystem 1324 serves as an interface for transmitting and receiving data from the computer system 1300 to and from other systems. For example, the communications subsystem 1324 may enable the computer system 1300 to connect to one or more devices via the Internet. In some embodiments, the communications 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 communications technologies, or any combination thereof), global positioning system (GPS) receiver components, and / or other components. In some embodiments, the communications 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, etc.

[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 communicate 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 computer system 1300 shown in the figure is intended as a specific example only. Many other configurations are possible, having 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 recognize other approaches and / or methods for implementing various embodiments.

[0156] While specific embodiments have been described, various modifications, variations, alternative constructions, and equivalents are also within the scope of the present disclosure. The embodiments are not limited to operation in any particular data processing environment, but can 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 present disclosure is not limited to the sequence of transactions and steps described. Various features and aspects of the above-described embodiments can be used individually or in combination.

[0157] Furthermore, while embodiments have been described using particular combinations of hardware and software, it should be recognized that other combinations of hardware and software are within the scope of the present disclosure. Embodiments may be implemented exclusively in hardware, exclusively in software, or using a combination thereof. The various processes described herein may be implemented on the same processor or any combination of different processors. Thus, when a component or module is described as being configured to perform particular operations, such configuration may be achieved, for example, by designing electronic circuitry to perform the operations, by programming a programmable electronic circuit (such as a microprocessor) to perform the operations, or any combination thereof. Processes may communicate using a variety of techniques, including, but not limited to, conventional techniques for inter-process communication; different pairs of processes may use different techniques, or the same pair of processes may use 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 below) 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 partially or wholly contained within, attached to, or joined 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 separate value falling within that range, unless otherwise stated herein, and each separate value is incorporated into the specification as if it were set forth individually 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 solely to better illustrate 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 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 will be able to adopt such variations as appropriate, and the present disclosure may be practiced 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 includes any combination of the above-described elements in all possible variations thereof.

[0162] All references, including publications, patent applications, and patents, cited in this specification 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-described 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. Accordingly, 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: receiving, by a client device, declarative metadata, at least a portion of the declarative metadata corresponding to one or more visual components displayed on an interface; The method comprises: parsing 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 on the client device and corresponding to a particular visual component of the one or more visual components, and 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 the 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. 5. The method of claim 1, wherein the component agent analyzes the declarative metadata to determine a number of component agents to replicate 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. 5. The method of claim 1, 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, by 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 wherein the server device is 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 in 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: transmitting, 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. 5. The method of claim 1, 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 that causes a processor to execute the method according to any one of claims 1 to 12.

14. A memory storing the computer program according to claim 13; 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