Is Your View of the Cloud Still a bit Foggy?

Posted By:  Steven Reese
Posted Date: 

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.