Techniques for large-scale functional testing in cloud-computing environments

Techniques are disclosed for generating an execution plan for performing functional tests in a cloud-computing environment. Infrastructure resources and capabilities (e.g., system requirements) may be defined within an infrastructure object (e.g., a resource of a declarative infrastructure provisioner) that stores a code segment that implements the resource or capability. Metadata may be maintained that indicates what particular capabilities are applicable to each infrastructure resource. Using the metadata, the system can generate an execution plan by combining code segments for each resource with code segments defining each capability in accordance with the metadata. The execution plan may include programmatic instructions that, when executed, generate a set of test results. The system can execute instructions that cause the set of test results to be presented at a user device.

BACKGROUND

Container orchestration tools provide a robust framework for managing and deploying containerized applications across a cluster of computing nodes in a computing environment. Examples of these tools include, for instance, Kubernetes, Open Shift, Docker Swarm, and the like. The usage of these tools has dramatically increased in the recent years with the rising popularity of cloud-based services and changes in the design of services/applications from large and monolithic systems to highly distributed and micro-service based systems.

Verifying functional requirements of various resources in such environments can be an arduous task. To ensure that these functional requirements are met, a number of tests may be employed. These tests are typically manually written by trained engineers. As the number of resources in a system increases, the task of verifying these requirements increases exponentially. Existing techniques include to manually generate functional tests are tedious, require specialized personnel, and do not scale to the size and complexity of these systems.

BRIEF SUMMARY

Techniques are provided (e.g., a method, a system, non-transitory computer-readable medium storing code or instructions executable by one or more processors) for adjusting the number of nodes of a computing cluster in response to actual and/or predicted changes in one or more performance metrics of the computing cluster. Various embodiments are described herein, including methods, systems, non-transitory computer-readable storage media storing programs, code, or instructions executable by one or more processors, and the like.

One embodiment is directed to a method for generating an execution plan for performing functional tests in a cloud-computing environment. The method may comprise maintaining a first set of code segments. In some embodiments, each code segment of the first set of code segments individually comprising programmatic instructions for generating a resource of a set of resources of a cloud-computing environment. The programmatic instructions may comprise a first set of functions calls of a limited set of function calls that are optimized for generating execution plans in the cloud-computing environment. The method may further comprise maintaining a second set of code segments. In some embodiments, each code segment of the second set of code segment may comprise respective programmatic instructions defining a capability of a set of capabilities of the cloud-computing environment. The respective programmatic instructions may comprise a second set of function calls of the limited set of function calls. The method may further comprise obtaining metadata indicating a corresponding set of capabilities that are applicable for each resource of the set of resources. The method may further comprise generating an execution plan based at least in part on combining the first set of code segments for generating the set of resources and the second set of code segments defining the set of capabilities. In some embodiments, the execution plan is generated in accordance with the metadata indicating the corresponding set of capabilities that are applicable for individual resources of the set of resources. The method may further comprise generating a set of test results based at least in part on executing the execution plan. In some embodiments, redundant programming instructions may be removed from the execution plan prior to executing the execution plan. The method may further comprise executing instructions that cause a result for each of the set of test results to be displayed at a user device.

In some embodiments, a subset of function calls of the limited set of function calls relate to at least one of: calling a first application programming interface of the cloud-computing environment, calling a second application programming interface of a declarative infrastructure provisioner, manipulating data associated with a respective resource or respective capability, executing Boolean logic with at least one resource or at least one capability, importing programmatic instructions associated with a particular resource, or importing programmatic instructions associated with a particular capability. In some embodiments, the result for each of the set of test results is presented in a graphical matrix.

In some embodiments, the declarative infrastructure provisioner is configured to define and provision infrastructure resources using a declarative configuration language.

In some embodiments, the execution plan comprises programmatic instructions for executing a test corresponding to each capability that is applicable to a given resource.

In some embodiments, at least one function call in the limited set of function calls comprises two or more overloaded functions, wherein a particular overloaded function is selected for execution based at least in part on a set of parameters used to call the at least one function call.

Another embodiment is directed to a computing device comprising one or more processors and one or more memories storing computer-executable instructions that, when executed by the one or more processors, cause and/or configure the computing device to perform the method described above.

Another embodiment is directed to a non-transitory computer-readable medium storing computer-executable instructions that, when executed by one or more processors of a computing device, cause the computing device to perform the method described above.

Various embodiments are described herein, including methods, systems, non-transitory computer-readable storage media storing programs, code, or instructions executable by one or more processors, and the like. These illustrative embodiments are mentioned not to limit or define the disclosure, but to provide examples to aid understanding thereof. Additional embodiments are discussed in the Detailed Description, and further description is provided there.

DETAILED DESCRIPTION

To ensure consistency across services in a cloud-computing environment, each resource may be required to pass a predefined set of requirements as a prerequisite to being released to the public. As used herein, an “infrastructure resource”, also referred to as a “resource” for brevity, may include any suitable infrastructure component of the cloud-computing environment including virtual networks, compute instances, domain name service records, containers, databases, object storage, load balancers, Application Programming Interface (API) gateways, and the like. These set of requirements can relate to services that handle authentication, accounts, compartments, limits, metering, monitoring, enhancements, and tagging, to name a few. Some of these services may include, but are not limited to:Identity—ensures users (e.g., tenants) can safely control access to all services in a consistent, predictable and usable manner via (a) individuals, (b) groups, (c) allow-based policies, and (d) federation.Accounts—centrally manage tenancy creation, quota suspension, fraud mitigation, and resource reclamation.Compartments—work across all resource types to allow users to map existing enterprise hierarchical mechanisms into a single cloud account for centralized billing, finance, usage, integration, and access management while still providing organizational flexibility (teams, projects, and initiatives).Limits—allows the cloud-provider to set default limits and overrides on resources for all users enabling fraud protection, cost control, capacity shortage/overage control, and governance at a realm, region, and accessibility domain levels.Metering—provides required data for various corporate billing systems resulting in invoices to users. It also provides metadata for investigation, research, analysis, and insight into usage and discovery of patterns therein.Monitoring—is an observable system across all services for metrics, alarms, events, health status, and analytics resulting in a shorter and better feedback loop for service improvement.Service Platform—fast-tracks rollout of a system-wide (e.g., cloud-wide) feature enhancements by eliminating the need for all services to make code changes in response to each enhancement and supports authentication, authorization, audit, events, and quota enforcement.Tagging—allows users define key-value metadata (e.g., to tag a resource with a label) for their own visibility into the cloud-provider's resource usage across all services, compartments and tenancies for cost control, budget tracking, departmental charge back, and resource structuring.

Traditionally, such tests would be manually defined by experienced engineers. This can be incredibly labor intensive. For example, given 100 resources, to test that each of the 100 resources has 150 corresponding capabilities, or in other words, passes 150 set of requirements, would require authoring 15,000 tests. The term “capability” and “requirement” may be used interchangeably. As the number of resources and/or number of requirements grow, so too does the number of tests needed to ensure that each resource meets each requirement prior to release.

In some embodiments, a system is provided that drastically reduces the amount of manual labor needed to produce such tests and enables the system to expand to add new tests easily when new resources and capabilities/requirements are introduced. The system may utilize a declarative infrastructure provisioner (DIP). This DIP is configured to define and provision infrastructure resources (e.g., data center resources) using a declarative configuration language. In some examples, the codes steps for creating a resource may be encapsulated in a resource block (e.g., a code segment that includes the operations for creating a resource). Similarly, the test logic associated with testing a capability may be encapsulated in a resource block (e.g., a code segment that includes the operations for testing the capability). Each code segment corresponding to a capability may include one or more placeholders corresponding to one or more resources with which the capability will be tested. The operations for creating a resource and the test operations may be defined using a domain specific language optimized to include a limited set of parameterized, reusable, statements (e.g., functions). By way of example, one statement/function for resource creation may be expressed as a statement where the resource type is a parameter. In this case, when a test needs to include operations for creating multiple resources (e.g., a virtual cloud network (VCN), a subnet, a virtual machine/compute instance), the test may include the same statement three times, each time passing in a different parameter corresponding to each resource. An explicit example will be discussed in connection withFIG.5below.

