Cloud architecture generation, simulation, and optimization

Abstract

Techniques are disclosed for generating, simulating, and optimizing one or more provider-specific cloud-based architectures from provider-independent architecture definitions. An architecture generator maps provider-independent service definitions to provider-specific service components for one or more specific cloud service providers. An architecture simulator simulates the execution of a set of actions for a provider-specific cloud-based architecture to determine one or more performance and cost metrics. An architecture optimizer varies one or more design choices or parameters of a provider-specific service component and suggests which variant is best suited to the optimization goal.

Description

Technical Field

[0001] Technical Field The present disclosure relates to simulating and measuring the performance of a provider-specific cloud-based architecture generated using a provider-independent cloud-based architecture template.

Background Art

[0002] Background Cloud-based services are for third parties who wish to provide their services to customers to use computing resources such as data storage, data processing, and networking services without having to invest in, manage, and maintain their own physical computing and network resources.

[0003] To use cloud-based services, a user may need to select which cloud service to use and select one or more cloud service components to use to host their particular service. As an example, a user can choose from data storage components, data management components, data processing components, and compute shapes to configure an architecture for their service. A cloud architecture refers to a particular set of cloud components and components provided by the user that are used in combination to provide a user's service. The selection of particular cloud components can affect the monetary cost of using the cloud service and the time required to complete tasks performed by the components within the architecture.

Summary of the Invention

[0004] The methods described in this section are methods that can be pursued, but not necessarily methods that have been previously devised or pursued. Therefore, unless otherwise indicated, no method described in this section should be assumed to be qualified as prior art simply by being included in this section.

[0005] Embodiments are shown in the accompanying drawings for illustrative purposes only, not as limitations. Note that whereever the “one” or “single” embodiment is referred to in this disclosure, it means at least one embodiment, and not necessarily the same embodiment. [Brief explanation of the drawing]

[0006] [Figure 1A] This figure shows a system according to one or more embodiments. [Figure 1B] This figure shows a system according to one or more embodiments. [Figure 2] This is a data flow diagram for an example of an architecture generator, based on one or more embodiments. [Figure 3] This is a data flow diagram for an example of an architecture simulator, based on one or more embodiments. [Figure 4] This is a data flow diagram for an example of an architecture optimizer, based on one or more embodiments. [Figure 5] This figure shows an exemplary set of operations for generating provider-specific architectures by one or more embodiments. [Figure 6] This figure shows an exemplary set of behaviors for simulating a provider-specific architecture, according to one or more embodiments. [Figure 7] This figure shows an exemplary set of actions for optimizing provider-specific architectures, according to one or more embodiments. [Figure 8] This figure shows an example of a provider-independent architecture definition. [Figure 9] This figure shows the first example of a provider-specific architecture. [Figure 10] This figure shows a second example of a provider-specific architecture. [Figure 11] This is a block diagram showing a computer system in one or more embodiments. [Modes for carrying out the invention]

[0007] Detailed explanation The following description provides numerous specific details for illustrative purposes to ensure a complete understanding. One or more embodiments may be implemented without these specific details. Features described in one embodiment may be combined with features described in a different embodiment. In some examples, known structures and devices are described with reference to block diagrams to avoid unnecessarily obscuring the invention.

[0008] 1.Overview 2. System Overview 3. Architecture Generator 4. Architecture Simulator 5. Architecture Optimizer 6. Actions for generating provider-specific architectures 7. Operation to simulate provider-specific architecture 8. Actions to optimize provider-specific architectures 9. Exemplary Embodiments 10. Computer networks and cloud networks 11. Hardware Overview 12. Miscellaneous rules, extensions 1.Overview One or more embodiments simulate provider-specific cloud architectures to generate and present corresponding performance metrics. The system generates provider-specific cloud architectures corresponding to each cloud-based system from the same provider-independent architecture definition. The provider-independent architecture definition includes user-selected components, service components, and connections representing data flows. For each corresponding cloud provider, the system generates a provider-specific architecture by mapping the service component descriptions to the system-selected service components of that corresponding cloud provider. Furthermore, the system incorporates user-selected components specified in the provider-independent architecture definition into the provider-specific architecture. Finally, the system configures the data flows represented by connections in the provider-independent architecture definition. The system simulates the operation for each of the provider-specific architectures corresponding to various cloud providers to generate and present performance metrics.

[0009] One or more embodiments described herein and / or claimed in the claims may not be included in this summary section.

[0010] 2. System Overview Figure 1A shows a system 100 according to one or more embodiments. As shown in Figure 1, the system 100 comprises an interface 102, an architecture selection engine 110, and a data repository 120. In one or more embodiments, the architecture selection engine 110 may include one or more functional components such as an architecture generator 112, an architecture simulator 114, and an architecture optimizer 116.

[0011] In one or more embodiments, system 100 may include more or fewer components than those shown in FIG. 1A. The components shown in FIG. 1A may be local or remote to each other. The components shown in FIG. 1A may be implemented in software and / or hardware. Each component may be distributed across multiple applications and / or machines. Multiple components may be combined into one application and / or machine. Operations described with respect to one component may instead be performed by another component.

[0012] In one or more embodiments, architecture selection engine 110 refers to hardware and / or software configured to perform the operations described herein for generating a cloud service architecture, simulating the architecture, and optimizing the architecture. Examples of operations for generation, simulation, and optimization are described below with reference to FIGS. 2-8.

[0013] In one or more embodiments, architecture generator 112 refers to software and / or hardware configured to receive a provider-independent architecture definition and generate one or more provider-specific architectures from the provider-independent architecture definition. Examples of operations for generating provider-specific architectures are described below with reference to FIGS. 2 and 5.

[0014] In one or more embodiments, architecture simulator 114 refers to software and / or hardware configured to receive a provider-specific architecture and simulate the operations of the provider-specific architecture for a set of operations to determine one or more performance metrics. Examples of operations for simulating provider-specific architectures are described below with reference to FIGS. 3 and 6.

[0015] In one or more embodiments, the architecture optimizer 116 refers to software and / or hardware configured to optimize a provider-specific architecture by receiving a provider-independent architecture definition, varying one or more characteristics of the provider-specific architecture, comparing performance over the variations, and identifying an optimal provider-specific architecture that varies according to goals and / or constraints. An example of an operation for optimizing a provider-specific architecture is described below with reference to FIGS. 4 and 7.

[0016] In one or more embodiments, the data repository 120 is any type of storage unit and / or device for storing data (e.g., a file system, a database, a set of tables, or any other storage mechanism). Further, the data repository 120 can include multiple different storage units and / or devices. The multiple different storage units and / or devices may or may not be of the same type and may or may not be located in the same physical location. Further, the data repository 120 may be implemented or executed on the same computing system as the architecture selection engine 110. Alternatively, or in addition, the data repository 120 may be implemented or executed on a separate computing system from the architecture selection engine 110. The data repository 120 can be communicatively coupled to the architecture selection engine 110 via a direct connection or via a network.

[0017] The data repository 120 can store one or more data elements used by the architecture selection engine 110. As shown in Figure 1B, for example, the data repository 120 may include a set of provider-independent service descriptions 121, a set of provider-specific architecture mappings 122, a set of provider-specific service components 124, a set of user-selected components 126, a set of provider-specific service component simulation models 128, and a set of input workloads 130. The information used by the architecture selection engine 110 can be performed across any of the components in the system 100. However, this information is presented in the data repository 120 for clarity and explanatory purposes.

[0018] In one or more embodiments, a provider-independent service description 121 may include a description of a cloud-based service without any reference to a specific cloud provider implementation. Some provider-independent service descriptions may include, for example, multi-tenant virtual machines, batch data processing, key-value object storage, virtual networks, organized resources, or account services. Some provider-independent service descriptions may include additional parameters. For example, a multi-tenant virtual machine description may include a parameter about the size of the compute shape of the multi-tenant virtual machine. For some services, a product with a specific brand name, such as the Oracle® database, may be specified as a provider-independent service description, but because different cloud service providers may use different versions, the provider-independent service description may not specify a particular version or implementation of the product.

