Is Your View of the Cloud Still a bit Foggy?

Steven Reese
02/25/13 at 04:55 am

Defining “Cloud”

All too many times I am on a conference call, sitting in a meeting with a partner, employee and/or client, attending a symposium or conference, and the term “cloud” comes up. Anymore, the term “cloud” comes up so often in the technology industry that I’m starting to think it isn’t a term, rather a punctuation mark. What I find interesting is the number of definitions that “cloud” seems to take on in those conversations. What is even more interesting is that many times, it is the same individual using “cloud” in so many different contexts. From what I can gather over the past few years, here are just a few definitions of “cloud” as it should be in the technology dictionary:

cloud: (kloud)

n: 1) a location to place information to be consumed by individuals or groups of individuals; 2)  a consumption model for information and other resources; 3) a financial model

adj: used to describe a type of computing model

v: to prepare information or other resources to be accessed in a different environment than it is currently (ex: You need to cloud ready your applications.)

adv: describes how computing takes place (cloud compute)

According to the National Institute of Standards in Technology (NIST), the definition of “cloud” is as follows:

The NIST definition lists five essential characteristics of cloud computing: on-demand self-service, broad network access, resource pooling, rapid elasticity or expansion, and measured service. It also lists three “service models” (software, platform and infrastructure), and four “deployment models” (private, community, public and hybrid) that together categorize ways to deliver cloud services. The definition is intended to serve as a means for broad comparisons of cloud services and deployment strategies, and to provide a baseline for discussion from what is cloud computing to how to best use cloud computing.

For the purposes of this document, I will use a combination of the NIST definition of “cloud” with my own interpretation:

“Cloud” is a services delivery architecture that incorporates elements of five different “services” to create on-demand self-service, broad network access, resource pooling, rapid elasticity, and measured services that optimizes the consumption of meaningful and relevant information by authorized consumers of said information, regardless of location or platform. Due to the embedded capability to measure services, the “cloud” service delivery architecture simplifies various financial alternatives. Determining capital expense, operational expense, or a more utility expense (pay by the drink) approach become a business decision rather than a restriction of the technology.


Now that I have established my definition of “cloud”, I will outline some of the considerations of things like service location (private, community, public, or hybrid), architectural management, and financial models.


Undoubtedly, security is typically the most top of mind for any executive looking at “cloud” services delivery architecture. In today’s world of regulation, compliance, liability, and litigation, this is often times one of the most frustrating and difficult hurdles to overcome. Regardless of whether the data is on a private, community, public, or hybrid cloud service delivery architecture, the data ownership, and therefore responsibility to protect it, falls directly on the organization.

The primary security challenge is understanding data structures and determining what, if any, liabilities can be tied to those data structures. Knowing what constitutes cardholder data (PCI), electronic health records (HIPAA), and personally identifiable information (state and federal privacy laws) just to name a few, is just the beginning. The primary security issues related to “cloud” are understanding the ramifications of these regulations and governing agency compliance requirements, how it applies to your business or agency, and how your current security policies, procedures, and controls need to evolve to support the “cloud” services delivery architecture that may employ compute platforms on community and/or shared public infrastructure.

Public infrastructure, software, and platform as-a-service providers will invest in the tools, technologies, and processes to maintain compliance; however these service providers will not typically indemnify or hold harmless the client whose information they are hosting. This creates a tremendous exposure level to the organization with regulated information, as they do not have management oversight of the underlying infrastructure, yet they are still accountable to the governing bodies for any fines, sanctions, and/or brand damage due to a breach of regulated information.

I have found that, even outside of the “cloud” services delivery model a fundamental exercise around securing information is rarely executed or observed, which is data classification and assignment. Fundamental security revolves around these two functions. Data classification the process in which information is classified based on its sensitivity to exposure. From company confidential to public, and anything in between, information must be classified on an ongoing basis in order to properly understand how its compromise would affect the organization’s sustainability, compliance, and brand.

In order for data to be classified, data custodians and/or data owners must be identified and assigned. These “data managers” have the responsibility of working with the governance team to identify the data classification for data management. Often times, structured data can be classified simply by matching the data set to the regulation or governing body. It is the unstructured data, or data that is not necessarily monitored or regulated by a governing body that is difficult to classify, and needs to be managed and coordinated with internal organizational resources to assure the correct controls are applied.

