Dynamic reconfiguration of microservice test environments

Abstract

Dynamic reconfiguration of microservice test environments Processing within a computing environment is facilitated by determining a set of microservices required to execute a microservice test suite within a test environment, where the test environment is an active microservice test environment having multiple microservices. The processing also includes determining that the test environment lacks sufficient resources to execute the microservice test suite using the set of microservices, and dynamically removing at least one microservice from the test suite that is not required to execute the microservice test suite to free test environment resources for executing the microservice test suite using the set of microservices. The processing also includes starting execution of the microservice test suite within the test environment based on the dynamically removing.

Description

[Background technology]

[0001] One or more aspects relate generally to enhancing processing within a computing environment, and more particularly to dynamically reconfiguring an active microservice test environment through selectively removing one or more microservices from the test environment to free up test environment resources and facilitate the execution of microservice test suites.

[0002] In a microservices computing environment or microservices infrastructure system, applications can be written as a collection of services, or microservices, each of which can run independently and communicate with other services using an application programming interface (API).

[0003] Microservice testing is typically via a microservice test suite, which may be a collection of one or more test cases grouped for test execution, for example, to test a software program to ensure that it has one or more specified sets of functionality.

[0004] Microservice infrastructure systems, such as microservice-based cloud infrastructure systems, often include a large set of components. In production environments, these systems are hosted by large data centers with vast resource capacities. However, in testing scenarios, it is common to have only a single test environment with limited resource capacity. In certain cases, the active test environment may lack sufficient resources (e.g., nodes, memory, CPU, storage, etc.) to run all the microservices required for a particular microservice test suite. Summary of the Invention

[0005] Certain deficiencies of the prior art are overcome and additional advantages are provided herein through the provision of a computer-implemented method that facilitates processing within a computing environment. The computer-implemented method includes determining a set of microservices required to execute a microservice test suite within a test environment, the test environment being an active microservice test environment having multiple microservices, and determining that the test environment lacks sufficient resources to execute the microservice test suite using the set of microservices. The computer-implemented method further includes dynamically removing from the test environment at least one microservice of the multiple microservices that is not required to execute the microservice test suite, where dynamically removing the at least one microservice frees test environment resources to facilitate execution of the microservice test suite using the set of microservices. The process further includes starting execution of the microservice test suite within the test environment based on the dynamically removing step.

[0006] Computer systems and computer program products relating to one or more aspects are also described and claimed herein. Additionally, services relating to one or more aspects may also be described and claimed herein.

[0007] Additional features and advantages are realized through the techniques described herein. Other embodiments and aspects are described in detail herein and are considered a part of the claimed aspects. [Brief explanation of the drawings]

[0008] One or more aspects are particularly pointed out and distinctly claimed as examples in the claims at the end of this specification. The above-discussed and other aspects, features, and advantages of one or more aspects will be apparent from the following detailed description when taken in conjunction with the accompanying drawings.

[0009] [Figure 1] 1 illustrates an example computing environment that may include and / or use one or more aspects of the present invention.

[0010] [Figure 2] 1 illustrates one embodiment of a computer program product having a microservices test environment reconfiguration and execution module in accordance with one or more aspects of the present invention.

[0011] [Figure 3] 1 illustrates one embodiment of a microservice test environment reconfiguration and execution process in accordance with one or more aspects of the present invention.

[0012] [Figure 4] 10 illustrates further examples of computing environments that may include and / or use one or more aspects of the present invention.

[0013] [Figure 5A] 1 illustrates a further embodiment of a microservices test environment reconfiguration and execution workflow in accordance with one or more aspects of the present invention. [Figure 5B] 1 illustrates a further embodiment of a microservices test environment reconfiguration and execution workflow in accordance with one or more aspects of the present invention. [Figure 5C] 1 illustrates a further embodiment of a microservices test environment reconfiguration and execution workflow in accordance with one or more aspects of the present invention. DETAILED DESCRIPTION OF THE INVENTION

[0014] The accompanying drawings, which are incorporated in and form a part of this specification, further illustrate aspects of the present invention and, together with this detailed description of the present invention, serve to explain aspects of the present invention. In this regard, it should be noted that descriptions of well-known systems, devices, processing techniques, etc. have been omitted so as not to unnecessarily obscure detailed aspects of the present invention. It should be understood, however, that the detailed description and its specific examples, while illustrating aspects of the present invention, are presented by way of illustration only and not limitation. Various substitutions, modifications, additions, and / or other arrangements within the spirit or scope of the underlying inventive concept will become apparent to those skilled in the art from this disclosure. It should be further noted that, while multiple aspects or features of the present invention are disclosed herein, and, to the extent not inconsistent, each disclosed aspect or feature can be combined with any other disclosed aspect or feature as desired for a particular application of the disclosed concept.

[0015] It should also be noted that exemplary embodiments are described below by way of example only, and not by way of limitation, using particular code, designs, architectures, protocols, layouts, schematics, or tools. Furthermore, exemplary embodiments are described in particular cases using particular software, hardware, tools, or data processing environments, by way of example only, for clarity of explanation. The exemplary embodiments may be used in conjunction with other comparable or similarly purposed structures, systems, applications, or architectures. One or more aspects of the exemplary embodiments may be implemented in hardware, software, or a combination thereof.

[0016] As will be appreciated by those skilled in the art, program code referred to herein may include software and / or hardware. For example, program code in certain embodiments of the present invention may utilize software-based implementations of the described functionality, while other embodiments may include fixed-function hardware. In certain embodiments, both types of program code are combined. An example of program code, also referred to as one or more programs, including operating system 122 and microservices test environment reconfiguration and execution module 200 stored in persistent storage 113 is shown in FIG. 1.

[0017] One or more aspects of the present invention may be incorporated into, executed by, and / or used by a computing environment. By way of example, the computing environment may be or include environments of various architectures and types, including, but not limited to, personal computing, client-server, distributed, virtual, emulated, partitioned, non-partitioned, cloud-based, quantum, grid, time-sharing, cluster, peer-to-peer, mobile, those having one node or multiple nodes, those having one processor or multiple processors, and / or any other type of environment and / or configuration capable of executing a process (or processes) that performs, for example, microservice test environment reconfiguration and test execution initiation processing as disclosed herein. Aspects of the present invention are not limited to a particular architecture or environment.

