Formerly known as Wikibon
Close this search box.

Strategic Comparison of Public Cloud versus Hybrid Cloud

Research done in collaboration with Stuart Miniman


CIOs understand that a clear cloud strategy is critical for IT today. Wikibon believes the biggest mistake organizations can make is converting major applications into the public cloud (including SaaS) without thinking about the implications to their existing business process workflows. Unlike web giants, most enterprise companies have a large, sprawling and integrated application portfolio. Wikibon recommends that IT develop and implement a hybrid cloud strategy (see Wikibon’s guidance on creating a hybrid cloud manifesto), using the existing workflows and compliance for both the public and private cloud components in the hybrid cloud.

In order to focus on creating early value for the organization, Wikibon recommends the public cloud be initially used for applications needing a richer development environments (e.g., new developing new mobile and big data applications) and for deploying SaaS applications that offer significant early business benefits. Wikibon recommends these public cloud are accessed and managed through the same hybrid cloud that is implemented to automate and orchestrate existing applications in the enterprise private cloud.  This hybrid cloud wrapper will ensure that both applications in both the public and private cloud meets the security, compliance, performance, governance, provenance and privacy edicts of your organization. Enterprises that take this hybrid cloud approach using existing workflows instead of simply pushing everything to public clouds will have a faster breakeven and reduce the risk of project failure or stall during a multi-year conversion.

Video (below) with Wikibon’s David Floyer and DeepStorageNet’s Howard Marks discussing this research

Executive Summary

The strategic decision facing many CIOs today is understanding the cloud topology options available to their organization as well as the financial and IT value creation implications of those decisions. Wikibon has looked in detail at an illustrative case study to help IT and CXO executives to filter the signal from the noise.

ExecSummaryCloudV2Figure 1 compares a hybrid vs. public cloud strategy in terms of financial metrics.  The research looked in detail at the strategic value of:

  1. Developing applications in the cloud and converting all existing applications to run within that hybrid cloud;
  2. Developing applications in the public cloud, and running existing applications in a private cloud and managing all the applications and data with a hybrid cloud.

For the purpose of this research, Wikibon assumed the business and IT models for an organization with $1 billion in revenue and 4,000 employees (see Table 1 in the Strategic Case Study section below).

Given our assumptions, Wikibon believes the hybrid cloud strategy can allow three times more value to be created, with a breakeven of 6 months, compared with a public cloud strategy with a breakeven of 25 months.

One of the most important metrics Wikibon tested was the comparative operational productivity of public cloud environments and hybrid cloud environments. Amazon Web Services (AWS) was used for the public cloud and for hybrid cloud, a VMware-based solution (Federation Enterprise Hybrid Cloud from EMC) was chosen, as it would match a typical existing enterprise data center environment. The philosophies of the two environments are, of course, very different with the existing workflow in the hybrid cloud replicated in an automation and orchestration layer. In the AWS case a new workflow was established with the AWS toolset. Once established, however, the productivity and time-to-deploy of the environments was very similar, as discussed in the Hybrid Cloud/Public Cloud Time-to-deploy Comparison section below. A well-run private cloud can be as cost-effective as a public cloud. There will be, of course, specific applications that will run better on one or the other at a given moment in time . But a hybrid cloud umbrella will allow migration as the landscape changes.

The main difference between the hybrid cloud and public cloud approaches is that the hybrid cloud is an extension of the existing workflows,  with very little change made to any of the processes or procedures except the outer automation/orchestration layer. The elapsed time for migration to a hybrid cloud environment was assumed to be four months. In the public cloud case, there needs to be a conversion over to a different workflow, which takes longer and requires freezing the applications while the conversion takes place.

The key to the success of the hybrid approach is that work better suited to a cloud solution can be migrated to one or more clouds, while the existing management workflows are retained in place. Wikibon believes that many of the claimed benefits of public cloud, i.e.,  bursting, following the sun, and migration of workloads because of local emergencies have exaggerated value. While a few examples of these benefits exist, the fact is that a vast majority of workloads are held in place by data which is expensive and difficult to move. The increasing use of low-latency storage environments will make it imperative that most data be kept close together, with an increasing amount of data sharing.

Wikibon believes in general that a hybrid step-by-step approach is a much better strategy for the majority of mid-sized and large IT organizations, which will allow lower conversion costs now and greater flexibility in the future.

Strategic Case Study

The strategic case study looks at the three year business case for two cloud scenarios:

  1. Converting everything to a Public Cloud, including development and all current systems;
  2. Migrating to a Hybrid Cloud, using the current workflow with improved orchestration and automation for both the private and public portions of the hybrid cloud. The development is moved to the public cloud to take advantage of the greater choice of tools and software.

