Different flavors of IaaS

Commodity vs. Enterprise Class IaaS is one of my favorite topics around Cloud. Both have similarities & differences and very often question that is being asked is: which is better? The answer is not around being better or worse - as both types of IaaS have different purposes. Commodity IaaS is intended for webscale applications and is mainly consumed by software developers and startup companies - who are writing a code for a specific cloud. Enterprise Class IaaS is intended to host enterprise class applications which can be moved from enterprise data centers into cloud to leverage on the new consumption & delivery model.

If you want to hear more - please come and join me on Cisco Live 2013 in London where I'll be hosting breakout session:


BRKSPG-2686: Different flavors of IaaS

Abstract:
Observing the IaaS marketplace and solutions which are being used to deliver IaaS - we found that there are multiple flavors of cloud. If we look on customer demands and expectations we can differentiate two main concepts: Commodity IaaS and Enterprise Class IaaS. Both clouds are compliant with cloud definition by NIST - but differ from architecture & implementation perspective. The goal of this session is to present similarities and difference of both flavors bringing special focus on infrastructure design which is main difrerentiator.

Tuesday, January 29, 11:15-12:45

South Halls S10 Room 22

Essential features of Enterprise Class IaaS (ECI)

Cloud is everywhere. If we'll make an analysis which IT news are making most of headlines - I bet "cloud" will be one of top 3. We see lot of interest out in the field as well. Service Providers (CSP's) are sending questions, RFI's or RFP's - trying to figure out what's available on the market for building public clouds. When meeting prospects first thing I'm trying to understand is "which cloud" they're trying to build and who's going to be target consumer of this cloud. According to my analysis - we have at least two major cloud concepts: Commodity Cloud & Enterprise Class Cloud. I'd not discuss Commodity Cloud as most of clouds being dicussed and build are Commodity Clouds (Amazon EC2, Openstack based clouds....ect.) I'd like to focus on Enterprise Class Cloud. There's no firm definiton and common vocabulary however there are number of features which are essential to Enterprise Class Cloud.

 

Feature #1: Target Consumer

First and foremost feature is TARGET CONSUMER. Target consumer for commodity cloud is software developper - often called DevOps - who wants to write webscale application and does not want to deal with infrastructure complexity. It takes an API (Amazon EC2 API for instance) and with few lines of code provisions relevant infrastructure that will host his application. This is not what an average enterprise user will be looking for. Enterprise user is hosting lot of "legacy applications" which have very specific infrastructure requirements like: resiliency, QoS or security. In most of the cases, applications are not "horizontally scalable" and are hosted in a single VM - therefore VM security is a paramount. In webscale applicaitons written for cloud VM is only a "small element" and application can withstand single or multiple VM outage. It's not a case in enterprise environmemnt.

Summarizing, enterprise class cloud shall provide automation for very complex network environments which are compatibile with what enterprises have currently in their datacenters. It's not only limited to virtualized infrastrcuture but as well shall cover physical rotuters, switches, ladbalancers and firewall to comply with security audit requirements.

 

Feature #2: Infrastructure

We have defined target consumer and now let's try to figure out infrastructure requirements. For commodity clouds most important thing is scalability to host hundreds of thousands VM's - hence networks for commodity clouds are based on L3 architectures without redundancy. Redundancy in most of the cases is being handled on "regional/datacenter" level. This is possible because redundancy in commodity clouds is being built in application logic. This is not a case for enterprise customer. Application running on VM must be SAFE and VM continuity is a key. Therefore we need to have fully redundant network infrastructure where underlying components outage will protect VM running on hypervisor. This is being handled on multiple levels: networking & hypervisor level - as enterprise class applications very occasionally are horizontaly scalable and in most of cases are running in single VM. Summaririzng, enterprise class cloud must provide compatibility with what enterprises are having in their datacenters in order to be able to move workloads to new operational model: cloud.

 

Feature #3: VM backup & restore