[0018] Before further describing detailed embodiments of the present invention, an example of a computing environment that may include and / or use one or more aspects of the present invention is discussed below with reference to FIG.

[0019] Various aspects of the present disclosure are described through text, flowcharts, block diagrams of computer systems, and / or block diagrams of machine logic included in computer program product (CPP) embodiments. For any flowchart, depending on the technology involved, operations may be performed in an order different from that shown in a given flowchart. For example, depending again on the technology involved, two operations shown in successive flowchart blocks may be performed in the reverse order, as a single integrated step, simultaneously, or in an at least partially overlapping manner.

[0020] A computer program product embodiment ("CPP embodiment" or "CPP") is a term used in this disclosure to describe any set of one or more storage media (also referred to as "media") collectively contained in one or more storage devices that collectively contain machine-readable code corresponding to instructions and / or data for performing the computer operations specified in a given CPP claim. A "storage device" is any tangible device that can hold and store instructions for use by a computer processor. The computer-readable storage medium may be, but is not limited to, an electronic storage medium, a magnetic storage medium, an optical storage medium, an electromagnetic storage medium, a semiconductor storage medium, a mechanical storage medium, or any suitable combination of the foregoing. Some known types of storage devices that include these media include diskettes, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), compact disc read-only memory (CD-ROM), digital versatile disk (DVD), memory stick, floppy disk, mechanically encoded devices (such as punch cards or pits / lands formed on a major surface of a disk), or any suitable combination of the foregoing. Computer-readable storage media, as the term is used in this disclosure, is not to be construed as storage in the form of transitory signals per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide, light pulses passing through fiber optic cables, electrical signals communicated through wires, and / or other transmission media.As will be appreciated by those skilled in the art, data is typically moved at some infrequent time during the normal operation of a storage device, such as during access, defragmentation, or garbage collection, but this does not make the storage device temporary because the data is not temporary while it is stored.

[0021] Computing environment 100 includes an example of an environment for execution of at least a portion of computer code involved in performing the methodology of the present invention, such as microservices test environment reconfiguration and execution module block 200. In addition to block 200, computing environment 100 includes, for example, computer 101, wide area network (WAN) 102, end user device (EUD) 103, remote server 104, public cloud 105, and private cloud 106. In this embodiment, computer 101 includes processor set 110 (including processing circuitry 120 and cache 121), communication fabric 111, volatile memory 112, persistent storage 113 (including operating system 122 and block 200, as identified above), peripheral device set 114 (including user interface (UI), device set 123, storage 124, and Internet of Things (IoT) sensor set 125), and network module 115. Remote server 104 includes remote database 130. The public cloud 105 includes a gateway 140, a cloud orchestration module 141, a set of host physical machines 142, a set of virtual machines 143, and a set of containers 144.

[0022] Computer 101 may take the form of a desktop computer, a laptop computer, a tablet computer, a smartphone, a smartwatch or other wearable computer, a mainframe computer, a quantum computer, or any other form of computer or mobile device now known or later developed that is capable of executing programs, accessing a network, or querying a database, such as remote database 130. As is well understood in the field of computer technology, and depending on the technology, performance of a computer-implemented method may be distributed among multiple computers and / or multiple locations. However, in this presentation of computing environment 100, to keep the presentation as simple as possible, the detailed discussion focuses on a single computer, specifically computer 101. Although computer 101 is not shown in FIG. 1 within a cloud, it may be located within a cloud. However, computer 101 is not required to reside within a cloud except to any extent that may be expressly indicated.

[0023] Processor set 110 includes one or more computer processors of any type now known or to be developed in the future. Processing circuitry 120 may be distributed across multiple packages, e.g., multiple tailored integrated circuit chips. Processing circuitry 120 may implement multiple processor threads and / or multiple processor cores. Cache 121 is memory located within the processor chip package and is typically used for data or code that should be available for fast access by threads or cores executing on processor set 110. Cache memory is typically organized into multiple levels depending on relative proximity to the processing circuitry. Alternatively, some or all caches for a processor set may be located “off-chip.” In some computing environments, processor set 110 may be designed to operate with qubits and perform quantum computing.

[0024] Computer-readable program instructions are typically loaded onto computer 101 and cause processor set 110 of computer 101 to execute a series of operational steps, thereby enabling a computer-implemented method, such that the instructions so executed instantiate the methods specified in the computer-implemented method flowcharts and / or descriptions contained herein (collectively referred to as the "methods of the present invention"). These computer-readable program instructions are stored in various types of computer-readable storage media, such as cache 121 and other storage media discussed below. The program instructions and associated data are accessed by processor set 110 to control and direct the execution of the methods of the present invention. In computing environment 100, at least a portion of the instructions for executing the methods of the present invention may be stored in block 200 within persistent storage 113.

[0025] Communications fabric 111 is the signal-conducting pathway that allows various components of computer 101 to communicate with one another. Typically, this fabric is made up of switches and conductive pathways, such as those that make up buses, bridges, physical input / output ports, and the like. Other types of signal communication pathways may be used, such as fiber optic and / or wireless communication pathways.

[0026] Volatile memory 112 may be any type of volatile memory now known or later developed. Examples include dynamic random access memory (RAM) or static RAM. Typically, volatile memory is characterized by random access, although this is not required unless expressly stated. In computer 101, volatile memory 112 is located in a single package and is internal to computer 101; however, alternatively or additionally, volatile memory may be distributed across multiple packages and / or located external to computer 101.

[0027] Persistent storage 113 is any form of non-volatile storage for a computer, now known or later developed. The non-volatility of this storage means that stored data is maintained regardless of whether power is supplied to computer 101 and / or to persistent storage 113 directly. While persistent storage 113 can be read-only memory (ROM), typically at least a portion of persistent storage allows data to be written, data to be deleted, and data to be rewritten. Some well-known forms of persistent storage include magnetic disks and solid-state storage devices. Operating system 122 can take several forms, including various known proprietary operating systems or open-source Portable Operating System Interface-type operating systems that employ a kernel. The code contained in block 126 typically includes at least a portion of the computer code involved in performing the methods of the present invention.