As a result of the legalities, it is often safer to host regulated information on a private cloud infrastructure. While it is possible to find providers that may provide some relief in the event of a breach, the one thing the providers cannot indemnify an organization from is the negative publicity due to the breach.


One of the benefits of “cloud” is elastic capacity. This provides for the model that if the private compute infrastructure owned by an organization hits its capacity, applications and/or information can transparently scale to additional infrastructure, be it private, community, or public.

The major technology issues that we see are more product specific than technology specific. Manufacturers are focusing on enhancing their product portfolios by creating features that are only available when integrated with their other products. The challenge this creates is that in a cloud service delivery architecture, where some of the infrastructure is provided in a pay per use consumption model, the premise technology may not be compatible with the hosted technology. This creates functional limitations of the cloud architecture rather than being simply a technology issue.

For the most part, however, the technology issues of cloud are not actual technology issues; rather they end up being misalignment of technology to business requirements. Certain elements of the cloud service delivery architecture are revolutionary, while other elements are evolutionary. In order to capitalize on the full benefits of cloud service delivery, policies must be modified, service catalogs defined based on business need, and support models need to be modified to support the new consumption strategies as well as the consumer owned devices that are being used to access them.

Thankfully, initiatives such as OpenStack are providing for cloud based operating systems that normalize the features that define a cloud based service delivery architecture, and many manufacturers are aligning with these initiatives. This alignment is allowing organizations the ability to create private cloud architectures that are able to fully utilize the elastic capabilities by scaling into community and public cloud architectures that are also compliant with cloud operating systems such as OpenStack.

Private versus Public

Two of the burning questions that organizations are dealing with today are what the benefit of private versus public is and what the risks of pubic versus private are. The challenge is that for each organization, and even each department within an organization, the answers are vastly different. Here are some of the considerations that have to be taken into account.

  1. Public cloud
    1. Public cloud infrastructure is managed by someone else. This tends to allow the IT department to focus on the components of technology that they need to focus on, without having to concern themselves with many of the underpinnings.
    2. Capital costs are significantly reduced with public cloud models. That is because the organization does not have to invest in the infrastructure components, and typically they will pay for use in some capacity. Examples of pay by use would be, per user, per gigabyte of storage, per compute cycle, or some other element of measurement depending on what is being consumed in the public cloud.
    3. The higher in the delivery stack, the less customizable the architecture.

i.       With infrastructure as a service, where you are typically paying for compute resources, the architecture is heavily customizable, however the administration of the elements within the architecture have no service level agreements. In this model, organizations are typically leasing compute, disk, memory, and network, and supply their own operating systems, applications, and customization. While this provides the most customizable environment, much of the management falls back to the organization’s IT department.

ii.      With platform as a service (ex: Amazon Web Services, Microsoft Azure), the flexibility is still pretty high, however these services are typically for offloading workloads. Your control is typically limited to the workload itself and the underlying operating system and configurations are managed by the platform provider. These environments provide for the redundancy, automated provisioning,

iii.      Software as a service is the least customizable option, but provides for specific information access and delivery. Software as a service is often used for outsourcing specific applications whereby reducing or completely eliminating internal IT support resources. Examples would be hosted collaboration,, payroll applications, etc.

  1. Companies have no control over the processes to which security controls are applied, only that those security controls are validated through third party audits. This can create some challenges if there are additional controls required that do not fall within the framework of governed information. Many times, partner companies can require additional levels of security in order to maintain a business relationship, and public providers are usually less flexible when it comes to allowing for custom controls.
  2. Elasticity in a public cloud is usually inherent, and the consumer of the cloud service only has to pay for the use of that elasticity. Multi-instance and/or multi-tenancy strategies of cloud hosting providers, there are tremendous economies of scale that allow for compute resource sharing.
  3. Public cloud providers are typically a “one-size-fits-all’ model for protecting your information. The analogy I use is: Suppose you are shipping a stuffed animal. The shipping company will only provide protection for the absolute value of the item being shipped. The stuffed animal could have been a gift from a close family relative of yours that recently passed away. The relative value of that stuffed animal is much higher. The shipping company will still only provide for recovery to the replacement value. The contextual value is not covered.
    Public hosting providers can only provide protection that your data will be there and secure. If the data that is compromised would be the detriment of your business if it were compromised, the cloud provider will not provide for any additional recovery or relief. This means that heavy consideration must be placed on what information, applications, and workloads are moved to public cloud environments.
  4. There are no assurances that the public cloud provider will continue to provide the type of environment necessary for you to continue to effectively run your business in their environment. If you think back to how your company leveraged technology five years ago, I would suspect it is wildly different than today. This would indicate that how you use technology five years from now will also be different. Cloud providers may not move their environments based on your specific needs, rather the needs of the many in the market.
  5. Private Cloud
    1. Private cloud environments require the organization to invest in all of the underlying compute, power, cooling, and real estate required to support their needs. This cost is either capitalized expenditure or operationalized expenditure in the form of lease, etc.
    2. Items such as support, monitoring, etc. for the private cloud can be outsourced; however it is all an incremental uplift in cost.
    3. Private cloud environments are heavily customizable, and can be built to support the exact needs of an organization.
    4. All security, compliance, and regulatory governance are the responsibility of the organization.
    5. Elasticity comes in either the form of over-investment of infrastructure to support unplanned demand, which is often difficult to estimate, or is provided through a connection to a public provider, thus creating a hybrid cloud model.
    6. Organizations can customize the level of protection they apply to their information, applications, and workloads based on the significance of the information to the business.

