Cloudy With a Chance of Configuration Management - ITBPL

Cloudy With a Chance of Configuration Management

By Joseph Hurley

Introduction

Contents Introduction

2

Why Bother with Configuration Management?

3

The Cloud Challenge

4

#1 Abstraction - the cloudiness in the cloud

4

#2 Dynamic Change - thunder and lightning

8

Into the Future - blue skies ahead

11

Summary

13

About the Author

13

Is the discipline of configuration management obsolete given the recent "Dynamic Infrastructure Paradigm Shift" in IT organizations? This is the question pondered by more than a few IT leaders in the service management space. How can a process-focused discipline hope to remain relevant in a world where configuration changes happen dynamically, in real-time, and often at a feverish pace? Further, is it relevant in an environment where the entirety of the infrastructure tier is often abstracted from the internal IT organization? Is cloud computing the death knell for the CMDB? This paper addresses the state of configuration management. It also illustrates why alarmist thinking regarding the end of configuration management is actually underscoring a critical weakness in the current conceptual thought around the cloudcomputing paradigm. In facilitating understanding around these weaknesses, it is my hope that we can avoid a reversal of the great work done thus far in the area of IT service management.

Why Bother with Configuration Management? Technology evolves, and to remain relevant so must processes. As a result, the question may arise, "Is it possible configuration management has outlived its usefulness?" To address that question, let us evaluate the value configuration management brings to an organization. In so doing, we can investigate whether these value propositions remain relevant in the new world of IT. Operational Service Definition The most important job of the configuration manager is the population and maintenance of the Configuration Management Database (CMDB) including the operational service definitions that drive nearly every function within the service operation lifecycle. Imagine attempting to analyze root cause or perform change impact analysis without a valid service definition. Would it be possible? How reliable would service level definitions be if not based on the cumulative operational level agreements of the components defined in a service hierarchy? How do you manage availability of a service if you don't have a definition of the component parts that make up that service? Baseline Configuration Management Configuration baselines are the control state against which we manage the evolution of a service. Acting as the control state, the baseline gives us a comparison point to watch, thus ensuring that our change and release controls are effective. Leveraging the control state, we can ensure configurations do Figure 1 - Configuration Management Functions not drift through unauthorized change. We can also ensure that failures in the release process do not leave us with unsynchronized environments. This improves our operational management and software development lifecycle. Perhaps most importantly, we can leverage this state for comparison during problem analysis to identify where rogue changes may have created service degradation or failures. How much time is saved in the problem analysis phase by having a definitive list of what has or has not changed in the configuration of a service?


Page 3 of 13

Continuous Service Improvement Outages occur. There is no such thing in IT as fault proof. It is the job of a configuration manager to mitigate configuration related service failures. When configuration errors are introduced through the release process, the offending configurations and parameters must be documented and managed. These, combined with the configuration documentation output from service transition become the basis for the configuration validation rules evaluated during the release management process. In this way, an effective configuration manager can ensure that faults related to configurations occur at most one time and are never repeated. Configuration Management is worth it As you can see, configuration management offers a variety of benefits that cannot be achieved in any other way. These benefits remain relevant even in a fully automated cloud environment. While cloud computing, particularly public clouds, introduce some complexity into the configuration management process, the need to continue on a "Service-Focused" path compels us to find a way to address these complexities rather than abandon the discipline on the whole as some have suggested.

The Cloud Challenge There are many configuration management challenges introduced when moving to a cloud-computing environment, but they fall primarily into one of two categories: abstraction and dynamic change. These two core issues manifest across a wide variety of use-case challenges, but by establishing a model that effectively addresses them both, we can resolve most of the complaints or objections to maintaining tight configuration management controls within the cloud.

#1 Abstraction - the cloudiness in the cloud The cloud is abstracted by design. This in fact is one of the primary value propositions of the cloud, the ability to stand up components to meet demand without requiring insight to the intricacies of the technology required to support that component. This lack of visibility into the stack, however, creates some challenges for configuration management. Below is a brief review of the two primary cross sections by which information is abstracted. Abstraction by purpose One of the most positive aspects of the cloud-computing paradigm is the ability to deploy a cloud container to meet a specific need. A cloud container is a deployable unit of computing capability offered by IT as a service. It is this notion of providing the capability as a service that differentiates cloud offerings from the standard virtualization initiatives we have seen develop over the last decade. While these containers come in a Cloudy With a Chance of Configuration Management