[0028] The peripheral device set 114 includes a set of peripheral devices of the computer 101. Data communication connections between the peripheral devices and other components of the computer 101 can be implemented in various ways, such as Bluetooth connections, Near-Field Communication (NFC) connections, connections made by cable (such as a universal serial bus (USB)-type cable), insertion-type connections (e.g., a secure digital (SD) card), connections made through a local area communication network, and even connections made through a wide area network such as the Internet. In various embodiments, the UI device set 123 can include components such as a display screen, speakers, microphones, wearable devices (such as goggles and smartwatches), keyboards, mice, printers, touchpads, game controllers, and haptic devices. The storage 124 can be external storage, such as an external hard drive, or insertable storage, such as an SD card. The storage 124 can be persistent and / or volatile. In some embodiments, storage 124 may take the form of a quantum computing storage device for storing data in the form of qubits. In embodiments where computer 101 is required to have a large amount of storage (e.g., where computer 101 stores and manages large databases locally), this storage may then be provided by a peripheral storage device designed to store very large amounts of data, such as a storage area network (SAN) shared by multiple geographically distributed computers. IoT sensor set 125 is made up of sensors that may be used in Internet of Things applications. For example, one sensor may be a thermometer and another may be a motion detector.

[0029] Network module 115 is a collection of computer software, hardware, and firmware that enables computer 101 to communicate with other computers over WAN 102. Network module 115 may include hardware such as a modem or Wi-Fi signal transceiver, software for packetizing and / or depacketizing data for communication network transmission, and / or web browser software for communicating data over the Internet. In some embodiments, the network control and network forwarding functions of network module 115 are performed on the same physical hardware device. In other embodiments (e.g., embodiments utilizing Software-Defined Networking (SDN)), the control and forwarding functions of network module 115 are performed on physically separate devices, such that the control function manages multiple different network hardware devices. Computer-readable program instructions for implementing the methods of the present invention may be downloaded to computer 101, typically from an external computer or external storage device, through a network adapter card or network interface included in network module 115.

[0030] WAN 102 is any wide area network (e.g., the Internet) capable of communicating computer data over non-local distances by any now known or later developed technology for communicating computer data. In some embodiments, a WAN may be replaced and / or supplemented by a local area network (LAN) designed to communicate data between devices located in a local area, such as a Wi-Fi network. WANs and / or LANs typically include copper transmission cables, optical fiber transmissions, wireless transmissions, and computer hardware such as routers, firewalls, switches, gateway computers, and edge servers.

[0031] End-user device (EUD) 103 is any computer system used and controlled by an end user (e.g., a customer of the enterprise operating computer 101) and may take any of the forms discussed above in connection with computer 101. EUD 103 typically receives useful and useful data from the operation of computer 101. For example, in a hypothetical case where computer 101 is designed to provide recommendations to the end user, the recommendations would typically be communicated from computer 101's network module 115 over WAN 102 to EUD 103. In this manner, EUD 103 can display or otherwise present the recommendations to the end user. In some embodiments, EUD 103 may be a client device, such as a thin client, a heavy client, a mainframe computer, a desktop computer, and the like.

[0032] Remote server 104 is any computer system that provides at least some data and / or functionality to computer 101. Remote server 104 may be controlled and used by the same entity that operates computer 101. Remote server 104 represents a machine that collects and stores useful and useful data for use by other computers, such as computer 101. For example, in the hypothetical case where computer 101 is designed and programmed to provide recommendations based on past data, then this past data may be provided to computer 101 from remote database 130 of remote server 104.

[0033] A public cloud 105 is any computer system available for use by multiple entities that provides on-demand availability of computer system resources and / or other computer functionality, particularly data storage (cloud storage) and computing power, without direct active management by users. Cloud computing typically leverages resource sharing to achieve coherence and economies of scale. Direct active management of the computing resources of the public cloud 105 is performed by computer hardware and / or software in a cloud orchestration module 141. The computing resources provided by the public cloud 105 are typically implemented by virtual computing environments running on various computers comprising a host physical machine set 142, which is the universe of physical computers within and / or available in the public cloud 105. A virtual computing environment (VCE) typically takes the form of virtual machines from a virtual machine set 143 and / or containers from a container set 144. It is understood that these VCEs may be stored as images and transferred among and between various hosts of physical machines either as images or after instantiation of the VCE. Cloud orchestration module 141 manages the transfer and storage of images, deploys new instantiations of VCEs, and manages active instantiations of VCE deployments. Gateway 140 is a collection of computer software, hardware, and firmware that enables public cloud 105 to communicate over WAN 102.

[0034] Some further description of a virtualized computing environment (VCE) is now provided. A VCE can be stored as an "image." A new active instance of a VCE can be instantiated from an image. Two well-known types of VCE are virtual machines and containers. A container is a VCE that uses operating system-level virtualization. This refers to a feature of an operating system in which the kernel allows the existence of multiple isolated user space instances called containers. These isolated user space instances typically behave as actual computers from the perspective of programs running within them. A computer program running on a typical operating system can utilize all of the computer's resources, such as connected devices, files and folders, network shares, CPU power, and quantifiable hardware capabilities. However, a program running inside a container can only use the contents of the container and of the devices assigned to the container; this feature is known as containerization.

[0035] A private cloud 106 is similar to a public cloud 105, except that its computing resources are available only for use by a single enterprise. While the private cloud 106 is shown in communication with the WAN 102, in other embodiments, the private cloud may be completely disconnected from the Internet and accessible only through a local / private network. A hybrid cloud is a composite of multiple clouds of different types (e.g., private, community, or public cloud types), often each implemented by a different vendor. While each of the multiple clouds remains a separate, discrete entity, the larger hybrid cloud architecture is bound together by standardized or proprietary technologies that enable orchestration, management, and / or data / application portability between the constituent clouds. In this embodiment, both the public cloud 105 and the private cloud 106 are part of a larger hybrid cloud.

[0036] The computing environment described above is merely one example of a computing environment that may incorporate, execute, and / or use one or more aspects of the present invention. Other examples are possible. Furthermore, in one or more embodiments, one or more of the components / modules of FIG. 1 need not be included in the computing environment and / or may not be used for one or more aspects of the present invention. Furthermore, in one or more embodiments, additional and / or other components / modules may be used. Other variations are possible.

[0037] By way of example, one or more embodiments of a microservice test environment reconfiguration and execution module and process will first be described with reference to Figures 2-3. Figure 2 illustrates one embodiment of a microservice test environment reconfiguration and execution module 200 that includes code or instructions for performing processing in accordance with one or more aspects of the present invention, and Figure 3 illustrates one embodiment of a microservice test environment reconfiguration and execution process in accordance with one or more aspects of the present invention.

