Real-World Financial Services Cloud

Cloud computing has been made very real today.

As I subtly alluded-to in March, The New York Stock Exchange (NYSE Euronext) today launched their Capital Markets Community Platform (CMCP) along with partners EMC and VMware. It's essentially a high-performance, low-latency, special-purpose cloud IaaS, replete with customers and roadmap. Register Coverage  FIN Alternatives Coverage

This is a very notable event for a few reasons:

• Cloud is not a commodity: Unlike general-purpose public clouds, NYSE has constructed a high-performance, low-latency infrastructure to meet the specific needs of trading firms. From these perspectives alone, use of a public cloud (AMZN, RAX, etc.) would never meet the stringent performance requirements. My belief is that we'll see even more of these industry-specific clouds arise. Differentiators will likely vary based on needs for performance, privacy, security, scale, etc.
• Cloud is highly reliable:  A lingering question has been whether the cloud - and associated automation controls - was reliable enough for mission-critical applications. NYSE is no stranger to Financial-Markets levels of reliability, and has clearly taken great pains to ensure that their experience carries-over to the CMCP.
• Cloud is highly secure: Ditto to above. the CMCP is accessible to customers only via a highly-secure network and only to pre-validated users.
• Cloud enables new forms of business: For me, this is the most exciting aspect. NYSE's cloud now allows small firms (picture 3 hedge fund managers and their dog in a garage) to take advantage of enterprise-grade hardware and data... say to test and run new trading algorithms. Access to resources such as this would have been far outside of the reaches of the small firm.
• The Cloud + Big Data story is real: What's also nifty about NYSE's implementation plan is that it allows users to create DB's on demand, and will allow users to access massive data in the form of market play-backs.  This DBaaS will obviate the need for tenants to replicate TB or even PB of data as they test algorithms against historic market data.

NYSE's partnered with EMC and VMware to construct the cloud, and VMW has also posted an excellent Blog on the topic. A few excerpts:

"So, why is this better, and why is NYSE Technologies the right organization to deliver? For hedge funds and other buy-side firms, their value isn't in integrating compute, storage, networks and security -- it's in analytics, trading strategies, algorithms, application strategies and other proprietary expertise. The NYSE service means those IT organizations no longer have to struggle with integrating data dumps and feeds into their infrastructure and operations. Trade execution speed can be critical, so physical location and proximity to the market matters. NYSE's experience in operating large scale, mission-critical VMware-based infrastructure -- the NYSE and Euronext exchanges -- is unquestionable....

"...NYSE represents an alternative cloud future: one that contains a vibrant ecosystem of clouds, both internal IT departments and external cloud service providers, with unique understanding and focus on customer needs, married with the ability to deliver through scalable, on-demand and trustworthy IT services. What internal IT organizations and cloud providers like NYSE share is a rejection of the concept of an inflexible cloud monoculture. Instead, they choose to build high performance, secure and scalable infrastructure because it meets critical business needs. They obsessively focus on value delivered to the customer and never confuse that with cost of service.

And that's it. Cloud is now about Value, even more than it has ever been about cost reduction.

Hosting/Cloud Index: Update

Back in December, 2009, I proposed an index of hosting and cloud providers, and posited that these sample portfolios would be an excellent gauge of the market's perception of the state of the business. I also made an update in December of 2010.

I thought I'd make an update again, and review the state of the business.  Also, it would seem that others are adopting the same idea, as I was recently reminded by Software Advice.  Good to see that these types of metrics are being adopted...hopefully they cut through some of the vendor hype.

Now, on with the statistics.

First, I created an index of a superset of publicly-traded hosting providers, some of whom also provide cloud computing resources. My only litmus test was that these were *not* SaaS providers, and that they provided hosting/IaaS services as their primary business. The performance was compared against the NASDAQ composite, and has been quite positive. The large increase in index price was primarily due to Verizon's acquisition of Terremark for a hefty premium.

Next, I took a subset of the providers who solely claimed to provide cloud-computing services.

As I had suspected, this index has vastly out-performed the NASDAQ - my supposition being that the market is placing a higher premium on any business conducting "cloud"-related business. 

The market would appear to still be going strong, and I'll continue to update progress every few months.

It's All Just Data to Me

Now that I’ve been with EMC for a few months, my relationship to storage, computing, and networking has once again shifted. And, in the context of the cloud computing operations model, my relationship to the physical location of data - and processing of that data - has shifted too.