[0019] In one or more embodiments, the provider-specific architecture mapping 122 may include a process and / or data structure that maps provider-independent service descriptions to provider-specific service components 124. The data repository 120 may include a provider-specific architecture mapping 122 for each cloud service provider supported by the engine 110. For a given particular cloud service provider, the mapping 122 may be a decision tree, a lookup table, or any other data structure and / or logic that receives provider-independent service descriptions and outputs provider-specific service components for that cloud service provider.

[0020] A provider-specific architecture mapping 122 may also include logic to resolve cases where one provider-independent service description maps to two or more provider-specific service components, or cases where it does not map to any provider-specific service components. The logic for resolving one-to-many mappings in a given provider-specific architecture mapping 122 can be improved by using a machine learning model that incorporates feedback from users and / or from one simulated or actual performance metric selected from many components.

[0021] In one or more embodiments, a provider-specific service component 124 can define a cloud service component for a particular cloud service provider. For example, one cloud service provider, AMAZON WEB SERVICES (AWS)®, provides the AMAZON RELATIONAL DATABASE SERVICE as a managed relational database system, and another cloud service provider, Oracle Cloud Infostructure (OCI), provides the OCI BASE DATABASE SERVICE as a managed relational database system. Within a provider-specific service component, additional parameters and design options may be selectable. For example, a provider-specific service component may be available in various compute shapes. A compute shape represents a set of computing resources, such as the number of processing units and the amount of memory that can be allocated to the provider-specific service component. Within a particular provider-specific service component, small, medium, or large compute shapes can be selected. The provider-specific service component 124 is selected by the architecture generator 112.

[0022] In one or more embodiments, the user-selectable component 126 may include software, metadata, or data that are provided and controlled by the user for deployment within a cloud-based architecture. The user-selectable component 126 is included in a provider-specific architecture generated by the architecture generator 112.

[0023] In one or more embodiments, the provider-specific service component simulation model 128 may include data specifying how software, metadata, and / or related provider-specific service components 124 behave with respect to data. The model 128 may include, for example, procedures for generating new subsequent events from received events, procedures for estimating how long an event will take, procedures for estimating how much it will cost to process an event, and / or parameters that can be adjusted to affect the cost and / or completion time of an event in a given context. In one or more embodiments, the procedure for estimating the time or cost to process an event may be implemented as a lookup table, a decision tree, or a machine learning model. The model 128 may include a semantic model for synchronous requests and a semantic model for asynchronous requests.

[0024] In one or more embodiments, the input workload 130 may include a set of data and / or actions for use when simulating a provider-specific architecture. For example, the input workload may include a set of actions such as database queries or batch data processing actions. Model 128 and the input workload 130 can be used by the architecture simulator 114 to simulate the actions of a provider-specific architecture.

[0025] In one or more embodiments, System 100 is implemented in one or more digital devices. The term “digital device” generally refers to any hardware device, including a processor. A digital device may refer to a physical or virtual machine running an application. Examples of digital devices include computers, tablets, laptops, desktops, netbooks, servers, web servers, network policy servers, proxy servers, general-purpose machines, hardware devices for specific functions, hardware routers, hardware switches, hardware firewalls, hardware network address translators (NATs), hardware load balancers, mainframes, televisions, content receivers, set-top boxes, printers, mobile handsets, smartphones, personal digital assistants (PDAs), wireless receivers and / or transmitters, base stations, communication management equipment, routers, switches, controllers, access points, and / or client devices.

[0026] In one or more embodiments, interface 102 refers to hardware and / or software configured to facilitate communication between the user and the architecture selection engine 110. Interface 102 may include an architecture design interface for the architecture engine 110 that allows the user to select, coordinate, connect, and configure user selection components 126 and provider-independent service descriptions 121. Interface 102 renders user interface elements and receives input through user interface elements. Examples of interfaces include graphical user interfaces (GUIs), command-line interfaces (CLIs), haptic interfaces, and voice command interfaces. Examples of user interface elements include checkboxes, radio buttons, drop-down lists, list boxes, buttons, toggles, text fields, date and time selectors, command lines, sliders, pages, and forms.

[0027] In this embodiment, different components of interface 102 are specified in different languages. The behavior of user interface elements can be specified in a dynamic programming language such as JavaScript®. The content of user interface elements is specified in a markup language such as Hypertext Markup Language (HTML) or XML User Interface Language (XUL). The layout of user interface elements is specified in a stylesheet language such as Cascading Style Sheets (CSS). Alternatively, interface 102 may be specified in one or more other languages ​​such as Java®, C, or C++.

[0028] Further embodiments and / or examples relating to computer networks are described below in Section 10, entitled “Computer Networks and Cloud Networks.”

[0029] 3. Architecture Generator Figure 2 shows an exemplary data flow diagram for the architecture generator 112 according to one or more embodiments. One or more operations shown in Figure 2 may be modified, rearranged, or omitted entirely. Therefore, a particular sequence of operations shown in Figure 2 should not be construed as limiting the scope of one or more embodiments.

[0030] The architecture generator 112 can receive a provider-independent architecture definition 202 from a user. The definition 202 can be received, for example, via interface 102. The definition 202 can include various elements, including one or more sets of user-selected components 126, one or more sets of provider-independent service descriptions 121, and one or more sets of connections 203. The connections 203 can represent data flows between the user-selected components 126 and the provider-independent service descriptions 121. For example, the connections 203 can identify where an input to one component or description connects to an output of another component or description. The provider-independent architecture definition 202 can also include metadata that specifies the order in which the components of the architecture are executed or accessed at runtime. An example of a provider-independent architecture definition is shown below with reference to Figure 8.

[0031] The architecture generator 112 can also receive a selection 205 of one or more cloud service providers for generating provider-specific architectures. The selection 205 can be received, for example, from a user via interface 102.

[0032] The architecture generator 112 can receive or retrieve provider-specific architecture mappings 122 for each cloud service provider in selection 205. The architecture generator 112 can apply the mappings 122 to provider-independent descriptions 121 in definition 202 to identify and select provider-specific service components 124 corresponding to provider-independent service descriptions 121.

[0033] Once each provider-independent service description is mapped to the respective provider-specific service components for the cloud service, the architecture generator 112 can generate a provider-specific architecture 204 for that cloud service provider. The provider-specific architecture 204 may include user-selected components 126, system-selected service components 124, and connections 203.

[0034] The architecture generator 112 can configure one or more data flows according to the connection 203. For example, the architecture generator 112 can identify the data type and / or format that is input or output from the user-selected component 126. The architecture generator 112 can configure one or more data flows according to data flow information associated with the connection between the user-selected component and the system-selected component. The architecture generator 112 can configure one or more data flows according to the data of the interface elements associated with the first user-selected component and the first system-selected component. The architecture generator 112 can configure one or more data flows according to a previously configured provider-specific architecture using the same or similar system-selected components and the same or similar user-selected components. One or more embodiments may determine that additional connections are required between components of a provider-independent architecture definition beyond those provided by the user. The architecture generator 112 can add these connections to the provider-independent architecture definition as system-selected connections.

[0035] The architecture generator 112 can repeat the generation process for each cloud provider in selection 205 to generate multiple provider-specific architectures. These provider-specific architectures 204 can be stored, for example, in the data repository 120. The stored architectures 204 can then be used, for example, for future deployment and use in cloud services, or as input for machine learning models. Examples of provider-specific architectures are described below with reference to Figures 9 and 10.

[0036] 4. Architecture Simulator Figure 3 shows an exemplary data flow diagram for the architecture simulator 114 according to one or more embodiments. One or more operations shown in Figure 3 may be modified, rearranged, or omitted entirely. Therefore, a particular sequence of operations shown in Figure 3 should not be construed as limiting the scope of one or more embodiments.