[0038] 1 and 2, microservice test environment reconfiguration and execution module 200, in one example, includes various sub-modules used to perform processing in accordance with one or more aspects of the present invention. The sub-modules are, for example, computer-readable program code (e.g., instructions) and computer-readable media (e.g., persistent storage (e.g., persistent storage 113, such as a disk) and / or cache (e.g., cache 121), as examples). The computer-readable media may be part of a computer program product, which may be executed by and / or using one or more computers, such as computer 101; a processor, such as a processor in processor set 110; and / or processing circuitry, such as processing circuitry in processor set 110.

[0039] In the embodiment of FIG. 2, example submodules of the microservice test environment reconfiguration and execution module 200 include, for example, a test suite microservice submodule 202 for determining a set of microservices required to execute a microservice test suite within a test environment, where the test environment is an active microservice test environment having multiple active microservices; a test environment resource submodule 204 for determining that the test environment lacks sufficient resources to execute a microservice test suite using the set of microservices; a microservice removal submodule 206 for dynamically removing at least one microservice of the multiple microservices from the test environment that is not required to execute the microservice test suite, where dynamically removing the microservice frees up test environment resources to facilitate execution of the microservice test suite using the set of microservices (and, optionally, where dynamically removing the microservice includes generating a data structure identifying the at least one microservice that was dynamically removed from the test environment to free up test environment resources); and an execute microservice test suite submodule 208 for initiating execution of the microservice test suite within the test environment based on the dynamic removal of the microservice. Additionally, in one or more implementations, the microservice test environment reconfiguration and execution module 200 may include a performance testing submodule 210 to, for example, facilitate iteratively and dynamically removing different available microservices from a plurality of active microservices in the test environment while executing the microservice test suite to determine optimal resource allocation for scaling up the microservice test suite in the test environment for performance testing.Advantageously, the microservice test environment reconfiguration and execution process disclosed herein takes an active microservice test environment and reconfigures it to accommodate the execution of a microservice test suite, even though prior to the reconfiguration, the environment may have had insufficient capacity to execute the requisite resources for the test suite. While various sub-modules are described, it should be noted that the microservice test environment reconfiguration and execution module process as disclosed herein may use or include additional, fewer, and / or different sub-modules. Particular sub-modules may include additional code, including code from other sub-modules, or less code. Furthermore, additional and / or other modules may be used. Many variations are possible.

[0040] In one or more embodiments, sub-modules are used to perform the microservice test environment reconfiguration and execution process in accordance with one or more aspects of the present invention. FIG. 3 illustrates one example of such a process. In one or more examples, the process is performed by a computer (e.g., computer 101 (FIG. 1)) and / or a processor or processing circuit (e.g., of processor set 110 of FIG. 1). In one example, code or instructions implementing the process are part of a module such as microservice test environment reconfiguration and execution module 200. In other examples, the code may be included in one or more other modules and / or in one or more sub-modules of the one or more other modules. Various options are available.

[0041] As one example, a microservice test environment reconfiguration and execution process 300 executing on a computer (e.g., computer 101 in FIG. 1 ), a processor (e.g., a processor in processor set 110 in FIG. 1 ), and / or a processing circuit (e.g., a processing circuit in processor set 110) determines 302 a set of microservices required to execute a microservice test suite within the test environment and determines 304 whether the microservice test environment lacks sufficient resources to execute the test suite using the set of microservices; i.e., the process determines or detects available resources within the microservice test environment for executing the microservice test suite. In one or more implementations, the test environment is an active microservice test environment with multiple actively running microservices, which is a more constrained environment than the production environment in which the microservices under test will execute in their end-use. The process further includes dynamically removing 306 one or more microservices from the active microservice test environment, which may include dynamically identifying and removing one or more unnecessary microservices from the test environment and / or removing one or more explicitly pointed, optional microservices from the test environment, for example, identified via a data structure associated with the microservice test suite. For example, in one embodiment, the test suite identifies certain microservices that are essential for executing the test suite and other non-essential microservices that may be optionally removed to facilitate execution of the test suite within the available test environment. In one or more embodiments, along with removing at least one microservice of the plurality of microservices that is not necessary for executing the microservice test suite from the active microservice test environment, the process generates a data structure that identifies the at least one microservice that was removed from the test environment to free up test environment resources and facilitate execution of the microservice test suite.The microservice test suite is deployed to the test environment and one or more test cases of the test suite are executed 308 within the reconfigured microservice test environment, which, in one or more embodiments, may include generating a test results report that identifies one or more microservices that were dynamically removed from the test environment to facilitate running the microservice test suite with the required set of microservices.

[0042] In one or more implementations, the microservice test environment reconfiguration and execution process 300 may optionally further include dynamically configuring the test environment to facilitate microservice test suite performance testing 310. In one embodiment, this may include iteratively dynamically removing different available microservices from the active microservice test environment while executing the microservice test suite to determine optimal resource allocation for scaling up the microservice test suite for performance testing. In one or more other embodiments, the process may iteratively run the microservice test suite execution to dynamically identify and update the list of microservices required to run the microservice test suite.

[0043] As described, microservices-based infrastructure systems, such as cloud infrastructure systems, often include a large set of components. In production, these systems are hosted by large data centers with enormous capacity. However, in testing scenarios, it is common to have only a single, constrained microservice test environment with limited capacity. A problem with having a limited test environment is that there may not be enough resources (e.g., nodes, memory, CPU, storage, etc.) to execute all the microservices required for a particular microservice test suite. Typically, microservice test cases may be deployed to a microservice test environment and executed on a subset of running services, rather than requiring all microservices that are running or active. Advantageously, computer-implemented methods, computer systems, and computer program products are disclosed herein for facilitating automatically configuring or adjusting an active test environment to facilitate execution of a microservice test suite with a required set of microservices.

[0044] In one embodiment, the microservice test environment reconfiguration and execution process creates a test dependency definition of the microservices (e.g., resources) required for the test suite (e.g., CPU, memory, dependent microservices, or additional resources in the environment such as other microservices, pods, services, configmaps, ingresses, etc.). The definition may include a list of required or essential microservices that cannot be evacuated or removed during the execution of the entire test. The definition may include a RemoveOptionalResourcesFlag, which may be used to ensure that only essential microservices are running in the test environment during the test, so that one or more types of microservices may be completely removed from the test environment for that test.