My new perspective starts with Computer Science 101: Where, at its heart, computing is simply data and instructions (stored on similar media) which are combined on a device (CPU) and produce an output.

Since computing began, this model was consistent – but as the data and instructions grew in size and abstraction, the media changed to the point where instructions (code) and data, were each stored in physically separate locations.

Until recently the data and instructions would be transported (over the network) to individual physical CPUs (with their own sets of OS) where they would be combined and executed. And then, the resulting data generally was transported back to its place of residence.

Servers are Just Bits

Now, enter the Virtual Machine.  At the heart of it, it's simply another file (e.g. VMDK) – in other words, just more data.

So in the modern virtualized data center, what we have – at the extreme – is a model where not only the data and instructions are bits… but the servers are bits too. All they require are physical CPUs to execute.

In the ‘traditional’ model, the data and instructions were brought to where the physical servers and O/S were.  But today, with pervasive farms of generic physical servers, we have the situation where *either* the data bits can be brought to the server, or the server bits can be brought to the data.

Some of the implications you’ve probably already thought of – such as vMotion of a VM from one physical server to another, or using a DRS-style control to re-locate VMs from failed physical compute resources elsewhere.

But consider another situation that’s happening with increasing frequency: The need to work with “Big Data” – such as running analytics on unstructured bits that could be on the Terabyte to Petabyte scale.  Here is a case where it makes sense to send Mohamed to the mountain than the other way around… To literally re-locate the servers (which are, after all just data themselves) closer to, or co-incident with, the data.

Or, consider a “follow-the-moon” strategy for data center energy efficiency: where the most energy-efficient (and least expensive) physical servers are chosen to handle workloads. Once again, the data (which includes the virtual server, data and instructions) is simply transported to the optimal set of physical processing resources.

Cloud Infrastructure and Data Management

From where I sit, the importance of data storage, data management and data portability suddenly becomes paramount. It can reasonably be argued that physical servers are now merely execution platforms for the VM data bits, and that the network is simply becoming flatter and fatter.

So the future data center and cloud model might be thought about as a data management problem. Where and how to locate bits, back-up bits, scale bits, operate on bits.   True, this is a data-centric view of the world. But it's also a healthy perspective from which to view the renewed importance of data and its dynamics, versus the other more static components of the data center.

Cloud's Transformation: The Softer Side

After having spoken to numerous customers and vendors, it's clear to me that cloud computing's operational transformation necessarily triggers structural changes in the IT organization - as well as in the rest of the enterprise.

Overheard at a conference late last year, an analyst I was briefing illustrated it this way: A Converged infrastructure requires a converged organization to operate it.

I'm convinced we'll see significant internal transformation in the future - not of technology, but of people, roles, skill-sets, and organizations. As evidence, just take a look at the organizational transformation EMC's IT department has gone through in the past 3 years (HT to Chuck's Blog)

Consider this:

• The Role of the CIO: Today the CIO is orchestrator of technologies, if not a technologist him/herself. Governance of the technologies/vendors is perhaps secondary because "keeping the lights on" is such a dominating task. In the future, the role will shift from technologist to where the CIO (and IT overall) will become a service portfolio and governance manager... Regardless of whether the services are generated internally or externally.  Implication: CIO's will need new skills, policies, processes.
• IT Organizations: Referring again to Chuck's blog (and excellent illustrations therein) the IT organization will shift from siloed / distinct organizations to a set of unified service organizations leveraging a common services infrastructure. Implication: change management, goal changes, departmental funding changes.
• Individual Skill-sets: Today's IT skills (esp. in larger organizations) are specialized around applications, servers, networking, backup, etc. each which aligns with the organizational structures, above.  However, in the future many of these functions will either become more automated and/or combine with (be embedded within) other service management functions. Implication: new skills training, certifications, processes.
• Supporting Services:  As IT transforms, so will adjacent organizations and services - like finance, lines-of-business, legal/compliance, vendor/partner management.  How IT is measured and accounted-for, related-to as a business partner, and how it dovetails with external partners/providers will necessarily shift.  Implication: need for change management and new organizational design.

Looking forward, if these transformations occur even at a modest level, I would expect too see other broader-scale industry-wide changes in these and related areas.