We mentioned that VM protection is a key in enterprise class cloud - therefore besides of network & hypervisor protection later - we need to provide facility where user can easily make backup & recovery of his VM. Most of the systems on the market are only dealing with VM provisioning & deprovisioning - leaving backup&restore for other 3rd party tools. In my opinion easy backup & restore is absolutuely essential and there must be a feature that by single click is enabling us to make VM backup on demand - or schedule backup to happen in off-peak hours. Havign said that Enterprise Class Cloud platfrom shall be seamlesly integrated with backup & restore applications. This is irrelevant for commodity cloud - as in commodity cloud VM is running only piece of code - therefore backup policies differ from enterprise requirements.

 

Feature #4: License Management

Bare VM is definitely not an offering which is of enterprise customer interest. Enterprise customer will be willing to purchse/consume VM+applicaiton stack on it - which includes operating system. Having said that, cloud platform needs to provide license key management. When consumer is purchsing an application then must have a choice to buy application license which needs to be taken care of by platform. This creates whole revenue chanel for SP by having extra license sales channel. For private cloud it's irrelevant as very often enteprises are using ELA's and they're being tracked by ITSM inventory tools. For public cloud it's bit different as you need to deal with licensing on multi tenant basis.

 

Feature #5: Service Assurance

Enterprise class user will be hosting enterprise class applications externally (in a cloud)  - therefore service assurance is an essential part. Customer needs to know how infrastructure is performing, heat maps & trending is highly regarded. Simple metrics about CPU/Memory are not enough in enterprise class cases. Systems must provide robust & complete analysis - otherwise enterprises will not move mission critical applications to the cloud.

 

Of course this list is not definitive. It's listing features of enterprise class cloud that I personally find essential. I'd try to list other features in comming blog posts.

Commoditization on CMP(*) market.

(*) CMP - Cloud Management Platform

Let's start with a bit of definitons:

1.  "Commodification (also called commoditization) occurs as a goods or services market loses differentiation across its supply base, often by the diffusion of the intellectual capital necessary to acquire or produce it efficiently. (Source: http://en.wikipedia.org/wiki/Commodity)

2. CMP (Cloud Management Platform) are integrated products that provide for the management of public, private and hybrid cloud environments. The minimum requirements to be included in this category are products that incorporate self-service interfaces, provision system images, enable metering and billing, and provide for some degree of workload optimization through established policies. More-advanced offerings may also integrate with external enterprise management systems, include service catalogs, support the configuration of storage and network resources, allow for enhanced resource management via service governors and provide advanced monitoring for improved "guest" performance and availability. A key ability of these products is the insulation of administrators of cloud services from proprietary cloud provider APIs, and thus they help IT organizations prevent lock-in by any cloud service or technology provider. The distinction between cloud management platforms (CMPs) and private clouds is that the former primarily provide the upper levels of a private cloud architecture, i.e., the service management and access management tiers, and thus do not always provide an integrated cloud "stack" (Source: Hype Cycle for Real-Time Infrastructure, Gartner 2011)

As we can see, in order  to be commoditized you needs to lose differentiation and this something that I'm observing in CMP market. We have number of CMP platforms available. Some are commercial (vCloud Director, Abiquo, Nebula) and some are opensource (Openstack, Cloudstack, Eucalyptus). Even they differ in some areas - the core functionality is very common: deliver VM's on demand and provide robust API for it. By purpose I'm not drilling down into other features as those mentioned are most relevant to topic I'm going to develop.

"VM on demand" - this is to me good characteristic of Cloud Management Platform - as this is something that was a starting point for Amazon EC2 and it's a starting point for many followers. Famous "DevOps" term (which is characterizing application development teams who are taking ownership of infrastructure  operations)  was born actually in Amazon where dev teams were given an API for infrastructure in order to facilitate process development.