[0037] The architecture simulator 114 can receive one or more provider-specific architectures 204. The architectures 204 can be retrieved from the data repository 120 or passed directly to the architecture simulator 114 from the architecture generator 112.

[0038] The architecture simulator 114 can receive or retrieve an input workload 130 from the data repository 120. The input workload 130 can include a set of actions for a provider-specific architecture 204 to perform. For example, the input workload 130 can include a set of database queries, a set of data on which one of the user-selected components 126 acts, or a combination of data and instructions. The input workload 130 can include parameters such as a time limit for the simulation, a maximum number of events to process, and / or the execution rate of the simulation. The input workload 130 may be static, in which case events are generated at a fixed rate. The input workload 130 may also be dynamic, in which case the number of events generated changes over time.

[0039] For a given provider-specific architecture 204, the architecture simulator 114 can retrieve provider-specific service component simulation models 128 associated with each system-selected service component 124 in the architecture 204. The architecture simulator 114 can construct, for example, a directed property graph data structure containing each of the simulation models 128 and connections 203. The architecture simulator 114 can also specify one or more services that affect the observable cost and execution time of the input workload 130. The architecture simulator 114 can also specify one or more model parameters that characterize how the simulation should run. For example, the model parameters could specify the average response time for executing a request.

[0040] In one or more embodiments, the architecture simulator 114 can simulate the execution of the architecture at the request level. The architecture simulator 114 can use a simulation model to track processing metrics, including timing data such as event arrival time, event processing start time, and processing completion time. The architecture simulator 114 can also track communication metrics associated with the communication of data between service components specific to each provider. The architecture simulator 114 can continue simulating the processing of the input workload until all events in the input workload 130 have been processed or until another simulation limit is reached.

[0041] The architecture simulator 114 can aggregate timing data and communication metrics from individual simulation models to generate and present one or more performance metrics 302 when the simulation is complete. Performance metrics may include the total time from the user's perspective to run the input workload across the architecture, referred to as wall time. Performance metrics may include the total time from the cloud service's perspective to process the input workload, referred to as total time. Timing information can be used, for example, to calculate cost information using cost lookup tables or machine learning models. Performance metrics may include the cost to complete processing of the input workload. Performance metrics may include idle system costs, representing the cost of provisioning a provider-specific architecture while idle. Performance metrics may include workload costs, representing the cost of running a specific workload against a provider-specific architecture. Other performance metrics may include, for example, throughput, mean latency, and / or total read data units.

[0042] One or more embodiments can obtain the time and cost of each event in each component of the architecture, thereby enabling the user to be presented with more diverse and granular performance metrics beyond mere total time or total cost estimates.

[0043] One or more embodiments may present the performance metrics 302 via interface 102, for example, as a table, chart, or other graphical representation of the performance metrics for simulation. When multiple simulations are run for multiple provider-specific architectures, for example, presenting the performance metrics may include comparative indications, such as highlighting the provider-specific architecture with the lowest cost or the provider-specific architecture with the fastest total time. Alternatively, or in addition, the architecture simulator 114 may present a display indicating which provider-specific architecture is recommended based on the performance metrics.

[0044] Some cloud architectures are static, meaning that once provisioned and deployed, the number and types of service components do not change. Other cloud architectures are dynamic, meaning that the number of resources can be scaled up or down based on factors such as the number of requests, the amount of data processed, and / or available network or compute resources. Therefore, provider-specific service components may include parameters in their associated simulation models that enable the architecture simulator 114 to simulate processing for various dynamic configurations of the architecture.

[0045] 5. Architecture Optimizer Figure 4 shows an exemplary data flow diagram for the architecture optimizer 116 according to one or more embodiments. One or more operations shown in Figure 4 may be modified, rearranged, or omitted entirely. Therefore, a particular sequence of operations shown in Figure 4 should not be construed as limiting the scope of one or more embodiments.

[0046] Some user-selectable components 126 and some provider-specific components 124 may include variants that provide the same functionality but are associated with attributes that affect the delivery of different costs, timings, or other performance. For example, some provider-independent service descriptions 121 may include multiple design choices, such as different compute shapes, for a service component. A set of options for a service component with design choices can be specified within a provider-specific architecture mapping 122 for the service component.

[0047] Some provider-specific service components 124 may include parameter options. For example, in the case of the APACHE SPARK® batch processing component, the number of executors can be selected. The set of options for parameter choices can be specified in the simulation model 128 for the service component.

[0048] The architecture optimizer 116 can determine the "optimal" architecture for the optimization objective 402 by varying the design and / or parameter choices of one or more components of the provider-specific architecture 204. The optimization objective 402 can specify conditions regarding simulation performance metrics that should be met or approached, such as cost minimization, total time minimization, or throughput maximization. The term "optimal" can refer to the architecture that satisfies the optimization objective 402 or comes closest to satisfying the optimization objective 402 compared to other variants of the architecture.

[0049] Therefore, the architecture optimizer 116 can receive provider-specific architectures 204 and optimization targets 402, and can generate a first variant 204-1 and a second variant 204-2 by modifying one or more aspects of the provider-specific architecture 204. For example, the architecture optimizer 116 can associate a first parameter choice for the system selection service component 124 with the first variant 204-1, and a second parameter choice for the system selection service component 124 with the second variant 204-2. Alternatively, the architecture optimizer 116 can associate a first design choice for the system selection service component 124 with the first variant 204-1, and a second design choice for the system selection service component 124 with the second variant 204-2.

[0050] The variants can be simulated by the architecture simulator 114 as described above to generate a first performance measure 404-1 associated with the simulation of the first variant 204-1 and a second performance measure 404-2 associated with the simulation of the second variant 204-2.

[0051] The architecture optimizer 116 can evaluate the first and second performance measurements and recommend variants corresponding to the performance measurements that satisfy the optimization objective 402.

[0052] Although two variants are shown, the architecture optimizer 116 can generate two or more variants. The architecture optimizer 116 can change two or more components at once, and / or change two or more aspects of a component at once, for example, by changing both design choices and parameter choices.

[0053] In some cases, the "optimal" architecture may not be practical for the user in other aspects. For example, the cheapest architecture may not run fast enough, or the architecture that processes data fastest may require excessive resources or be excessively expensive for the user. In these cases, one or more constraints can be used by the architecture optimizer 116 to generate an architecture that is more practical for the user's needs. For example, the architecture optimizer 116 may include constraints to minimize the total time it takes to process a workload so that the workload cost is less than a specified amount.

[0054] 6. Actions for generating provider-specific architectures Figures 5A and 5B illustrate an exemplary set of operations for generating a provider-specific architecture in one or more embodiments. One or more operations shown in Figure 5 may be modified, rearranged, or omitted entirely. Therefore, a particular sequence of operations shown in Figure 5 should not be construed as limiting the scope of one or more embodiments.

[0055] One or more embodiments receive a provider-independent architecture definition (operation 502). The architecture generator 112 can receive a provider-independent architecture definition from a user. The architecture generator 112 receives the definition, for example, via an interface. The user can select components via the interface, for example, from a menu, file system, or library data structure. The user can connect components via the interface, for example, using a drawing operation to connect two components with a line. The user can connect components, for example, by specifying an input source and output destination for each component. The user can upload or otherwise select an existing partial or complete provider-independent architecture from a data repository.

[0056] One or more embodiments receive a selection of one or more specific cloud service providers (operation 504). The architecture generator 112 can receive from the user a selection of each cloud service provider from which the user wishes to generate a provider-specific architecture. For example, the architecture generator 112 can present the user with a list of all available cloud service providers via an interface and receive the user's selection from the list. The architecture generator 112 can determine a candidate set of cloud service providers based on a provider-independent architecture definition. For example, the architecture generator 112 can identify cloud service providers that provide compute components that map to component descriptions in a provider-independent architecture definition. The architecture generator 112 can present the candidates to the user via an interface. The architecture generator 112 can then receive the user's selection via an interface.

