A few weeks ago, Dell acquired Enstratius. They make excellent software for managing and governing multiple cloud environments (via the APIs), and we’ve had their leadership team on the podcast a few times (here, here). They primarily delivered their software as a SaaS application, although it could also be run on-premise. Since the acquisition, Dell has shifted their Public Cloud strategy and now Enstratius products are the core of a plan to let customers leverage resources from multiple cloud platforms. And I believe the fact that it can be delivered as a SaaS application was key to making that shift. It made it much simpler for customers to begin the process of consuming cloud resources, instead of having to setup tons of equipment (hardware/software/security) on-premise.

Last week, a friend that works quite a bit with VMware environments sent me this “BOM” (Bill of Materials) for a reasonable sized setup to create the full vCloud Suite (vCenter, vCloud Director, vChargeback, vCAC, vCNS, vCO). What jumped out at me was the breadth of things that had to be in place to get a Cloud environment up and running. Windows, Linux, Web Servers, multiple Databases. This isn’t uncommon for any Cloud Management Platform (CMP) – OpenStack, CloudStack, etc. – and would typically require teams with a variety of skills to coordinate putting getting this configured properly.

• 20 Management servers: 2x vCenter, 2x DB servers for vCenter/vCloud/vChargeback, 2x vCloud Cells, 2x vCNS Manager, 2x DB for vCAC, 2x WebServers for vCAC, 2x vCAC DEM Orchestrators, 2x vCAC DEM Workers, 2x vCAC Agent Machines, 1x vChargeback server, 1x vCO
• 8 Databases: 2x vCenter Update Service, 2x vCenter, 1 vCloud, 1 vCAC, 1 vChargeback, 1x vCO
• 7 Management Interfaces: 2x vCenter, vCloud, vCNS, vChargeback, vCAC, vCO

And again last week, Gartner analyst Alessandro Perilli (@a_perilli) tweeted:

Cloud management platform vendors should seriously consider a SaaS delivery model. Today’s solutions too complex to deploy, scale, expand.

— Alessandro Perilli (@a_perilli) June 3, 2013

Perilli is one of many people at Gartner that covers the Cloud Management Platform space, so he gets to see the breadth of offerings in the market from many vendors.

So this ultimately begs the question, “Should Cloud Management be delivered as a SaaS application?“

The basic thinking is that by leveraging CMP as a SaaS application, companies could gain several potential benefits:

• Leverage existing on-premise equipment (investments, data center space)
• Keep data on-premise if there are concerns about privacy, security, data loss, etc.
• Leverage the operational expertise of the SaaS provider to simplify setup, scaling, maintenance
• Acquire the CMP through various payment models (dedicated-instance/CAPEX, PAYG/OPEX, contract/OPEX, etc.)

As with any SaaS application, there are pros and cons:

• What happens if the Internet connection fails? For a period of time, new resources can’t be provisioned and visibility can be reduced (although some visibility from on-premise systems like vCenter or SCVMM, etc.)
• How far does the SaaS application manage? This would depend on what systems are on-premise and how much they can be managed. Most systems (eg. vCenter, SCVMM, OpenStack, CloudStack) have existing APIs to manage, but that’s not always the case for the infrastructure (servers, storage, network, LB, FW, etc.). So managing and automating the associated infrastructure may be more complicated and require additional system components.
• Who would manage the CMP? It would depend on the offering. Typically SaaS applications are managed by the SaaS provider, with some customization available for the customer.

I’ve written before (here, here) that operations is one of the biggest complexities for companies to build their own cloud platforms. While many companies are still trying to build their own clouds, using local Cloud Management Platforms, but it will be interesting to see if CMP vendors (or open-source projects) evolve to offer SaaS as a new option to address some of those challenges.

• “Pre-Defined” or “Pre-Validated” all-in-one racks of equipment
• Hardware Reference Architectures
• Hardware + Software Reference Architectures
• Software-Only Design Docs that are “hardware agnostic”