In some embodiments, each test may be associated with corresponding metadata that indicates which capabilities (requirements) will be tested and which resources will be used for the test. Any suitable number of tests and corresponding instances of metadata may be utilized. Thus, while one test may test every capability against every resource in the system, another test may be used to test a subset of capabilities and/or a subset of resources.

By utilizing the techniques discussed herein, the complexity of authoring tests may be drastically reduced. Whereas to manually author each test would require a test written for every unique combination of resource to capability (e.g., with R resources and C capabilities, R*C manually created tests), using the disclosed techniques the labor may be reduced to only defining resources and capabilities once, while the system will handle combining the two (e.g., R+C manually created code segments).

Referring now to the drawings,FIG.1depicts an example of a computing environment100for deploying and testing various infrastructure resources in a cloud-computing environment, in accordance with at least one embodiment. The computing environment100may include a test environment112and a production environment122. The test environment112and the production environment122may comprise one or more computing systems that execute computer-readable instructions (e.g., code, program) to implement the test environment112and the production environment122. As depicted inFIG.1, the test environment112includes a test system108and the production environment122includes a deployment orchestrator system116. Portions of data or information used by or generated in the test environment112may be stored in a persistent memory such as a data store120. The systems depicted inFIG.1may be implemented using software (e.g., code, instructions, program) executed by one or more processing units (e.g., processors, cores) of a computing system, hardware, or combinations thereof. The software may be stored on a non-transitory storage medium (e.g., on a memory device).

The computing environment100depicted inFIG.1is merely an example and is not intended to unduly limit the scope of claimed embodiments. One of ordinary skill in the art would recognize many possible variations, alternatives, and modifications. For example, in some implementations, the computing environment100can be implemented using more or fewer systems than those shown inFIG.1, may combine two or more systems, or may have a different configuration or arrangement of systems and subsystems.

The computing environment100may be implemented in various different configurations. In certain embodiments, the computing environment100comprising the test system108and the deployment orchestrator system116may be implemented in an enterprise servicing users of the enterprise. In other embodiments, the resources in the computing environment100may be implemented on one or more servers of a cloud provider and provided to subscribers of cloud services on a subscription basis.

In certain situations, to facilitate non-disruptive transition during an upgrade, or to provide a gradual change delivery model during the application development process, both an earlier version of the component and an updated (or new) version of the component may need to co-exist and execute in parallel the containerized environment for some time. In certain embodiments, the test system108and the deployment orchestrator system116include capabilities for enabling different versions of a component of a containerized application to co-exist on different computing nodes in a cluster of nodes of the containerized environment at the same time.

In certain embodiments, a user may interact with the test system108using a user device102that is communicatively coupled to the test system108, possibly via one or more communication networks. The user device102may be of various types, including but not limited to, a mobile phone, a tablet, a desktop computer, and the like. The user may interact with the test system108using a browser and/or any suitable user interface to identify executed by the user device102. For example, the user may use a user interface (UI) (which may be a graphical user interface (GUI)) of the browser executed by the user device102to interact with the test system108.

At104, a user may, via the UI, provide an application to be deployed in the computing environment. The application may represent a micro-service based containerized application that may be deployed in the production environment122. In certain examples, the application104may comprise multiple resources where multiple instances of each resource can be executed as containers on nodes within a cluster of nodes in a containerized environment of the production environment122. In certain examples, the containerized environment may be provided by a container orchestration platform such as Kubernetes, OpenShift, Docker Swarm, and the like. In certain examples, the application (comprising a set of one or more components) may be provided to the test system108prior to its deployment in the containerized environment.

At105, the user may select and/or define, via the UI, one or more options to indicate a set of resources with which the user would like to test a set of capabilities. These resources and/or capabilities may be predefined as resource blocks and stored within data store120. The test system108may include execution engine110. Execution engine110may be configured to utilize the users input at105to identify and/or generate metadata that defines every combination of capability/resource pairs to be tested. The set of capabilities and/or resources from which this metadata may be generated may be obtained from the data store120. Once generated, the metadata may be utilized by the execution engine110to generate an execution plan for the test. An execution plan may include a superset of every operation needed to perform the test on every unique combination of a capability and resource. In some embodiments, the execution engine110may be configured to optimize the execution plan such that redundant operations are removed and/or the efficiency of such operations is improved. These optimization may be identified based at least in part on a predefined set of rules. The execution engine may then execute the operations of the execution plan to produce output. This output may provide an outcome of each test corresponding to each resource/capability combination. It should be appreciated that the operations of105may be performed at any suitable time, according to a predefined schedule and/or periodicity, and/or according to user input obtained via a user interface provided by the test system108.

At107, the execution engine110may be configured to execute instructions for presenting the outcome of each test to the user device102. In some embodiments, the outcome may be formatted as a matrix where the rows and columns of the matrix identify the resources and capabilities performed. As a non-limiting example, each column of the matrix may be identified as corresponding to a particular capability, while each row may be identified as corresponding to a particular resource. At the intersection of each resource and capability, the outcome of the test result may be presented. In some embodiments, the outcome may be indicated with a symbol, a color, an icon, text, or any suitable graphical element. As a non-limiting example, a box at the intersection of a particular resource and capability may include a gray box to indicate the resource is incapable of executing the capability, a red box to indicate the resource failed to demonstrate the capability, a green box to indicate the resource successfully demonstrated to capability, or a black box to indicate the capability was not tested on the resource.