Page 4 of 13

wide variety of shapes and sizes, they are typically aligned to one of the following three categories. Each category listed is increasingly abstracted from the last.  Infrastructure Often called "Infrastructure as a Service", this container is characterized by the ability to request a dynamically allocated virtual platform. Probably the most common application of the cloud paradigm today, infrastructure containers house one or more virtualized servers that reside on the cloud. These are the most transparent of the common cloud containers as the end user typically has full control over the configuration of the virtualized operating system, as well as any applications or components installed therein.  Application Sometimes called "Software as a Service", this container features the ability for the requestor to provision an application container into which they can deploy an application of their own design or leverage an application developed by the cloud provider. These applications are then typically combined with other components or containers to provide a cohesive service. In these containers, the requestor will have varying levels of visibility into the application, but will usually have no visibility into the infrastructure on which the application resides. Readers should take care not to confuse the related concepts of cloud application containers as technology components, and "Software as a Service" (SaaS) as a licensing model wherein software vendors use a cloud application container model to deliver their wares to customers on a subscription basis.  Content A content container is used for the distribution or storage of content elements typically provided by the requestor. Common examples include media hosting such as Akamai and "Storage as a Service" providers such as Mozy Online Backup. In these containers, there is usually no visibility into the application of infrastructure tier. Abstraction by environment Public vs. Private vs. Hybrid? This is a question being asked in many IT departments today. More than a simple architecture decision, this question represents the three levels abstraction by environment. In each, the infrastructure that powers the cloud becomes increasingly or decreasingly transparent.


Page 5 of 13

 Private Cloud In a private cloud, the infrastructure that powers the cloud is owned wholly by the internal IT organization. Because the ownership of the components falls under the same organization providing access to the cloud services, there is minimal abstraction from the configuration manager.  Public Cloud In a public cloud model, the cloud containers are leased from an outsourced service provider. The configuration manager for the services built on top of a public cloud has no visibility into the underlying infrastructure.  Hybrid Cloud As the name implies, the hybrid cloud automatically leverages elements of the public and private clouds to create a blended solution. Focusing on clarity, not transparency In dealing with the abstraction concerns relating to configuration management, it is important to remember that complete transparency in not necessary to provide the appropriate level control. Consider the application development lifecycle. In the early days of configuration management, there was much confusion regarding managing application source code. It was suggested that the source code constituted part of the baseline and that it should be controlled as part of the configuration manager function. This debate was ended by one simple question, "What value does having source code bring to the configuration manager?" In almost every case, the answer was "None." Someone with skills across every utilized application development platform in an organization rarely staffs the configuration manager role. To the configuration manager, the application is a black box with a list of configuration attributes that must be tracked and related to other black boxes in the context of a service. Having the source code does nothing to help in this. In the same way, we must ask the question of abstracted cloud infrastructure. "What value does understanding the infrastructure of the cloud environment bring to the configuration manager?" In a private cloud, the configuration of the infrastructure is actionable by the internal team, and therefore must be managed, as any other environment would be. Conversely, in a public cloud, the internal team has no access to the underlying infrastructure. Assume the team had visibility into a configuration error on the supporting infrastructure of a public cloud container, what would they do with that information? They could do nothing directly to resolve the issue, and would have to rely on the provider to resolve the problem. Likewise, they should rely on that provider to detect and manage the configuration issue in the first place. In this way, IT can focus its efforts on those things it can control, and manage the rest via the contractual negotiations around SLAs with the outsourced providers.


Page 6 of 13