There are many other pros and cons to public versus hybrid, but these are just of few of the significant characteristics of each.


It is impossible to assign cloud service delivery architecture to an organization without full understanding their business needs. More often than not, we find that while many applications and workloads can be outsourced to a public cloud provider, many workloads are too sensitive, and require the need to be insource managed in order to maintain the sustainability of the business from a security and recovery perspective. This tends to lend to hybrid cloud service delivery architecture.

The important first steps are to determine your “cloud readiness”. This involves understanding what your current capacity is for supporting the technical characteristics as defined by NIST, as well as your need to deliver the services as defined in the graphic above. Not every organization is ready to support cloud service delivery architecture, but more importantly, not every organization needs to support cloud service delivery architecture.

Also See: 

Steps To Success With Private Cloud Computing Initiatives

Johan Milbrink, Data Center Practice Manager

The following is one of a collection of articles that addresses strategy around hybrid cloud architecture and IT as a Service.

The IT industry is once again undergoing another great transformation. Cloud computing, by replacing operational heroics with business driven speed and agility, will spur a lot of innovation. As an IT leader for your organization it is important you ask yourself, “Are we ready? Are we, as an organization, well-suited or ill-suited for the future of IT, and can we afford not to be ready?”

Many legacy data centers are built on old technology that just wasn’t designed for the demands and pace of today’s business.  Many IT organizations are therefore ill-equipped to meet business requirements for faster service delivery. Their process is manual, cumbersome, inconsistent, and often takes a week or longer for the end-to-end delivery of the requested service. But cloud computing has the potential to turn that complex and drawn out delivery process on its head and make it fast, agile, self-service, and on demand.

Presidio has developed methodology around helping our clients achieve success on their journey to cloud. Too often, inquiries and discussions concerning private cloud computing start with: “What technology should I buy?” But as with virtualization, the real challenges with private cloud computing lie with processes, business management and people. Private cloud computing is primarily a change in the relationship between IT and the business and a change in how IT is managed and funded.



The journey starts with forming a cloud computing strategy that is right for your business, and that has executive level support and consensus. From that context, a cloud computing roadmap and execution plan can be formed. Every private cloud computing initiative requires supportive leadership and executive support. This is because cloud computing affects the relationship between IT and the business, how IT is consumed, and the jobs within the IT organization. Overall it requires a change in culture and processes. The organization leaders must all buy-in to the strategy and collectively help drive these changes past any organizational friction. The alternative is an unsuccessful initiative.

The next step is to identify the roadmap components that align with the cloud computing strategy. A set of individual projects tailored for your environment must be designed, initiated, and executed - sometimes in parallel. These projects will address the areas of finance, infrastructure, organization, policy, security, and applications. All of these areas must align with your strategy.