In certain embodiments, as a result of the processing performed by the test system108(e.g., every test performed by the execution engine110was successful (e.g., each resource successfully demonstrated each applicable capability and/or user input processed by the test system108), the test system108generates a deployment package114that includes the component(s) of the application104to be deployed and their associated network polices. A deployment orchestrator system116in the production environment122receives the deployment package114and uses the deployment package to deploy the component(s) of the application and to different nodes in a cluster of nodes in the containerized environment.

FIG.2depicts an example workflow200for executing an experiment, in accordance with at least one embodiment. An “experiment,” as used herein, refers to use cases that execute and track one or more scenarios. A “scenario” refers to an execution of a test involving a single capability and a single resource (although the code segment for this resource may involve more than one resource). Some example experiments may include running the entire matrix (e.g., a matrix defining every resource and every capability and every possible combination of the two) at a predefined periodicity, frequency, and/or according to a predefined schedule. As another example, an experiment could include re-running part, or the entire matrix of scenarios as part of an operational re-drive. As yet more examples, an experiment may include running a set of scenarios on a particular tenancy (e.g., with a particular set of features), running a single scenario as part of a development process, and running all possible variations for a particular resource/requirement combination. A “variation” refers to a particular version of a scenario (e.g., operations for testing a particular capability in a particular manner). In some embodiments, there may be multiple variations of a given scenario maintained in the system (e.g., multiple code segments that correspond to the requirement, in which each code segment includes differing operations for testing the requirement with the resource).

Execution of an experiment is modeled in workflow200. At202, scenarios are resolved. During scenario resolution, a scenario resolver (e.g., a component of the execution engine110ofFIG.1) may be configured to determine coverage and variation specifications to generate a set of (resource, requirement, and variation) tuples for each test in the experiment. The term “coverage” refers to a particular part of the matrix on which scenarios are to be run (e.g., a range of resources and requirement). The tuples may be utilized to generate an execution plan that includes programmatic instructions for executing each scenario corresponding to a tuple of the set of tuples.

By way of example, user input may be received that indicates a range of resources and a range of requirements (referred to as capabilities). As a non-limiting example, the range of resources may include all resources and the range of requirements may include all requirements. Thus, the scenario resolver204may utilize a predefined set of rules to identify which variation of each scenario to utilize if there are multiple from which to choose. In some embodiments, the scenario resolver204may incrementally determine which variation to select for each scenario as part of a process it executes to generate (resource, requirement, variation) tuples for each test in the experiment. The tuples may then be utilized to generate an execution plan by appending a code segment corresponding to the requirement (a particular variation) to an execution plan and injecting the code segment of the resource in a position designated by a resource placeholder within the code segment corresponding to the requirement. An execution plan may include any suitable combination of: (1) exact lists of operations to be performed, (2) requirements for one or more tenancy where plan can be executed, and/or (3) cleanup steps/operations to be performed after plan execution. Each attempt to resolve a scenario (e.g., to generate the corresponding tuple, to append the code segment corresponding to the requirement, and/or to inject the code segment corresponding to the resource within the code segment corresponding to the requirement) may be successful, unsuccessful, or partially successful. In some embodiments, the experiment may be configured to continue with only some of the scenarios resolved successfully, while in some embodiments, the experiment may be aborted if there are one or more scenarios that are unsuccessful resolved or only partially successfully resolved. In some embodiments, if resolving a scenario is unsuccessful or partially successful, the status and any suitable data corresponding to the scenario may be logged as a test failure at206.

At208, the successfully resolved scenarios may be scheduled. It may be there are other tasks being performed by the execution engine such that the necessary processing resources may be unavailable immediately. Thus, the execution engine may utilize any suitable predefined rules for scheduling the scenarios to be run for a time when the processing resources are assumed to be available once again.

At210, the scenarios may be executed according to the execution plan generated at202and the execution engine may wait for scenario execution to complete. In some embodiments, if at any time execution fails or is halted, the execution engine may log the failure and any suitable corresponding data at206.

At212, output data corresponding to each test (e.g., each resource, requirement, variation combination) may be processed to determine success or failure of each test. For every experiment execution additional data such as: timestamps (start time, completion time, etc.), status information (resolution success, scenario running success, etc.), overall completion percentage, and the like may be tracked. Any test failures may be logged at206, while any successes may be logged at214. In either case, any additional tracked data may be included in the log. The failures and successes logged at206and214, respectively, may be presented at a user device (e.g., the user device102ofFIG.1) at any suitable time via any suitable interface provided by the execution engine. One example user interface (e.g., a graphical interface element) is discussed below with respect toFIG.4.

FIG.3depicts an example workflow for executing a scenario, in accordance with at least one embodiment. As described above, a scenario refers to a single test of a given capability with respect to a given resource, or said another way, a test to determine whether a given resource meets a particular requirement.

At302, the scenario may be resolved by the scenario resolver304, a component of the execution engine110ofFIG.1. Resolving the scenario may include generating a tuple corresponding to the resource, requirement, and variation of requirement that is to be utilized to execute the scenario. The tuple may then be utilized to generate an execution plan that includes programmatic instructions for executing this particular scenario corresponding to the tuple.

At306, a tenancy may be resolved (e.g., chosen from a set of tenancies) by the tenancy resolver308(e.g., a component of the execution engine110) using the scenario, execution plan, and/or scenario metadata. The particular manner by which a particular tenancy is selected may be identified by a predefined set of rules. In some embodiments, execution of the execution plan may be paused until the chosen tenancy is available.

At310, the execution engine may verify/ensure various prerequisites. The operations performed at this point in the workflow ensure that the tenancy has the necessary prerequisites for executing the scenario, or creates them. For example, before running scenario operation(s), a tenancy may be allocated (selected and/or generated) which meets certain expectations. For example, one expectation may identify that if the scenario is not idempotent, the tenancy should not run the scenario again. Another expectation may relate to a requirement prerequisite that specifies that in order to test that requirement, certain prerequisites may need to be met (e.g. zero limits need to be set for all resources). As another example, an expectation may relate to a resource prerequisite that specifies that in order to test that resource, certain prerequisites may need to be met (e.g. VPC for compute instances). As yet another example, an expectation may be a special requirement to run on a specific tenancy (e.g., as part of a virtual lab).

At312, the scenario operation(s) may be executed according to the execution plan generated at302and the execution engine may wait for scenario execution to complete.

At314, any suitable cleanup operation(s) defined within the execution plan may be executed to delete resources created during scenario execution.

At316, output data corresponding to the scenario may be processed to determine the test's result (e.g., success or failure of the test). Scenario data including timestamps (start time, completion time, etc.), status information (scenario resolving success/failure, scenario running success/failure, etc.), overall completion percentage, and the like may be tracked. The test result may be presented at a user device (e.g., the user device102ofFIG.1) at any suitable time via any suitable interface provided by the execution engine.

FIG.4depicts an example graphical interface element400for presenting test results, in accordance with at least one embodiment. The graphical interface element400may vary in size depending on the number of capabilities and resources involved in the experiment. If running a single scenario, the graphical interface element400may be used to present a single test result. As depicted, the graphical interface element400represents a matrix in which the columns correspond to individual capabilities and the rows correspond to resources. Each intersecting box corresponds to a test result of a particular scenario. By way of example, test result402corresponds to a test result of testing whether resource14has capability3(e.g., whether resource14met a requirement corresponding to capability3).

Legend404includes a number of statuses (e.g., status1-4) indicated with a corresponding symbol. Although symbols are used inFIG.4to convey status, it should be appreciated that any suitable indicator such as test, characters, colors, or the like may be similarly used to express a test result. In some embodiments, the symbol406may indicate a successful test, symbol408may indicate a failed test, symbol410may indicate the capability was never implemented for the given resource, and symbol412may indicate particular capabilities that were not tested based on previously submitted user input. In some embodiments, the test results may be first collected in their entirety and the graphical interface element400may be generated and presented. While in other embodiments, the graphical interface element400may be presented as soon as test execution commences (or at any suitable time) and updated as test results are determined for each test.

FIG.5depicts two example algorithms for creating a resource, in accordance with at least one embodiment. Algorithm502specifies operation(s) for creating resource R1(e.g., a bucket/storage container). Algorithm504specifies operation(s) for creating resource R2(e.g., a virtual machine). The exact operations executed for each operation may vary. However, in some embodiments, each operation performed that utilizes a function call may utilize a function of a limited set of functions. For example, a domain specific language (DSL) may be predefined to be optimized for creating test plans. The functions provided in this DSL may relate to operations corresponding to communicating with programming interfaces of a declarative infrastructure provisioner (DIP). The DIP is configured to define and provision infrastructure resources (e.g., data center resources) using a declarative configuration language. Some functions of the DSL may correspond to call to a Representative State Transfer (REST) Application Programming Interface (API). A REST API refers to an API that conforms to constraints of a REST architecture style and allows for communication between two software programs of the cloud computing environment in which one program can request and/or manipulate resources of the other. Some functions of the DSL may relate to data manipulation such as assigning values to variables, utilizing expressions (e.g., type declarations, reading from memory, reading from settings, extracting a field, combining objects, etc.). Some functions of the DSL may relate to perform logical operations (e.g., Boolean operations, not, all, any, assert, etc.). Some functions of the DSL may relate to special instructions such as specifying a placeholder where resource operations may be injected.

As a non-limiting example, the DSL may include a single function call that may be utilized to create a resource. In some embodiments, the function may be overloaded and/or have multiple definitions/code segments that may vary depending on the resource to be generated. In some embodiments, a particular function of the set of overloaded functions may be selected based at least in part on the parameter list, which may indicate the particular type of resources to be created. Thus, the actual operations performed to create each resource may differ depending on the type of resource it is, however, the same function may be utilized, albeit with potentially different parameter lists. Similarly, the DSL may include a delete function that performs clean-up/delete operations on whatever resource is identified in the parameter list used when calling the function. Thus, the DSL may be made up of a relatively limited number of functions (e.g., 20, 24, 30, etc.), where each function may be thought of as providing a particular type of functionality, where the particular resource on which this functionality is applied depending on the parameter list used in the function call. Another function may relate to asserting a particular condition is true. The particular condition being checked for truth may be determined based on the parameter list past into the assert function. As an example, a string (e.g., “TagPresent”) may be passed in the parameter list of an Assert function that determines whether a particular condition is true (e.g., is a tag present for a given resource). The function may operate on a resource object (e.g., resourceObject.Assert(“TagPresent”).

Algorithm502may be defined within a code segment associated with the resource type (e.g., bucket). Thus, any time a user desired to create a resource of that resource type, the same code segment may be used.

Algorithm504may define different operations of a different code segment that is associated with a resource type (e.g., a virtual machine) that is different from the resource type associated with algorithm502. In some embodiments, like that of algorithm504, creating a resource (e.g., resource R2) may depend on creating other resources first. Thus, as algorithm504depicts, the code segment defined for creating a resource of this type (e.g., a virtual machine) may include first executing one or more operations for creating a first resource (e.g., executing a create resource function and indicating a virtual cloud network (vcn) is to be created). An object (or other suitable container) may be returned upon executing those operations. The object may be associated with any suitable attribute that describes aspects of the resource (e.g., name, type, identifier, etc.). Once the first resource is created, the algorithm may specify that particular data (e.g., an identifier (ID) for the vcn) may be extracted from the returned object. The extracted data may then be utilized to create a second resource (e.g., by executing the create resource function with an indication that a subnet is to be created). The creation of the second resource may require the extracted data (e.g., the vcn ID) which may be passed in a parameter list (e.g., in the parameter list of the create resource function). An object (e.g., corresponding to the subnet) may be returned. Once the second resource is created, the algorithm may specify that particular data (e.g., an identifier (ID) for the subnet) may be extracted from the returned object. The extracted data may then be utilized to create a third resource (e.g., by executing the create resource function with an indication that a virtual machine is to be created). The creation of the third resource may require the extracted data (e.g., the subnet ID) from the second resource, which may be passed in a parameter list (e.g., in the parameter list of the create resource function). An object (e.g., corresponding to the virtual machine) may be returned. It should be appreciated, that the same function for creating a resource may be utilized to create the first resource, the second resource, and the third resource, although each will use different parameter list that identify the particular function call to correspond to a particular type of resource. Similarly, extracting metadata from the first and second resources may utilize the same function call but utilize a parameter list that designates the particular metadata to extract from the object.

FIG.6depicts two example algorithms for creating a capability, in accordance with at least one embodiment. Algorithm602specifies one or more operations for testing whether a resource implements a particular capability C1(e.g., whether a resource meets a particular requirement). Algorithm604specifies one or more operations for testing whether a resource implements another capability C2(e.g., a virtual machine). The exact operations executed for each operation may vary depending on the capability (and/or variation of the capability). However, in some embodiments, each operation performed that utilizes a function call within the code segment associated with each capability may utilize a function of a limited set of functions described above with respect toFIG.5.

By way of example, algorithm602may relate to capability C1(e.g., the ability to tag a resource with a label). Algorithm602may include operations for creating a resource placeholder (e.g., a placeholder where a code segment corresponding to a resource is to be inserted) and a number of operations (e.g., “A,” “B,” and “C”) that are directed to testing whether a resource implements that particular capability. As a non-limiting example, for testing the ability to tag a resource with a label, the operations may call a REST API to tag a resource, then call another REST API to get the tag of a resort, and then execute an assert function call to assert that the tag is present. The assert function call may be configured to return true if a tag is associated with the resource or false if no tag is associated with the resource.

In some embodiments, a capability C2may relate to checking whether a non-privileged user is restricted from deleting a resource. Thus, the first algorithmic step may cause a user (e.g., a type of resource) to be created. An object may be return that is represents the created user and provide access to attributes associated with the user (e.g., name, privileges, identifiers, etc.). Like algorithm602, algorithm604may include one or more operations for creating a resource placeholder that designates a position within the code segment associated with capability C2where a code segment corresponding to a resource is to be inserted and a number of operations (e.g., “A,” “D,” “E,” and “F”) that are directed to testing whether a resource implements that particular capability. The remaining operations of algorithm604may provide the various operations for testing whether a non-privileged user is restricted from deleting a resource. By way of example, the user resource created in step one may be utilized to call a REST API to attempt to delete the resource created at step 2, then a REST API may be called to attempt to get access to the resource, and then an assert function call may be executed to assert that the resource is present/not deleted. The assert function may be configured to return true when the resource is accessible and false when it is not.

FIG.7depicts an example execution plan700for testing the capabilities ofFIG.6as executed with the resources ofFIG.5, in accordance with at least one embodiment. Although the execution plan700is described in algorithmic steps, it should be appreciated that an execution plan includes the code for the operations to be performed. The execution plan700depicts four tests that correspond to each unique combination of R1and R2ofFIG.5and C1and C2ofFIG.6. That is, each test corresponds to a test to check whether a given resource (e.g., a bucket for R1, a virtual machine for R2) implements a particular capability (e.g., can the resource be tagged in accordance with C1, can a non-privileged user delete the resource in accordance with C2).

Test 1 may include code segments corresponding to algorithm502and602ofFIGS.5and6, respectively. By way of example, the code segment corresponding to capability C1(e.g., algorithm602) may be appended to the execution plan. A create resource placeholder may be identified. The system (e.g., the execution engine110ofFIG.1) may identify a first resource with which the capability will be tested (e.g., R1according to a matrix and/or tuples generated via user input as described inFIG.2). The system may retrieve the code segment corresponding to that resource and inject that code segment within the code segment corresponding to the capability C1. Thus, the sub-points within test 1 each represent operations defined in the combination of the code segment associated with R1and the code segment associated with capability C1.

Test 2 may include code segments corresponding to algorithm504and602ofFIGS.5and6, respectively. By way of example, the code segment corresponding to capability C1(e.g., algorithm602) may be appended to the execution plan (e.g., after the code segments already added for test 1). A create resource placeholder may be identified. The system may identify a second resource with which the capability will be tested (e.g., R2according to a matrix and/or tuples generated via user input as described inFIG.2). The system may retrieve the code segment corresponding to that resource and inject that code segment within the code segment corresponding to the capability C1. Thus, the sub-points within test 2 each represent operations defined in the combination of the code segment associated with R2and the code segment associated with capability C1.

This process may be repeated any suitable number of times depending on the number of resources with which capability C1is to be tested. This would depend on the tuples and/or matrix that specify which tests are to be performed (and what variations are to be used for each test).

Continuing with the example, test 3 may include code segments corresponding to algorithm502and604ofFIGS.5and6, respectively. By way of example, the code segment corresponding to capability C2(e.g., algorithm604) may be appended to the execution plan (after the code segments for test 1 and test 2). A create resource placeholder may be identified. The system may identify a first resource with which the capability C2will be tested (e.g., R1according to a matrix and/or tuples generated via user input as described inFIG.2). The system may retrieve the code segment corresponding to that resource and inject that code segment within the code segment corresponding to the capability C2. Thus, the sub-points within test 3 each represent operations defined in the combination of the code segment associated with R1and the code segment associated with capability C2.

Test 4 may include code segments corresponding to algorithm504and604ofFIGS.5and6, respectively. By way of example, the code segment corresponding to capability C2(e.g., algorithm604) may be appended to the execution plan (e.g., after the code segments already added for tests 1, 2, and 3). A create resource placeholder may be identified. The system may identify a second resource with which the capability will be tested (e.g., R2according to a matrix and/or tuples generated via user input as described inFIG.2). The system may retrieve the code segment corresponding to that resource and inject that code segment within the code segment corresponding to the capability C2. Thus, the sub-points within test 4 each represent operations defined in the combination of the code segment associated with R2and the code segment associated with capability C2.

This process may be repeated any suitable number of times depending on the number of resources with which capability C2is to be tested. This would depend on the tuples and/or matrix that specify which tests are to be performed (and what variations are to be used for each test). It should be appreciated that tests 1-4 may be arranged in any suitable order within the execution plan700, not necessarily the order depicted inFIG.7.

FIG.8is an example of a method800for generating and executing an execution plan, in accordance with at least one embodiment. The operations of method800may be performed in any suitable order. Although a number of operations are described in connection withFIG.8, it should be appreciated that more or fewer operations may be utilized. In some embodiments, the method800may be performed by the execution engine110ofFIG.1(e.g., as part of the test system108ofFIG.1, or as part of an execution engine operations as part of the production environment122ofFIG.1, etc.).

The method800may begin at802, where a first set of code segments is maintained (e.g., in data store120ofFIG.1). In some embodiments, each code segment of the first set of code segments (e.g., the code segments ofFIG.5) individually comprise programmatic instructions (e.g., one or more lines of codes) for generating a resource of a set of resources of a cloud-computing environment. The programmatic instructions comprise a first set of functions calls of a limited set of function calls (e.g., some subset of the function calls discussed in connection withFIG.5) that are optimized for generating execution plans in the cloud-computing environment.

At804, a second set of code segments is maintained (e.g., in the data store120ofFIG.1). In some embodiments, each code segment of the second set of code segments (e.g., the code segments ofFIG.6) comprises respective programmatic instructions defining a capability of a set of capabilities of the cloud-computing environment. The respective programmatic instructions comprise a second set of function calls of the limited set of function calls.

At806, metadata (e.g., the tuples discussed in connection withFIGS.2and/or3) indicating a corresponding set of capabilities that are applicable for each resource of the set of resources is obtained (e.g., generated based on user input).

At808, an execution plan is generated based at least in part on combining the first set of code segments for generating the set of resources and the second set of code segments defining the set of capabilities. The execution plan may be generated in accordance with the metadata indicating the corresponding set of capabilities that are applicable for individual resources of the set of resources. By way of example, each of the second set of code segments may include one or more placeholders that indicate a position at which a code segment corresponding to a resource is to be injected as described in connection withFIG.7. In some embodiments, generating execution plan may include removing repetitive function calls (e.g., two instances of the same function call within the same code segment).

At810, a set of test results is generated based at least in part on executing the execution plan.

At812, instructions that cause a result for each of the set of test results to be displayed at a user device are executed. By way of example, each of the set of test results may be displayed at the graphical interface element400ofFIG.4as part of a matrix of test results.

Example Architectures

The VCN906can include a local peering gateway (LPG)910that can be communicatively coupled to a secure shell (SSH) VCN912via an LPG910contained in the SSH VCN912. The SSH VCN912can include an SSH subnet914, and the SSH VCN912can be communicatively coupled to a control plane VCN916via the LPG910contained in the control plane VCN916. Also, the SSH VCN912can be communicatively coupled to a data plane VCN918via an LPG910. The control plane VCN916and the data plane VCN918can be contained in a service tenancy919that can be owned and/or operated by the IaaS provider.

The control plane VCN916can include a control plane demilitarized zone (DMZ) tier920that acts as a perimeter network (e.g., portions of a corporate network between the corporate intranet and external networks). The DMZ-based servers may have restricted responsibilities and help keep breaches contained. Additionally, the DMZ tier920can include one or more load balancer (LB) subnet(s)922, a control plane app tier924that can include app subnet(s)926, a control plane data tier928that can include database (DB) subnet(s)930(e.g., frontend DB subnet(s) and/or backend DB subnet(s)). The LB subnet(s)922contained in the control plane DMZ tier920can be communicatively coupled to the app subnet(s)926contained in the control plane app tier924and an Internet gateway934that can be contained in the control plane VCN916, and the app subnet(s)926can be communicatively coupled to the DB subnet(s)930contained in the control plane data tier928and a service gateway936and a network address translation (NAT) gateway938. The control plane VCN916can include the service gateway936and the NAT gateway938.

The control plane VCN916can include a data plane mirror app tier940that can include app subnet(s)926. The app subnet(s)926contained in the data plane mirror app tier940can include a virtual network interface controller (VNIC)942that can execute a compute instance944. The compute instance944can communicatively couple the app subnet(s)926of the data plane mirror app tier940to app subnet(s)926that can be contained in a data plane app tier946.

The data plane VCN918can include the data plane app tier946, a data plane DMZ tier948, and a data plane data tier950. The data plane DMZ tier948can include LB subnet(s)922that can be communicatively coupled to the app subnet(s)926of the data plane app tier946and the Internet gateway934of the data plane VCN918. The app subnet(s)926can be communicatively coupled to the service gateway936of the data plane VCN918and the NAT gateway938of the data plane VCN918. The data plane data tier950can also include the DB subnet(s)930that can be communicatively coupled to the app subnet(s)926of the data plane app tier946.

The Internet gateway934of the control plane VCN916and of the data plane VCN918can be communicatively coupled to a metadata management service952that can be communicatively coupled to public Internet954. Public Internet954can be communicatively coupled to the NAT gateway938of the control plane VCN916and of the data plane VCN918. The service gateway936of the control plane VCN916and of the data plane VCN918can be communicatively couple to cloud services956.

In some examples, the service gateway936of the control plane VCN916or of the data plane VCN918can make application programming interface (API) calls to cloud services956without going through public Internet954. The API calls to cloud services956from the service gateway936can be one-way: the service gateway936can make API calls to cloud services956, and cloud services956can send requested data to the service gateway936. But, cloud services956may not initiate API calls to the service gateway936.

In some examples, the secure host tenancy904can be directly connected to the service tenancy919, which may be otherwise isolated. The secure host subnet908can communicate with the SSH subnet914through an LPG910that may enable two-way communication over an otherwise isolated system. Connecting the secure host subnet908to the SSH subnet914may give the secure host subnet908access to other entities within the service tenancy919.

The control plane VCN916may allow users of the service tenancy919to set up or otherwise provision desired resources. Desired resources provisioned in the control plane VCN916may be deployed or otherwise used in the data plane VCN918. In some examples, the control plane VCN916can be isolated from the data plane VCN918, and the data plane mirror app tier940of the control plane VCN916can communicate with the data plane app tier946of the data plane VCN918via VNICs942that can be contained in the data plane mirror app tier940and the data plane app tier946.

In some examples, users of the system, or customers, can make requests, for example create, read, update, or delete (CRUD) operations, through public Internet954that can communicate the requests to the metadata management service952. The metadata management service952can communicate the request to the control plane VCN916through the Internet gateway934. The request can be received by the LB subnet(s)922contained in the control plane DMZ tier920. The LB subnet(s)922may determine that the request is valid, and in response to this determination, the LB subnet(s)922can transmit the request to app subnet(s)926contained in the control plane app tier924. If the request is validated and requires a call to public Internet954, the call to public Internet954may be transmitted to the NAT gateway938that can make the call to public Internet954. Memory that may be desired to be stored by the request can be stored in the DB subnet(s)930.

In some examples, the data plane mirror app tier940can facilitate direct communication between the control plane VCN916and the data plane VCN918. For example, changes, updates, or other suitable modifications to configuration may be desired to be applied to the resources contained in the data plane VCN918. Via a VNIC942, the control plane VCN916can directly communicate with, and can thereby execute the changes, updates, or other suitable modifications to configuration to, resources contained in the data plane VCN918.

In some embodiments, the control plane VCN916and the data plane VCN918can be contained in the service tenancy919. In this case, the user, or the customer, of the system may not own or operate either the control plane VCN916or the data plane VCN918. Instead, the IaaS provider may own or operate the control plane VCN916and the data plane VCN918, both of which may be contained in the service tenancy919. This embodiment can enable isolation of networks that may prevent users or customers from interacting with other users', or other customers', resources. Also, this embodiment may allow users or customers of the system to store databases privately without needing to rely on public Internet954, which may not have a desired level of threat prevention, for storage.

In other embodiments, the LB subnet(s)922contained in the control plane VCN916can be configured to receive a signal from the service gateway936. In this embodiment, the control plane VCN916and the data plane VCN918may be configured to be called by a customer of the IaaS provider without calling public Internet954. Customers of the IaaS provider may desire this embodiment since database(s) that the customers use may be controlled by the IaaS provider and may be stored on the service tenancy919, which may be isolated from public Internet954.

FIG.10is a block diagram1000illustrating another example pattern of an IaaS architecture, according to at least one embodiment. Service operators1002(e.g. service operators902ofFIG.9) can be communicatively coupled to a secure host tenancy1004(e.g. the secure host tenancy904ofFIG.9) that can include a virtual cloud network (VCN)1006(e.g. the VCN906ofFIG.9) and a secure host subnet1008(e.g. the secure host subnet908ofFIG.9). The VCN1006can include a local peering gateway (LPG)1010(e.g. the LPG910ofFIG.9) that can be communicatively coupled to a secure shell (SSH) VCN1012(e.g. the SSH VCN912ofFIG.9) via an LPG910contained in the SSH VCN1012. The SSH VCN1012can include an SSH subnet1014(e.g. the SSH subnet914ofFIG.9), and the SSH VCN1012can be communicatively coupled to a control plane VCN1016(e.g. the control plane VCN916ofFIG.9) via an LPG1010contained in the control plane VCN1016. The control plane VCN1016can be contained in a service tenancy1019(e.g. the service tenancy919ofFIG.9), and the data plane VCN1018(e.g. the data plane VCN918ofFIG.9) can be contained in a customer tenancy1021that may be owned or operated by users, or customers, of the system.

The control plane VCN1016can include a control plane DMZ tier1020(e.g. the control plane DMZ tier920ofFIG.9) that can include LB subnet(s)1022(e.g. LB subnet(s)922ofFIG.9), a control plane app tier1024(e.g. the control plane app tier924ofFIG.9) that can include app subnet(s)1026(e.g. app subnet(s)926ofFIG.9), a control plane data tier1028(e.g. the control plane data tier928ofFIG.9) that can include database (DB) subnet(s)1030(e.g. similar to DB subnet(s)930ofFIG.9). The LB subnet(s)1022contained in the control plane DMZ tier1020can be communicatively coupled to the app subnet(s)1026contained in the control plane app tier1024and an Internet gateway1034(e.g. the Internet gateway934ofFIG.9) that can be contained in the control plane VCN1016, and the app subnet(s)1026can be communicatively coupled to the DB subnet(s)1030contained in the control plane data tier1028and a service gateway1036(e.g. the service gateway ofFIG.9) and a network address translation (NAT) gateway1038(e.g. the NAT gateway938ofFIG.9). The control plane VCN1016can include the service gateway1036and the NAT gateway1038.

The control plane VCN1016can include a data plane mirror app tier1040(e.g. the data plane mirror app tier940ofFIG.9) that can include app subnet(s)1026. The app subnet(s)1026contained in the data plane mirror app tier1040can include a virtual network interface controller (VNIC)1042(e.g. the VNIC of942) that can execute a compute instance1044(e.g. similar to the compute instance944ofFIG.9). The compute instance1044can facilitate communication between the app subnet(s)1026of the data plane mirror app tier1040and the app subnet(s)1026that can be contained in a data plane app tier1046(e.g. the data plane app tier946ofFIG.9) via the VNIC1042contained in the data plane mirror app tier1040and the VNIC1042contained in the data plane app tier1046.

The Internet gateway1034contained in the control plane VCN1016can be communicatively coupled to a metadata management service1052(e.g. the metadata management service952ofFIG.9) that can be communicatively coupled to public Internet1054(e.g. public Internet954ofFIG.9). Public Internet1054can be communicatively coupled to the NAT gateway1038contained in the control plane VCN1016. The service gateway1036contained in the control plane VCN1016can be communicatively couple to cloud services1056(e.g. cloud services956ofFIG.9).

In some examples, the data plane VCN1018can be contained in the customer tenancy1021. In this case, the IaaS provider may provide the control plane VCN1016for each customer, and the IaaS provider may, for each customer, set up a unique compute instance1044that is contained in the service tenancy1019. Each compute instance1044may allow communication between the control plane VCN1016, contained in the service tenancy1019, and the data plane VCN1018that is contained in the customer tenancy1021. The compute instance1044may allow resources, that are provisioned in the control plane VCN1016that is contained in the service tenancy1019, to be deployed or otherwise used in the data plane VCN1018that is contained in the customer tenancy1021.

In other examples, the customer of the IaaS provider may have databases that live in the customer tenancy1021. In this example, the control plane VCN1016can include the data plane mirror app tier1040that can include app subnet(s)1026. The data plane mirror app tier1040can reside in the data plane VCN1018, but the data plane mirror app tier1040may not live in the data plane VCN1018. That is, the data plane mirror app tier1040may have access to the customer tenancy1021, but the data plane mirror app tier1040may not exist in the data plane VCN1018or be owned or operated by the customer of the IaaS provider. The data plane mirror app tier1040may be configured to make calls to the data plane VCN1018but may not be configured to make calls to any entity contained in the control plane VCN1016. The customer may desire to deploy or otherwise use resources in the data plane VCN1018that are provisioned in the control plane VCN1016, and the data plane mirror app tier1040can facilitate the desired deployment, or other usage of resources, of the customer.

In some embodiments, the customer of the IaaS provider can apply filters to the data plane VCN1018. In this embodiment, the customer can determine what the data plane VCN1018can access, and the customer may restrict access to public Internet1054from the data plane VCN1018. The IaaS provider may not be able to apply filters or otherwise control access of the data plane VCN1018to any outside networks or databases. Applying filters and controls by the customer onto the data plane VCN1018, contained in the customer tenancy1021, can help isolate the data plane VCN1018from other customers and from public Internet1054.

In some embodiments, cloud services1056can be called by the service gateway1036to access services that may not exist on public Internet1054, on the control plane VCN1016, or on the data plane VCN1018. The connection between cloud services1056and the control plane VCN1016or the data plane VCN1018may not be live or continuous. Cloud services1056may exist on a different network owned or operated by the IaaS provider. Cloud services1056may be configured to receive calls from the service gateway1036and may be configured to not receive calls from public Internet1054. Some cloud services1056may be isolated from other cloud services1056, and the control plane VCN1016may be isolated from cloud services1056that may not be in the same region as the control plane VCN1016. For example, the control plane VCN1016may be located in “Region1,” and cloud service “Deployment8,” may be located in Region1and in “Region2.” If a call to Deployment8is made by the service gateway1036contained in the control plane VCN1016located in Region1, the call may be transmitted to Deployment8in Region1. In this example, the control plane VCN1016, or Deployment8in Region1, may not be communicatively coupled to, or otherwise in communication with, Deployment8in Region2.

FIG.11is a block diagram1100illustrating another example pattern of an IaaS architecture, according to at least one embodiment. Service operators1102(e.g. service operators902ofFIG.9) can be communicatively coupled to a secure host tenancy1104(e.g. the secure host tenancy904ofFIG.9) that can include a virtual cloud network (VCN)1106(e.g. the VCN906ofFIG.9) and a secure host subnet1108(e.g. the secure host subnet908ofFIG.9). The VCN1106can include an LPG1110(e.g. the LPG910ofFIG.9) that can be communicatively coupled to an SSH VCN1112(e.g. the SSH VCN912ofFIG.9) via an LPG1110contained in the SSH VCN1112. The SSH VCN1112can include an SSH subnet1114(e.g. the SSH subnet914ofFIG.9), and the SSH VCN1112can be communicatively coupled to a control plane VCN1116(e.g. the control plane VCN916ofFIG.9) via an LPG1110contained in the control plane VCN1116and to a data plane VCN1118(e.g. the data plane918ofFIG.9) via an LPG1110contained in the data plane VCN1118. The control plane VCN1116and the data plane VCN1118can be contained in a service tenancy1119(e.g. the service tenancy919ofFIG.9).

The control plane VCN1116can include a control plane DMZ tier1120(e.g. the control plane DMZ tier920ofFIG.9) that can include load balancer (LB) subnet(s)1122(e.g. LB subnet(s)922ofFIG.9), a control plane app tier1124(e.g. the control plane app tier924ofFIG.9) that can include app subnet(s)1126(e.g. similar to app subnet(s)926ofFIG.9), a control plane data tier1128(e.g. the control plane data tier928ofFIG.9) that can include DB subnet(s)1130. The LB subnet(s)1122contained in the control plane DMZ tier1120can be communicatively coupled to the app subnet(s)1126contained in the control plane app tier1124and to an Internet gateway1134(e.g. the Internet gateway934ofFIG.9) that can be contained in the control plane VCN1116, and the app subnet(s)1126can be communicatively coupled to the DB subnet(s)1130contained in the control plane data tier1128and to a service gateway1136(e.g. the service gateway ofFIG.9) and a network address translation (NAT) gateway1138(e.g. the NAT gateway938ofFIG.9). The control plane VCN1116can include the service gateway1136and the NAT gateway1138.

The data plane VCN1118can include a data plane app tier1146(e.g. the data plane app tier946ofFIG.9), a data plane DMZ tier1148(e.g. the data plane DMZ tier948ofFIG.9), and a data plane data tier1150(e.g. the data plane data tier950ofFIG.9). The data plane DMZ tier1148can include LB subnet(s)1122that can be communicatively coupled to trusted app subnet(s)1160and untrusted app subnet(s)1162of the data plane app tier1146and the Internet gateway1134contained in the data plane VCN1118. The trusted app subnet(s)1160can be communicatively coupled to the service gateway1136contained in the data plane VCN1118, the NAT gateway1138contained in the data plane VCN1118, and DB subnet(s)1130contained in the data plane data tier1150. The untrusted app subnet(s)1162can be communicatively coupled to the service gateway1136contained in the data plane VCN1118and DB subnet(s)1130contained in the data plane data tier1150. The data plane data tier1150can include DB subnet(s)1130that can be communicatively coupled to the service gateway1136contained in the data plane VCN1118.

The untrusted app subnet(s)1162can include one or more primary VNICs1164(1)-(N) that can be communicatively coupled to tenant virtual machines (VMs)1166(1)-(N). Each tenant VM1166(1)-(N) can be communicatively coupled to a respective app subnet1167(1)-(N) that can be contained in respective container egress VCNs1168(1)-(N) that can be contained in respective customer tenancies1170(1)-(N). Respective secondary VNICs1172(1)-(N) can facilitate communication between the untrusted app subnet(s)1162contained in the data plane VCN1118and the app subnet contained in the container egress VCNs1168(1)-(N). Each container egress VCNs1168(1)-(N) can include a NAT gateway1138that can be communicatively coupled to public Internet1154(e.g. public Internet954ofFIG.9).

The Internet gateway1134contained in the control plane VCN1116and contained in the data plane VCN1118can be communicatively coupled to a metadata management service1152(e.g. the metadata management system952ofFIG.9) that can be communicatively coupled to public Internet1154. Public Internet1154can be communicatively coupled to the NAT gateway1138contained in the control plane VCN1116and contained in the data plane VCN1118. The service gateway1136contained in the control plane VCN1116and contained in the data plane VCN1118can be communicatively couple to cloud services1156.

In some examples, the customer of the IaaS provider may grant temporary network access to the IaaS provider and request a function to be attached to the data plane tier app1146. Code to run the function may be executed in the VMs1166(1)-(N), and the code may not be configured to run anywhere else on the data plane VCN1118. Each VM1166(1)-(N) may be connected to one customer tenancy1170. Respective containers1171(1)-(N) contained in the VMs1166(1)-(N) may be configured to run the code. In this case, there can be a dual isolation (e.g., the containers1171(1)-(N) running code, where the containers1171(1)-(N) may be contained in at least the VM1166(1)-(N) that are contained in the untrusted app subnet(s)1162), which may help prevent incorrect or otherwise undesirable code from damaging the network of the IaaS provider or from damaging a network of a different customer. The containers1171(1)-(N) may be communicatively coupled to the customer tenancy1170and may be configured to transmit or receive data from the customer tenancy1170. The containers1171(1)-(N) may not be configured to transmit or receive data from any other entity in the data plane VCN1118. Upon completion of running the code, the IaaS provider may kill or otherwise dispose of the containers1171(1)-(N).

In some embodiments, the trusted app subnet(s)1160may run code that may be owned or operated by the IaaS provider. In this embodiment, the trusted app subnet(s)1160may be communicatively coupled to the DB subnet(s)1130and be configured to execute CRUD operations in the DB subnet(s)1130. The untrusted app subnet(s)1162may be communicatively coupled to the DB subnet(s)1130, but in this embodiment, the untrusted app subnet(s) may be configured to execute read operations in the DB subnet(s)1130. The containers1171(1)-(N) that can be contained in the VM1166(1)-(N) of each customer and that may run code from the customer may not be communicatively coupled with the DB subnet(s)1130.

In other embodiments, the control plane VCN1116and the data plane VCN1118may not be directly communicatively coupled. In this embodiment, there may be no direct communication between the control plane VCN1116and the data plane VCN1118. However, communication can occur indirectly through at least one method. An LPG1110may be established by the IaaS provider that can facilitate communication between the control plane VCN1116and the data plane VCN1118. In another example, the control plane VCN1116or the data plane VCN1118can make a call to cloud services1156via the service gateway1136. For example, a call to cloud services1156from the control plane VCN1116can include a request for a service that can communicate with the data plane VCN1118.

FIG.12is a block diagram1200illustrating another example pattern of an IaaS architecture, according to at least one embodiment. Service operators1202(e.g. service operators902ofFIG.9) can be communicatively coupled to a secure host tenancy1204(e.g. the secure host tenancy904ofFIG.9) that can include a virtual cloud network (VCN)1206(e.g. the VCN906ofFIG.9) and a secure host subnet1208(e.g. the secure host subnet908ofFIG.9). The VCN1206can include an LPG1210(e.g. the LPG910ofFIG.9) that can be communicatively coupled to an SSH VCN1212(e.g. the SSH VCN912ofFIG.9) via an LPG1210contained in the SSH VCN1212. The SSH VCN1212can include an SSH subnet1214(e.g. the SSH subnet914ofFIG.9), and the SSH VCN1212can be communicatively coupled to a control plane VCN1216(e.g. the control plane VCN916ofFIG.9) via an LPG1210contained in the control plane VCN1216and to a data plane VCN1218(e.g. the data plane918ofFIG.9) via an LPG1210contained in the data plane VCN1218. The control plane VCN1216and the data plane VCN1218can be contained in a service tenancy1219(e.g. the service tenancy919ofFIG.9).

The control plane VCN1216can include a control plane DMZ tier1220(e.g. the control plane DMZ tier920ofFIG.9) that can include LB subnet(s)1222(e.g. LB subnet(s)922ofFIG.9), a control plane app tier1224(e.g. the control plane app tier924ofFIG.9) that can include app subnet(s)1226(e.g. app subnet(s)926ofFIG.9), a control plane data tier1228(e.g. the control plane data tier928ofFIG.9) that can include DB subnet(s)1230(e.g. DB subnet(s)1130ofFIG.11). The LB subnet(s)1222contained in the control plane DMZ tier1220can be communicatively coupled to the app subnet(s)1226contained in the control plane app tier1224and to an Internet gateway1234(e.g. the Internet gateway934ofFIG.9) that can be contained in the control plane VCN1216, and the app subnet(s)1226can be communicatively coupled to the DB subnet(s)1230contained in the control plane data tier1228and to a service gateway1236(e.g. the service gateway ofFIG.9) and a network address translation (NAT) gateway1238(e.g. the NAT gateway938ofFIG.9). The control plane VCN1216can include the service gateway1236and the NAT gateway1238.

The data plane VCN1218can include a data plane app tier1246(e.g. the data plane app tier946ofFIG.9), a data plane DMZ tier1248(e.g. the data plane DMZ tier948ofFIG.9), and a data plane data tier1250(e.g. the data plane data tier950ofFIG.9). The data plane DMZ tier1248can include LB subnet(s)1222that can be communicatively coupled to trusted app subnet(s)1260(e.g. trusted app subnet(s)1160ofFIG.11) and untrusted app subnet(s)1262(e.g. untrusted app subnet(s)1162ofFIG.11) of the data plane app tier1246and the Internet gateway1234contained in the data plane VCN1218. The trusted app subnet(s)1260can be communicatively coupled to the service gateway1236contained in the data plane VCN1218, the NAT gateway1238contained in the data plane VCN1218, and DB subnet(s)1230contained in the data plane data tier1250. The untrusted app subnet(s)1262can be communicatively coupled to the service gateway1236contained in the data plane VCN1218and DB subnet(s)1230contained in the data plane data tier1250. The data plane data tier1250can include DB subnet(s)1230that can be communicatively coupled to the service gateway1236contained in the data plane VCN1218.

The untrusted app subnet(s)1262can include primary VNICs1264(1)-(N) that can be communicatively coupled to tenant virtual machines (VMs)1266(1)-(N) residing within the untrusted app subnet(s)1262. Each tenant VM1266(1)-(N) can run code in a respective container1267(1)-(N), and be communicatively coupled to an app subnet1226that can be contained in a data plane app tier1246that can be contained in a container egress VCN1268. Respective secondary VNICs1272(1)-(N) can facilitate communication between the untrusted app subnet(s)1262contained in the data plane VCN1218and the app subnet contained in the container egress VCN1268. The container egress VCN can include a NAT gateway1238that can be communicatively coupled to public Internet1254(e.g. public Internet954ofFIG.9).

The Internet gateway1234contained in the control plane VCN1216and contained in the data plane VCN1218can be communicatively coupled to a metadata management service1252(e.g. the metadata management system952ofFIG.9) that can be communicatively coupled to public Internet1254. Public Internet1254can be communicatively coupled to the NAT gateway1238contained in the control plane VCN1216and contained in the data plane VCN1218. The service gateway1236contained in the control plane VCN1216and contained in the data plane VCN1218can be communicatively couple to cloud services1256.

In some examples, the pattern illustrated by the architecture of block diagram1200ofFIG.12may be considered an exception to the pattern illustrated by the architecture of block diagram1100ofFIG.11and may be desirable for a customer of the IaaS provider if the IaaS provider cannot directly communicate with the customer (e.g., a disconnected region). The respective containers1267(1)-(N) that are contained in the VMs1266(1)-(N) for each customer can be accessed in real-time by the customer. The containers1267(1)-(N) may be configured to make calls to respective secondary VNICs1272(1)-(N) contained in app subnet(s)1226of the data plane app tier1246that can be contained in the container egress VCN1268. The secondary VNICs1272(1)-(N) can transmit the calls to the NAT gateway1238that may transmit the calls to public Internet1254. In this example, the containers1267(1)-(N) that can be accessed in real-time by the customer can be isolated from the control plane VCN1216and can be isolated from other entities contained in the data plane VCN1218. The containers1267(1)-(N) may also be isolated from resources from other customers.

In other examples, the customer can use the containers1267(1)-(N) to call cloud services1256. In this example, the customer may run code in the containers1267(1)-(N) that requests a service from cloud services1256. The containers1267(1)-(N) can transmit this request to the secondary VNICs1272(1)-(N) that can transmit the request to the NAT gateway that can transmit the request to public Internet1254. Public Internet1254can transmit the request to LB subnet(s)1222contained in the control plane VCN1216via the Internet gateway1234. In response to determining the request is valid, the LB subnet(s) can transmit the request to app subnet(s)1226that can transmit the request to cloud services1256via the service gateway1236.

FIG.13illustrates an example computer system1300, in which various embodiments may be implemented. The system1300may be used to implement any of the computer systems described above. As shown in the figure, computer system1300includes a processing unit1304that communicates with a number of peripheral subsystems via a bus subsystem1302. These peripheral subsystems may include a processing acceleration unit1306, an I/O subsystem1308, a storage subsystem1318and a communications subsystem1324. Storage subsystem1318includes tangible computer-readable storage media1322and a system memory1310.

Processing unit1304, which can be implemented as one or more integrated circuits (e.g., a conventional microprocessor or microcontroller), controls the operation of computer system1300. One or more processors may be included in processing unit1304. These processors may include single core or multicore processors. In certain embodiments, processing unit1304may be implemented as one or more independent processing units1332and/or1334with single or multicore processors included in each processing unit. In other embodiments, processing unit1304may also be implemented as a quad-core processing unit formed by integrating two dual-core processors into a single chip.

In various embodiments, processing unit1304can execute a variety of programs in response to program code and can maintain multiple concurrently executing programs or processes. At any given time, some or all of the program code to be executed can be resident in processor(s)1304and/or in storage subsystem1318. Through suitable programming, processor(s)1304can provide various functionalities described above. Computer system1300may additionally include a processing acceleration unit1306, which can include a digital signal processor (DSP), a special-purpose processor, and/or the like.

Computer system1300may comprise a storage subsystem1318that comprises software elements, shown as being currently located within a system memory1310. System memory1310may store program instructions that are loadable and executable on processing unit1304, as well as data generated during the execution of these programs.

Depending on the configuration and type of computer system1300, system memory1310may be volatile (such as random access memory (RAM)) and/or non-volatile (such as read-only memory (ROM), flash memory, etc.) The RAM typically contains data and/or program modules that are immediately accessible to and/or presently being operated and executed by processing unit1304. In some implementations, system memory1310may include multiple different types of memory, such as static random access memory (SRAM) or dynamic random access memory (DRAM). In some implementations, a basic input/output system (BIOS), containing the basic routines that help to transfer information between elements within computer system1300, such as during start-up, may typically be stored in the ROM. By way of example, and not limitation, system memory1310also illustrates application programs1312, which may include client applications, Web browsers, mid-tier applications, relational database management systems (RDBMS), etc., program data1314, and an operating system1316. By way of example, operating system1316may include various versions of Microsoft Windows®, Apple Macintosh®, and/or Linux operating systems, a variety of commercially-available UNIX® or UNIX-like operating systems (including without limitation the variety of GNU/Linux operating systems, the Google Chrome® OS, and the like) and/or mobile operating systems such as iOS, Windows® Phone, Android® OS, BlackBerry® 13 OS, and Palm® OS operating systems.

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

Storage subsystem1300may also include a computer-readable storage media reader1320that can further be connected to computer-readable storage media1322. Together and, optionally, in combination with system memory1310, computer-readable storage media1322may comprehensively represent remote, local, fixed, and/or removable storage devices plus storage media for temporarily and/or more permanently containing, storing, transmitting, and retrieving computer-readable information.

Communications subsystem1324provides an interface to other computer systems and networks. Communications subsystem1324serves as an interface for receiving data from and transmitting data to other systems from computer system1300. For example, communications subsystem1324may enable computer system1300to connect to one or more devices via the Internet. In some embodiments communications subsystem1324can include radio frequency (RF) transceiver components for accessing wireless voice and/or data networks (e.g., using cellular telephone technology, advanced data network technology, such as 3G, 4G or EDGE (enhanced data rates for global evolution), WiFi (IEEE 802.11 family standards, or other mobile communication technologies, or any combination thereof), global positioning system (GPS) receiver components, and/or other components. In some embodiments communications subsystem1324can provide wired network connectivity (e.g., Ethernet) in addition to or instead of a wireless interface.

In some embodiments, communications subsystem1324may also receive input communication in the form of structured and/or unstructured data feeds1326, event streams1328, event updates1330, and the like on behalf of one or more users who may use computer system1300.

Communications subsystem1324may also be configured to output the structured and/or unstructured data feeds1326, event streams1328, event updates1330, and the like to one or more databases that may be in communication with one or more streaming data source computers coupled to computer system1300.