[0057] One or more embodiments map a provider-independent architecture definition component description to a provider-specific service component for a particular cloud service provider in a received selection (operation 506). For example, if a provider-independent architecture is represented as a directed property graph of vertices corresponding to component descriptions and edges corresponding to connections, the architecture generator 112 may select a first vertex in the directed property graph. The architecture generator 112 may select another vertex in a subsequent pass of the set of operations.

[0058] The architecture generator 112 can determine whether a component description corresponds strictly to a single provider-specific component. For example, the architecture generator 112 can use a lookup table that can include multiple entries for provider-independent component descriptions, where each entry is coupled to a provider-specific service component. The architecture generator 112 can also use a decision tree that can include a logical flow of choices and results, where the choices can be provider-independent architecture components and the results can be provider-specific service components. The choices can also include parameters such as size, number of processing resources, programming language, or data format.

[0059] A provider-independent architecture definition can be mapped to 0, 1, or 2 or more provider-specific service components. When a provider-independent architecture definition maps to exactly one provider-specific service component, the architecture generator 112 can select exactly one provider-specific service component. For example, the architecture generator 112 can store provider-specific service components in a provider-specific architecture. The architecture generator 112 can take over any connections associated with the selected provider-specific component in the provider-independent architecture definition.

[0060] In another example, the architecture generator 112 can store metadata associated with selected provider-specific service components in a data structure representing the provider-specific architecture. Once all provider-independent architecture definitions are mapped, the architecture generator 112 can generate the provider-specific architecture from the stored metadata and connections.

[0061] When a provider-independent architecture definition is mapped to two or more possible provider-specific service components, the architecture generator 112 can select one provider-specific component based on additional properties when the component description corresponds to two or more provider-specific components. The provider-specific architecture mapping for the selected cloud service provider may include logic to select from multiple service components based on one or more additional parameters. The architecture generator 112 can select one of the possible service components based on the dependency between another provider-specific service component and the currently mapped provider-specific service component. For example, one provider-specific service component may output data in a format that can be input to one of the provider-specific service components but cannot be input to another.

[0062] The architecture generator 112 can select one of the possible service components based on real-time data associated with the data traffic within the provider-specific architecture. For example, one possible service component may be able to process data faster than another and may be better suited to the expected data flow within the architecture.

[0063] The architecture generator 112 can select one of several service components based on the one with the highest degree of functional match between the selected provider-specific service component and the functionality specified in the description. The architecture generator 112 can also select one of several services based on the properties and / or behavior of the user-selected component associated with the service description. For example, if the user-selected component is the underlying database in the first format, the first database service component for a managed relational database system can be selected, whereas for a database product in the second format, a second different database service component can be selected for the same cloud service provider.

[0064] One or more embodiments may select multiple provider-specific service components to map to a single provider-independent architecture definition in order to achieve the functionality specified by the provider-independent architecture definition. For example, if additional processing power is required, multiple virtual machine service components may be selected.

[0065] In some cases, if it is not possible to select a provider-specific service component, the architecture generator 112 may present an error to the user (not shown). The architecture generator 112 may further suggest that additional properties may need to be added to the mapping, or that the provider-independent service description may be overly broad and may need to be subdivided. In addition, or alternatively, the user may be prompted to manually select from multiple provider-specific service components.

[0066] When a provider-independent architecture definition does not map to any provider-specific service component, the architecture generator 112 may select an alternative provider-specific component provided by the user. The architecture generator 112 may prompt the user to create and / or register a new provider-independent service description as a placeholder for a provider-specific service component that does not exist. In some cases, the architecture generator 112 may suggest a provider-specific service component that provides similar functionality, if one exists. If no suitable functional equivalent exists for a provider-specific service component, the architecture generator 112 may generate an error. One or more embodiments can constitute a provider-specific service component (operation 508). The architecture generator 112 may configure a provider-specific service component to perform a specific operation related to a user-selected component associated with the provider-specific service component. The architecture generator 112 may configure a provider-specific service component to send a specific dataset and / or operation results to another provider-specific service component. The architecture generator 112 may configure a provider-specific service component to process data received from another component. For example, applying a metadata classifier to an input data item, and then storing the classifier in a data store.

[0067] One or more embodiments can configure a connection for data flow (operation 510). The architecture generator 112 can, for example, examine metadata for user-selected or system-selected components to determine the input and output data types of two connected components. The architecture generator 112 can configure data flow between two connected components in an architecture based on data flow information associated with the connection between the two components. The architecture generator 112 can configure data flow between two connected components based on interface elements associated with the receiving component. The architecture generator 112 can configure data flow between two connected components based on a previously configured provider-specific architecture using the same system-selected components and similar user-selected components.

[0068] One or more embodiments determine whether the configuration of components and data flows for a provider-specific architecture has been completed based on a user-selected provider-independent architecture definition (operation 512). The architecture generator 112 can check that each provider-independent service description has been mapped to a provider-specific service component. The architecture generator 112 can examine the provider-specific architecture to determine whether each component is used in at least one of the data flows. The architecture generator 112 can examine the provider-specific architecture to determine whether the output of each component is used in at least one of the data flows.

[0069] When configuration for the provider-specific architecture is complete, the architecture generator 112 terminates the process (operation 514). If it is not already stored, the architecture generator 112 can store the provider-specific architecture, for example, in the data repository.

[0070] If configuration for a provider-specific architecture is not complete, the architecture generator 112 may return to operation 508 to configure any remaining components and proceed to operation 510 to configure any remaining connections.

[0071] 7. Operation to simulate provider-specific architecture Figure 6 shows an exemplary set of actions for simulating a provider-specific architecture in one or more embodiments. One or more actions shown in Figure 6 may be modified, rearranged, or omitted entirely. Therefore, a particular sequence of actions shown in Figure 6 should not be construed as limiting the scope of one or more embodiments.

[0072] One or more embodiments select a provider-specific architecture for simulation (operation 602). The architecture simulator 114 can receive one or more sets of provider-specific architectures directly from the architecture generator 112 or via user selection through an interface.

[0073] One or more embodiments receive a set of actions representing an input workload for simulation (action 604). The architecture simulator 114 can prompt the user to select a set of actions from the data repository that represents the type of data on which the provider-specific architecture operates. The architecture simulator 114 can suggest one or more sets of actions to the user to select based on sets of actions previously used for similar architecture components.

[0074] One or more embodiments simulate a set of operations in a provider-specific architecture to determine performance metrics (operation 606). For a given provider-specific architecture, the architecture simulator 114 can retrieve provider-specific service component simulation models associated with each system-selected service component in the provider-specific architecture. The architecture simulator 114 can, for example, construct a directed property graph data structure containing each of the simulation models and connections defined in the architecture.

[0075] For example, the architecture simulator 114 can simulate event generation, event acceptance by service components at that vertex, event queuing, event processing, and event termination at each vertex of a directed property graph data structure. At the start of the simulation, the architecture simulator 114 can start a priority data queue structure and associate the simulation clock time with the head of the priority queue. The simulation can begin by generating arrival events from the input workload to the queue. The earliest event can be dequeued and passed to the first simulation model in the directed property graph. When each simulation model receives an event, it can generate subsequent events if the simulation model includes the necessary steps for them. For example, if an event represents a database query, the simulation model for the database management service component can generate an event representing the result of the query and pass this to the next node in the directed property graph data structure. The architecture simulator 114 can use the simulation models to track processing metrics, including timing data such as event arrival time, event processing start time, and processing completion time. The architecture simulator 114 can also track communication metrics associated with data communication between service components specific to each provider. The architecture simulator 114 can continue simulating the processing of the input workload until all events in the input workload 130 have been processed, or until another simulation limit is reached.

[0076] Next, the architecture simulator 114 can pass data from the set of actions to the simulation models as input events. The architecture simulator 114 can track when the input events are passed to each simulation model until the entire set of actions has been processed or until another simulation limit has been reached.