Step three is to design the service catalog and self-service portal. Carefully assess, understand, plan, standardize, and re-evaluate the services IT needs to offer on demand to your organiza-tion including what services will be used, who will use them, and how will they be used? Make the self-service portal as easy to use as possible to drive stickiness and adoption. The importance of this cannot be overstated. If you do not drive adoption or offer the right services, your cloud initiative is almost guaranteed to fail. This warrants spending time with your end users to clearly understand what services to offer them and how to make the consumption of those services as easy as possible. We’ve found that a great job on the first project results in positive word-of-mouth and increased adoption.

Next, adopt a phased and targeted approach. Instead of biting off more than you can chew, move from limited test to small pilot to larger production implementations over a period of time, learning along the way. This phased approach enables gaining experience in running and supporting a cloud while expanding your readiness. Unanticipated events related to end user behavior or requests, necessary changes, or technical glitches can more easily be addressed when a project is implemented in phases. Additionally, a phased approach will allow you to establish clear project objectives and be very targeted during the initial implementation, addressing for exam ple a small part of a test/development environment, rather than a bigger environment with more demands.

Once the foundation of your cloud is in place, you will continually be improving the infrastructure. This requires lifecycle management, asset management, configuration management, usage metering, and event monitoring. These complementary services ensure that you can build an enterprise class, mission critical cloud. Initially, you can start with a shared infrastructure and portal to validate that you can actually provision services. Once you showcase that the cloud works, you can surround it with service management and business management.

Another important step is to evaluate and select a cloud platform that is Enterprise-class, extensible, and can easily be customized to offer the services the end users in your organization need. The core platform on which to execute your journey to the cloud should require no future fork-lift upgrades in order to scale, and it should offer multiple service and deployment models. It should be an extensible framework on which to add functionality for your enterprise and datacenter such as: image management, multiple hardware vendors, multiple hypervisors, CMDB and ticketing integration, financial show-back, and chargeback.

Using a house construction metaphor: before all else, a builder must ensure that a strong sub-foundation and foundation are in place, whether building a new structure, adding to an existing one or making renovations. The sub-foundation and foundation must be able to support any new construction or changes added to an existing building. The solid sub-foundation is essential in order to support the foundation that supports the house. The cloud platform should be viewed similarly. Take some time to compare and contrast different cloud platform vendor offerings and make sure your selection meet your organization’s strategy, roadmap, and service requirements. Selecting the wrong platform may prove to be a costly mistake and it could be difficult to recover.



FORM A STRATEGY THAT HAS BUY-IN. Getting support, inspiring employees, driving organizational changes, and overcoming objections are all critical to a successful private cloud computing initiative.

IDENTIFY SPECIFIC COMPONENTS WITHIN THE ROADMAP. Ensure that individual projects are in alignment with the overall strategy.

WORK WITH END USERS. Determine the standard offerings to deliver in a private cloud by that provide quantifiable business benefits. Focus on providing services that are easy for the end user to consume.

START SMALL. Using a phased approach, start with a simple private cloud service offering with minimal support needs. Use these pilot services to discover what additional services and capabilities are in high demand, and evolve the private cloud over time.

COMPARE/CONTRAST CLOUD PLATFORM SOLUTIONS. Select the one that makes sense for your organization’s cloud strategy and offers the most scalability and extensibility.


STEPS TO SUCCESS WITH PRIVATE CLOUD COMPUTING INITATIVES is one in a series of articles that create the conversation of “High Availability in a Hybrid World.” These assets are meant as a resource for IT decision makers who are faced with the challenge of creating either a hybrid cloud or IT as a Service strategy.



Hybrid cloud is a composition of two or more clouds (private, community or public) that remain unique entities but are bound together, offering the benefits of multiple deployment models.  By utilizing hybrid cloud architecture, companies and individuals are able to obtain degrees of fault tolerance combined with locally immediate usability without dependency on internet connectivity. Hybrid cloud architecture requires both on-premises resources and off-site (remote) server-based cloud infrastructure. Hybrid cloud provides the flexibility of in-house applications with the fault tolerance and scalability of cloud based services.



(ITaaS) is an operational model where the IT organization of an enterprise is run much like business, acting and operating as an internal service provider. In this model, IT simplifies and encourages service consumption, provides improved financial transparency for IT services, and partners more closely with lines of business. This type of IT transformation is business focused rather than cost focused, leading directly to improved levels of business agility. Typically, ITaaS is enabled by technology models such as Infrastructure as a Service (IaaS) and Platform as a Service (PaaS), all of which are part of cloud computing.


For more information please contact us at