Lots of vendors or systems integrators have promised to deliver a cloud to their customers in a pre-defined package, but it is typically missing one critical component – OPERATIONS. And when you think about it, the operational model is cloud computing, so it begs the question – are cloud operations transferable?

Recently GigaOm wrote about the latest round of Cloud Providers trying to bring their version of cloud to a new set of customers. Others have tried this or are currently using a similar strategy for both IaaS or PaaS platforms, including Apprenda, Joyent, Rackspace, Virtustream, and VMware (both CloudFoundry and vCloud).

While operations does include elements of technology, the vast majority is driven by people skills and company specific processes. This is why you’ll see cloud pioneers like Netflix open-source many of their internal tools, or Rackspace give up leadership in OpenStack to the OpenStack Community, because their expertise and learning-curve advantages are in the operations of their cloud environments. The AWS APIs are open (documented), but they don’t expose much of their internal operations.

But what makes the operations so difficult to transfer?

Business Models – While there are some cloud providers that have similar business models, the reality is that almost none of them have identical business models. How customers engage with the cloud can vary quite a bit – direct via API; directly through a Service Catalog UI; initially via a Systems Integrator or VAR then via Self Service. Some clouds target developers, some target vertical industries and others target certain sized customers. Understanding how well your “cloud in a box” aligns to the provider’s business model is an important first step.

Onboarding – How does the cloud get the user from the Service Catalog to using the service? Does it have to integrate the cloud platform with existing CRM/Catalog systems, or will it be a greenfield system?

Products/Service Consumption - What are you planning to offer your users?  Is it a set of raw services, or bundles with variable sizes, or some mix of ala carte and bundles? Are the products targeted as developers or other types of users? Who is responsible for supporting the service, the cloud provider or the end-user?

Capacity Planning -> Budget Planning - Cloud Providers are able to spread the cost of infrastructure across multiple customers, but what happens when the cloud is for a single company? Have you figured out how to change the budgeting model to spread costs across multiple business-units, or get budgeting that allows for “expandable capacity”, or are you stuck buying hardware &/or software on a project-by-project basis?

Billing – How hard could it be to create a bill? First, make sure you can identify the customer by a unique number that aligns to other systems. Then make sure you can align to a cost-center for the accountants. Next you need to make sure you can bill for both products (setup, dependencies) as well as usage (mins, months, contract terms, etc.). And of course you need to have excellent logging so that you can manage repudiation (those angry customer refuting their bills). And all of this probably needs to link into some sort of payment system, or at least budgeting dashboard so that users and leaders can see billings, chargebacks or showbacks. Pretty simple, huh?

And all of this assumes you have the right skills in place (technology, project management, product management, financial analyst). Not as simple as buying a standardized set of hardware…

While it was an excellent discussion and did surface a few fringe industries that might fall into this category (undertaker, local hair-salon, etc.), the general consensus was that every business today is essentially a tech business.  While it’s fairly easy to highlight this with companies where technology is their core product (eg. Netflix, Facebook, etc.), it’s also not difficult to see how technology is core to businesses that don’t make technology-centric products (eg. tractors or farm equipment).

For example, if you’re John Deere (just an example, don’t have insider information on their operations), you obviously have a complex supply-chain in place to be able to pull together all the elements that make up a tractor. They also need sophisticated analytics systems to be able to forecast sales, costs of raw materials, currency exchanges and other macro-level things that could be effected by the economy, government policy, etc. Then within the tractors, there is an ecosystem building around tools and applications that can help farmers better manage their fields. Somewhere all the data being collected could be creating new “big data” knowledge that could be improving crop yields, fuel efficiency of tractors, etc.

But in an example like this, what is being transformed by technology? Is this transformation of IT, or transformation of the product/ecosystem, or transformation of the business?

When I think about “transforming IT”, I tend to think about the adoption of new technologies, reducing costs and improving worker productivity.

When I think about “transforming the product/ecosystem”, I tend to think about making data accessible to open APIs, or expanding areas where value can be added to a product (customization, etc.).

