A Community Cloud: Real-World Example

When I first heard the term "Community Cloud" I shuddered. I thought: Just what we need... another cloud definition.

But I had a peek at one yesterday speaking with an established services customer (who must remain anonymous for the moment). They got their start building a co-location facility for companies in their specialized and highly-regulated industry.  But it became obvious that they could add more value as a service provider than just supplying a cement slab, cooling and electrical outlets.

So they've set out to create a raw cloud IaaS infrastructure, but with some attributes that are specific to the community/ecosystem that they serve:

• Security: Access to the cloud is granted only after a trusted validation of identity (required by regulating bodies) - and certain out-of-band management functions can only be made over hardware VPNs.
• Availability: Cloud resources are available at roughly a five-9's level (or better) including complete fail-over and DR sites - this is uber-Enterprise-Grade availability.
• Performance: Because of the specialized industry, the processing and networking performance of the cloud is optimized for high transaction rates and extremely low-latency.

Most other cloud properties, such as elasticity and metering are as you would expect.

Because of the special attributes, the company aims to become a special-purpose Cloud Service Provider to its industry - something that a generic AWS, Google or Rackspace could never be. And many other firms in the industry -- large and small -- will likely find both economic and performance advantages to host in its infrastructure.

Then, things really got interesting...

In addition to the raw IaaS they'll provide, they also plan to provide a special-purpose PaaS to tenants. For example, most clients will tend to use a common set of "Big Data" - ranging in size from Terabytes to Petabytes. If each tenant maintained their own instance of this data, it would be massively costly, inefficient and complex. So instead, the company will host a single, on-site shared instance of the data, charging for its access and use by users of the cloud. And they expect to offer a wide range of such PaaS services in the future.

What does this example say to me?  That (as many predict) the market may in fact only support a very few number of generic IaaS providers who compete almost solely on cost and economies-of-scale. But, assuming this example is even partially successful, there will be room in the market for countless "community clouds" serving the special needs of enterprises and ecosystems globally.

I'd be interested to know if you're aware of opportunities (or instances) of other real-life specialized community clouds in your area of business. The era of cloud has only just begun.

Cloud Attributes Apply Across the Stack

My “aha” moment here at EMC came during my first week when I was asked to describe the generic attributes of cloud infrastructure. Here I was, in an organization that’s made billions on storage, and I was about to talk about cloud attributes solely from a compute perspective.Was I missing something?

I then realized that I’d always related to storage as a “big, fat, dumb disk in the sky”, and assumed that it was merely subservient to the compute stack.

Well, not exactly.

My re-think was that attributes of Compute, Storage, and yes, Network, all had to be reconsidered in the context of a holistic cloud-based infrastructure.

Cloud Attributes:

Most will agree that the following attributes describe the operational profile of a generic cloud: (HT to IDC)

• Shared, standard service. Built for a market (public), not a single customer
• Solution packaged. A “turnkey” offering, integrates required resources
• Self-service. Admin, provisioning; may require some “onboarding” support
• Elastic scaling. Dynamic and fine grained
• Usage-based pricing. Supported by service metering
• Accessible via the Internet. Ubiquitous (authorized) network access
• Standard UI technologies. Browsers, RIA clients, and underlying technologies
• Published service interface/API. Web services and other common Internet APIs

 I’ll add a few functional attributes as well:

• Consolidation: ability to make optimal use of lower-level resources
• Automation: ability to self-configure to provide the required service
• Self-healing/failover: ability to correct for failure with little or no service interruption
• Multi-tenancy, Multi-tiered-SLA: ability of resources to securely house individual services & service-levels across a shared infrastructure
• Global availability: ability to provide a shared service across multiple availability zones

Attributes in a Storage Context

The first assumption most make is that these traits apply exclusively to the compute layer (physical servers, VMs and the like). But pause and consider the storage (and network) facilities need to embody most, too.

But consider this: In a virtualized world, servers are files, and files are just data.

So, when we talk about cloud-related scaling, service migration, server fail-over etc., we must also implicitly speak of managing data dynamics, data replication and data mobility. When we talk about automation, self-service provisioning and service elasticity, we’re implicitly talking about dynamic data/storage provisioning and expansion. When speaking of multi-tenancy and tiered SLAs, we’re also speaking of shared storage facilities performing identical functions in lock-step with the compute facilities.

From a broader perspective , begin to consider implications of global availability and hyper-scale. The terabytes of data that embody virtual servers and their data might need to be migrated to (or duplicated in) multiple hemispheres- not a trivial task from an integrity and latency perspective. We can know (or hope) that the physical servers will be there… but it’s the bits that still have to travel.

