Premise: While the vast majority of CIOs place Hybrid Cloud near the top of their strategic priority list, the number with a plan of action is often a much smaller percentage. In today’s 24x7x365 world of business, the prospect of migrating a critical business application to the Cloud is a daunting task and one that could have significant financial impact on the business if not executed properly. 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.
This is Part II of a series where Wikibon explores Hybrid Cloud architectures and strategies. Part I can be found here.
Unlike web-scale cloud providers, most enterprise companies have a large and aging application portfolio that mixes modern and legacy systems. Wikibon recommends that technology organizations develop and implement a hybrid cloud strategy (see Wikibon’s guidance on creating a hybrid cloud manifesto), that builds upon existing workflows and compliance for private cloud components in the hybrid cloud.
As highlighted in the Wikibon’s True Private Cloud research, there are significant differences between Private Cloud and Public Cloud deployments and adoption.
While Wikibon does not recommend the concept of split mode IT organizations, due to evolving organizational dynamics, there is a distinct recognition that the need for digital business transformation will force many companies to rethink the customer-facing side of their business. For this reason, it is important to align the usage of public cloud resources vs. private cloud resources to the pace of change needed, and the flexibility of the associated applications.
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 or consuming SaaS applications that offer significant early business benefits.
Accessing and managing public cloud resources through the same operational framework that are used for existing applications is very difficult and not easily supported using existing tools and frameworks in the marketplace today. This is the promise of hybrid cloud, which Wikibon believes is lacking in maturity in the market, and is evolving into many forms of application use-cases.
For some companies, the speed and agility side of a digital transformation is a top priority, and will bypass (or de-prioritize) the need for a hybrid cloud framework at this point. Their focus will be on new, cloud-native application development and frameworks. But for other companies, where consistency of process are more critical, the need to create a “hybrid cloud wrapper” will take priority for application migrations.
This hybrid cloud wrapper will ensure that applications in both the public and private cloud meet 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.
The strategic decision facing many CIOs today is understanding the cloud deployment options available to their organization as well as the value creation implications of those decisions, both financial and IT . Wikibon has looked in detail at an illustrative case study to help IT and CXO executives to filter the signal from the noise.
Figure 1 compares a hybrid cloud vs. all-public cloud strategy in terms of financial metrics. The research looked in detail at the strategic value of:
- Developing applications in the public cloud and converting all existing applications to run within that public cloud;
- Developing new applications into the public cloud, and running existing applications in a private cloud and managing all the applications and data with hybrid cloud framework.
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 an all-public cloud strategy with a breakeven of 25 months. NOTE: Wikibon focuses this framework on business value creation instead of cost-savings.
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, an HPE Enterprise solution (HPE Helion) was chosen, as it would match a common enterprise data center environment. The philosophies of the two environments are very different with the existing workflow in the hybrid cloud replicated in an HPE Helion automation and orchestration layer. In the AWS environment, a new set of application workflows 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. Given the high cost of re-architecting both the applications and the workflows to a all-public cloud environment, for existing legacy applications, a hybrid cloud can be as cost-effective as a public cloud. There will be specific applications, both legacy and new that will run better on one or the other at any given moment in time. But a hybrid cloud management framework will allow migration as the application landscape changes.
The main difference between the hybrid cloud and public cloud approaches is that the hybrid cloud is an extension of existing workflows, especially for the large portfolio of installed applications within an enterprise. Very little changes will be 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 both application conversion and process/workflow conversion, which takes longer and requires freezing the existing applications while the conversion takes place. As a general rule of thumb, Wikibon advises avoiding conversions that are complicated and require a substantial code freeze. This guidance is particularly relevant for situations where change is frequent as long freeze times will necessarily limit competitiveness in the marketplace.
The key to the value proposition 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 for most customers. While a few examples of these benefits exist, the fact is that a vast majority of existing 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/migration 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:
- Converting everything to a Public Cloud, including application development and all current systems;
- Migrating to a Hybrid Cloud framework, using the current workflows with improved orchestration and automation for both the private and public portions of the hybrid cloud. The new application development is moved to the public cloud to take advantage of the greater cesce 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. It is a measure that quantifies the value that IT contributes 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 model 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 3X – in other words, a $1 investment in technology returns, on average, $3 to the company.
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 systems, 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. Hence, in our model example, $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 application development goes to new applications, and assuming the same value multiplier, $4.8 million is created each year in new application value.
The cost of setting up a hybrid cloud comes mainly from the services for implementing and integrating the current IT workflows into a hybrid framework. The HPE Enterprise – HPE Helion solution 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 or updates in management software costs. 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’s time to completion. Note: We chose to exclude the latter scenario of not freezing the code as in our experience the results could be disastrous and put a company out of business. We don’t see that approach as a viable option for a conversion of any substantive magnitude.
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 (for a total of $9 million in lost value due to the freeze).
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 public 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.
The 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 (Internal Rate of Return) 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 shorter, because it is reflecting the current workflows and management procedures. Then only the pieces that will get a significant return by running 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 Amazon AWS) 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:
- Identify the level of effort required by infrastructure admins
- Identify the level of effort required by application developers
- Identify time required to deploy cloud infrastructure
- Identify time required to deploy cloud applications
- Identify key performance indications for .NET applications running on Linux, Apache, MySQL and Python (LAMP).
The tasks for the process included:
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.
Hybrid Cloud Software and Tools Used
The hybrid cloud chosen was the HPE Enterprise / HPE Helion Hybrid Cloud. Wikibon’s scenario starting point was an enterprise that used .NET Visual Studio tools 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.
See the Appendix at the end of this report for a summary of tasks and results.
Bursting or Load 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 nearby for 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, as many cloud providers only charge for outbound bandwidth usage.
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 Azure is making significant investments in this area with Express Route, and Amazon AWS has similar Direct Connect offerings.
The migration of traditional storage with 10 millisecond I/O 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 where 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 the majority of their current workflow, and within this strategy, sytematically choose specific applications or functions to move to a public cloud best suited to run it.
As always, Wikibon recommends conversions be avoided like the plague. For many 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.