When I think about “transforming the business”, I tend to think about using technology to eliminate an element of the existing supply chain. Netflix is a great example of this (remove the need to obtain physical media at a store or kiosk). iTunes is another great example (remember record stores??). Sports has been going through this for the last 10-15 years. But it’s harder to think of examples of these types of transformations where the business isn’t entirely based around technology. It does create some blurred likes, such as how Bechtel is using technology to enhance how they manage contractor relationships and project management.

So this is one of those areas where definitions might actually be more of a hinderance than a structure to help companies understand how to plan for transitions or transformations. Regardless of what definitions people use, I’d suggest that there are a few areas that need serious consideration:

1. Do you understand your supply chain and have you gone back and examined it lately with an eye towards how technology (or technology partners) might be able to help reduce links?  Have you looked at how new technology could enhance the existing portfolio? [Example: With airlines struggling so much, why haven't any of them leveraged their footprint at major airports + telepresence technologies to create augmentations for the output of a large percentage of travel - business meetings?]
2. Do you understand the potential ecosystem that could be created around your business, your product or (most importantly) your data? We explored the data element on the podcast. This is actually another variant of the supply-chain discussion, but it involves thinking about the value-chain for the business and considering the opening of new doors and some loss of control of the outcome.
3. Can you build a better mousetrap? Most people thought Apple was crazy to begin building physical stores when the Internet had proven that brick & mortar business was dead. But they just did retail better than everyone else on the planet. They drew a direct line from the customer’s experience (which involved convenience, repair, physical touch/feel) and aligned it to their goals (don’t sell as massive discounts). Zappos took a similar approach with low-margin shoes – focus on the experience and inconvenience of the past and leverage technology to solve those customer pain points.
4. Can you measure every element of the business, not just the things that are reported on the financial reports? Do you understand the things that influence the direct results or the buying process or satisfaction levels? Given that every aspect of our lives is now recorded digitally, there is an extremely good chance that the information is available (directly or through external services).
5. The underlying technology is obviously important, but as we’ve seen time and time again, it’s the process and people that need to embrace the change more than the technology. Technology change/transformation is a given. It might take 5yrs or 10yrs, but it’ll happen. Process and business model change doesn’t have EoL dates, it has Chapter 11.

So as usual, Simon Wardley is right about this. But the question becomes, are you transforming technology or transforming how the business leverages technology. They aren’t the same, no matter how many times companies tell you the CIO deserves a table with the decision makers in the company.

But as a good disciple of Cloud Computing, I went and read Gene Kim’s excellent book on DevOps, The Phoenix Project. We also had him on the podcast. Travel permitting, I attend the excellent sessions at the Triangle DevOps meetups, run by a bunch of people that do DevOps stuff everyday (operationally or developing products like Chef, Ansible, etc.). When possible, we grab some of them for the podcast as well.

So here’s where I keep seeing the disconnect. For a while, the discussion about Enterprise Cloud was always focused around Private Cloud, which often times meant something using VMware vSphere (and maybe vCloud Director). But when I listen to all the people doing DevOps today, it’s rarely on VMware (or even VM-based) environments, it’s almost entirely using various Linux-based tools and packages. and it’s primarily for web-based or web-facing applications. Not the things you’d typically associate with IT-supplied applications. We explored this a while ago, but I don’t know if it’s changed much, even with things like Windows support being added to tools like Puppet.

Thought leaders like Randy Bias has been saying for a while that there really are two Enterprise environments now, the one run by IT and the new one for new applications. Others like Joshua McKenty are building their products to better align to this vision. In essence  it’s DevOps for the new IT, or at least the new usage of technology by business (maybe it’s not the traditional IT group).

So the question is – is it a bad thing that traditional IT might not be the group that drives DevOps within a company? Or is DevOps mostly a trend for online (eg. Public Cloud) service operations, and will only be a minor trend within an Enterprise?

If it’s driven by “Dev”, will it move faster because the learning curve to the new model is not nearly as steep as IT as a Service might be, or will the use of open-source tools/software accelerate it because they aren’t burdened by the budget requests and budget cycles of traditional IT?

To me it feels like DevOps is real, and business is increasing using technology to compete in the marketplace, but where are those two things really meeting up? Is it happening in more off-the-radar places from IT than many people know about, or is it happening right in front of them and it just feels like subtle changes and a few new automation tools.

I’m left to wonder what “Enterprise Cloud” really means – is it defined by traditional Enterprise Class characteristics (eg. SLAs, Compliance, etc.), is it more defined by where it physically resides (eg. private data center or colo facilities), or is it Enterprise budgets (eg. Shadow IT) taking greater control over how technology impacts their business? And in which of these definitions does DevOps have the most impact?

Do you DevOps?

• “Own the Base and Rent the Spike”
• “Cloudbursting”
• “Application migration”
• “Application Portability”
• “Avoid Lock-in’

Pick your favorite slogan, they were all there. Throw in the ability to dynamically migrate workloads between physical locations and there was a frenzy of excitement over the possibilities of a Hybrid environment.

And then reality set in and people began to realize that the limitations far outweighed the possibilities. Limited Bandwidth. Security Concerns. Ownership Issues. Consistency of Operations. Early offerings such as Amazon AWS could provide a VPC (Virtual Private Cloud), but it had limitations (or “wish-lists“). CloudSwitch did some cool things (since acquired by Verizon/Terremark), but it was cloaked in a security story and hence didn’t get as much visibility as it could have from “Cloud Architects” at the time.

It also led to an explosion of definitions of Hybrid Cloud, mostly to match the needs of a vendor selling their HW/SW, or an Enterprise Architect trying to justify their design to their CIO. Either way, it’s evolved to where Hybrid Cloud can mean any mix of offerings or architectures where the resources and applications are both on-premise and off-premise. And if I squint my eyes just right, my borrowed concept of “Cloud Concierge” might even fit one of these definitions.

Fast forward to 2013 and we’re beginning to see a new set of Hybrid Cloud offerings emerge that are backed by both evolving technology and vendors large and small. They tend to fall into these categories:

Virtual Private Cloud (VPC) – This is the category of solutions that involve a Public Cloud vendor (eg. Amazon AWS) offering a VPN or Gateway offering at the edge of the Enterprise. The edge offering might be from them, it might involve API-level integration (eg. Eucalyptus) or a 3rd-party gateway product (eg. TwinStrata, StorSimple, Riverbed Whitewater, NetApp).

Federated Clouds – This category of solutions are enabled by placing consistent Cloud Management Platform software on both a Public Cloud and Private Cloud, and leveraging the federation capabilities between the two (or multiple) locations. These include VMware vCloud, Apache CloudStack, and Virtustream xStream. Over time I would expect OpenStack to add federation capabilities, as multi-cloud interop is one of the core tenants of that project.

Workload Migration – These solutions are focused on ways to take existing applications (virtualized or on bare metal) and either seamlessly migrate them to a Public Cloud, or create synchronization between a Private Cloud and Public Cloud on a per-application basis. These include AWS’s VM Import, CloudVelocity (podcast) and Ravello Systems (podcast). Layer on top of this the emergence of new Public/Private PaaS platforms (Apprenda, CloudFoundry, etc.) and we’re also beginning to see portability higher up the stack.

Multi-Cloud Managers – In the past the definition of Hybrid centered around Public + Private. But as more Public options have evolved to fill niches, offer differentiated pricing or performance, or geographic presence, a new class of Hybrid has evolved – the multi-Public hybrid. Companies like Enstratius (Dell), Rightscale and AppOps have emerged to providing leading technology in navigating management and governance between clouds, Public or Private.

Over the past 4-5 years, the definition of Hybrid Cloud took many forms and meant many things to different people. The good news is we appear to be coming out of the hype cycle and are beginning to have wider choices of hybrid solutions to address multiple use-case and workload requirements. And as even more of these evolve to being software-centric deployment models, I expect that we’ll see the acceleration of hybrid architectures expand quite rapidly. And over time, we’ll begin to see more of the elements that are considered “tools” or smaller functionality get integrated into larger cloud offerings (eg. AWS Cloud Gateway, OpsWorks and CloudWatch).

What are your plans for Hybrid Cloud in the near-term and long-term? What critical elements do you still see missing in the market place today?

btw – if you’d like a view of Hybrid Cloud as only my wonder British colleagues can describe it, check out this beauty from Stevie Chambers (@stevie_chambers, CTO at Canopy Cloud)

Since then, I’ve had a number of business leaders and financial analysis reach out to ask, “What is OpenStack?”. My first reaction is to give them a little bit of history and overview of the technology landscape. But then I’ve quickly come to realize that this isn’t what they are looking for. From their perspective, they want to really understand where OpenStack fits into the broader IT hierarchy and if it should become part of their strategic thinking. Here’s a sampling of the follow-up questions they tend to ask:

What does OpenStack actually do?

In the most basic sense, OpenStack is a software framework that coordinates the services needed to provide on-demand computing/storage resources for applications. Those services include computing, hypervisors, storage, networking and security. From a user perspective, if OpenStack is implemented correctly, it should just look like a few menus and clicks that let the application owner say, “I need this many resources to start, then I’ll want to grow or shrink that number over time, and I’d also like a few other services to augment my application (backup, geographic resiliency, load-balancing, etc.” If OpenStack is used as part of a more complex system, those menu items would be replaced with programmable APIs. [NOTE: This same description could be used for almost all "cloud management platforms" in the market today.]

OpenStack is not a company (eg. Rackspace), although some companies are using OpenStack as part of their commercial services, and some companies are trying to sell packaged version of OpenStack.

Does OpenStack compare to something I’m familiar with today?

Removing some of the semantics (open vs. closed, etc.), OpenStack is most frequently thought of as being similar to Amazon Web Services. Like AWS, it has the goal of being a services-oriented framework for providing on-demand computing/storage resources for applications. Beyond that, OpenStack by the nature of it being open source, has the goal of allowing interoperability and application portability between multiple clouds running OpenStack. As OpenStack thought leaders like Joshua McKenty point out, OpenStack is probably better suited to be a framework for modern, scale-out applications.

To a lesser extend, OpenStack is somewhat similar to VMware’s vCloud Director or other cloud management platforms that tend to be more focused on virtualizing and automating legacy applications. VMware is typically better suited for virtualizing traditional applications, and they have a broad ecosystem of partners who have built tools to handle additional functionality (backup, replication, management, etc.).

If Amazon Web Services works today and is growing, why do people care about OpenStack?

AWS created a new market segment which is focused on delivering services to the application developers that either could not afford to purchase/operate the underlying equipment themselves, didn’t desire to operate those system (core vs. context of their business), or who were unable to obtain those resources from their IT department in the required timeframe or price point. Some people call this “Shadow IT”, but it’s really just a mismatch between IT Demand and IT Supply (Economics 101). With that in mind, some people see short-comings in the AWS offering that they believed could be solved using an alternative approach. Some of these approaches are alternative offerings in the marketplace by other public cloud providers (eg. Google Compute Engine, Microsoft Azure, etc.). The OpenStack projects approach is attempting to offer an open source alternative for anyone that wants to build their own cloud to either compete in the market (eg. Service Providers) or for companies that want to build/own/operate cloud services for their business.

Why does it matter than OpenStack is open source?

For an in-depth understanding of the impact that open source can have on technology (strategy, competition, business models, etc.), I’ll defer people to Simon Wardley’s excellent blog. From the perspective of OpenStack, the use of open source is important for a few reasons:

1. # of Developers – By using the community model of open source, OpenStack has the ability to attract more developers to the projects than proprietary software, and more developers offers a better chance to catch up to the capabilities of services such as AWS. Now, it’s important to note that just because a project is open source doesn’t necessarily mean it will attract the most developers. Microsoft has 1000s of ISVs that create applications and tools around their SDKs. AWS has 1000s of developers that write tools and create services around their APIs. Developers are attracted to opportunities to have their software make an impact (generate revenue, showcase their talents, leverage other software to solve a problem, etc.). 
2. # of Clouds – One of the core pillars of OpenStack is that it will help create the foundation for 1000s of clouds to be created, hopefully all being interoperable, and allowing different segments of the market to customize those clouds to meeting their specific needs (low-cost, high-performance, industry-specific, etc.). It’s important to note that interoperability isn’t a given, as vendors are already adding proprietary extensions to OpenStack that aren’t being contributed back to the community projects. Over time, the OpenStack Foundation will have to determine how it manages OpenStack compatibility issues.

Who wins if OpenStack is successful?

Unfortunately this question always comes up, because that’s the nature of our industry. Something has to win, something has to die, etc. In reality, it’s not an easy question to answer. But here are a few answers that are generally applicable:

• OpenStack is part of a broader movement where the Economic 101 of technology are shifting (on-demand, experimentation vs. ROI, etc.), but the application landscape is shifting (web-scale apps, mobile apps, data analytics). OpenStack is trying to be the toolbox for DIY cloud builders hoping to be at that economic and application crossroads. There are other DIY toolkits in the marketplace as well (Apache CloudStack, Eucalyptus, VMware vCloud, OpenNebula, Virtustream xStream, Joyent SmartOS, etc.)
• OpenStack is playing catchup to AWS, but so are many other efforts. From purely a technology perspective it’s behind, but we all know that technology isn’t the sole decision-making criteria in our industry. OpenStack has the backing of many industry giants (IBM, RedHat, HP, Cisco, Dell, etc.) who have huge customer installed-base and sales channels. AWS might be a $2.5-3B business today, but IT is a $4T market. There are lots of businesses and IT groups that like to have their own systems to build/operate.
• OpenStack is a software-centric offering. Software is a different business than hardware, and especially open source software vs. traditionally proprietary software. Companies that will be successful with OpenStack will have to evolve to this new model.
• Even if OpenStack fails to grow in the market place going forward (for whatever reason), the market as a whole should continue to win because this will drive greater competition for new services and drive down pricing for new units of cloud computing consumption.

I know that’s not really a list of winners, but the reality is that cloud computing is in such a nacent stage that it’s better to highlight trends than pick winners. There’s too much cultural change that has to happen and too much money at stake to bet the mortgage just yet.

In 2006, Amazon launched the first of their AWS (Amazon Web Services) services, EC2 (compute) and S3 (storage). AWS was targeted at development organizations looking to change the pace and economics of how applications were developed for the web. Since then, they have rapidly grown the number of services to include databases, long-term storage, DNS, CDN, queuing and many other capabilities. The quantity of services have grown to a point where many people ask if AWS is still an IaaS (Infrastructure as a Service) service or moved up to become a PaaS (Platform as a Service) service. Where it fits into the NIST definition seems to be irrelevant to the architects of AWS, who are focused on delivering a set of scalable services for developers looking to build next-generation applications (web, mobile, analytics, etc.). It’s this structure that recently had Jeff Sussna (@jeffsussna) writing “Services-Dominant Logic: Why AWS is So Far Ahead“.

While both of these approaches are being marketed under the umbrella term “cloud computing”, it’s becoming increasingly clear that they are targeting very different groups and they are targeting very different value propositions.

Software-defined is targeting a few different elements: (1) moving technology capabilities that traditionally resided in hardware (networks, storage, firewalls) and moving them to software running on/over commodity hardware, (2) a set of tools that would give existing IT departments the ability to build their own automated systems for delivering IT services, (3) the promise that IF these tools are put in place AND the associated people-skills and business-processes evolve, that time and money will be saved.

Services-defined is targeting a different set of elements: (1) providing developers with a set of standardized services that can be used as building blocks to build new applications, (2) providing developers with tools at scale (and on-demand) that they might not otherwise have been able to leverage without significant capital investment or build-out, (3) providing developers with a way to easily experiment with aspects of their new applications, allowing to choose the right tools for the project. The promise of services-defined being that agility and speed are the key elements of new applications and new business opportunities.

What these two approaches are beginning to clearly define is that we’re at the beginning of IT potentially being fragmented from the future of how businesses use technology, especially technology that requires an element of speed and agility to create market differentiation. It highlights the stark contrast between vertical architectures and loosely-coupled horizontal architectures, and it will begin to force business leaders to ask what percentage of their budgets to they want to spend on saving money vs the percentage they spend on making money.

One of the powerful aspects of an open source project is that developers or companies can take the code and use it any way they choose. Target a certain market. Target certain use cases. Target certain business models.

And in return, users of the software can decide what they want the software to do. They can modify the software if they have a specific need. They can buy packaged versions and use the embedded functionality.

For a project like OpenStack, which is maturing during a time when the market is already full of competing offers, it will often be compared to an existing expectation (or experience) that users have of other products/services.

An example of this is a simple question I posted on Twitter yesterday. In the “Grizzly” release, support for VMware ESXi hypervisor has been added.  So I asked:

The reason for my question is that I’ve heard a number of Enterprise IT organizations say that they are planning to explore OpenStack in the coming year for their Private Cloud (or Virtualized Data Center) environments. Given that VMware vSphere has 60-80% marketshare in that market segment, many of them are also curious about reusing existing investments in hypervisor licenses, and Live Migration has become a standard capability for Enterprise IT organizations and legacy applications.

The responses I got back varied quite a bit. Some talked about Live Migration support across multiple hypervisors (Xen, KVM, Hyper-V). Others talked about the added components needed (eg. VMware vCenter). Still others claimed that including vSphere in any cloud environment is a bad design.

What happened next was a discussion about what “Live Migration” really meant, as not all hypervisors work the same way as Enterprise customers might expect from VMware vSphere.  Some claimed that it was “seamless enough”, while others highlighted that it still required some additional capabilities that are only available in a commercial distribution of OpenStack.

All this discussion for a single feature/function.

Does any of this really matter? Maybe or maybe not. It all depends on the expectations of the users. It all depends on the applications being deployed on a cloud infrastructure. It all depends on which systems they are hoping to re-use or which systems they are looking to eliminate (or avoiding overlapping functionality). If nothing else, it highlights that users may have to reset expectations if they plan to migrate to a new cloud system.

If you’re looking to explore OpenStack in 2013, what expectations do you have for the projects?

Jason Edelman works for a well-known VAR (Value-Added Reseller), with a deep technical focus on emerging networking technologies (SDN, OpenStack Quantum, Open vSwitch, etc.). Not only is he trying to stay ahead of the technology evolutions, but he’s also trying to forecast how the changes in consumption models (eg. cloud computing) and open-source (free, paid-support, etc.) might impact his company.

To give Jason some guidance, I sent him a couple links (here, here) that seemed relevant to VARs. It seemed like a simple way to share some knowledge in 140 characters.

But the more I thought about, his question really does hit on much larger system-level evolutions. The good news is that IT is like many industries and we can look to history for how it will likely evolve.

Let’s start with a few very good reads - Those two sources should be on everyone’s reading list

• Simon Wardley’s blog: Simon (@swardley) is a scientist with a deep understanding of technology, economics and industry modeling. Just start by reading the “Popular Posts” on the right side of the page and you’ll quickly realize that the changes we are seeing align to models than many industries have seen in the past. Simon is an excellent follow on Twitter, and has been a guest on the podcast.
• Porter’s Five Forces: The classic strategy model provides useful frameworks for understanding supply-chains, competitive strengths and weaknesses, buyer vs. seller leverage and competitors.

While I try and read, and re-read, many of those links on a frequent basis, sometimes they can feel sort of academic at times. So I’ve started to create some questions that I’ll ask myself to see if I’m able to translate the theories and models into the action (or potential actions) of today’s companies and communities. Here’s a few I use:

1. What does the FULL value chain from supplier to end-user look like today? How much value (profit) does each link in chain receive?
2. Where are there opportunities to remove a link in the chain, or have that link become part of another link (merger; consolidation)?
3. Are any of those links based on a structure that could be disrupted (or eliminated) by new technology?
4. Where in the value chain is the greatest profit? Is the “value” provided still considered valuable by the market, or has it commoditized (or moved) to some other level?
5. Are there opportunities to change the way customers buy the products/services (CAPEX > OPEX; Smaller Quantities; More Customized)?
6. What would happen if a portion of that value-chain was driven to $0 (revenue/profit)? How would that effect competition? How might that expand the market?
7. Are competitors only focused on aggressive actions (acquire revenues), or do they also engage in actions that eliminate the strength of competitors (eliminate advantages/leverage)?

Cloud Computing is allows companies to bypass portions of the historical value-chain.

Open source software is allows companies change the way they “buy” products/services differently.

Open source software allows suppliers to potentially remove a link in the value-chain by leveraging communities, or focusing on service delivery or customizations.

Projects like OpenDaylight are attempting to reduce/eliminate the strength (or revenue stream) of competitors.

Projects like OpenStack, CloudStack, Eucalyptus are trying to change the competitive playing field for commodity cloud services by leveraging communities of developers.

So to answer Jason’s original question, it’s valuable to not only look at the associated technology, but more importantly it’s important to learn how it aligns to the industry evolution models that we’ve seen historically. It’s obviously that the value-chain is changing, but how each individual company responds is still to be determined. History tends to repeat itself, but not everybody learns from the lessons of the past.

All people need to do is show up at their gym and they’ll quickly become the envy of their friends and neighbors. Just buy the right clothes, the right shoes and the right electronics. Lured by the promise of a smaller waistline, greater flexibility and improved health, customers line up with their checkbook to get the promise of an improved life.

The first couple gym visits go OK. It’s painful, but they loose a couple pounds. They believe a lifestyle change is possible. Then February comes along, and work or travel or family make it tough to get to the gym. The weight-loss plateaus because losing the next 10-15 lbs would require both gym visits AND dietary changes. Being able to look like that athletic guy or girl, doing extra reps each day, would require a full-on lifestyle change. And by May or June, the enthusiam is gone and you’ve fallen back into your old ways. Sure, you visit the gym from time to time, but getting significantly better is a lot more work than you expected. Maybe next year you’ll follow through with your goals.

Sound familiar IT folks? Even though we continue to see studies claiming that Enterprise IT organizations are prioritizing their Private Cloud build-outs, the reality of successful deployments is much fewer than expected, and it’s taking much longer than pontificated.

But how is this possible? You’ve bought all the latest hardware from vendors claiming to have the right “journey to cloud” . You saw some initial cost savings and faster provisioning times of virtual machines. Things were feeling good, but then something happened. Your cost savings began to plateau, and your users continued to ask for services faster than you’ve been able to deliver with the new “cloud”.

• Maybe you called your virtualized environment a cloud, but didn’t implement any of the aspects that would make it a real cloud (elastic capacity, self-service consumption, on-demand pricing models, etc.)
• Maybe you realized that existing business units didn’t want to co-mingle their resources, preventing you from actually delivering multi-tenant security or economics.
• Maybe you realized that your IT organization wasn’t structured, from a budgeting perspective, to have additional (elastically scalable) resource available to quickly respond to new project requests.
• Maybe your management group didn’t have the patience to not see results for 2+ years before they saw a change in service delivery.
• Maybe your business units didn’t care about 3yr ROI models for a new app, when their business demands needed to see ROI and improved revenues within the next 90 days.

Or maybe you just realized that implementing a Private Cloud requires a full-on lifestyle change. But instead of adding vegetables and long runs, this lifestyle-change requires costs, people and processes to change. And as far too many Enterprise IT organizations are finding out, making that happen is a lot more work than you expected.