Take Action by defining appropriate levels of transparency In an effort to define and document the appropriate level of depth for each of the various cloud containers, the configuration manager should establish the following families and classes with the corresponding attributes within the CMDB.  Public Cloud This would be an endpoint within the service definition. The public cloud is a reference point for the platform provided by the outsourced service provider. The primary attributes would represent the container classifications supported and the SLAs with the provider.  Private Cloud Like the public cloud element, this would track the container classification support and the SLA offered to the business users of this service; however, it would not be an endpoint in the service definition. The private cloud would be a mid tier element which connected upstream to the collection of infrastructure elements supporting the cloud.  Content Cloud Container The primary attributes of this element would include the attributes used to Figure 2 - Cloud-Enabled Service Map instantiate the container. Information such as owner, requestor, duration, size, purchased availability and bandwidth are all examples of information that would be key to this element's configuration. This element would link upstream to a public or private cloud/clouds on which they reside and downstream to the content hosted (assuming that content is itself a configuration item) or the services and elements leveraging this content container to provide service.  Application Cloud Container


Page 7 of 13

The attributes for this element would be similar to that of the content container, and would include any additional instantiation information pertaining to the hosted application. Downstream would reside the configuration of the actual application instance and downstream from that, the elements depending on the container to provide service. The upstream connection would be the public or private cloud/clouds on which the application container resides.  Infrastructure Cloud Container Following the trend from the previous containers, this container would list the instantiation parameters as the key attributes. Downstream the configuration of the hosted virtualized system/systems would be the primary consumer of this CI. These systems would, in turn of course be leveraged by other CIs to provide services. The upstream connection would be the public or private cloud/clouds on which the infrastructure container resides.  Hybrid Cloud The hybrid cloud would not need a direct representative element in the CMDB, as it would be inferred from a single container spanning both public and private clouds. These spanned relationships would define the context of the hybrid strategy from a configuration management perspective. By providing a management strategy, we can deemphasize the importance of infrastructure abstraction. When properly classified, the cloud elements in the CMDB can continue to provide the necessary decision support capabilities.

#2 Dynamic Change - thunder and lightning The more difficult challenge to maintaining an effective configuration management practice in a cloud environment is managing dynamic change. Another of the primary value propositions of the cloud is the ability to dynamically provision and de-provision based on demand. This goes well beyond the ability to quickly add or remove environments. The most advanced systems can dynamically respond to increases in consumption and allocate additional capacity to meet the user load. Additionally, automated failover and redundancy are becoming increasingly standard as part of the cloud enabling technologies. How then, with this level of automation can we establish process-based controls to manage change? Remember, the CMDB is the representation of the "control state" not the "current state" which is located in the Performance Management Database (PMDB). The CMDB should be a representation of the cumulative change orders executed in the environment. How do we keep this up to date with changes happening sometimes minute by minute - this question, more than any other is the basis for some feeling that the discipline of configuration management is fundamentally not compatible with the future cloud-enabled direction of IT.


Page 8 of 13

The clouds part The good news is, the answers required to address the concerns pertaining to the dynamic nature of the cloud exist and are already in common usage in many IT environments. The basis of the solution to this problem consists of two major parts. First and most importantly is the process. We need to leverage capabilities already inherent in the service management framework to become more adaptable to dynamic environments. The second part of the solution is technology. Here again, good news in that the very solutions which enable the cloud can, with some slight tweaks, be made to support the proper functioning of the configuration management control objectives. Process... Process... Process... Like location in real estate, there is no more important facet of a service management program than the process. One of the most common mistakes in the initialization of a service management program is the mistaken belief that acquiring technology touted as "certified" in some best practice or another will make you compliant with that practice. Technology is a tool to be used in support of a process, in many ways no different from a hammer. If you are attempting to build a house, no hammer, regardless of its certifications, cost, level of automation, etc. will replace the need for a good blueprint. Without that blueprint, you are stuck haphazardly nailing boards together. Without the blueprint, the process, you will never have a house, just a pile of unused hammers. How then do we address the dynamic change requirements of our cloud environment with the blueprint provided from our service management discipline? In the normal change process, a change is proposed; a change owner identified; the relevant parties review the change; it is approved and scheduled by the change advisory board (CAB); and finally it is released and the relevant baselines are updated to reflect the updated environment. This process can be incredibly time consuming and certainly cannot scale to meet the dynamic demand of a cloud environment. Fortunately, a contingency for these types of frequent repetitive updates to the CMDB already exists. It is called the "Standard Change Process." Standard Change Process to the rescue Standard changes are those changes that occur with enough frequency in our environment that special consideration is given to minimize the administrative overhead in facilitating them. In these changes, rather than relying on a review of the change package and normal scheduling and release, the CAB pre-certifies both the events that can trigger the change as well as the process by which the change is allowed to occur. In putting this framework around the change, the CAB essentially establishes the guidelines by which changes can be created and released in an ad-hoc fashion. For a change type to be classified standard, it must happen frequently, it must have predefined conditions that trigger its execution, and it must follow a prescribed deployment path certified by the CAB. Consider now the dynamic changes that happen in the cloud. Do they happen frequently? Are the conditions that might trigger these Cloudy With a Chance of Configuration Management