[0045] In one or more implementations, the disclosed microservice test environment reconfiguration and execution process allows microservices not utilized in a test pass to be safely removed (e.g., deactivated, removed, evacuated), while allowing the restoration or re-establishment of the microservice test environment that existed before the dynamic removal of one or more microservices after testing is complete. Advantageously, this allows intensive local testing of microservices designed to run on cloud infrastructure systems to be scheduled on a single active microservice test environment with limited resource capacity. After testing is complete, the removed or removed microservices or resources are restored for the next microservice test suite. Aspects of the present invention further enable test execution with repeated removal of optional resources so that performance scaling can be performed as part of the testing.

[0046] In one or more embodiments, the microservice test environment reconfiguration and execution process disclosed herein, in addition to creating test dependency definitions for microservices required for the test suite to run, further includes creating a separate list of environment-required resources required for the test environment itself, independent of the test suite (e.g., API server, Vault); this list is added to the set of required microservices that cannot be removed. Furthermore, certain microservices may need to maintain state; these microservices are also added to the list of microservices required for running the microservice test suite. As part of running a microservice test suite, one or more microservices not in the list of required microservices may be removed as needed based on the resource requirements for the microservice test suite to run. For example, if there is insufficient CPU to run one or more test cases in the test suite, certain microservices not in the list of required microservices may be dynamically removed so that the tests can run successfully in the active test environment. Furthermore, if the RemoveOptionalResourcesFlag is set, which forces the removal of any optional microservices, all optional microservices currently active in the test environment are automatically removed. After the microservice test suite has completed successfully within the test environment, the deleted microservice is restored for the next execution of the microservice test suite within the test environment.

[0047] In one or more aspects, the microservice test environment reconfiguration and execution process further includes generating a report that identifies which microservices have been removed in order for the microservice test suite to be executed. Additionally, in one or more embodiments, the process may be executed as a dry run, where an actual test suite is not executed; rather, the process verifies that resource requirements have been determined and provides a report that indicates which microservices will be removed in order for the microservice test suite to be executed in the test environment.

[0048] In one or more embodiments, if a required microservice is removed and one or more test cases in the test suite fail to complete execution, this may be captured so that the test dependency definition can be updated to include the identified required microservice. Optionally, the process may also automatically add the newly revealed required microservice to the requirements list for running the microservice test suite and automatically re-run the test. If the test is repeated and a new dependency list is detected, this is reported back so that the definition of the microservices required to run the microservice test suite can be updated. If the test suite cannot be run because there is no combination of microservices that can be removed from the active test environment and still satisfy the list of required microservices, this may also be reported, for example, to a user of the system.

[0049] Advantageously, the microservice test environment reconfiguration and execution process disclosed herein enables a microservice test suite to be executed in a single active microservice test environment in which the test suite could not otherwise be executed. For example, to fit a particular microservice test suite into an active test environment, the microservices required for the test are determined, thereby optimizing actual resource consumption for the test suite's execution, thereby facilitating execution of the test suite within a single active test environment with constrained resource capacity (i.e., compared to an end-use production environment). The process disclosed herein also provides a mechanism for explicitly removing optional resources for a particular test so that necessary microservices can use the full resource capacity of the test environment for scale / performance testing. Advantageously, the process disclosed herein does not affect existing deployments, as it dynamically removes and restores microservices from the test environment in the process. The combination of running microservices may change as different test suites are executed in the environment, but upon completion, the environment is restored to its normal state or the state at the start of the microservice deployment. Additionally, in one or more embodiments, the processes disclosed herein can be used to verify whether a test suite can be executed within a microservice test environment and adjust active microservices within the environment as needed to accommodate different test cases. This allows for better management of resources within the test environment. In one embodiment, the disclosed processes include an automatic error reconciliation facility for correcting failures caused by unexpected microservice removal, for example, in the case of an unknown microservice dependency required to run a particular microservice test case. In one or more implementations, aspects of the present invention can be used within a microservice test environment. For example, the processes can be used across multiple control planes of the environment to reduce development test environment requirements.

[0050] By way of further explanation, Figure 4 illustrates another embodiment of a computing environment or system 400 that may incorporate or implement one or more aspects of an embodiment of the present invention. In one or more implementations, system 400 is implemented as part of a computing environment, such as computing environment 100 described above in connection with Figure 1. System 400 includes one or more computing resources 410 that execute program code 412 that implements one or more aspects of a module or mechanism as disclosed herein, such as, for example, microservices test environment reconfiguration and execution module 200.

[0051] In computing environment 400, one or more microservice test suites 420, each containing one or more test cases, will be executed in a constrained active microservice test environment 430, such as a clustered test environment. For example, in one or more embodiments, microservice test suite 420 includes specific test cases for functional testing of a microservice intended to run, for example, in a cloud-based runtime or production environment.

[0052] In one or more embodiments, the microservice test environment reconfiguration and execution module 200 determines a set of microservices required to execute a microservice test suite within the test environment 430 and determines the available resource capacity of the active test environment, i.e., whether the active test environment lacks sufficient resources to execute the microservice test suite with the required set of microservices. Furthermore, the microservice test environment reconfiguration and execution module 200 dynamically removes one or more microservices from the active test environment that are not required to execute the microservice test suite, freeing up test environment resources by dynamically removing them to facilitate execution of the microservice test suite with the required set of microservices. The microservice test environment reconfiguration and execution module 200 then deploys the microservice test suite to the test environment and begins execution of the microservice test suite within the test environment based on the dynamic removal of microservices from the test environment. Optionally, a test execution report may be generated based on executing the microservice test suite within the test environment. In one or more embodiments, the test execution report may include an indication of whether sufficient resources were available within the test environment to fully execute the microservice test suite, i.e., whether all microservices required for test suite execution were available within the microservice test environment.

[0053] System 400 may include or utilize one or more networks for interfacing various aspects of the system, including, for example, a database including one or more microservice test suites 420, computing resources 410, and one or more active microservice test environments 430. By way of example, the network may be, for example, a telecommunications network, a local-area network (LAN), a wide-area network (WAN) such as the Internet, or a combination thereof, and may include wired, wireless, fiber optic connections, etc. The network may include one or more wired and / or wireless networks capable of receiving and transmitting data, as discussed herein.

