In my previous blog, Hybrid Application Management – Managing Above a Cloudy Infrastructure, I suggested:
“The definition of Application Performance Management has been expanded to include managing the performance of the process that delivers applications to the enterprise.”
The term process was emphasized because I believe the future of automated Application Lifecycle Management (ALM) will include what has traditionally been called “Business Process Management (BPM)”. Application Lifecycle Management includes the processes of commissioning and decommissioning an entire application, including all of its subcomponents and the necessary configuration of those subcomponents so that they can deliver application services to the end user. In most datacenters today, individual components (such as virtual machines) can be automatically commissioned and decommissioned, but the deployment of an application as a single object, consisting of a collection of VMs, their software stacks, the data stores and the necessary interconnects, is still a manual and error-prone process necessary for the business of IT.
For a while, BPM was a nice new, shiny name that was thrown around. By monitoring key events during a business process, we could measure and determine which processes could be automated and thus reduce cycle time for a business activity. Using automation to replace manual activity is as old as computing itself. Back during the Manhattan project, computers were used to automate the integration of complex functions to help make decisions regarding nuclear fusion. On the commercial side, automation has been used to replace “back office” activity, such as billing, bookkeeping, inventory management, etc.
The role of computing has always been to automate. Given that automation is such an all-inclusive work, I think we need to be more specific when we discuss automation. If, as Franz Boas claims, the Eskimos allegedly have dozens of words for types of snow, I think two names for types of automation for application life cycle management is not a burden. I have looked over a number of clouds that provide some level of application life cycle management. In all cases, I see two types of automation – provisioning and orchestration.
Provisioning has been a staple in the datacenter. In 1999, Marc Andreessen (father of the Internet Browser) and a few other innovators started a company called Loud Cloud. Their innovative product, OpsWare, provided server and network device provisioning. Opsware was bought by HP in July, 2007.
A similar product set, called BladeLogic, was bought by BMC in March 2008. Since that time, there have been open source communities built around provisioning, such as Puppet and Chef. Microsoft recommends PowerShell for provisioning. Essentially, provisioning can start during the device’s software/firmware initialization and is used afterwards for maintenance, such as software and configuration updates. It is essentially the automation of error-prone command line management.
Orchestration implies the management of multiple active processes and “orchestrating” how they are managed during the stages of the process. One such process would be the approval process that ensures the user can commission the application. The use case is the following: An authorized cloud user selects an application to be “stood up” from a service catalog. Before it can be commissioned, the user must be approved to create the application. An approval process can be very simple, such as automatically allowing the authorized user to commission a standard application as long as the predetermined number of instantiations is not exceeded. For other approvals, the process may be quite complex, including the management of emails sent to and responded by approvers.
Another use case is that the user would like to stand up the application and run tests to guarantee end-to-end delivery of the application’s services. An application consisting of a number of components will require orchestration to stand up the components in a specific sequence. For example, an application server may require that a database be fully deployed before the application server can be operational. Orchestration automates the order of stages, as well as dependencies and the state of the various software components.
And here, we have gone full circle. These two use cases are business processes. Business process management (orchestration) provides the flexible, event-driven framework for the automation while provisioning automation scripts are spun off to work asynchronously to finish off the details of the main steps in the process.
Application life cycle management is just starting to mature. Here are some obvious examples of use cases. In today’s agile software development environment, commissioning and decommissioning applications for test and development is necessary to continually drive down the latency time between feature requests and delivery to production. As more and more products are being offered in a Software as a Service (SaaS) business model, new customers will require an instance of the product to be stood up quickly and flawlessly. As application life cycle management matures, we should expect to see innovations that we can’t imagine at this time. I invite others to comment on these observations and contribute your vision of where this can go in the future.