Page 9 of 13

changes finite and pre-determined? Are the executions of these changes standardized in a certifiable process? Clearly, the means addressing the dynamic nature of the cloud fits nicely within the boundaries of the standard change process. While the exact triggers for the executions of cloud-based changes are widely varied, they are finite and easily definable. Some examples might include:  An authorized request for a container from the cloud provisioning system  A triggered load event in which additional capacity is added or removed  A fault in which the container is migrated to a non-faulted segment of the cloud infrastructure In each of these cases, it would be a simple matter for the CAB to define the conditions and review the automation procedures by which the changes are executed. With that, the changes can happen as frequently as necessary and still comply with the process-based standards set forth by the configuration management control objectives. In fact, the only challenge would be keeping up with the application of these constantly revising baselines in the CMDB. To solve that challenge, we must turn to the technology. Automation - taken to the next level To maintain a relevant CMDB, we must find a way to keep up with the high level of standard changes occurring in the cloud. Fortunately, the best cloud management tools already possess the capability to establish these standard change order records and execute the updates to the corresponding CMDB baselines. The vast majority of the leading change management and CMDB solutions on the market today are web service enabled. Correspondingly, the best cloud management solutions leverage native workflow capabilities that are able to integrate calls for external integration via web services. Through the combination of these capabilities, it is easy to see how the standard change process could be fully automated directly within the cloud management suite. Returning to our use cases, imagine the follow scenarios:  A user requests a container. The approval is automated based on the container type and the associated role of the user. Upon approval, the request generates a standard change request with the configuration parameters submitted for the container. Once the change record is created, the cloud management suite instantiates the cloud container. Upon successful provisioning, a new cloud container CI instance is created in the CMDB and linked to the cloud on which it resides. The collective parameters established throughout the standard change process are added to the CI record and stored as its version one release.  A load event is detected. The cloud management system creates a standard change using the template classifications preapproved by the CAB for the specified container. The management system executes the scaling action, then updates the standard change record and updates the attributes of the CI thus iterating the version to the next in sequence.


Page 10 of 13

 A fault occurs and is detected. The cloud management system immediately transfers load to redundant nodes and creates an event to review the fault. The system then opens a standard change record and begins restoring the containers staged on the inoperative segment. Once complete, the change is updated and the affected CIs are versioned with the updated information. Later, when the original segment is restored, a new change is created and the containers are migrated back to the original equipment. Upon completion, the versions of the affect containers are iterated again with the new relationship data. In each of these use-cases, we have not only seamlessly addressed the demand in accordance with the best-practices in cloud management, we have additionally maintained the control source (the CMDB) on which the service owners, change managers, problem managers, etc. can continue to base their decisions without painful manual correlation of data elements from the cloud management system.

Into the Future - blue skies ahead Leveraging a combination of process and technology, we have addressed the major issues that seem to be giving most cause for concern in considering the future of configuration management. There is however, more to be achieved than simply maintaining the configuration management status quo. Earlier in this paper, we discussed the fact that a fundamental issue exists in the conceptual thought around the cloud-computing paradigm. This flaw is - for all the talk of abstracting technology for a greater business benefit - that cloud discussions today are mostly technology-based. Reviewing the conversation around both the cloud creation processes and the practical applications thereof reveals an approach suited only for technical consumption. Following this trajectory, the cloud runs a real risk of moving IT conversation away from being business and service focused (a trend enabled the last few years with the help of service management) and back towards a siloed technology discussion wherein the cloud itself becomes another silo alongside the systems, applications, network, databases, etc. This is obviously not a desirable outcome. Fortunately, effective configuration management can help establish a better dialog around cloud technology. Just as we have shifted focus from network, system, and application discussions towards discussions of the service and those CIs in relation to the service provided, so too must we move the discussion of the cloud container to a service-focused context. As an example, look at the reservation system that serves as the front end of most cloud environments today. They are almost entirely focused on the technical parameters of the cloud container. Ignoring for a moment that a request for a cloud container is no different from a request for any other service from IT and clearly should reside in the Service Catalog, the context under which these containers are requisitioned is entirely