The next idea these observations triggered was the need to keep compute, network and storage stacks in lock-step when rolling-out cloud services. The answer (not surprisingly) is converged infrastructure... An approach where the desired cloud attributes are assigned to the 3 stacks simultaneously. More about that in a future Blog.

But I'm now encouraging everyone to view storage of bits in a completely different light – one where the functional and operational attributes of storage must be architected to embrace the core attributes of cloud computing. For without the bits, there can be no servers, no data, and no services. More about that in a future post as well :)

Why Utility Computing Failed (But Cloud Computing Didn't)

Since about 2006 I’ve been involved with data center IT automation. Back then I started with Cassatt, one of the first companies trying to automate infrastructure components in the data center.  Rob Gingell, the CTO, had a design principle of “service-level automation”, where the variable monitored and maintained was the service, not the server. That was a revolutionary thought.

The technology behind this was a combination of orchestrating physical and virtual devices, which automatically composed appropriate infrastructure stacks to keep the service SLA within pre-defined bounds. And it absolutely worked!  The best market description we had for this technology was “Utility Computing,” and drew from the analogy of electrical utilities: No matter what the draw (load), the supply would always be generated/retired (elasticity) to keep up with it.
 
But selling the Utility Computing model, and service-level automation technology, was hard, if not impossible. We’d frequently have successful POC’s, and demonstrate the product, but the sales inevitably stalled.  The reasons were many and varied, frequently tied to the ‘psychographic’ of the buyers.  But overall, we could point to a few frequent problems:

• Automation was scary: The word “Automation” frequently scared-off  IT administrators.  They were accustomed to complete control of their hand-crafted infrastructure, and visibility into every layer.  If they couldn’t make and see the change, they didn’t trust that the system actually worked.
• Lack of  market reference points:  Peers in the market hadn’t tried this stuff either – and there was no broad acceptance that utility computing was being adopted
• Inflexible Process: The use of ITIL and ITSM procedures were designed to govern manual IT control, and had no way to incorporate automatic approaches to (for example) configuration management.
• Organizational fear: There was usually the un-stated fear that the utility computing automation systems would obviate the need for certain jobs, if not entire IT organizations. Plus, the systems spanned multiple IT organizations, and it was never clear which existing organization should be put in charge of the new automation.
• Multiple Buyers: Because Utility Computing touched so many IT organizations, the approval process necessarily included many of them. Getting the thumbs-up from a half-dozen scared organizations was hopeless. Even if the CxO mandated utility computing, implementation was inevitably hog-tied.

Enter Virtualization

Somewhere around 2007, OS virtualization began to go mainstream. And its value proposition was simple and uncomplicated: Consolidate applications, reduce hardware sprawl. It was a no-brainer.

But just below the surface, virtualization had an interesting effect on IT managers: It began to make them more comfortable to break the binding of physical control and physical management of servers, transitioning instead to being more at ease with logical control of servers.

As consolidation initiatives penetrated data centers, additional virtualization management tools followed. And with them, more automated functions. And with each new function came IT’s incremental comfort with automating logical data center configurations.

And Then, Commercial Examples

At just about the same time, Amazon Web Services had begun to commercially offer these virtual machines in their EC2 – Elastic Compute Cloud. This could be had for the use of a credit card, and charged-for on an hourly basis. IT end-users now had simple – if sometimes only experimental – access to a truly automated, logical infrastructure. And one where all “hands-on” aspects of configuration were literally masked inside a black box.

Now the industry had its proof-point: There were times when full-up IT automation, without visibility into hardware implementation, worked and was useful.

Use of EC2 (initially) lay outside the control bounds of IT management and IT’s organizational boundaries. Developers and 1-off projects could leverage it without fear of pushback from IT – usually because IT never even knew about its use.

Once IT management acquiesced that EC2 (and similar services) was being used, they finally had reason to look more closely. And the revelations were telling: How was it that the annualized cost basis for a medium-sized server was lower than an in-house implementation could possibly hope to achieve? How come configuration and tear-down was so simple? Finally IT had to look in the mirror at the fact that this thing called cloud computing might be here to stay?

Looking Back

While it’s clear that the concept of cloud computing isn’t new, some important industry changes – more psychological and organizational than technological – had to take place before widespread adoption would happen.  And even then, it took some simple commercial implementations to prove the point. Too bad these weren't around a few years earlier during the "utility computing" era.

Watching this unfold, lessons *I* learned – or at least some explanations of this effect I’ve examined have been

• Psychology/Attitude shifted:  the more broadly OS virtualization was adopted, the more IT’s attitudes became accepting of automation and of logical control.
• Technology change was replaced by operational change: The new approach is more a change to the operational approach than a technology upheaval. The way users interacted with the cloud was appealing and nearly viral.
• Value was Immediate: The “new” cloud economic evidence was/is usually so compelling that it has forced IT to take a second look. This started with simple consolidation economics, but has expanded well beyond that.
• Broad availability accelerated adoption: Even only a few commercially available cloud providers helped provide immediate proof-points that the new model was here to stay. And purchasing this technology was as simple as entering a credit card number

Going forward, I would expect these 4 (perhaps more) “pressure points” will continue to help accelerate the use and adoption of internal clouds, public clouds, etc.   In future Blogs I’ll begin to look at how to further mainstream Cloud (and automation) adoption, as it serves to accelerate improvements to business’ bottom line.

Hosting/Cloud Index outperforms NASDAQ Nearly 4x

Exactly a year ago, in 2009, I started looking into whether the market for Hosting and Cloud Computing could be measured in the stock market - with my first Blog on the topic. I revisited again in January 2010, and later in February 2010.

I created a number of model portfolios based on leading public hosting companies. The list included: Digital Realty Trust; DuPont Fabros; Equinix; Internap; Iomart; Macquarie Telecom; Navisite; Rackspace; Savvis; Switch & Data; Telecity; Terremark. During 2010, this index has gained 45% to the Nasdaq's 17%

I also created a sub-group of those companies with explicit cloud computing offerings. That included Equinix; Navisite; Rackspace; Savvis; Terremark. During 2010, this sub-index has gained 57% to the Nasdaq's 17%

I'm not surprised by either outcome... Assuming the market doesn't lie because it takes into account valuations and expectations, I draw a few personal conclusions:

• More enterprises are turning to outsourcing their IT. Whether or not it involves cloud computing, I suspect enterprises find it advantageous to hand-over IT (management, or at least co-location) to businesses where this technology is core. It may also indicate the skyrocketing consumption of computing power by enterprises.
• It would appear that hosting firms with Cloud Computing offerings are being valued higher than their counterparts. I haven't looked at cashflows or balance sheets (yet) to determine whether this is actual value, or speculative value.

What's next for 2011?  I'm going to guess more of the same, if not an acceleration as more companies move to outsource non-core IT operations.  I'll also be watching consolidation of data center operators, as recently evidenced by Rackspace acquiring cloudkick, and Cologix acquiring Navisite. 'Guess I'll have to update my portfolio companies...

IO Virtualization: The “Hypervisor” for Your Infrastructure

An Explosive Technology, But Don't Treat as a Standalone Product
  
More than ever in 2010, IO Virtualization (IOV) has been showing-up in products, written about, spoken about. Because I’ve had a few years’ experience with this technology, I wanted to give a very brief explanation of the concept, and focus more on why it will be increasingly important.
 
In particular, I want to draw an analogy where you should view IOV as a critical enabling feature of future IT Management…  but not as a stand-alone product. Why? It's similar in concept to how the hypervisor is an enabler (but usually not used as a stand-alone product) of data center management services. 

This blog is related to my 2009 installment on Fabric as an IT Enabler.

What is IOV?

Today's Physical Infrastructure

IO Virtualization is an approach whereby physical IO components such as Network Interface Cards (NICs) Host Bus Adaptors (HBAs) and Keyboard/video/Mouse ports (KVM) are reproduced logically rather than physically.  In other words, a physical IO port (Ethernet, Infiniband, PCI, etc.) might logically represent itself to the O/S as different configurations.

Clearly this is convenient because it (a) eliminates multiple costly IO devices that also consume power and installation time. But it’s also convenient because IO – and it’s associated addressing such as IPs, MACs, Worldwide Names, etc. – can be instantly configured with a mouse.


The other consequence of IOV is that a single physical port means a single physical cable.  In essence, a server’s logical IO is consolidated down to a single (physical) converged network which carries data, storage and KVM traffic.   So this means that no matter how many logical IO devices you configure for a server, there is still only a single cable out the back.  So IOV yields the ideal “wire-once” server environment that’s still infinitely re-configurable.

The overall value of IOV becomes clear fast:  Fewer physical IO devices to buy, fewer cables to install, zero re-cabling, fewer physical ports to buy, and instantly re-configurable IO. 

Differing Implementation Approaches

Infrastructure With
IO Virtualization

In brief, there are a few differing approaches to IO virtualization:

• Existing on-board Ethernet with new IO drivers: (e.g. Egenera)
• Converged Networking Adapters (e.g. Qlogic, Emulex)
• Appliances + high-throughput IO devices (e.g. Xsigo)
• Existing physical IO but with address hardware-based mapping/virtualization (e.g. HP VirtualConnect)

Putting IOV in Perspective

You should think of IOV using the following analogy: The way in which the hypervisor abstracts software in the application domain, IOV abstracts IO and networking in the infrastructure domain.  (However, to be clear, IOV is not a software layer as-is the hypervisor)

This analogy leads to a few more observations:

1. Where the hypervisor added software portability in the software domain IOV will do the same for the infrastructure domain.  Higher-order services like HA and consolidation were made possibly by the hypervisor.  Similarly, HA, DR and migration can be accomplished with IOV. And what’s more, a hypervisor is not required for IOV, so you can use IOV with native applications too.
2. The hypervisor used to be the focus, but now it’s merely an enabling feature embedded within higher-level IT management products. Those products leverage the hypervisor to perform tasks such as migration, fail-over and consolidation. You should view IOV similarly: it is an enabling feature that will allow for analogous IO consolidation, migration and fail-over.
3. Where hypervisor implementations and performance used to be hotly-debated, nobody really cares anymore.  Today the real *value* is not in the hypervisor, but in the management tools surrounding it.  Similarly, IOV should be judged less on how it is implemented, and more on the management tools and automation which manage it.

Forrester analyst Galen Schreck made a similar observation recently:

….Aside from benefits like reducing cabling and switch ports, I think the most interesting aspect of virtualized IO is the ability of a physical server's personality to be moved to any other server in the data center. In addition to the underlying network technology, the thing that makes this possible is integrated management of the server and data center fabric. In most cases, this won't be a stand-alone product that you acquire (though you can build your own solution from InfiniBand and PCI Express products on the market). This capability will most likely be an integrated part of whatever server and network environments you select, but now is the time to begin planning how you'll tie it in with the rest of your system management environment.

IO Virtualization in the IT Management Landscape

How might IO virtualization be used as part of the IT ecosystem in an integrated manner?

In much the same way that the hypervisor has since been embedded in tools like VMware’s vCenter, IOV can (and has been) embedded with higher-level management tools.

Taking an example I’m rather familiar with, Egenera’s PAN Manager Software surrounds IOV technology with facilities such as integrated with converged fabric networking, server boot control and storage connectivity.  When used alongside these and other services, IOV enables:

• Server High Availability– In the case of hardware failure, a server’s infrastructure state (IO addressing, storage naming, network topology and workload) can be re-instantiated on another bare-metal server. This provides a ‘universal’ style of failover that doesn’t require clustering software. And what’s more, the failed-over server workload could be a native OS, or a VM host.  IOV is agnostic to the workload!
• Disaster Recovery – expanding on the example above, if an entire domain of servers fails, the entire group of server IO states, networking states, etc. can be recovered onto another domain (assuming shared/replicated storage).  This approach to DR is elegant because it fails-over not just workloads but  the entire logical server/environment configuration as well.
• Scaling-Out – where a series of server profiles can be instantly replicated into an instant cluster. Workloads, NICs, HBAs, networking addressing and storage connections (complete with fabric-based load balancing) can all be cloned… starting with the IO and networking profiles, made possible through IOV.

In future blogs I’ll dive more deeply into how software-based IOV operates as part of the IT management ecosystem, and why it is a popular approach because of its cross-platform compatibility in a heterogeneous data center.

Converged Infrastructure, Part 3

Converged Infrastructure: What it Is, and What it Isn't

In my two earlier posts, I first took a stab at an overview of converged infrastructure and how it will change IT management, and in the second installment, I looked a bit closer at converged infrastructure's cost advantages. But one thing that I sense I neglected was to define what's meant by converged infrastructure (BTW, Cisco terms it Unified Computing). Even more important, I also feel the need to highlight what converged infrastructure is not. Plus, there are vendor instances where The Emperor Has No Clothing -- e.g. where some marketers have claimed that they suddenly have converged infrastructure where the fact remains that they are vending the same old products.

Why splitting hairs in defining terms? Because true converged infrastructure / unified computing has architectural, operational, and capital cost advantages over traditional IT approaches. (AKA Don't buy the used car just because the paint is nice)


Defining terms - in the public domain
Obviously, it can't hurt to see how the vendors self-describe the offerings... here goes:
 
Cisco's Definition (via webopedia)

"...simplifies traditional architectures and dramatically reduce the number of devices that must be purchased, cabled, configured, powered, cooled, and secured in the data center.  The Cisco Unified Computing System is a next-generation data center platform that unites compute, network, storage access, and virtualization into a cohesive system..."

Egenera's Definition

"A technology where CPU allocation, data I/O, storage I/O, network configurations, and storage connections are all logically defined and configured in software. This approach allows IT operators to rapidly re-purpose CPUs without having to physically reconfigure each of the I/O components and associated network by hand—and without needing a hypervisor."

HP's Definition

"HP Converged Infrastructure is built on a next-generation IT architecture – based on standards – that combines virtualized compute, storage and networks with facilities into a single shared-services environment optimized for any workload."

Defining terms - by using attributes
Empirically, converged infrastructure needs to have two main attributes (to live up to its name): It should reduce the quantity and complexity of physical IT infrastructure, and it should reduce the quantity and complexity of IT operations management tools. So let's be specific:

Ability to reduce quantity and complexity of physical infrastructure:

• virtualize I/O, reducing physical I/O components (e.g. eliminate NICs and HBAs)
• leverage converged networking, reducing physical cabling and eliminating re-cabling
• reduce overall quantity of servers, (e.g. ability to use free pools of servers to re-purpose for scaling, failure, disaster recovery, etc.)

Ability to reduce quantity and complexity of operations/management tools:

• be agnostic with respect to the software payload (e.g. O/S independent)
• fewer point-products, less paging between tool windows (BTW, this is possible because so much of the infrastructure become virtual and therefore more easily logically manipulated)
• reduce/eliminate the silos of visualizing & managing physical vs virtual servers, physical networks vs virtual networks
• simplified higher-level services, such as providing fail-over, scaling-out, replication, disaster recovery, etc.

To sum-up so far, if you're shopping for this stuff, you need to
a) Look for the ability to virtualize infrastructure as well as software
b) Look for fewer point products and less windowing
c) Look for more services (e.g. HA, DR) baked-into the product.