[0054] In one or more implementations, the computing resource 410 houses and / or executes program code 412 configured to perform processes in accordance with one or more aspects of the present invention. By way of example, the computing resource 410 may be a computing system-implemented resource. Furthermore, for illustrative purposes only, the computing resource 410 in FIG. 4 is depicted as a single computing resource separate from the microservice test suite database and test environment. This is one non-limiting example implementation. In one or more other implementations, the microservice test suite 420 and / or the active microservice test environment 430 may execute on the same computing resource 410 as the microservice test environment reconfiguration execution module 200. In one or more further implementations, one or more aspects of the microservice test environment reconfiguration and execution module 200 may be implemented, at least in part, on multiple separate computing resources or systems.

[0055] Briefly, in one embodiment, the computing resources 410 may include a processor, e.g., one or more central processing units (CPUs). The processor may also include functional components used in integrating program code, such as functional components for fetching program code from a location such as in a cache or main memory, decoding and executing the program code, accessing memory for instruction execution, and writing results of executed instructions or code. The processor may also include registers to be used by one or more of the functional components. In one or more embodiments, the computing resources may include memory, input / output, network interfaces, and storage, which may include and / or access one or more other computing resources and / or databases as required to implement the machine learning processes described herein. The components of each computing resource may be coupled to each other via one or more buses and / or other connections. The bus connection may be one or more of any of several types of bus structures, including a memory bus or memory controller, a peripheral bus, an accelerated graphics port, and a processor or local bus, using any of a variety of architectures. By way of example and not limitation, such architectures may include Industry Standard Architecture (ISA), micro-channel architecture (MCA), enhanced ISA (EISA), Video Electronic Standard Association (VESA), a local bus, and a peripheral component interconnect (PCI).As mentioned, examples of computing resources or computer systems that may implement one or more aspects disclosed are further described herein with reference to the figures.

[0056] In one or more implementations, the microservice test environment reconfiguration and execution process disclosed herein determines the set of microservices or resources required to execute a microservice test suite. This may include evaluating the microservice test suite, including any microservice dependency chains within the test. The process further includes determining or detecting that insufficient resources are available in the current active test environment to successfully execute the microservice test suite using the required microservices. Based on this, one or more optional resources or microservices are removed from the test environment, where one or more microservices may be dynamically determined and / or explicitly listed (e.g., in the microservice test suite). In one or more embodiments, the microservice test suite is then deployed to the test environment, resulting in the execution of a test plan within the test environment. This test plan execution, in one embodiment, may be either a dry run or an actual execution of the microservice test suite. In a dry run scenario, the test cases themselves are not executed; rather, the process determines the resources required to execute the test suite. A test results report may be generated that includes which microservices or resources were evacuated to run the microservice test suite, and in one embodiment, the test plan for the microservice test suite may be automatically updated with any additional microservices required to run the test suite. In one or more embodiments, the process may repeat the test run to dynamically update the microservices required to run the test suite and update the test suite list of required services.

[0057] As one example, when a new feature is developed and new resources need to be deployed and tested in a test case, the new feature may require spinning up a new microservice (e.g., a new pod or software server) to support the feature. The new microservice may not fit into the existing active test environment. In this example, the required microservice or resource is added to the microservice test plan, and the test case is submitted to the system for analysis. The system (or a microservice test environment reconfiguration and execution module or mechanism) determines that the new microservice required for the feature to be tested cannot be executed within the current active test environment. Based on this, the system dynamically removes one or more microservices or resources that are not essential for executing the microservice test suite, such as monitoring microservices (e.g., SYSDIG, LOGDNA, etc.). The test suite is executed, after which the microservice resources added for the new feature are removed from the test environment, and the previously removed microservices in the test environment are restored to the test environment. Note that the list of optional microservices may be determined by comparing the input required microservice list of the test suite against the microservices available in the test environment. For example, the monitoring / logging resources mentioned, such as SYSDIG and LOGDNA, may not be listed in the required microservices list and are therefore candidates for removal. Another example is when testing a networking microservice, where existing storage-related microservices may not be listed as required.

[0058] As another example, when performance testing is required, certain services or pods may be required for test cases that require a large amount of resources (e.g., CPU and / or memory) to run large-scale performance tests. For test isolation, all services not in the required microservices list for the test case are dynamically removed, allowing the required services to scale up and consume more CPU and / or memory when the test case runs. Thus, in this use case, all microservices not in the required microservices list for the test suite will be removed, which may result in one or more types of microservices being removed entirely. In one embodiment, the process of removing all microservices not required to run the test plan may be indicated by the "RemoveOptionalResourcesFlag" being equal to true. A test case is submitted to the system, and the system removes all test environment resources not in the list of microservices required for that test case, thereby freeing up the maximum possible resources in the test environment. The test suite is executed (in one embodiment), and then any microservices added for the test suite performance testing are removed from the test environment, and any previously removed microservices in the active test environment are restored, i.e., restarted. In this use plan, the microservice test environment configuration and execution process temporarily removes all optional microservices to optimize performance testing, even though they may be run simultaneously with the microservices required for the test suite.

[0059] One or more aspects of the dynamic reconfiguration of a microservice test environment disclosed herein encompass a method for facilitating testing of microservices in a resource-constrained environment by dynamically removing one or more active microservices that are not essential for testing. Generally, the process obtains a test suite, which is a set of tests that need to be executed on the resource-constrained environment. Typically, the tests in the test suite are related and test a subset of the overall system's functional capabilities. In traditional systems, the test suite interacts directly with the test environment to initiate test execution. In this disclosure, the test suite first interacts with a microservice test environment reconfiguration and execution mechanism or module to determine whether the test environment can execute the tests and whether any microservices need to be removed before executing the tests. The test environment is a resource-constrained environment in which multiple microservices belonging to the system under test, such as all of the system's microservices, are running. In a normal sequence of operation, a test environment may fail due to a particular microservice occupying too many CPU / memory or other resources, or due to an attempt to run too many microservices, resulting in one or more of the microservices not running due to CPU / memory or other resource constraints. Advantageously, the microservice test environment reconfiguration execution mechanism or module disclosed herein determines which microservices are essential for running tests and the resource capacity of the test environment, and, if necessary, removes one or more active microservices from the test environment as needed, deploys microservice tests to the test environment, restores the removed resources, and generates, for example, a test execution report.