[0077] One or more embodiments present performance metrics (operation 608). The architecture simulator 114 may present one or more performance metrics, including tracked timing information, aggregated tracked timing information, results of calculations using the timing information, or any other information regarding the execution of a provider-specific architecture simulation model in a set of operations.

[0078] One or more embodiments may allow a user to select one or more provider-specific architectures for further operations such as optimization or deployment to a cloud service provider. The architecture simulator 114 may recommend one of the provider-specific architectures, for example, based on performance metrics.

[0079] 8. Actions to optimize provider-specific architectures Figure 7 shows an exemplary set of actions for optimizing a provider-specific architecture in one or more embodiments. One or more actions shown in Figure 7 may be modified, rearranged, or omitted entirely. Therefore, a particular sequence of actions shown in Figure 7 should not be construed as limiting the scope of one or more embodiments.

[0080] One or more embodiments receive a provider-specific architecture (operation 702). The architecture optimizer 116 may receive a provider-specific architecture from the architecture generator 112, from the architecture simulator 114, or via user selection, for example, from a set of stored provider-specific architectures on a data repository.

[0081] One or more embodiments select provider-specific service components to modify within the provider-specific architecture (operation 704). In some cases, only one component within the provider-specific architecture may have variants. In other cases, the architecture optimizer 116 may prompt the user to select from a number of provider-specific service components to be modified via an interface, and the user may specify which components they wish to modify for optimization.

[0082] One or more embodiments optimize a provider-specific architecture for a target by varying provider-specific service components (operation 706). When a variant for a selected provider-specific service component includes design choices, the architecture optimizer 116 can generate distinct variants of the selected provider-specific service component for each option provided in the provider-specific architecture mapping for that component, or for a subset of the options. When a variant for a selected provider-specific service component includes parameter choices, the architecture optimizer 116 can generate distinct variants of the selected provider-specific service component for each option specified in the simulation model for that provider-specific service component, or for a subset of the options.

[0083] The architecture optimizer 116 can provide the architecture simulator 114 with provider-specific architectures having variants for simulation. The architecture optimizer 116 can evaluate performance metrics from each simulation for the optimization goal. In one or more embodiments, the architecture optimizer 116 can use the architecture simulator 114 in a Bayesian optimization process. The optimization process can be unconstrained optimization or constrained optimization. In unconstrained Bayesian optimization, the architecture optimizer 116 can vary design choices for provider-specific service components in a first pass. In a second pass, the architecture optimizer 116 can vary the version of the architecture that has the optimal design choice for the set of parameters in the simulation model. The architecture optimizer 116 can select a version of the provider-specific architecture that satisfies the optimization object as the optimized architecture.

[0084] One or more embodiments present an optimized provider-specific architecture (operation 708). The architecture optimizer 116 can update the provider-specific architecture with a variant that has generated an optimized version, and can present the updated architecture to the user for selection and for deployment to cloud service providers.

[0085] 9. Exemplary Embodiments Detailed examples are provided below for clarity. The components and / or operations described below should be understood as one specific example that may not be applicable to certain embodiments. Accordingly, the components and / or operations described below should not be construed as limiting the scope of any of the patent claims.

[0086] Figure 8 shows a graphical representation of a provider-independent architecture definition 802. The provider-independent architecture definition 802 described describes a service that receives batch data processing jobs that apply a machine learning classifier to each input data row and store the corresponding classification output in storage.

[0087] Architecture definition 802 includes user-selection components 826-1, 826-2, 826-3, 826-4, and 826-5. Architecture definition 802 includes provider-independent service descriptions 821-1, 821-2, 821-3, 821-4, and 821-5. Architecture definition 802 includes connections 803-1, 803-2, 803-3, and 803-4.

[0088] User-selected component 826-1 represents a REST service virtual machine provided by the user that receives requests to start batch data processing jobs. User-selected component 826-1 is associated with provider-independent service description 821-1, which is a multi-tenant virtual machine with a small compute shape as a design choice.

[0089] User-selected component 826-2 represents an APACHE SPARK machine learning job that receives APACHE SPARK jobs submitted by user-selected component 826-1 via connection 803-1. User-selected component 826-2 is associated with provider-independent service description 821-2, which is a batch data processing service with an existing cluster.

[0090] User-selected component 826-3 represents a database from which user-selected component 826-1 caches job metadata via connection 803-3. Job metadata may include information that allows, for example, an adjacent system to query the architecture for the status of a batch processing job. User-selected component 826-3 is associated with provider-independent service description 821-3, which is a managed relational database (DB) system using Oracle's small database class as a design choice.

[0091] The user selection component 826-4 represents data for input keys and values. The user selection component 826-2 requests and receives input values ​​from the user selection component 826-4 via connection 803-4. The user selection component 826-4 is associated with the key-value object storage 821-4, which is a data storage component.

[0092] User-selected component 826-5 represents output data from a machine learning classifier applied to user-selected component 826-2, for example, input data. User-selected component 826-2 writes output values ​​to user-selected component 826-5 via connection 803-2. User-selected component 826-5 is associated with key-value object storage 821-5, which is a data storage component.

[0093] In one or more embodiments, a provider-independent architecture definition can be stored, for example, in a data repository, as a template for subsequent architecture design. The user can then select a stored architecture definition, replace user-selected components with others, modify one or more parameters or design choices, and proceed to generate one or more provider-specific architectures.

[0094] Figure 9 shows a first example of a provider-specific architecture 902 that can be generated from a provider-independent architecture definition 802. In the example shown, architecture 902 is generated for the cloud service provider AMAZON WEB SERVICES (AWS). User-selected components 826 and connections 803 may remain the same from the provider-independent architecture to the provider-specific architecture, but the provider-independent service descriptions 821-1, 821-2, 821-3, 821-4, and 821-5 are replaced by system-selected components 921-1, 921-2, 921-3, 921-4, and 921-5, respectively.

[0095] As shown, a multi-tenant virtual machine with a small compute shape (821-1) is mapped to AWS's AMAZON Elastic Cloud Compute® (921-1) with the corresponding compute shape m6in.large®. A batch data processing service with an existing cluster (821-2) is mapped to the AMAZON Elastic MapReduce component (921-2). A managed relational database (DB) system using the ORACLE small database class (821-3) is mapped to the AMAZON Relational DB Service component (921-3) which uses ORACLE db.m4.large as the small database class. Key-value object storage 821-4 and 821-5 are mapped to AMAZON Simple Storage Service® components 921-4 and 921-5, respectively.

[0096] Figure 10 shows a second example of a provider-specific architecture 1002 that can be generated from a provider-independent architecture definition 802. In the example shown, architecture 1002 is generated for the cloud service provider ORACLE CLOUD INFRASTRUCTURE® (OCI). User-selected components 826 and connections 803 may remain the same from the provider-independent architecture to the provider-specific architecture, but the provider-independent service descriptions 821-1, 821-2, 821-3, 821-4, and 821-5 are replaced by system-selected components 1021-1, 1021-1, 1021-3, 1021-4, and 1021-5, respectively.

[0097] As shown, a multi-tenant virtual machine with a small compute shape (821-1) is mapped to an OCI Virtual Machine Instance (1021-1) with the corresponding compute shape VM.Optimized3.Flex. A batch data processing service with an existing cluster (821-2) is mapped to an OCI Data Flow component (1021-2) that does not have a cluster specification. A managed relational database (DB) system using the ORACLE small database class (821-3) is mapped to an ORACLE Base DB Service component (1021-3) that uses ORACLE VM.Standard2.1 as the small database class. Key-value object storage 821-4 and 821-5 are mapped to ORACLE Object Storage components 1021-4 and 1021-5, respectively.

[0098] 10. Computer networks and cloud networks In one or more embodiments, a computer network provides connectivity between sets of nodes. These nodes may be local and / or remote to one another. The nodes are connected by a set of links. Examples of links include coaxial cables, unsheathed twisted cables, copper cables, optical fibers, and virtual links.