Page 11 of 13

technical. How much RAM do you need? What is the anticipated load? What is the acceptable level of transactional performance? Very few of these systems request input pertaining to the business function the cloud container will serve. What services will it support? These questions are critical, and the failure to ask these questions and think in these terms is creating a great deal of anxiety (particularly within governance and IT security) around the cloud paradigm as a whole. The following examples will illustrate some of these concerns.  Request for a content container What service is the content related to? Is the content proprietary? Is it considered intellectual property? How sensitive is the content? Does it contain data that falls under a compliance control objective? All of these are valid questions and many are critical from a security and audit perspective, especially in an environment considering a public or hybrid cloud approach. Gaps in this kind of information can have costly outcomes such as fines and penalties, loss of certifications, intellectual property loss, and more. Imagine if instead, the request for this resource were made through the Service Catalog in one of the following service requests: o Request for a backup container for the patient information database o Request for secondary storage of the customer web store application o Request for media content distribution related to internal HR policies and procedures o Request for media content distribution of the investor analyst call recording Upon receiving one of these service-focused requests, would the potential risk be more apparent. Would understanding the request in this way change the methods with which you chose to provision the system.  Request for infrastructure container Again, without the service-focused information, many of the same questions linger. Is the request for a production instance of a Service? If so, what service? Is this meant to be a virtualized test environment? Wouldn't knowing the service to be tested make it more likely the container we provision was fit for the purpose it was intended? If the service to be tested is a three tier architecture container, wouldn't it make sense to replicate the container baseline of the production system to ensure proper validation of the build. Is validating the system functions properly on a single-tier architecture really the same as validating it on the three-tier architecture model?


Page 12 of 13

Modeling improvements are just the beginning. Configuration management can add many additional benefits to the cloud. For example, once we have established a servicefocused cloud management system that draws container design models from the CMDB and manages requests through the service catalog, it becomes simple to enable late-stage request validation. While it may be simple to approve a container request for a user in a given role, ensuring that container is used in a way that conforms to the guidelines set forth by the business can be a challenge. By building a cloud strategy closely aligned with service management, we enable a single definition of the service control state that can be cleanly and easily managed within the CMDB. Imagine for example, your information governance tool discovers sensitive data on a newly provisioned cloud container. Because the container definition is stored in the CMDB, the governance tool can easily and automatically determine whether the detected class of sensitive data is authorized on the specific cloud container and/or cloud segment. Additionally, it can leverage the service relationship information to determine whether the data is relevant to the modeled service. Any failures in these validations can automatically trigger a configuration exception to be reviewed by the configuration manager. In this way, cloud can move well beyond providing faster more reliable access to infrastructure, it can become a framework for delivering continual alignment to the evolving needs of the business.

Summary Despite the concerns of many in the industry, the future of configuration management is bright. Rather than becoming obsolete with the proliferation of cloud computing, configuration management will become even more critical. By adopting the necessary process controls and aligning the cloud technology to the appropriate configuration management objectives, the configuration manager will help IT to achieve its next quantum leap in value. The cloud is important and should not be underestimated. It is the evolution of extrapolation of the application from the infrastructure that supports it... the evolution of cloud, however, will be the alignment of application in context of a business value, thus providing true cloud-enabled governance.

About the Author Joseph Hurley has over 15 years experience in IT. He has spent the last 10 years focused primarily on the areas of service management and asset management. A software developer by training, he has worked closely with a wide variety of companies ranging from small startups to the Fortune 500. He operates ITBPL.org, a website devoted to expanding industry exposure to IT Best Practices. He has authored several whitepapers, presented at itSMF events, holds certifications in ITIL and ITAM, and is currently a Sr. Principal Consultant for CA, Inc.


Page 13 of 13