A cloud service generally refers to a service that allows end recipient computer systems (thin clients, portable computers, smartphones, desktop computers and so forth) to access a pool of hosted computing and/or storage resources (i.e., the cloud resources) and networks over a network (the Internet, for example).
Enterprises are ever-increasingly using cloud services to develop and deploy applications. Enterprises, in general, typically want to quickly move a set of innovative features to production to gain a competitive edge in the market place.
An enterprise may use development operation products (called “Devops products” herein) for purposes of quickly developing and deploying their applications into cloud environments. In this context, “deploying” an application to a cloud environment generally refers to installing the application on one or multiple components of the cloud environment, including performing activities to make the application available to use via the cloud environment, such as provisioning virtual and physical resources of the cloud environment for the application; communicating files and data to the cloud environment; and so forth.
In general, a Devops product may enhance the joint cooperation and participation of teams that may be assigned tasks relating to the different lifecycle stages of the application. The lifecycle stages may include a development stage in which the machine executable instructions, or “program code,” for the application may be written; a testing stage in which components of the application may be brought together and checked for errors, bugs and interoperability; a staging stage in which production deployment may be tested; and a production stage in which the application may be placed into production. The application may be deployed in more than one lifecycle stage at the same time. For example, developers and testers may be developing code and testing code implementations for the development and testing lifecycle stages at the same time that a version of the application may be in the process of being staged and evaluated in the staging lifecycle stage.
Over the course of its development, the business enterprise may deploy the application onto different virtual resource environments for the different lifecycle stages of the application. The “virtual resource environment” refers to the virtual resources that are available to the application. A given virtual resource environment may be defined by such factors as a number of virtual machines and the number of compute and memory shares of the corresponding resource pool, which is allocated to the virtual machines.
A Devops product may be used by application architects and developers of the business enterprise to model the overall application deployment process; and a resource administrator may use a Devops product to configure the virtual resource environments onto which the application may be deployed for the different lifecycle stages. The parameters of the virtual resource environments may vary, according to the demands of the lifecycle stage. As an example, for the production lifecycle stage, the application may be deployed on a virtual environment that may contain one hundred virtual machines, whereas for the testing stage, the application may be deployed on a virtual resource environment that may contain twenty virtual machines. Moreover, the virtual resource environment may have more allocated compute and memory resource pool shares for the production lifecycle stage than for the testing lifecycle stage.
The virtual resource environment may be based on a sharing model in which underlying physical resources support the virtual resources of the virtual resource environment. The virtual resources are abstractions of actual devices, whereas the “physical resources” refer to the actual, real devices that support the virtual resources. As examples, physical resources may include: central processing unit (CPU) cores; random access memories (RAMs); RAM partitions; non-volatile memories; non-volatile memory partitions; solid state drives (SSDs); magnetic storage-based disk drives; storage network or arrays; servers; server groups; clients; terminals; and so forth. The physical resources that support the virtual resource environment are part of a physical resource environment. In general, a physical resource environment may be defined by its specific physical resources, the manner in which the physical resources are connected, and/or the boundaries among the physical resources. As an example, in accordance with some implementations, a given physical resource environment may be a physical datacenter (a public, private or hybrid datacenter, for example) or a partition thereof.
One way to assign physical resources that support a given virtual resource environment may be to assign the physical resources as the application is deployed in each of its lifecycle stages. However, different application teams may be concurrently working on the application in connection with different lifecycle stages; and such an approach may ignore the effects that the physical resource boundaries have on each other. Examples described herein may allow a user, such as a resource administrator, to predefine different physical resource environments for different lifecycle stages of the application. Such an approach may provide the advantage of taking into account or predicting the interdependencies of the physical resource environments, so that these interdependencies may be addressed. More specifically, in accordance with example implementations that are disclosed herein, the resource administrator may use a Devops resource policy engine to search for and identify one or multiple candidate physical resource environments for a given lifecycle stage so that one of these physical resource environments may be selected and used to support the virtual resource environment. This may allow the resource administrator to define the boundaries and resources of the physical resources for each application team, while considering the effects that a given physical resource environment may have on one or multiple other physical resource environments and/or considering how one or multiple physical resource environments may affect the given physical resource environment.
Configuring, controlling, and isolating the physical resource environment usage based on application lifecycle stage via the pre-designation discussed herein may enhance testing, resource requirement support, and the like. For example, the physical resource environments may be configured to isolate the physical resource environment used to run performance tests in the staging lifecycle stage from the other physical resource environments. The isolated environment may enhance the performance tests, as the isolated environment may isolate resource consumption by developers and testers in the development and testing lifecycle stages from affecting the performance test results in the staging lifecycle stage. As another example, the production stage may benefit greatly from being physically isolated from other environments so that the application may not exhibit a slow down because of resource consumption by the developers and testers. Moreover, the configuration, control and isolation of the physical resource environments may be beneficial for purposes of supporting different resource requirements. For example, physical resource environments that support the staging and production lifecycle stages may use SSDs for non-volatile memory, whereas physical resource environments that support development and testing lifecycle stages may use magnetic-based storage devices.
Referring to
For the example implementation of
In accordance with example implementations, the Devops resource policy engine 170 may use information contained in an application model 172. The application model 172, in general, may define the layers of the application along with a “recipe” for managing the deployment of the application. Although a single application model 172 is depicted in
Users (such as a resource coordinator) may access the user interface engine 190 of the Devops resource policy engine 170 using an end user system 150 (a desktop, portable computer, smartphone, tablet, and so forth) for such purposes as interacting with Devops components associated with the cloud service, including the Devops resource policy engine; submitting application deployment requests that are handled by the Devops resource policy engine 170 as well as potentially one or multiple Devops components or engines; creating descriptions of the physical resource environments; interacting with the Devops resource policy engine 170 to tag the physical resource environments with lifecycle stages to update, create or change the mapping 180; confirming a physical resource environment selected by the Devops resource policy engine 170 based on the mapping 180; receiving an indication of one or multiple candidate physical resource environment candidates for a given lifecycle stage from the Devops resource policy engine 170; selecting one of multiple candidate physical resource candidates presented by the Devops resource policy engine 170; and so forth. The cloud service manager 160 may contain Devops products or engines other than the engine 170, which may perform other functions related to the development and/or deployment of the application onto the cloud, in accordance with further implementations.
As depicted in
Referring to
The example application model of
The application model 300 may further define the parameters (number of virtual machines 324 and 328, resource pools and so forth) for the virtual resource environment 320 based on the particular lifecycle stage involved with the deployment. As illustrated at 340, the model 300 may define parameter sets 344, 346, 348 and 360 that define the parameters of the virtual resource environment 320 for the development, testing, staging stage and production lifecycle stages, respectively
As a more specific use example, example physical resource environments may be formed by partitioning a private cloud datacenter. For this example, the datacenter may have a total capacity of 800 GB RAM and ten Logical Units (LUNs) of two TeraBytes (TB) each. Out of the ten LUNs, two of the LUNs may support Solid State Drives (SSDs), while the other eight LUNs may be magnetic-based hard disk drives. As an example, a resource administrator may partition the datacenter resources to form four datacenter partitions: 1.) a first partition having 300 GB RAM and a three magnetic storage hard disk-based LUN; 2.) a second partition having 500 GB RAM and a five magnetic storage hard disk-based LUN; 3.) a third partition having 90 GB RAM and 1 SSD LUN: and 4.) a fourth partition having 110 GB RAM and one SSD LUN. For these four partitions of the datacenter, the resource administrator may create four different physical resource environments corresponding to the partitions and assign an associated lifecycle stage to each of these environments.
Referring back to
Thus, for example, in response to a deployment request for the development lifecycle stage, the Devops policy engine 170 may identify and select the physical resource environments that are associated with the Physical ResourceEnvironment_0001 and PhysicalResourceEnvironment_0002 IDs.
As illustrated in the example above, the mapping 180 (
Thus, referring to
Referring to
In accordance with exemplary implementations, the physical machine 600 may be located within one cabinet (or rack); or alternatively, the physical machine 600 may be located in multiple cabinets (or racks).
A given physical machine 600 may include such hardware 610 as one or more processors 614 and a memory 620 that stores machine executable instructions 650, application data, configuration data and so forth. In general, the processor(s) 614 may be a processing core, a central processing unit (CPU), and so forth. Moreover, in general, the memory 620 is a non-transitory memory, which may include semiconductor storage devices, magnetic storage devices, optical storage devices, and so forth. In accordance with example implementations, the memory 620 may store data representing the application model 172 and data representing the mapping 180.
The physical machine 600 may include various other hardware components, such as a network interface 616 and one or more of the following: mass storage drives; a display, input devices, such as a mouse and a keyboard; removable media devices; and so forth.
The machine executable instructions 650 contained in the physical machine 600 may, when executed by the processor(s) 614, cause the processor(s) 614 to form one or more of the Devops resource policy engine 170, the physical resource provisioning engine 186 and the user interface engine 190. In accordance with further example implementations, one of more of the components 170, 186 and 190 may be constructed as a hardware component formed from dedicated hardware (one or more integrated circuits, for example). Thus, the components 170, 186 and 190 may take on one or many different forms and may be based on software and/or hardware, depending on the particular implementation.
In general, the physical machines 600 may communicate with each other over a communication link 670. This communication link 670, in turn, may be coupled to the user end devices 150 (see
As an example, the cloud service manager 160 may be an application server farm, a cloud server farm, a storage server farm (or storage area network), a web server farm, a switch, a router farm, and so forth. Although two physical machines 600 (physical machines 600-1 and 600-N) are depicted in
While the present techniques have been described with respect to a number of embodiments, it will be appreciated that numerous modifications and variations may be applicable therefrom. It is intended that the appended claims cover all such modifications and variations as fall within the scope of the present techniques.
Number | Date | Country | Kind |
---|---|---|---|
3171/CHE/2015 | Jun 2015 | IN | national |
Filing Document | Filing Date | Country | Kind |
---|---|---|---|
PCT/US2016/021908 | 3/11/2016 | WO | 00 |