The invention relates to the field of software deployment, and more particularly to defining an environment class and generating a deployment of an environment instance from it.
To maintain a competitive edge, software companies need to be highly agile while not compromising product quality. In reality, most quality issues are discovered late in the product development cycle, which tremendously multiplies costs as engineering resources get allocated to troubleshooting and debugging rather than innovation and development. This allocation of funds negatively impacts productivity and schedules and results in a lack of agility.
In the software lifecycle, one of the biggest barriers to productivity is the sheer complexity of software deployment. Deployment stands for all of the activities that make a software system available for use, such as machine allocation, operating system installation and configuration, setup of various software prerequisites and installation of the various system services. Deployment is critical not just for the obvious reason of enabling users to use the system, but also to identify quality issues that do not surface outside a fully deployed production environment. Setting up a test or development environment involves enormous efforts with a steep learning curve. It requires close familiarity with available deployment tools and processes, as well as deep knowledge of the product being deployed. Experts are often needed to deploy environments due to their high level of complexity. Experts must know numerous configuration details, including dependencies, conflicts, geographical location restrictions, and software prerequisites. The configuration details between environments in the development cycle are often inconsistent and are installed by different experts. Many of these activities are recurring as the product evolves and new versions become available or when new customer scenarios are introduced. For instance, if a new version of a particular software component is released, the entire deployment must be recreated to account for the new version.
Furthermore, it is almost impossible to transfer knowledge of how to deploy entire environments between teams while keeping consistency through all stages of development. What is therefore needed is a way to uncover quality issues as far upstream as possible and the ability to test the systems in a near-production environment.
An object-oriented approach to programming provides many advantages over traditional procedural programming approaches. For example, an object-oriented approach permits code reuse through inheritance and modularity through encapsulation. In general, objects incorporate procedures (also called “methods” or “operations”) and data (also called “attributes” or “properties”). Objects are instantiated from and described by structures known as classes or types. A class is a general abstract specification, and an object instantiated from a class is a specific concrete instance of the class. In other words, a class defines the abstract characteristics and behaviors of an object, including the object's attributes, fields, properties, methods, operations and features. As used herein, the term “class” means a template for an object or a user-defined datatype that contains the variables, properties and methods in it.
A class consists of an interface and an implementation. The interface comprises variables and function declarations, wherein the variables represent the attributes of the class, and the function declarations specify methods for manipulating those attributes as well as performing other operations. The declaration specifies the name, return class, and argument, known collectively as the signature. The implementation refers to the actual code that implements the methods specified in the interface. Objects are instantiated from an implementation type.
Object instances, instantiated from implementation classes, are used for the execution of programs. Many instances of an object can be instantiated from an implementation class during execution of a program. The creation and deletion of object instances during program execution is referred to as “object life cycle.” Object life cycle management becomes very complex in large programs because thousands of object instances are created and deleted throughout the execution of a program.
Generating and deploying an environment is a complex process involving many fine details and requiring the combined efforts of multiple subject-matter experts. The term “role” is used to refer to software service (code or data). Roles are the building blocks of an environment. Roles include, but are not limited to, services, databases, network components, and any other functional components of the environment. Functional requirements include, but are not limited to geographical location, domain, and other requirements depending on the specific application contemplated. Each role has its own unique deployment package (all the required binaries to install the role) and installation method, unique configuration steps, prerequisites (including, but not limited to operating system version, CPU architecture, .Net flavor, and others), and dependencies or conflicts with other roles. These details and nuances are the domain of expert knowledge, which sometimes requires manual steps and tweaking to install and properly configure a role. This expert knowledge might be different for different versions of the same role, which adds to the overall complexity of installing a single role. Each environment consists of multiple roles, which makes every deployment a complex, lengthy, tedious and error-prone process best left to experts.
According to one aspect of the present invention, a machine-implemented method for instantiating a software development environment includes defining an environment class, generating at least one physical representation to which the environment class will be deployed, and deploying the environment class to generate an environment instance from the environment class. Through the use of the environment class, software prerequisites are added automatically to the environment. The environment class includes at least one role encapsulating deployment information.
According to another aspect of the present invention, the environment class includes a first role, at least one additional role, and at least one rule defining at least one dependency between the first role and the additional role.
According to another aspect of the present invention, defining an environment class is achieved by selecting a first role from a pre-populated role catalog; dragging the first role to a planning board; selecting a second role from the role catalog; dragging the second role to the planning board; indicating at least one dependency between the roles; and recording the environment class to a memory device.
According to yet another aspect of the present invention, at least one property of the environment class is overridden to create the environment instance.
While the specification concludes with claims particularly pointing out and distinctly claiming the invention, it is believed that the embodiments will be better understood from the following description in conjunction with the accompanying figures, in which:
An “environment class” is the entity which consolidates a set of rules that define which roles are needed to form the environment, any interdependencies or conflicts, and the way they are distributed across machines, networks and geographical locations. In other words, an environment class is the logical topology of the environment. Once an environment class is defined, a live environment can be instantiated out of it in a repeatable and consistent manner, enabling users to quickly and easily deploy their own private environment instance.
In an object-oriented deployment system, environment classes hold the logical representation or logical topology of an environment, rather than the physical topology typically selected and defined by software engineers. In other words, rather than needing to define the relationships between machines and roles, the software engineer establishes the logical topology for the program which can then be adapted to multiple physical topologies while the functionality remains the same. The environment class is defined according to the logical topology of the environment. The separation of the logical topology from the physical topology provides many benefits, including consistency and scalability across varying physical topologies. In other words, the environment instance for development, the environment instance for production, and the environment instance for testing created from the same environment class will have the same logical topology and function, but can have differing physical topologies using differing numbers of machines.
In some embodiments, the user can select a multiplier number for each role 12 in the environment class 10. In such embodiments, role replication enables the user to easily replicate the role 12 automatically in the environment, reducing or even eliminating the need for the user to identify the role 12 in the environment multiple times. For example, if the developer has a service which needs to be load balanced, he can mark the role 12 to be replicated N times in the environment. In some embodiments, N can be a specific number (such as 5 or 10) while in alternative embodiments, the number can be left open, meaning that the number of replications is determined according to a rule. Other benefits of role replication will be apparent to one skilled in the art.
In embodiments in which physical topologies are automatically created at instantiation time, machine learning algorithms can be used along with resource availability, the expected usage metrics of each role 12, and role dependencies to optimally allocate the roles 12 to machines 16 in a way that would maximize resource usage while keeping the best performance and most efficient cost. Automatic creation of physical topologies also increases machine utilization by optimizing hardware resource use of each host machine, increases the general reliability of roles by automatically striping them smartly across the environment, and increases the overall system performance by optimizing the physical locations of interdependent roles thereby reducing latencies, saving time, and simplifying optimization despite complexity.
Since environment classes hold the logical topology of the environment, different users can instantiate different instances, with different versions of the same roles. In some embodiments, the logical topology includes the number of instances of each role, referred to as a cluster. For example, the same environment class can be used to instantiate the current production version or a newer version that is under development. This simplifies the complexity of managing environments and enables the same developer to easily reproduce a production environment or a development environment with the latest build using the exact same steps. Furthermore, an environment class can include roles that are identified by rules or left open, rather than by specific version numbers. For example, an environment class can include a role of which the most recent version is to be used. In such cases, when the environment class is instantiated, the most recent version of that role in the cluster will be installed on the machines, eliminating the need for the engineer to make a determination as to which version is the most recent version each time he deploys the environment. In this way, the environment can be tested using the latest versions of software, even when the engineer is not aware that a new version was released. Similarly, version ranges can be identified in the environment class, such that when an instance is created, only certain versions of a role can be used.
When roles are left open, the engineer can also override this property, and specify a specific version of the role to be used in an environment instance. For example, if the engineer is trying to recreate an environment used previously to locate a problem or to test compatibility, the engineer can select the specific version of the role that he wishes to install. In some embodiments, properties of the environment class can be overridden even if not left open. In such embodiments, the engineer uses the environment class as a template, saving him the time and energy ordinarily required to recreate large parts of an environment when only a small portion of an already existing environment class requires modification. Other properties of the environment class or specific roles therein can be overridden, depending on the specific application contemplated and the specific needs of the user.
The use of environment classes enables an operations engineer to utilize the benefits described above to create pre-production environments for testing. In production, it is common to find the same functional environments configured differently across different datacenters which complicates manageability and hot fixes. This is primarily because different people are involved in the deployment process, different processes are used, and because historical deployments are sometimes kept untouched. Using an environment class with one logical topology results in consistency across the entire development process as well as in production deployments across datacenters.
In some embodiments, the environment class contains zero (0) roles, and the logical topology is referred to as an “empty logical topology.” An environment class with an empty logical topology is useful during the development process since a developer can have an iterative way of working. For example, the developer can create an environment instance from an environment class with no roles, manually work with the machines and learn how to best create his role, release the instance, create a new instance with that role, and manually work with the machines to learn how to best create his next role. In such embodiments, the default physical topology includes a defined number of servers. For example, one physical topology for an environment class with an empty logical topology includes five servers. The user can then add or remove servers as needed during the development process. The specific number of servers varies depending on the specific application contemplated.
The next step in creating an environment instance from an environment class is to generate the physical topology to which the environment class will be deployed. In some embodiments, a series of physical topologies to which the environment class will be deployed is created. The generation of a physical topology is shown in
In some embodiments, the generation of a physical topology is conducted automatically or at least partially automatically. The automatic generation of a physical topology can be achieved through the use of an algorithm executed on a machine. The algorithm can be configured to allocate each role to one of a plurality of machines according to the number of machines available, expected usage metrics of each role, and dependencies and conflicts identified between roles. The expected usage metrics of each role are encapsulated with each role, along with the deployment and other information. Dependencies and conflicts indicate to the system which roles should be located on the same machine 16 and which roles cannot be co-located. In some embodiments, machine 16 is a physical box or hardware, such as is described in accordance with
As shown in
As shown in
After the environment class has been used to generate a physical topology of the environment, the next step in deploying an environment instance is provisioning the machines to be used. Provisioning refers to operations needed to enable the machines to be used in a particular way within the environment. Provisioning the machines includes, but is not limited to, configuring servers and other consumable resources, such as storage space, central processing unit (CPU) usage, and connection bandwidth. In addition to provisioning the machines, prerequisites encapsulated by the roles are installed, and the roles themselves are installed on the appropriate machines. Finally, the environment is tested. If the environment fails one or more tests, it is retained for further investigation and debugging. Otherwise, the environment could be automatically archived and its resources are returned to the pool. The pool can include pre-provisioned servers, environment instances, pre-configured servers (servers including the operating system and installed prerequisites), scarce networking resources including machines with specific security setting configurations, IP ranges, software serial or activation keys, licenses, and any other resources that require either human intervention to create or need to be counted. The use of a resource pool is optional, and enables performance improvement and a faster response time when resources need to be reclaimed by the user.
The result of the completion of the deployment process is an environment instance. Within the environment instance, users can perform post-deployment, configuration and debugging actions, including, but not limited to, re-installing specific machines or roles, saving snapshots of the environment, zooming into server sessions of live machines in the environment, and other interactions with the machines.
Exemplary Computing System
Computer system 22 further includes one or more storage devices 32. Storage device 32 can include a hard disk drive for reading from and writing to a hard disk, a magnetic disk drive for reading from and writing to a removable magnetic disk, and an optical disk drive for reading from or writing to a removable optical disk such as a CD or other optical media. The storage device, whether a hard disk drive, a magnetic disk drive, an optical disk drive, or a combination thereof, is connected to the bus 28 by an appropriate interface. The drives and their associated computer-readable media provide nonvolatile storage of computer-readable instructions, data structures, program modules and other data for computer system 22. Although the exemplary embodiment described herein refers to a hard disk, a removable magnetic disk, and a removable optical disk, it should be appreciated by those skilled in the art that other types of computer-readable media which can store data that is accessible by a computer, such as magnetic cassettes, flash memory cards, digital video disks, random access memories (RAMs), read only memories (ROMs), and the like, can also be used in the exemplary operating environment.
A number of program modules can be stored on the storage device 32, RAM, and ROM, including an operating system, one or more application programs, other program modules, and program data. A user can enter commands and information into the computer system 22 through input devices 34 such as a keyboard or a pointing device. Other input devices 34 can include a microphone, joystick, game pad, satellite dish, scanner, or the like. These and other input devices 34 are connected to the processor 24 through an interface that is coupled to the bus 28. A monitor or other type of display 36 is also connected to the bus 28 via an interface. In addition to the monitor, personal computers typically include other peripheral output devices such as speakers and printers.
Computer system 22 also includes a communication interface 38 coupled to bus 28. Communication interface 38 provides a two-way data communication coupling to a network link that is connected to a local network 40. Communication interface 38 can be an integrated services digital network (ISDN) card or a modem to provide a data communication connection to a corresponding type of telephone line or a local area network (LAN) card to provide a data communication connection to a compatible LAN. Wireless links can also be used, depending on the specific application contemplated. In any such implementation, communication interface 38 sends and receives electrical, electromagnetic or optical signals that carry digital data streams representing various types of information.
Computer system 22 commonly operates in a networked environment using local connections to one or more remote computers, such as host 42 or remote computer 44. The remote computer 44 can be another personal computer, a server, a router, a network PC, a peer device or other common network node, and typically includes many or all of the elements described above relative to computer system 22. In the embodiment shown in
Generally, the data processors of computer system 22 are programmed by means of instructions stored at different times in the various computer-readable storage media of the computer. At execution, programs are loaded at least partially into the computer's primary electronic memory from the computer's secondary memory where they are stored. The invention described herein includes these and other various types of computer-readable storage media when such media contain instructions or programs for implementing the steps described in conjunction with a microprocessor or other data processor.
While various embodiments of the present invention have been described above, it should be understood that they have been presented by way of example, and not limitation. It will be apparent to persons skilled in the relevant art(s) that various changes in form and detail can be made therein without departing from the scope of the present invention. Thus, embodiments of the present invention should not be limited by any of the above-described exemplary embodiments, but should be defined only in accordance with the following claims and their equivalents.