[0060] 5A-5C illustrate a further embodiment of a microservice test environment reconfiguration and execution workflow 500 according to one or more aspects of the present invention. In workflow 500, the main flow and database access are indicated separately. Test-required microservices 501 are part of the test dependency definition of resources required for the test suite (e.g., CPU, memory, dependent microservices, additional resources in the test environment, such as pods, services, configmaps, ingress, etc.). The definition includes a list of required microservices that cannot be evacuated during the entire test execution. Furthermore, in one or more embodiments, the definition may include a RemoveOptionalResourcesFlag 504, which may be used to ensure that only required resources are executed in the test environment during a particular test. Additionally, in one embodiment, environment-required microservices 502, which are resources required for the test environment itself independent of the test suite (e.g., API server, Vault), are identified in the list, and this list may be added to a list of microservices that should not be removed. Furthermore, stateful microservices 503 may be a list of resources for which state may need to be maintained. These also cannot be removed and are added to the list or set of microservices required to run the microservice test suite.

[0061] A single dependent microservices list 510 is created that identifies the requirements for attempting to successfully execute the current test suite within the test environment. In one embodiment, this single dependent microservices list is stored in a required microservices database 511. A list of available resources is also collected 512, for example, from the test environment. This includes information about which microservices will run in the test environment and what the CPU and / or memory configurations for the microservices in that environment are. In one embodiment, the available microservices list can be stored in an available microservices database 513 for use by the process.

[0062] In one or more embodiments, the process determines 520 whether the microservice requirements are satisfied, which may include comparing the dependent microservice list from required microservices database 511 with the available microservice list from database 513 to verify whether all microservice requirements for running the test suite are satisfied. If the requirements are not satisfied, the process determines 522 whether there are any optional microservices that can be removed to satisfy the resource requirements. If so, in one embodiment, the removal microservice list is updated with the identification of the microservice for storage in removal microservice list or database 525. Note that RemoveOptionalResourcesFlag 504 may be considered here to determine which resources may still need to be added to the list for removal. If no optional microservices remain, the process updates 526 reports, such as user reports, and terminates 528 the workflow.

[0063] Assuming the requirements are met, in this case, the process determines 530 whether this is a dry run request. If yes, a report is generated 532 stating that the requirements are met, including identifying which microservices will be removed, and the workflow terminates 534. If this is not a dry run, the process determines 540 whether microservices need to be removed. If yes, all microservices in the removal microservices list or database 525 are removed from the test environment 542, and an actual test run occurs 544. If no microservices need to be removed, a test run 544 occurs. In one embodiment, when the test environment or test harness takes over test execution, the test environment determines whether the tests in the test suite pass or fail. Once the testing is complete, the workflow 500 includes determining 550 whether microservices were removed to facilitate the execution of the test suite, and if yes, the removed microservices are restored to the test environment 552. Otherwise, the process determines 554 whether the test run of the test suite was successful, meaning all resources required to run the tests were present. If no, one or more required microservices are not available, a report 556 (e.g., a report to the user) is generated or updated, and the required microservices list is also updated 558, which is stored back in the required microservices database 511. Otherwise, after a successful test run 554, a results report is generated 532, after which the process terminates the workflow 534.

[0064] The previously described use cases illustrate the above workflow. In the first test case, a new feature is being tested. A new feature is being developed, and new resources (e.g., microservices) need to be deployed and tested in the test case. The new feature requires spinning up a new pod or service to support the feature, which may not fit into the existing test environment and may result in the removal of one or more running microservices, as described herein. In this case, the resources needed to execute the test plan are identified, and the test plan is submitted to the system. If the system determines that the new microservice cannot be created within the existing system configuration, it spins down, i.e., removes, one or more active microservices (e.g., pods, servers, etc.) marked as optional in the test case. This process continues until there are sufficient resources in the test environment to execute the new microservice test. Once the required resources are available to execute the microservice test suite, the microservice test environment reconfiguration and execution mechanism then begins executing the tests.

[0065] Another use case disclosed herein is functional performance testing. Performance testing is necessary when a microservice in a test case requires, for example, greater limits (CPU and / or memory) to run the performance test. For test isolation, any microservices on the list of optional microservices are removed, which can generate the most accurate performance metrics for the test. Therefore, in this use case, all unnecessary microservices are removed. For example, when running performance tests on microservices for flight services, billing microservices do not need to run, and they can be spun down to eliminate them and reduce the load on the test environment. In this use case, all microservices other than those labeled as essential by the microservice test suite are removed or evacuated, for example, by setting RemoveOptionalResourcesFlag to true.

[0066] In another use case, the workflows discussed herein are applied to an existing functional test suite. For example, a previously successfully executed test case may fail due to the addition of a new microservice or changes in the resource requirements of an existing microservice running in the microservice test environment. The workflows disclosed herein also address this case; a new run of a previously executed test suite may result in a different subset of resources being removed compared to a previous run of the same test suite, which may or may not have required any microservices to be removed.

[0067] In a further use case, the workflows disclosed herein can take into account changes in the test environment itself. For example, the available resources, such as CPU and memory capacity, of the test environment may decrease due to a server failure, resulting in a reduced capacity for executing microservices within the test environment (i.e., either the number of microservices or the available resources allocated to each microservice may decrease). In this scenario, the workflows dynamically reevaluate which microservices are essential for a particular test case to run successfully, which may include removing different microservices from a previously successful test case run.

[0068] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the invention. As used herein, the singular forms "a," "an," and "the" are intended to include the plural forms as well, unless the context clearly dictates otherwise. It will be further understood that the terms "comprise" (and any form of comprise, e.g., "comprises" and "comprising"), "have" (and any form of have, e.g., "has" and "having"), "include" (and any form of include, e.g., "includes" and "including"), and "contain" (and any form of contain, e.g., "contains" and "containing") are open-ended linking verbs. Consequently, a method or device that "comprises," "has," "includes," or "contains" one or more steps or elements includes, but is not limited to, those one or more steps or elements. Similarly, a method step or device element that "comprises," "has," "includes," or "contains" one or more functions retains those one or more functions, but is not limited to retaining only those functions. Furthermore, a device or structure that is configured in a particular way is configured in at least that way, but may also be configured in ways not recited.