The assumptions and calculations are given in Table 1 below. The “organization” used in the study is the standard “Wikibon organization” with $1 billion in revenue, 4,000 employees and an IT budget of $40 million (4% of revenue). The percentage of budget spent of application development (including application maintenance) is assumed to be $8 million (20% of $40 million).

Wikibon uses the term application value to describe the value of an application to the business. The basic assumption is that end-users will be at least as productive using IT as they are in all the other activities they perform (meetings, travel, planning, telephone, factory work, etc.). The revenue per employee of the Wikibon organization is $250,000. The amount of time an average employee is actively using IT (being just signed in does not count) is assumed to be 12% (of course knowledge workers will be much higher, and other workers lower). The application value from IT is calculated as 12% of the revenue per employee, an average of $30,000 per employee. The total application value for the Wikibon organization is $30,000 x the number of employees, which equals $120 million. The IT spend is $40 million, so the value multiplier for IT is 3.

Applications and IT in general lose value each year if they are not maintained. The business world is constantly changing, and unless IT is updating the application and IT, the value of IT will decrease over time. Wikibon has done extensive work in this area, and the assumption used for the business case is a 10% loss each year, which we believe to be conservative. $12 million is lost in application value if there is no application maintenance or replacement (similar to asset depreciation).

IT is assumed to spend 80% of application development keeping the lights going and maintaining the current application environment. This resource is applied to avoid losing the $12 million in application “depreciation”, about $1 million per month. 20% of AD goes to new applications, and assuming the same value multiplier, $4.8 million is created each year in new application value.

AssumptionsHybridPublicCloudsV2The cost of setting up a hybrid cloud is mainly from the services for implementing and integrating the current IT workflows into a hybrid framework. The Federation Enterprise Hybrid Cloud was the example in this case study. This figure is estimated as $300,000, which includes the implementation of orchestration and automation.

The second part of the set-up costs is the increase in software costs,  and some upgrades in VMware management software. This license cost is estimated as $900,000, with a 22% maintenance cost in years two and three.

The elapsed time for accomplishing this project is estimated as four months. One of the key assumptions in the hybrid cloud case is that the cost and productivity of the private cloud component (after automation and orchestration) will be competitive with the public cloud. Wikibon conducted  specific hands-on work to test this assumption (detailed in the “Hybrid Cloud/Public Cloud Time-to-deploy Comparison” section below) and found that there is no significant productivity or functionality difference between best of breed use of a public cloud and a best of breed use of hybrid clouds. Of course, for different organizations there will be specific applications that will run better in the public cloud, and some in the private cloud, but we believe our test represented a fair general comparison.

The cost of conversion of applications from one operating system to another or from one platform to another requires testing the converted code, and setting and testing new processes and procedures for managing the applications. There are two ways of managing a conversion project; the first is to freeze the applications and procedures until after the conversion is complete, and the second is to continue to update applications both in the source and target systems.  The second approach works initially, but is extremely difficult to manage in the later part of any conversion project, and can significantly extend the project. This case study assumes a best practice approach of freezing the applications until after the conversion is complete. The major disadvantage of this is the business dissatisfaction with not allowing change, and the decreased functionality of the applications over time. The cost of the conversion effort is estimated at $0.75 million, with an elapsed time of 9 months. The application value lost is estimated at $1 million for each of the nine months, as discussed above.

The case study assumes that application development elapsed time and effort will be reduced by 40% by moving to a public cloud. This benefit is achieved in both our hybrid and publci cloud scenarios. As a result of this improvement in productivity for maintenance, the amount of AD resource dedicated to maintenance will decrease from 80% to 48%. This releases additional AD resources for new application development. The estimated additional application value is calculated as $7.7 million per year.

The 3-year business case for the two alternatives are shown in Table 2 below.

BusinessCasePublicvsHybridCloudV31The net present value of a public cloud conversion project, given the assumptions in Table 1, is shown to be $6.2 million over 3-years, with a breakeven of 24 months and an IRR of 41%. The net present value of a hybrid cloud migration is shown to be three time higher at $17.3 million, with a breakeven of 6 months and an IRR of over 300%.

The key to understanding the benefit of the hybrid approach is that the effort required to establish the hybrid cloud is short, because it is reflecting the current workflows and management procedures. Then only the pieces that will get a significant return by being in the public cloud are migrated to the public cloud. That cloud may be an infrastructure cloud (IaaS), a platform cloud (PaaS) or an application cloud (SaaS). Good hybrid clouds will allow multiple public clouds to be enabled, and for ease of migration between different public clouds.

Hybrid Cloud/Public Cloud Time-to-deploy Comparison

Objectives and Metrics