Beware.... when the Emperor Has No Clothes...
In closing, I'll also share my pet peeve: When vendors whitewash their products to fit the latest trend. I'll not name-names, but beware of the following stuff labeled "converged infrastructure":

• If the vendor says "Heterogeneous Automation" - that's different. For example, it could easily be scripted run-book automation.  This doesn't reduce physical complexity in the least.
• If the vendor says "Product Bundle, single SKU" - Same as above. "Shrink wrapped" does not equal "converged"
• If the vendor says "Pre-Integrated" - This may simplify installation, but does not guarantee physical simplicity nor operational simplicity

 Thanks for reading the series so far.  I'm pondering a fourth-and-final installment on where this whole virtualization and converged infrastructure thing is taking us - a look at possible future directions.
 

Postcards from the IT Financial Management Association

This week marks the third time I have been invited to speak at the ITFMA World of IT Financial Management conference.  This is a really amazing/unique conference, created nearly single-handedly by Terry Quinlan, their Executive Director. Quick overview:

The IT Financial Management Association (ITFMA) was established in 1988 and founded the IT Financial Management profession at that time. ITFMA is the only association dedicated to this profession and provides a comprehensive education program on the principles and practices used to financially manage Information Technology (IT) organizations. ITFMA is the national leader in the education of IT financial management professionals and the only recognized provider of certification in the various financial disciplines of IT financial management.