[0069] In the following claims, corresponding structure, materials, acts, and equivalents of all means-plus-function or step-plus-function elements are intended to include, where applicable, any structure, material, or act for performing a function in combination with other specifically claimed elements. The description of one or more embodiments has been presented for purposes of illustration and description, but is not intended to be exhaustive or limited to the disclosed form. Many modifications and variations will be apparent to those skilled in the art. The embodiments have been chosen and described to best explain various aspects and practical applications and to enable others skilled in the art to understand various embodiments with various modifications as suitable for the particular uses contemplated.

Claims

1. determining a set of microservices required to execute the microservice test suite within a test environment, the test environment being an active microservice test environment having a plurality of microservices; determining that the test environment lacks sufficient resources to run the microservice test suite using the set of microservices; dynamically removing at least one microservice of the plurality of microservices from the test environment that is not required to execute the microservice test suite, where the dynamically removing frees test environment resources to facilitate execution of the microservice test suite using the set of microservices; and Initiating execution of the microservice test suite within the test environment based on the dynamically removing the at least one microservice.

1. A computer-implemented method for facilitating processing within a computing environment, comprising:

2. 10. The computer-implemented method of claim 1, further comprising generating a data structure that identifies the at least one microservice that was dynamically removed from the test environment to free up test environment resources.

3. 3. The computer-implemented method of claim 2, further comprising restarting the at least one dynamically removed microservice identified in the data structure to restore the at least one dynamically removed microservice within the test environment, wherein the restarting is based on successful execution of the microservice test suite with the set of microservices within the test environment.

4. 10. The computer-implemented method of any one of the preceding claims, wherein the dynamically removing the at least one microservice comprises iteratively dynamically removing microservices of the plurality of microservices from the test environment until the test environment has sufficient resources for successful execution of the microservice test suite using the set of microservices.

5. 5. The computer-implemented method of claim 4, wherein the iteratively dynamically removing microservices from the plurality of microservices includes removing another microservice from the plurality of microservices from the test environment; and determining, based on the removing the other microservice from the test environment, whether the test environment has sufficient resources to successfully run the microservice test suite in the test environment using the set of microservices.

6. 10. The computer-implemented method of any one of the preceding claims, further comprising: determining, based on executing the microservice test suite in the test environment, that another microservice is required to execute the microservice test suite; and updating the set of microservices required to execute the microservice test suite to include the another microservice.

7. 7. The computer-implemented method of claim 6, further comprising repeating the dynamically removing and initiating execution based on the updating the set of microservices required to execute the microservice test suite within the test environment.

8. 10. The computer-implemented method of any one of the preceding claims, wherein the executing further comprises executing the microservice test suite within the test environment, generating a test results report that identifies the at least one microservice that was dynamically removed from the test environment.

9. 1. A computer system for facilitating processing within a computing environment, comprising: memory; and at least one processor in communication with the memory; wherein the computer system is configured to execute a method, the method comprising: determining a set of microservices required to execute the microservice test suite within a test environment, the test environment being an active microservice test environment having a plurality of microservices; determining that the test environment lacks sufficient resources to run the microservice test suite using the set of microservices; dynamically removing at least one microservice of the plurality of microservices from the test environment that is not required to execute the microservice test suite, where the dynamically removing frees test environment resources to facilitate execution of the microservice test suite using the set of microservices; and Initiating execution of the microservice test suite within the test environment based on the dynamically removing the at least one microservice.

1. A computer system for facilitating processing within a computing environment, comprising:

10. 10. The computer system of claim 9, further comprising generating a data structure that identifies the at least one microservice that was dynamically removed from the test environment to free up test environment resources.

11. 11. The computer system of claim 10, further comprising: restarting the at least one dynamically removed microservice identified in the data structure to restore the at least one dynamically removed microservice within the test environment, wherein the restarting is based on successful execution of the microservice test suite with the set of microservices within the test environment.

12. 12. The computer system of claim 9, wherein dynamically removing the at least one microservice comprises iteratively dynamically removing microservices of the plurality of microservices from the test environment until the test environment has sufficient resources for successful execution of the microservice test suite using the set of microservices.

13. 13. The computer system of claim 12, wherein the iteratively dynamically removing microservices from the plurality of microservices includes removing another microservice from the plurality of microservices from the test environment, and determining, based on the removing the other microservice from the test environment, whether the test environment has sufficient resources to successfully run the microservice test suite within the test environment using the set of microservices.

14. 14. The computer system of claim 9, further comprising: determining, based on executing the microservice test suite in the test environment, that another microservice is required to execute the microservice test suite; and updating the set of microservices required to execute the microservice test suite to include the another microservice.

15. 15. The computer system of claim 14, further comprising repeating the dynamically removing and initiating execution based on the updating the set of microservices required to execute the microservice test suite within the test environment.

16. One or more computer-readable storage media and program instructions collectively stored on the one or more computer-readable storage media for performing a method, the method comprising: determining a set of microservices required to execute the microservice test suite within a test environment, the test environment being an active microservice test environment having a plurality of microservices; determining that the test environment lacks sufficient resources to run the microservice test suite using the set of microservices; dynamically removing at least one microservice of the plurality of microservices from the test environment that is not required to execute the microservice test suite, where the dynamically removing frees test environment resources to facilitate execution of the microservice test suite using the set of microservices; and Initiating execution of the microservice test suite within the test environment based on the dynamically removing the at least one microservice.

1. A computer program product for facilitating processing within a computing environment, comprising:

17. 17. The computer program product of claim 16, further comprising: generating a data structure identifying the at least one microservice that was dynamically removed from the test environment to free up test environment resources; and restarting the at least one dynamically removed microservice identified in the data structure to restore the at least one dynamically removed microservice into the test environment, wherein the restarting is based on successful execution of the microservice test suite using the set of microservices in the test environment.

18. 18. The computer program product of claim 16 or claim 17, wherein the dynamically removing the at least one microservice comprises iteratively dynamically removing microservices of the plurality of microservices from the test environment until the test environment has sufficient resources for successful execution of the microservice test suite using the set of microservices.

19. 19. The computer program product of claim 16, further comprising: determining, based on executing the microservice test suite in the test environment, that another microservice is required to execute the microservice test suite; and updating the set of microservices required to execute the microservice test suite to include the another microservice.

20. 20. The computer program product of claim 19, further comprising repeating the dynamically removing and starting execution based on the updating the set of microservices required to execute the microservice test suite within the test environment.

Images