The Path of Cloud

Usually the title of this blog is referred to as the path to cloud.  Based on recent conversations, cloud is already leveraged in most organizations.  Thus, we are in the cloud, not moving to it.  But what is the best way to weave these pockets of cloud together?  I hear questions around the nature of Platform as a Service or public cloud versus private cloud versus hybrid cloud.   Sometimes discussions reflect on how to reign in rouge public cloud use or how to provide seamless access to multiple Software as a Service offerings.  The success of those efforts is the end state.  They should not be goals for the beginning of the journey.

As a former athlete and forever competitor, my experience in developing any skill is to begin with the basics.  All training is focused on ensuring form is correct before leveraging complex movements or thoughts.  This is one hundred percent true of cloud as well.  The purpose of enterprise cloud is for IT to become a service broker, or IT as a Service.   To achieve this, we need to automate everything IT has been trying to do for the last 30 years. 

These are my guidelines for a successful path of cloud:

1.    Solidify virtualization

If your organization is not comfortable with virtualization, this will be a large barrier to cloud.  Ensure the standard architecture for virtualization can support all workloads in performance and capacity.  Implement reference architectures across main data centers and remote sites.  Reduce the variables of physical hardware, software versions, patch levels, and virtual machine templates to a handful of approved types.  Remove the process of negotiating for resources with application owners and developers.  Leverage templates only.

2.    Implement cloud management and monitoring

Once virtualization is standardized across the enterprise, performance and capacity management is key to ensure internal and external customer satisfaction.  Older monitoring tools were not built for cloud agility and hypervisor capabilities.  Capacity management is also different for virtualized environments as the various workloads and peaks running on the same hardware is difficult to account for in manual methods.

This step does not mean all previous tools are discarded.  Instead, the ones providing unique data should be retained and rolled into the main analysis engine.  But, where features overlap, it is an opportunity to prune down the number of solutions in the environment to a manageable number.  This will also lower CapEx and OpEx costs for IT by not maintaining support on redundant software.

3.    Implement configuration management

The solution required for this is not unique to cloud environments.  The important requirements are that all hypervisors and operating systems are supported.  The configuration management system should tie into cloud management and monitoring for a complete root cause picture when diving into issues.

4.    Implement log aggregation and analysis

This toolset is also not unique to cloud environments but should support all standardized infrastructure and applications.  Integration with the management and monitoring tool is ideal for root cause analysis.  Understanding system and application logs is the only way to know the underpinnings of any environment.

5.    Implement cost analysis

The main purpose of cost analysis is not to “Chargeback” to the business units for their overall environment consumption.  Chargeback is a great feature, but more importantly IT must understand its spending.  Also, IT must strive to become an innovation center instead of the cost center that exists today.  Recognizing the least expensive location for workloads and reinforcing workload sizing is critical to success in later stages of cloud.

Once these five steps are complete, or at least well underway, then it is time to automate.  Cloud is automating the request and delivery of a service.  If an empty Operating System is deployed, this is Infrastructure as a Service.  If it is a development platform, a web server, a database server, etc, then it is Platform as a Service.  If the service is to a ready to use application, this is Software as a Service.

The reason I am providing these definitions is I have found, to my surprise, that they differ among the industry.  The delineation of these terms is not to require folks to adhere to them, but to instead show the complexity of each.  Each service builds on the former mentioned in the paragraph above.  Thus, when I am asked where to start with automation, I always suggest Infrastructure as a Service because this is the simplest to provide.  Simple is not to be confused with easy.  When integrating requests with approvals, ticketing systems, IP management systems, networks, security, global DNS, operating systems, backups, monitoring, change management databases, and other tools, automation is a big step.  Do not let this list of integrations deter you.  It is the end state.  The beginning is self-service access to basic virtual machines. 

Keep in mind that the rewards of cloud are vast.  The new measurement for an IT organization is not percent virtualized or time for deployment of a template.  It is not cost per GB of storage or amount of network ports used in a data center.  Innovation percentage versus “keeping the lights on” is the new measurement.  The early adopter organizations are reaching 50% to 75% on the innovation side of the equation.  This is only accomplished through the path of cloud.