Cloud 101 – Private, Public, Hybrid and Community

Cloud computing is one of the top 5 priorities of almost every CIO out there today. While the benefits of the Cloud have been documented fairly extensively, I want to take it back to basics with this series of Cloud 101 posts. I will be looking at a definition for the different types of cloud and also write about some of specific challenges that can be addressed for clients in the Middle East.

Let’s start with an illustration.

Public, Private and Hybrid Clouds in one shoddy picture

Private clouds are developed to host services that are consumed internal to an organisation. In plainer English, a company’s IT department would deliver their technology services to the different departments in the company via a private cloud.

Public clouds are developed to host services that are consumed externally to an organisation. Companies that develop public clouds are referred to as service providers and can provide services to other organisations as well as individual consumers. Two examples of public cloud offerings in the Middle East that are making waves are Vodafone Egypt’s Sherkety and the Etisalat/Pacific Controls partnership.

Hybrid clouds are slightly different in that they are not a discrete construct but rather consist of a private cloud and a public cloud that can be linked together to enable workloads to move between the two clouds. For example, if my internal IT department is maintaining a file share for me to store all my documents and are running low on space, instead of waiting the standard 6 – 8 weeks to purchase more storage, they can temporarily expand this file share to use some storage hosted in a service provider’s public cloud.

There is one more type of cloud that also emerging and that’s the community cloud. This type of cloud is one that is shared amongst a limited number of organisations with shared values or requirements and a collaborative goal to reach. Examples of shared requirements for a community cloud can encompass shared governance and policy compliance needs or security. From my experience, the line between community clouds and hybrid clouds is very blurred and so I will be concentrating on hybrid cloud development until we see a larger community cloud demand that cannot be fulfilled through a hybrid cloud.
Typically, community cloud environments are favoured by national governments that are looking to provide shared IT between their different departments.

So now we’ve covered where the different types of cloud live and a very high level description of what there are used for, it’s time to go into a bit more detail on what makes up a cloud. The National Institute of Standards and Technology (NIST) is a US government agency which has set the standard for a cloud definition with the following:

 “cloud computing is a model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction.”

Well that makes things much clearer, right? Ok, let’s dig a little deeper. NIST also lists five essential categories that make up a cloud:

  1. On-demand self-service
  2. Broad network access
  3. Resource pooling
  4. Rapid elasticity or expansion
  5. Measured service

On-Demand Self-Service

This is a service consumer’s ability to provision, decommission and modify a service easily at the point of requirement. That statement is still not as clear as it should be so we need to decompose it a little.

The on-demand characteristic refers to the ability to provision, decommission and modify a service in real-time. When you do something to the service, it happens then and there, rather than waiting a period of time for someone else to analyse the request, take some actions and then get back to you. A good example of this is Gmail. When you sign up and request an email address, it is provisioned automatically within a matter of seconds.

The self-service characteristic refers to the ability to carry out the provisioning, decommissioning and modification actions yourself. This is the difference between making a request to the IT department of your company and logging into a portal and selecting the action yourself.
I’ve mentioned a portal, that’s quite an important concept, I’ll talk a little more on it later on.

On-demand and self service are the biggest drivers for cloud adoption that I am seeing in the Middle East. SMBs and enterprises (non-service providers) are looking for these abilities to decrease their time to market and their IT departments want to become much more responsive to the business side of the house. This will open up market share advantages and increased customer loyalty.
Service providers are reacting to this demand and specifying that the new services they release are compliant with the self-service, on-demand model.
Individual consumers are the most demanding of the lot. They have a huge magnitude of choices on the marketplace for services to consume and they don’t want to have to pick up the phone or wait hours, let alone days, to get the services they have purchased with their hard earned cash.

Broad Network Access

This characteristic covers two related questions – “Where can I access my service from?” and “What can I access my service on?”.
SMBs, Enterprises and individual consumers do not want to be limited by what devices they should use (e.g. desktops, smartphones or tablets) or specific network mechanisms required (e.g. VPNs or dedicated network links) to access cloud services.

Withing the corporate world, the need for broad network access is being spearheaded by the bring your own device (BYOD) initiative. In every client meeting I participate in, at least one attendee is accompanied by their own personal tablet.
I, myself, work on a laptop, a Blackberry, an iPad and a HTC mobile device. One of my main criteria for choosing a service to purchase from the cloud is how many devices will it support and will I have to modify my standard workflow because one of my devices is not on the list.

While employees love the flexibility of BYOD, security teams are often pulling their hair out over issues such as data leakage and a loss of control over the boundaries of their corporate security policies. A successful cloud service is required to directly address these concerns to stand any chance of being adopted by the enterprise market.

An interesting side effect of broad network access is the push towards higher and higher mobile bandwidths from telecoms operators. GPRS to 2G to 3G and now 4G are being provided directly off the back of more and more people consuming cloud and web hosted content on the go.