[0099] A subset of nodes implements computer networks. Examples of such nodes include switches, routers, firewalls, and network address translators (NATs). Another subset of nodes utilizes computer networks. Such nodes (also called "hosts") can run client processes and / or server processes. Client processes make requests for computing services (such as running a specific application and / or storing a specific amount of data). Server processes respond by performing the requested services and / or returning the corresponding data.

[0100] A computer network may be a physical network that includes physical nodes connected by physical links. A physical node is any digital device. A physical node may also be a function-specific hardware device such as a hardware switch, hardware router, hardware firewall, and hardware NAT. In addition or alternatively, a physical node may be a general-purpose machine configured to run various virtual machines and / or applications that perform their respective functions. A physical link is a physical medium that connects two or more physical nodes. Examples of links include coaxial cables, uninsulated twisted cables, copper cables, and optical fibers.

[0101] A computer network may be an overlay network. An overlay network is a logical network implemented on top of another network (such as a physical network). Each node in the overlay network corresponds to each node in the underlying network. Therefore, each node in the overlay network is associated with both an overlay address (for addressing the overlay node) and an underlay address (for addressing the underlay node that implements the overlay node). Overlay nodes may be digital devices and / or software processes (such as virtual machines, application instances, or threads). Links connecting overlay nodes are implemented as tunnels through the underlying network. The overlay nodes at both ends of the tunnel treat the underlying multi-hop path between these overlay nodes as a single logical link. Tunneling is performed through encapsulation and deencapsulation.

[0102] In the embodiment, the client may be local and / or remote to the computer network. The client may access the computer network via a private network or another computer network such as the Internet. The client may communicate requests to the computer network using a communication protocol such as the Hypertext Transfer Protocol (HTTP). Requests are communicated through an interface such as a client interface (such as a web browser), a program interface, or an application programming interface (API).

[0103] In embodiments, a computer network provides connectivity between clients and network resources. Network resources include hardware and / or software configured to run server processes. Examples of network resources include processors, data storage, virtual machines, containers, and / or software applications. Network resources are shared among multiple clients. Clients independently request computing services from the computer network. Network resources are dynamically allocated to requests and / or clients on an on-demand basis. Network resources allocated to each request and / or client may be scaled up or down based, for example, (a) computing services requested by a particular client, (b) aggregated computing services requested by a particular tenant, and / or (c) aggregated computing services requested to the computer network. Such a computer network may also be referred to as a “cloud network”.

[0104] In an embodiment, a service provider provides a cloud network to one or more end users. The cloud network can implement various service models, including, but not limited to, Software as a Service (SaaS), Platform as a Service (PaaS), and Infrastructure as a Service (IaaS). In SaaS, the service provider provides end users with the ability to use the service provider's applications running on network resources. In PaaS, the service provider provides end users with the ability to deploy custom applications on network resources. Custom applications can be created using programming languages, libraries, services, and tools supported by the service provider. In IaaS, the service provider provides end users with the ability to provision processing, storage, networking, and other basic computing resources provided by the network resources. Any application, including an operating system, can be deployed on the network resources.

[0105] In embodiments, but not limited to, various deployment models can be implemented by the computer network, including private clouds, public clouds, and hybrid clouds. In a private cloud, network resources are provisioned for exclusive use by a specific group of one or more entities (wherein used herein, the term “entity” refers to a company, organization, person, or other entity). Network resources may be local and / or remote to the premises of a particular group of entities. In a public cloud, cloud resources are provisioned for multiple entities that are independent of each other (also referred to as “tenants” or “customers”). The computer network and its network resources are accessed by clients corresponding to different tenants. Such a computer network may be referred to as a “multitenant computer network”. Several tenants may use the same particular network resources at different times and / or at the same time. Network resources may be local and / or remote to the tenant’s premises. In a hybrid cloud, the computer network comprises a private cloud and a public cloud. Interfaces between the private cloud and the public cloud enable data and application portability. Data stored in the private cloud and data stored in the public cloud may be exchanged through these interfaces. Applications running on a private cloud and applications running on a public cloud may have dependencies on each other. Calls from an application in the private cloud to an application in the public cloud (and vice versa) may be made through an interface.

[0106] In embodiments, tenants in a multi-tenant computer network are independent of each other. For example, the business or operations of one tenant may be separate from the business or operations of another tenant. Different tenants may have different network requirements for the computer network. Examples of network requirements include processing speed, data storage capacity, security requirements, performance requirements, throughput requirements, latency requirements, resilience requirements, quality of service (QoS) requirements, tenant isolation, and / or consistency. The same computer network may need to implement the different network requirements demanded by different tenants.

[0107] In one or more embodiments, tenant isolation is implemented in a multi-tenant computer network to ensure that applications and / or data of different tenants are not shared with one another. Various tenant isolation approaches may be used.

[0108] In this embodiment, each tenant is associated with a tenant ID. Each network resource in a multi-tenant computer network is tagged with the tenant ID. A tenant is only permitted to access a particular network resource if the tenant and the specific network resource are associated with the same tenant ID.

[0109] In this embodiment, each tenant is associated with a tenant ID. Each application implemented by the computer network is tagged with the tenant ID. In addition, or alternatively, each data structure and / or dataset stored by the computer network is tagged with the tenant ID. A tenant is granted access to a particular application, data structure, and / or dataset only if the tenant and the particular application, data structure, and / or dataset are associated with the same tenant ID.

[0110] As an example, each database implemented by a multi-tenant computer network may be tagged with a tenant ID. Only tenants associated with the corresponding tenant ID may access the data in a particular database. As another example, each entry in a database implemented by a multi-tenant computer network may be tagged with a tenant ID. Only tenants associated with the corresponding tenant ID may access the data in a particular entry. However, the database may be shared by multiple tenants.

[0111] In this embodiment, the subscription list indicates which tenants have authentication to access which applications. For each application, a list of tenant IDs of tenants authenticated to access the application is stored. A tenant is permitted to access a particular application only if their tenant ID is included in the subscription list corresponding to that application.

[0112] In this embodiment, network resources (such as digital devices, virtual machines, application instances, and threads) corresponding to different tenants are isolated in tenant-specific overlay networks maintained by a multi-tenant computer network. For example, packets from any source device in a tenant overlay network can only be sent to other devices within the same tenant overlay network. Encapsulation tunnels are used to prevent transmission from any source device on one tenant overlay network to devices in other tenant overlay networks. Specifically, packets received from a source device are encapsulated within an external packet. The external packet is sent from a first encapsulation tunnel endpoint (communicating with the source device in the tenant overlay network) to a second encapsulation tunnel endpoint (communicating with the destination device in the tenant overlay network). The second encapsulation tunnel endpoint decapsulates the external packet to retrieve the original packet sent by the source device. The original packet is then sent from the second encapsulation tunnel endpoint to the destination device in the same specific overlay network.

[0113] 11. Hardware Overview According to one embodiment, the technologies described herein are implemented by one or more dedicated computing devices. These dedicated computing devices may be wired together to perform these technologies, or may include one or more digital electronic devices such as application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or network processing units (NPUs) that are permanently programmed to perform these technologies, or may include one or more general-purpose hardware processors programmed to perform these technologies in accordance with program instructions in firmware, memory, other storage, or a combination thereof. Such dedicated computing devices may also combine custom hardwired logic, ASICs, FPGAs, or NPUs with custom programming to perform these technologies. Dedicated computing devices may be desktop computer systems, portable computer systems, handheld devices, networking devices, or any other devices that incorporate hardwired logic and / or programmable logic to implement these technologies.

[0114] For example, Figure 11 is a block diagram showing a computer system 1100 that can carry out an embodiment of the present invention. The computer system 1100 comprises a bus 1102 or other communication mechanism for communicating information and a hardware processor 1104 coupled to the bus 1102 for processing information. The hardware processor 1104 may be, for example, a general-purpose microprocessor.