The attendees are largely non-technical, but are comprised of financial managers, controllers, project managers and purchasing managers all in the IT field mainly with F1000 companies.

And what sets this conference apart for me is the fact that 90% of the topics of conversation are non-technical. It's not about the speeds-and-feeds, but rather about the project management, cost accounting, charge-back, managerial and regulatory issues facing IT.  It gave me pause that, while technologists focus on keeping the electrons moving, there are also folk who keep the paper and the money moving.

On particularly illustrative conversation I had in mind -- with an IT financial manager from the State of Oregon, who oversees the state's shared/hosted IT infrastructure.  They were promised by a large national consulting company that through consolidation of equipment and data centers, the state would save tons of $$ and reduce the managerial headcount as well. As it was described to me, the technical consolidation was largely a success, but the consultant failed to accurately account for the business and managerial staffs associated with the IT. And over time, while the square feet of data center shrank, the overall IT staffing continued to grow. Lest we commit the sin of assuming that all of IT is technologists.

Overall, the ITFMA is a "must-attend" -- especially now that IT is going through such large changes as data center consolidation, virtualization, automation and cloud computing. All of these have non-linear impacts on IT finances, and all can cause disruptive effects on topics like capital forecasting, project management, expense vs  investment projections, etc. Not to mention the newer issues caused by cloud computing such as data ownership, security, operations control, etc.

The event is a relative bargain to attend, and Terry always finds classic, historic venues for the conferences.