Resource pooling

Resource pooling is a cloud design consideration where technical resources such as servers, storage and even software are combined into a pool from which multiple services and users are hosted. These resources can be used much more efficiently in a pool as it drives up utilisation of the resources and therefore, as an infrastructure owner, you get more value for your investment.
For example, if I purchase email as a service from Microsoft (either through Hotmail or Office365), they will not spin up a dedicated server with my own dedicated instance of Exchange to host my email. My service will be residing on shared infrastructure and even an instance of Exchange shared by multiple users. That infrastructure (servers, storage, network, etc…) will probably also be used to host other services such as SharePoint with it’s own set of users.
One of the best known and most widely used mechanisms for creating resource pools is virtualisation. Utilising VMware, hyperV or one of the other virtual platforms will enable you to create a shared server resource pool while storage virtualisation technologies exist today to enable you to create heterogeneous storage pools.

One of the foremost requirements I am seeing from clients who are building public clouds with shared resource pools is federation. This is the ability to combine public cloud resources with a customer’s private cloud resources. In a nutshell, it is the ability to extend a private cloud into a public cloud so that resources can be consumed easily.
With that ability, comes anxiety. If you are building a public cloud with federation in mind, you need to assure your customers that there is no chance of their assets leaking out into someone else’s cloud. A strong cloud security model needs to be built-in and communicated effectively to potential customers.
Federation may seem like a corporate concern for organisations creating hybrid clouds, however there are examples of cloud federation for individual consumers – Oxygen Cloud provides storage as a service to individual consumers and gives the ability to federate the storage pool it provides in the cloud with a portion of your hard disk to create a bigger pool of storage for you to utilise.

Rapid elasticity or expansion

This is the ability for a cloud to expand or contract based on a customer’s immediate requirements.
Jeff Barr has written a great article on how President Obama used the cloud for his 2012 presidential campaign that illustrates elasticity perfectly. The campaign IT team were able to ramp up IT services as the election cycle progressed and at the end scale it back down to save on costs. Imagine what the IT cycle would be if they had to follow the usual design-procure-implement-manage process and what would they do with all that infrastructure when it was no longer needed.

Elasticity is integral for both private and public clouds as in both cases, nobody wants to suffer the wrath of their users when they can’t get the service they want because they are waiting for you to design, procure, implement and manage.

Measured Service

This is the ability to measure the usage of a service in terms of value, typically how much is it costing me to consume this service.
In traditional models, you go to a website and purchase a package and that amount is what you pay, regardless of what your utilisation is. Taking into account elasticity, the cloud model needs to show a customer exactly what is being consumed and how much it is worth. Measuring this becomes a complicated affair as the service being consumed is on a shared infrastructure (resource pools) and has been modified based on the demands of the customer rather than service provider packaged offerings.

There are two mechanisms for demonstrating measured service:
Charge back – Taking money from a customer based on their service utilisation. This is being used by service providers to monetise their public cloud offerings and internal IT departments to decentralise their IT budgets for private cloud service offerings.
Show back – showing customers the financial value of cloud services being consumed. This is used by internal IT organisations, primarily in the enterprise segment to curb uncontrolled demand for technology resources from their business units.

There is a subtle mindset change that is taking place because of the measured service characteristic.
In the traditional IT lifecycle, investment over time formed a series of steps – a large up-front investment is made to provision the service whose total cost of ownership (TCO) is based on an initial estimate for the number of users of the service and is only realised as this estimate is met.
Instead with the measured service characteristic of clouds, relatively small investments are made to provision these services and this cost only grows if the service usage increases. This means that TCO is realised from day one.

So What Does a Cloud Offer?

Throughout this post I’ve made reference to cloud services and given a few examples of cloud service providers and specific offerings. Cloud services can be categorised into three main definitions (again, thanks to our friends at NIST):

  1. Software as a Service (SaaS) – Full applications (and associated application data) that can be accessed through a front-end (usually web based) over a network. Unlike traditional software models, you don’t pay for a license, you pay for the ability to use the software
  2. Platform as a Service (PaaS) – A set of packaged technology components that can be utilised to develop and deploy an end service in the cloud. For example, when I purchased hosting for this blog, I didn’t get this website. I was provided with a set of tools including some storage, a database, a blogging platform (WordPress) and some management tools. I had to put some work into developing the site from these components.
  3. Infrastructure as a Service (IaaS) – Raw technical components such as a virtual machine, some storage space or some backup space. In some cases this can be a little more featured, for example, Desktop as a Service can be considered as a type of IaaS.


Sharing Options

  • Twitter
  • LinkedIn
  • Google Plus
  • Facebook
  • Reddit
  • StumbleUpon
  • Delicious
  • Email

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>