[0115] The computer system 1100 also includes main memory 1106, such as random access memory (RAM) or other dynamic storage device, coupled to bus 1102 for storing information and instructions executed by processor 1104. Main memory 1106 may also be used to store temporary variables or other intermediate information during the execution of instructions by processor 1104. Once such instructions are stored in a non-temporary storage medium accessible to processor 1104, the computer system 1100 becomes a dedicated machine customized to perform the operations specified by the instructions.

[0116] The computer system 1100 further includes a read-only memory (ROM) 1108 or other static storage device coupled to the bus 1102 for storing static information and instructions for the processor 1104. A storage device 1110, such as a magnetic disk or optical disk, is provided and coupled to the bus 1102 for storing information and instructions.

[0117] The computer system 1100 can be coupled via a bus 1102 to a display 1112, such as a cathode ray tube (CRT), for displaying information to the computer user. An input device 1114, including alphanumeric keys and other keys, is coupled to the bus 1102 to communicate information and command selections to the processor 1104. Another type of user input device is a cursor control unit 1116, such as a mouse, trackball, or cursor directional keys, for communicating directional information and command selections to the processor 1104, and for controlling cursor movement on the display 1112. This input device typically has two degrees of freedom along two axes, a first axis (e.g., x) and a second axis (e.g., y), which allows the device to specify a position in a plane.

[0118] The computer system 1100 can implement the techniques described herein using customized hardwired logic, one or more ASICs or FPGAs, firmware, and / or program logic that, when combined with the computer system, make the computer system 1100 a dedicated machine or program it to be a dedicated machine. According to one embodiment, the techniques described herein are executed by the computer system 1100 in response to the processor 1104 executing one or more sequences of one or more instructions contained in the main memory 1106. Such instructions may be read into the main memory 1106 from another storage medium, such as a storage device 1110. The execution of the sequence of instructions contained in the main memory 1106 causes the processor 1104 to perform the process steps described herein. In alternative embodiments, hardwired circuits may be used instead of or in combination with software instructions.

[0119] The term “storage medium” as used herein refers to any non-temporary medium that stores data and / or instructions that cause a machine to operate in a particular manner. Such storage mediums may include non-volatile and / or volatile media. Non-volatile media include, for example, optical or magnetic disks such as storage device 1110. Volatile media include dynamic memory such as main memory 1106. Common forms of storage mediums include, for example, floppy disks, flexible disks, hard disks, solid-state drives, magnetic tapes, or any other magnetic data storage media, CD-ROMs, any other optical data storage media, any physical media having a perforated pattern, RAM, PROMs, EPROMs, FLASH-EPROMs, NVRAMs, any other memory chips or cartridges, associative memory (CAM), and tertiary associative memory (TCAM).

[0120] A storage medium is different from a transmission medium, but may be used together with a transmission medium. The transmission medium is involved in the transfer of information between storage mediums. For example, the transmission medium includes coaxial cables, copper wires, and optical fibers, which include wires with a bus 1102. The transmission medium may also take the form of sound waves or light waves, such as those generated during radio communication and infrared data communication.

[0121] Various forms of media may be involved in transporting one or more sequences of one or more instructions to the processor 1104 for execution. For example, the instructions may initially be transported on a magnetic disk or solid-state drive of a remote computer. The remote computer may load the instructions into its dynamic memory and transmit them over a telephone line using a modem. A modem local to computer system 1100 may receive the data over the telephone line and convert the data into an infrared signal using an infrared transmitter. An infrared detector may receive the data transported by the infrared signal, and appropriate circuitry may place the data on bus 1102. Bus 1102 transports the data to main memory 1106, from which the processor 1104 retrieves and executes the instructions. The instructions received by main memory 1106 may optionally be stored on storage device 1110 before or after execution by processor 1104.

[0122] The computer system 1100 also includes a communication interface 1118 coupled to bus 1102. The communication interface 1118 provides bidirectional data communication coupling to a network link 1120 connected to a local network 1122. For example, the communication interface 1118 may be an Integrated Services Digital Network (ISDN) card, a cable modem, a satellite modem, or a modem for providing data communication connectivity to a corresponding type of telephone line. As another example, the communication interface 1118 may be a local area network (LAN) card for providing data communication connectivity to a compatible LAN. A wireless link may also be implemented. In any such embodiment, the communication interface 1118 transmits and receives electrical, electromagnetic, or optical signals carrying digital data streams representing various types of information.

[0123] A network link 1120 typically provides data communication to other data devices through one or more networks. For example, a network link 1120 can provide connectivity to a host computer 1124 or to data equipment operated by an Internet service provider (ISP) 1126 via a local network 1122. The ISP 1126 then provides data communication services through a global packet data communication network now commonly referred to as the “Internet” 1128. Both the local network 1122 and the Internet 1128 use electrical, electromagnetic, or optical signals to carry digital data streams. Signals traversing various networks, and signals on the network link 1120 through the communication interface 1118, carry digital data to and from the computer system 1100 and are exemplary forms of transmission media.

[0124] The computer system 1100 can send messages and receive data, including program code, through the network, network link 1120, and communication interface 1118. In the case of the internet, server 1130 may send requested code for an application program through the internet 1128, ISP 1126, local network 1122, and communication interface 1118.

[0125] The received code may be executed by the processor 1104 at the time of receipt, and / or stored in the memory device 1110 or other non-volatile memory device for later execution.

[0126] 12. Miscellaneous rules, extensions The embodiments relate to a system comprising one or more devices, each including a hardware processor and configured to perform any of the operations described herein and / or any of the operations enumerated in any of the appended claims.

[0127] In the embodiment, the non-temporary computer-readable storage medium includes instructions that, when executed by one or more hardware processors, cause to perform any of the operations described herein and / or any of the operations enumerated in any of the claims.

[0128] Any combination of features and functions described herein may be used according to one or more embodiments. Throughout the foregoing specification, embodiments have been described with reference to many specific details that may differ from embodiment to embodiment. Therefore, the specification and drawings should be considered illustrative rather than restrictive. The sole and exclusive indication of the scope of the present invention, and what the applicants intend to be the scope of the present invention, is the literal and equivalent scope of any set of claims derived from this application, in any specific form derived from such claims, including any subsequent modifications.

Claims

1. A non-temporary computer-readable medium containing instructions, wherein, when executed by one or more hardware processors, the instructions cause an operation to be performed, and the operation is: This includes receiving a provider-independent architecture definition for a cloud-based system, wherein the provider-independent architecture definition is: A set of 1-territory user-selectable components, A set of one or more descriptions of service components that will be selected based on provider-specific services for a cloud-based system, A set of one or more user-selectable components and a set of one or more connections representing one or more data flows between the service components, Define, The aforementioned operation is, A first provider-specific architecture corresponding to the first cloud provider, at least, Integrating the set of user-selectable components into the first provider-specific architecture, The process involves mapping the set of one or more descriptions to a first set of provider-specific services corresponding to the first cloud provider, thereby obtaining a first set of system selection service components corresponding to the first cloud provider. Configuring one or more data flows based on the one or more connections, This includes generating based on the provider-independent architecture, The aforementioned operation is, This includes simulating a first set of operations for the first provider-specific architecture and calculating a first performance metric for the first provider-specific architecture, The aforementioned operation is, A second provider-specific architecture to support the second cloud provider, at least, Integrating the set of user-selectable components into the second provider-specific architecture, Mapping the set of one or more descriptions to a second set of provider-specific services corresponding to the second cloud provider to obtain a second set of system selection components corresponding to the second cloud provider, Configuring one or more data flows based on the one or more connections, This includes generating based on the provider-independent architecture, The aforementioned operation is, To simulate a second set of operations for the second provider-specific architecture and to calculate a second performance metric for the second provider-specific architecture, To present information based on the first performance metric for the first provider-specific architecture and the second performance metric for the second provider-specific architecture, A medium that includes

2. Mapping is The first description is mapped to a set of one or more descriptions to a plurality of provider-specific service components, This includes selecting one of the aforementioned provider-specific service components, wherein the selection is A dependency between another provider-specific service component in the provider-specific architecture and one of the selected provider-specific service components, Real-time data associated with data traffic within the provider-specific architecture, The actions performed by user-selected components, The one selected from among the multiple provider-specific service components that has the highest degree of functional agreement with the function specified in the description, Based on at least one of the following: The medium according to claim 1.