Question I'm asking myself whether "VM on demand" is a service by itself for business customer. I really doubt it. Business customer is looking for something more business oriented. For something that is more aligned to his business processes. Good example of business customer is IT departament - who was tasked by company board to introduce cloud to the company. They will be looking for an operator who will provide do them "business service" no only bare VM. They will be looking for virtuak servers which are wrapped in service contracts & SLA. Very often they will be looking for clever application datastore from which they will be able to install applications. They will be asking what infrastructure is underneath, whether is redundant and how many levels of redundancy it have. Compliance checks are absolutely essential. This will be all needed before they move their business applications into given cloud.

Having said that - we need to wrap VM's into something more elaborated to become business service. Hence the need for smart service catalog which will help create those business services. Business users - are expecting business interface - not just API - which is mainly for DevOps/techies. Having said that CMP is only a subset, building block for Service Providers and Enterprises who want to build business oriented cloud for business users.

In order to build whole service delivery platform we'll need the following building blocks:

• Business Portal (Marketplace) and Service Catalog
• Orchestration Layer that orchestrates following domains:
  • Cloud Domain - manage Cloud Management Platform which provides "VM's on demand"
  • Network Domain - that automates network infrastructure (whole suite is not only set of virtual networks but as well whole chain of real switches, routers and service appliances like loadbalancers and firewalls.
  • Physical Compute domain - something that automates baremetal servers
• Physical Storage domain - something that manages block storage (which later on can be turned into filesystem

Of course we expect from Service Delivery platform good enforcements for business processes like: approvals, delegations of authority etc.... Alltogether it should represent business oriented solution which is catering for business users.

Summarizing, it's not enough to take from the market CMP to say that "we build a business cloud". CMP is a commodity and they only cloud you can built with it is a commodity cloud. In order to differentate - you need to focus on what business user is looking for and to do that you need to build whole business oriented  service delivery platform where CMP is only a small component.

Why it's a bad idea for SP to compete with Amazon? (*)

(*) SP is a connection service provider who provides managed services to it's customers.

Following Amazon sucess with EC2 everyone wants to jump on Cloud bandwagon and repeat that success. SP's are no different. They suffer from declining margins and are looking for new opportunities to secure the revenue. Unfortunatley  "EC2 type" of cloud  (called later on "commodity cloud") is a bad idea to pursue. This does not mean that there's no opportunity in a cloud for SP's. Of course there is but in a bit different type of cloud.

Why it's a bad idea for SP's  to compete in "commodity cloud" space?

First we need to define who's SP regular customer. In most of the cases it's enterprise or SMB customer who's already subscribing number of services for their businesses. It's used to quality service support and willing to pay the premium for good SLA it guarantees business continuity. If we look on Amazon regular customer - in most of the cases it's a software developper in a form of startup or well established software house. It's not hard to imagine that those two types of customers have very different expectations and demands. Developpers are hardly willing to pay the premium. They will figure out hundreds of ways to customize their applications in order to avoid the premium.  Having said that commodity cloud consumer is looking for relatively simple and not expensive service.

Second thing is commodity cloud compatibility with enterprise class customer demands. In most of the cases enterprise customers are running "legacy applications" which very often are only vertically scalable. Those kind of workloads are hardly portable to commodity cloud due to it's lack of compatibility with cloud architecture.

Going further we need to look on scale. Commodity clouds are leveraging on scale effect.  Amazon is lowering it's prices few times a year - but they really can afford it. The reached critical mass  and their runrate business is reaching $1B.  Quite a lot - but let's see how many servers are needed to run this cloud. Amazon is not sharing this data but according to some analysts they manage over 500k physical servers and over 1.5M IP addresses. No wonder they are leveraging on scale effect. 

Last but not least: innovation rate. Amazon is introducing couple of  new features per month. This is something which is bit odd for SP's who are providing Managed Services.  Usually their processes are constructed to introduce new feature once per few months.

As we can see, there's number of incompatibilities between commodity cloud and SP. But where's "the beef" for SP's ?

I see an opportunity in selling VDC's (Virtualized Data Centers) - where enterprise customers can leverage on the new consumption & operational model that cloud is providing to them (cloud is operational model and technology is only enabler). Enterprise customers can request by themselves chunk of infrastructure - I'll call it container - which is compatibile with container in their datacenter. Such container shall contain elements that are currenlty used in enterprise datacenter like: multiple L2 segments (to host multitier applicaitons), firewalls & loadbalancers. Some of them can be virtualzied but some of them must remain physical (for security & audit reasons). We shouldn't forget that container must be stand up on fully redundant infrastructure (something missing in commodity cloud). As we can see there's whole lot of infrastructure automation - as cloud is all about automation.

Why this is needed? Because cloud is a journey. Sooner or later all will migrate to commodity cloud - but before that happens - enterprises must rewrite their applications to be "cloud compatibile". This will not happen overnight. Therefore I see an opportuinty for SP's to help enterprises transition into that space.

Will SP's make millions on it? I really doubt it. But we need to take into account that for SP's very important is customer loyalty and stickiness. Very often reffered as "churn". The more good services you provide to customer - the less likely customer is willing to move to another SP. This is something that we shouldn't underestimate.

Inevitable cloud outages

Few weeks ago market was boiling hot with news and analysis on Amazon EC2 outage. Microsoft Azure was no different. They faced an outage as well. I'd bet that smaller cloud providers are facing this more often but due to it's local nature - we do not see it much in media. There were number of blogs and analysis trying to figure out whether cloud can be more robust or redundant. Some of blogs were pitching hybrid clouds as a remedy. Some were asking for more governance improvements (as yes, most of outages were caused by human factor)
Let's face the truth: cloud infrastructure is designed to fail!
If we look at architecture designs, the most important aspect are scalability & cost - which are not going on par with redundancy I'm afraid. This does not mean that applications running on cloud will be impacted. It's really up to application developer to take into account cloud architecture and design application in a way that can cope with cloud outage. If we take for instance Amazon EC2 - they have number of mechanisms which  used properly shall provide robust applications running on EC2. Multi-region zones, availability zones, load balancers etc. There's very nice whitepaper describing how to build fault tolerant applications on AWS. As we can see - responsibility shifted from infrastructure provider into application developer - and this is major change that comes with cloud.
If we take legacy datacenter application and we try to move it into the cloud - we will have very unpleasant surprise. Legacy applications are mainly designed with assumption that they're running on redundant infrastructure. Of course some of them are clustered in order to withstand single server failure but in most of the cases legacy applications are only vertically scalable monoblocks. Cloud applications are different beasts. They're horizontally scalable entities and this makes a difference. When we add distributed load balancers that balance traffic into different regions - we should be safe when single availability zone or even region goes down. Of course it comes at price but it's different story ;)
Having this distinction in mind - I very often characterize cloud as two different flavors: commodity cloud and enterprise class cloud. The first one is targeted for developers who need to design applications with given cloud architecture in mind. Commodity cloud infrastructure is built in a very specific way and it's designed to fail. Enterprise class cloud is bit different. It uses the same consumption & operational model ("as a service, on demand. self service") but it's designed to host legacy applications in it. It's infrastructure is redundant and maybe less scalable but more robust for sure.
If you're interested how commodity clouds are being built, there are nice resources on www.referencearchitecture.org - especially networking part - as in fact it's network that makes a difference. There's very good lecture from one of OpenStack Summits: Discover Diablo Networking Mode

Summarizing, commodity clouds are designed to fail - but it does not mean that it's something bad. We simply have responsibility shift - which is now on developer to cope with it. It's like power supply to our home. Who does have redundant cables from separate power supply companies coming to your home? Likely no one. It's upon us to secure continuity for our servers at home, hence we buy UPS'es. Cloud is utility. Let's face it :)