Wikibon developed and tested a sample scenario for an enterprise looking to leverage their pre-existing software develop life cycle (SDLC) process on public cloud (we chose AWS EC2) infrastructure.

The scope of the test was to determine the level of effort and time required to deploy a development environment for enterprise application based on a typical scenario given in the scenario sub-heading of this document. The test was limited to the effort to deploy the environment and did not directly test the performance of the application or reliability of the infrastructure.

The objectives and metrics we chose were:

  1. Identify the level of effort required by infrastructure admins
  2. Identify the level of effort required by developers
  3. Identify time required to deploy infrastructure
  4. Identify time required to deploy cloud applications
  5. Identify key performance indications for .NET applications, Linux, Apache, MySQL and Python (LAMP) application

Tasks Included 

The tasks for the process included:

One Time Tasks and Infrastructure Tasks
Table 3: One Time and Infrastructure Task to Created Public Cloud Environment
Source: Wikibon 2015


Comparison Scenario

In order to provide a context for the benchmark, Wikibon posited the following reference scenario for the comparison.

  • A regulated company is looking to enable rapid application development for highly availability applications based on Microsoft .NET and the LAMP stack.
  • The organization has an infrastructure group responsible for security and operating system (OS) management.
  • This infrastructure group is also responsible for creating and maintaining the service catalog for the developers.

The target enterprise IT operations had the below high level requirements.

Enterprise IT Requirements
Table 4: Overall Management Requirements for Application to be Deployed
Source: Wikibon 2015

Hybrid Cloud Software and Tools Used

The hybrid cloud chosen was the VMware-based Federation Enterprise Hybrid Cloud (EHC), which represents a low migration point for many IT installations with VMware management tools. Wikibon’s scenario starting point was an enterprise using VMware Workstation 10.0 to develop standard OS images. Common developer tools and application binaries were deployed within the OS image.

Public Cloud (Amazon) Tools and Services Used

The Amazon Import/Export command line tool was used for the import and export of volumes for creation of AMIs. Amazon’s Databases Services were used for application environments needing highly available databases. Amazon’s CloudFormation service was used to orchestrate and automate the deployment of services for individual application environments within a VPC.

Comparison Results

See the Appendix at the end of this report for a summary of tasks and results.

Bursting or Balancing

Vendors are constantly talking about the value of bursting to a public cloud. There are some unicorn cases, but for most practical applications the data has to be near the processing. Data is heavy, expensive and time-consuming to move to a public cloud for all but the smallest of applications. And moving data back out again from a public cloud is even more expensive.

There maybe some ability to balance workloads within hybrid clouds by migrating the application and data. This is much easier if a mega datacenter strategy is utilized, where the private cloud is co-located in the same data center as the public cloud, and where fast low-latency within building communications are available. For example, both Equinix and SuperNAP offer co-location and very fast communication to public clouds. Microsoft is making significant investments in this area with Azure.

The migration of traditional storage with 10 millisecond IO times to flash-only storage with 1 millisecond will make movement of data even more difficult and expensive. Wikibon continues to recommend that enterprises move away from major internal data centers in favor of the use of mega datacenters.

Conclusions and Recommendations

This study shows that wholesale conversion of a working infrastructure to the public cloud is unlikely to be an optimal strategy. There will be some organizations were a wholesale migration to a public cloud is justified, including greenfield start-ups and very small organizations, or those organizations with very highly skewed processing for all its mission critical applications. For most enterprise customers, Wikibon recommends that taking a hybrid cloud approach will allow them to maintain their current workflow, and within this strategy strategically choose specific applications or functions to move to a public cloud best suited to run it.

Action Item

As always, Wikibon recommends conversions be avoided like the plague. For most organizations implementing a hybrid cloud strategy using existing workflows will be the preferred strategic choice.  The workflows should be upgraded with good automation and orchestration to optimize ease-of-use and ease-to-deploy. Workloads that should be in a public infrastructure cloud, including SaaS and PaaS options, should be migrated within the control of the hybrid cloud. Where possible, Wikibon recommends co-locating the private cloud in the same mega datacenter where there are many options for public cloud services. 



AWS Pre-Work
Table 5: AWS Public Cloud Pre-work required
Source: Wikibon 2015
Screen Shot 2015-04-02 at 5.27.21 PM
Table 6: Infrastructure & Developer Work required to Deploy an AWS Windows.NET Environment
Source: Wikibon 2015


Table 7: EMC Hybrid Public Cloud Pre-work required by Administration and Developers
Source: Wikibon 2015
Microsoft .NET EHC
Table 8: Infrastructure & Developer Work required to Deploy an EMC Hybrid Cloud Windows.NET Environment
Source: Wikibon 2015


Article Categories

Book A Briefing

Fill out the form , and our team will be in touch shortly.
Skip to content