3. Configuring the aforementioned one or more data flows is The first data flow between the first user-selected component and the first system-selected component is Data flow information associated with the connection between the first user selection component and the first system selection component, Interface elements associated with the first user selection component and the first system selection component, Identifying the data type output by one of the first user-selected component and the first system-selected component, and the data type received as input by the other of the first user-selected component and the first system-selected component, A previously configured provider-specific architecture using the same first system selection component and similar first user selection components, The medium according to claim 1, comprising being composed of at least one of the following.

4. Each provider-specific service component includes its own simulation model, and simulating the set of operations is: Receiving input workloads and, Determining one or more processing metrics associated with the processing of the input workload by each of the provider-specific service components based on the respective simulation models, To determine one or more communication metrics associated with data communication between the respective provider-specific service components, To present at least one performance metric based on at least one of the one or more processing metrics and the one or more communication metrics, The medium according to claim 1, further comprising:

5. The aforementioned simulation model, A procedure for estimating the time required to execute an event using the provider-specific service components, The procedure for generating a new subsequent event from a received event, Procedures for estimating the cost of processing an event, Adjustable parameters that affect event costs, Adjustable parameters that affect completion time, The medium according to claim 4, comprising at least one of the following.

6. Further including analyzing the first performance metric and the second performance metric, The medium according to claim 1, wherein the information presented includes, based on the analysis, a recommendation for one of the first provider-specific architecture and the second provider-specific architecture.

7. Simulating the first set of operations means that for each operation in the set of operations, Event generation, Acceptance of the aforementioned event by the service component, Queuing for the aforementioned event, Processing of the aforementioned event, The conclusion of the aforementioned event, The medium according to claim 1, comprising simulating at least one of the following.

8. The medium further includes instructions, which, when executed by one or more hardware processors, cause an operation to be performed, and the operation is Receiving a selection of either the first provider-specific architecture or the second provider-specific architecture, In the selected provider-specific architecture, identify a provider-specific service component having at least two variants, To generate a first variant provider-specific architecture having a first variant of the identified provider-specific service component, This involves simulating a set of operations for the architecture specific to the first variant provider and calculating a first optimization metric, To generate a second variant provider-specific architecture having a second variant of the identified provider-specific service component, The second optimization metric is calculated by simulating the set of operations for the architecture specific to the second variant provider, Comparing the first optimization metric and the second optimization metric with the target, Based on which optimization metric satisfies the objective, select the first variant of the provider-specific service component or the second variant of the provider-specific service component for the selected provider-specific architecture, The medium according to claim 1, including the following:

9. The medium according to claim 8, wherein the first variant includes a first provider-specific service component that maps to a description from the set of one or more descriptions in the provider-independent architecture definition, and the second variant includes a second provider-specific service component that maps to the same description from the set of one or more descriptions in the provider-independent architecture definition.

10. The medium according to claim 8, wherein the first variant includes a first set of parameters applied to a provider-specific service component, and the second variant includes a second set of parameters applied to the provider-specific service component.

11. The medium according to claim 8, further comprising optimizing the selected provider-specific architecture with respect to one or more constraints on the first optimization metric and the second optimization metric.

12. A non-temporary computer-readable medium containing instructions, wherein, when executed by one or more hardware processors, the instructions cause an operation to be performed, and the operation is: This includes receiving a provider-independent architecture definition for a cloud-based system, wherein the provider-independent architecture is: A set of 1-territory user-selectable components, A set of one or more descriptions of service components that will be selected based on provider-specific services for a cloud-based system, A set of one or more connections representing one or more data flows between the set of one or more user selection components and the set of one or more descriptions of the service components, Define, The aforementioned operation is, A first provider-specific architecture corresponding to the first cloud provider, at least, Integrating the set of user-selectable components into the first provider-specific architecture, The process involves mapping one or more sets of descriptions to a first set of provider-specific services corresponding to the first cloud provider to obtain a first set of system selection service components corresponding to the first cloud provider, wherein each system selection service component includes its respective simulation model. Configuring one or more data flows based on the one or more connections, This includes generating based on the provider-independent architecture, The aforementioned operation is, For at least one objective, the first provider-specific architecture described above is at least, To simulate a set of operations for a first version of the first provider-specific architecture having a first variant of the system selection service component, and to generate a first optimization metric, To simulate the set of operations for a second version of the first provider-specific architecture having a second variant of the system selection service component, and to generate a second optimization metric, Selecting the version of the first provider-specific architecture having the optimization metric that satisfies the objective, Optimizing by, A medium that includes

13. Optimizing is In the first provider-specific architecture described above, the provider-specific service component having at least two variants is identified, To generate a first version of the provider-specific architecture having a first variant of the identified provider-specific service component, To generate a second version of the provider-specific architecture having a second variant of the identified provider-specific service component, The medium according to claim 12, further comprising:

14. Simulating the aforementioned set of operations is Receiving input workloads and, Determining a first set of one or more performance metrics associated with processing the input workload by the first version of the first provider-specific architecture based on the respective simulation models, To generate the first optimization metric based on the first set of one or more performance metrics, Determining a second set of one or more metrics associated with processing the input workload by the second version of the first provider-specific architecture based on the respective simulation models, To generate a second optimization metric based on a second set of one or more performance metrics, To recommend one of the first or second versions of the first provider-specific architecture having the optimization metrics that satisfy the objective, The medium according to claim 12, further comprising:

15. Generating a variant is Identifying the set of parameters in the simulation model of the system selection service component, As a variant of the system selection service component, one parameter value is selected from the set of parameters, The system selection service component is modified using the selected parameter value, The modified system selection service component is included in the first version of the provider-specific architecture, The medium according to claim 12, further comprising:

16. Each system selection service component has an associated provider-specific mapping, and generating variants is possible. Identifying a set of design options in the associated provider-specific mapping for the system selection service component, The first of the aforementioned design options is selected as the first variant of the system selection service component, The first design option is included in the first version of the provider-specific architecture, The second of the aforementioned design options is selected as the second variant of the system selection service component, The second design option is to be included in the second version of the provider-specific architecture, The medium according to claim 12, further comprising:

17. Optimizing is To simulate the set of operations for a third version of the first provider-specific architecture having a third variant of the system selection service component, and to generate a third optimization metric, To simulate the set of operations for a fourth version of the first provider-specific architecture having a fourth variant of the system selection service component, and to generate a fourth optimization metric, Selecting the version of the first provider-specific architecture having the optimization metric that satisfies the objective, The medium according to claim 12, further comprising:

18. The medium according to claim 17, wherein the first variant and the second variant correspond to a first design option and a second design option of the system selection service component, and the third variant and the fourth variant correspond to a first parameter selection and a second parameter selection of the system selection service component.

19. The medium further includes instructions, and when the instructions are executed by the one or more hardware processors, they cause an operation to be performed, and the operation is, A second provider-specific architecture to support the second cloud provider, at least, Integrating the aforementioned set of user-selectable components into a second provider-specific architecture, Mapping the set of one or more descriptions to a second set of provider-specific services corresponding to the second cloud provider to obtain a second set of system selection components corresponding to the second cloud provider, Configuring one or more data flows based on the one or more connections, This includes generating based on the provider-independent architecture, The aforementioned operation is, To simulate a second set of operations for the second provider-specific architecture and to calculate a second performance metric for the second provider-specific architecture, To present information based on the first performance metric for the first provider-specific architecture and the second performance metric for the second provider-specific architecture, The medium according to claim 12, including the following:

20. It is a system, A device comprising at least one hardware processor, The system is configured to perform the operation described in any one of claims 1 to 19.

21. A system comprising means for performing the operation described in any one of claims 1 to 19.

22. A method comprising the operation described in any one of claims 1 to 19.

Images