1. CIO roles will shift to governance & vendor management (perhaps even modeling supply-chain management)
2. Organizational & change-management resources (firms facilitating change specific to IT transformation) will be in higher demand
3. IT skills development will re-invent itself; new training and certifications (e.g. cloud architect) will become the norm. Fewer special-purpose technologists will be needed, in favor of a new breed of "converged" technologists
4. Entirely new categories for job recruitment will emerge to find and place this new talent
5. IT financial management skills development, training etc. will be in further demand as IT shifts from being a high-dollar capital expense to becoming an on-demand business resource/enabler.

 In the future I'll continue to reflect and blog about what I'm hearing in the market. But we should all be keenly aware of the non-technical impacts of the IT technology shift.

And, if you know of examples today, do share!

Marketing the Cloud

Of all the marketing, marketing "The Cloud" has all the makings of a real challenge: The concept is new, the technology is disruptive, buyers are skeptical, hype abounds, and the terminology (just what is "cloud"?) is murky. So, when recently asked how do I "market the cloud" this Blog idea arose.

For me, marketing is far more than making "buzz" in the market. It's about matching seller and buyer: First, ensuring that the seller's product specifically targets one or more needs in the market (and adjusting as-needed), and second, ensuring that the buyers understand the product and its fit-for-their-purpose (and adjusting the buyer segments as-needed).

So, where a nascent concept, confused buyers, and evolving definitions are concerned, I turn to basics of new product introduction: (a) understanding customer problems/opportunities, (b) clearly defining the product/solution, (c) addressing objections, (d) helping customers through the adoption cycle.

Focus on specific issues the cloud addresses, not the Cloud itself: Before I recommend "cloud" as a solution, I ask myself what problems will customers really try to solve? They've heard “cloud” and it likely interested them, but for what reason? Getting to the need point is critical: It is cost? agility? keeping-up-with-the-Jones’? New business enablement?  You have to first ask the business need question, not try to force-feed a solution. Usually the cloud model is compelling on nearly all levels - but the customer first needs to understand - and want to pursue - the opportunity. Good marketers ensure customers self-select into the solution, even if it's an extremely broad one. Also, an exercise I sometimes pursue is to avoid using the term "cloud" altogether during this phase. Instead, I focus on the attributes of cloud computing, and wait to hear whether they resonate with the customer's needs. Sometimes they might not.

Get clear on definitions - and use lots of adjectives: The next question to ask is: What cloud?  Too often marketers of the cloud model don't modify the noun Cloud with an adjective like Private/Internal, Public, Hybrid, etc. causing even more confusion. It's alphabet soup. Many buyers usually start by thinking the only cloud is the public cloud. Once buyers are clear about the operational cloud model you're both talking about, you can have a more meaningful marketing action.

Know your buyer's technology maturity, and technology appetite: Different markets, segments and customers will have different technology appetites and be at different technology maturity states. So, as much as vendors want buyers to take a big step and buy all-new stuff, there has to be a spectrum of offerings to fit buyers at different stages of the maturity curve. (See "It's A Journey", below...)

Be pragmatic - identify resistance areas and objections: I say pragmatic, because everyone has their own list of objections and concerns. They might be trust/security/governance issues; economic models to justify the investment; the risk of moving to new operational models; dealing with change management (a change in IT will necessarily impact changes in related orgs); the list goes on.  Make sure you've listened carefully to all objections, and thought-through responses.  I've unfortunately seen wonderful products fail - not because they don't work, but because when it comes to implementation, all of the pot holes and speed bumps haven't been identified and addressed.

Be pragmatic - it's a Journey: Few buyer segments adopt all-new models - especially cloud - in their entirety on day-1. So marketers need to be prescriptive about where to start, what to do when, and how to help buyers with a roadmap that accelerates them down the path. Most cloud buyers (with the exceptions of folks like service providers) make incremental changes to infrastructure – so marketers have to help recommend the incremental changes (and products/services) they’ll need in the coming years.

Educate: Finally, I believe a rising tide lifts all boats. The more the market is educated about cloud computing models - and how to get there - the faster the market will mature. It's our job to help provide education tools, models and success stories. And to draw distinctions between here-and-now vs. futures vs. vision.

The opportunity we have with cloud is also a danger: There is an inordinate amount of hype in the space. So, as we move down the hype cycle, we need to get pragmatic about the value the cloud model offers, the journey customer take to implement, and the opportunities it creates. 

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 :)