The Case for OpenStack in the Enterprise Private
Not long ago Gartner released an oft-quoted statistic: 95% of private clouds fail.
According to Tom Bittman, VP Distinguished Analyst at Gartner, of 140 customers
polled, 95% reported “something was wrong” with their private cloud (article
).Identifying a shortcoming and labeling it a ‘failure’ might be a bit of hyperbole, but it still leaves enterprises wondering if there is a place for private cloud in their strategy. This paper will attempt to answer this question, and will focus on the role of OpenStack in particular as a private cloud solution.
The world is already Intercloud
A little over a year ago, Cisco introduced the idea of an Intercloud to the public. The term “Intercloud” means that there are many flavors of clouds in use today, and that they are somehow connected. The vision is quite simple: there are enterprise private clouds, cloud-based services (usually but not always SaaS), managed service providers, and of course the giant commodity clouds such as AWS and Azure.
Cisco Confidential 16 © 2014 Cisco and/or its affiliates. All rights reserved.
Cisco IntercloudEnterprise Private Clouds Public Clouds Intercloud
Partners Cloud Services &
Applications HCS IaaS PaaS Microsoft Suite aaS DRaaS Enterprise Workloads Native Cloud Applications
Big Data & Analytics Collaboration & Video Meraki Analytics WebEx Security Energy Management HANA aaS vDesktop aaS APIs Portal APIs APIs
Figure 1. Cisco’s Vision of Intercloud
Among IT departments, there is sometimes a perception of the inside and the outside. By this I mean, there is my
data center(s), and then there are all the things that happen outside the data center, with which we will interact. IT
departments and CIOs in particular often grossly underestimate the amount of “outside” cloud usage that is already happening in their enterprises. For example, Cisco offers a cloud discovery service to customers that measures and analyzes the actual consumption of outside cloud services by employees. We typically discover that there is 5 to 10 times more cloud traffic than anticipated, and much of it is unauthorized. So the reality is that most IT organizations are already living in an “Intercloud.”
Does this make the private cloud obsolete? Should enterprises just outsource all their cloud needs to providers? Do all applications sit equally well in an outsourced public cloud? This paper will make the case that there is a definite need for an enterprise-hosted private cloud. The private cloud is part of a larger strategy around managing the Intercloud.
Application development is shifting
Before we get too deeply into cloud infrastructure, we need to recognize the big shift in application development that has taken place over the last few years. There is a new generation of applications being developed as “cloud native.” They are built as a collection of loosely coupled services that are managed with APIs. The development style associated with this kind of application is known as “agile.” It is highly influenced by Lean philosophy and puts an emphasis on speed and flexibility: feature sprints, continuous development, and rapid shifts to meet customer
feedback. This approach is opposite to the traditional hardware/virtualization approach. Rather than dividing a single server up into multiple applications (as with traditional virtualization), multiple virtual servers support a single application.
Cisco Confidential 5 © 2014 Cisco and/or its affiliates. All rights reserved.
Agile (cloudy, stateless, scale
Server Single Server Hypervisor
Many Servers Single Application
Figure 2. Traditional vs. Cloud Applications
This does not mean that traditional virtualization will go away. Some applications such as systems of record, legacy applications, and large enterprise suites are best suited to traditional development. Applications that demand elasticity or rapid evolution based on customer experience as well are suited to cloud development. Applications will drive the platform.
Lydia Leong, Research VP at Gartner, has proposed the term “Bimodal IT” to describe this dualism. For now, there will be two separate types of development and applications in enterprises that IT departments will have to support.
The challenge is that processes that support traditional IT do not work for agile/cloudy development. The common complaint is that “IT just gets in the way.” Developers become frustrated if relatively simple tasks like provisioning a new virtual machine could take weeks. This time delay and perceived obstruction by IT has led to the rise of public clouds.
Why have public clouds (AWS, Azure) been so widely adopted?
The perception of traditional IT as an impediment not and enabler--as something that slowed down development and put roadblocks in the way--has caused developers to turn to public clouds such as Amazon Web Services and Microsoft Azure. In short, it’s about agility--not cost.
The agile development style that is so closely coupled with cloud development puts a premium on speed and agility. Waiting several weeks to get a new server or even have a port opened is simply too slow. Developers under
pressure use personal credit cards to get resources on-demand from AWS, for example. This used to be called “Shadow IT.” Now it appears to be going mainstream.
We have observed a trend of individual Lines of Business (LoB) having increased discretionary spending when it comes to hosting their own project development and deployment. In other words, traditional IT now competes with AWS and Azure for projects within their own enterprise. Many enterprises have entered into agreements with Amazon and Azure (among others) to provide this IaaS to their development teams.
As mentioned earlier, cloud-native applications are driven by loosely coupled services and APIs. Elasticity is driven with the application itself. For example, if a web server becomes unresponsive, simply destroy it and create a new one, all through automation. This facility is commonly called “infrastructure as code” by development teams. It also means that developers care less about where their application is hosted and more about the ability to interact with the infrastructure through APIs.
Put another way, a cloud solution will live-or-die by its agility and its APIs. Public clouds such as AWS and Azure have been able to solve that need.
Why bring the cloud in-house?
If public cloud providers were so great, why would an enterprise even bother with a private cloud? There are definitely some apps that do very well and probably should live in hosted cloud: applications that require a lot of elasticity and scalability with no predictable pattern, for example. Yet there are also some apps that are better suited for in-house management, especially if they are data intensive or subject to data regulation. Here are the most common reasons to bring a cloud in house.
1. Cost – While public clouds can grant a lot of flexibility, it does not come free. The more services are consumed, the higher the price tag becomes. In many cases, the costs creep up past planned expenses as the
developers respond to customer requirements. As a rule of thumb, if there are more than 100 VMs in EC2 (size Medium), it may be possible to lower the TCO by deploying a cloud in-house.
2. Business considerations – There are some non-technical reasons to keep some clouds in house. One very common one is data sovereignty. As our globally connected Intercloud world is evolving, some nations have created legislation requiring companies to maintain their data inside geo-political boundaries. Other
enterprises have very strict regulatory and security requirements that disallow for any public cloud presence. For example, a financial services company may have a strict rule that no code leaves the premises as a means of consolidating security and competitive secrecy.
3. Data Intensive Applications – Some applications that have a lot of data movement do much better in house. A common example is Big Data such as a Hadoop deployment. The amount of East-West traffic when running analysis is staggering, and is much more efficient with low latency systems housed inside the enterprise. 4. Noisy Neighbors – Another challenge of public clouds lies in the nature of the shared infrastructure. IT
departments have no control over what workloads are placed where, and there can be situations where someone else’s application will consume a very large portion of the resources, leaving your application struggling to perform. This is called the “Noisy Neighbor” problem. Applications that demand quick
responsiveness (e.g. ticket reservation systems, real time updates) are better off on dedicated infrastructure that can be managed for performance.
What you lose when going from public to private
The reason many enterprises adopted public clouds was to speed up development by making complex
infrastructure management someone else’s problem. And yet we are making the case to bring some applications in-house. Does that mean that IT departments must wrestle with complexity and legacy tools to fit the new cloud-native development? The answer is an emphatic “No.” But there will be some changes.
Before we get into typical changes, what are the features you lose by moving from public to provide cloud? 1. Vendor Specific Services - In some cases, applications have evolved and been built around services provided
by the vendor. For example, Amazon provides a long list of consumable services from Identity Management to Archive Storage to Database-as-a-Service. In many cases there is an existing enterprise service already in place, but the effort to integrate from one set of services to another could be daunting. On the other hand, it is a way for vendors to lock in their customers.
2. Outsourced Management - Possibly the most valuable feature of public clouds is the outsourced management. While it does have some drawbacks (as discussed above) there is some discernable value to projects, and developers to have some ‘always available’ resources.
3. Infrastructure as Code - The API-centric interface that makes cloud development so powerful is much more difficult in traditional virtualization tools such as VMware. Traditional virtualization simply will not perform for cloud development.
OpenStack - Agility in-house
For many enterprises, the way to keep the above features while deploying in-house is through OpenStack. OpenStack is a very large and mature open source cloud management solution. It is growing exponentially in features and robustness as thousands of developers and some of the largest tech companies (such as Cisco, HP, and Red Hat) contribute the project. It offers the same flexibility and API-centric control as a public cloud. Even better, it is platform agnostic and supports multiple hardware and software platforms.
Figure 3. OpenStack Model
Some of the largest web applications in the world are deployed on OpenStack due to its scalability and robustness. The early adopters of OpenStack were tech companies whose main business was run off one or two major
applications, and were willing to add resources to maintain the stack. PayPal is a great example of a highly scalable and demanding app.
As OpenStack evolves, the features have progressed enough to be useful for general enterprise use cases, and many companies are already deploying the solution. Research firm 451 predicts that OpenStack’s market cap will reach $1.6 billion by 2016. So OpenStack is fast becoming the solution for private in-house clouds.
In summary, OpenStack provides the elasticity and infrastructure as code required for agile developers, while avoiding vendor lock in.
Challenges – OpenStack is a project, not a product
First understand: there will be cultural changes. Simply downloading and installing OpenStack does not a private cloud make. As described earlier, cloud development is a combination of process and technology. Successful private clouds embrace the DevOps model, where developers and IT work together in teams, not as silos. That means that IT Ops should not impede the speed of developers, but instead should provide them with exposed APIs and scalable, on-demand infrastructure. In other words, IT must provide infrastructure as code. On the developer side, code and applications must conform to policy and standards to make the job of management easier on IT Ops. In this new world, the role of IT Ops will be to monitor, manage, and assist--not control.
Figure 4. A DevOps Model
The second challenge will come from OpenStack itself. While the software is very powerful and scalable, it cannot be ignored that OpenStack is an open sourced project, not a product. As such, it has all the limitations of open source software: No help desk support, unintuitive management features, and potential bugs when deployed at large scale or on incompatible hardware.
Figure 5. Under the covers of OpenStack module interaction—an incomplete view
In particular, there is the issue of complexity. The tradeoff for power and flexibility is usually some complexity of configuration and maintenance. Installation itself can be a challenge, and several vendors such as Red Hat have created OpenStack ‘packs’ for easier distribution. However, none of these are production-class deployments. Regarding production deployments, this is another issue to address. A great number of enterprises have deployed OpenStack in small lab or POC environments, but relatively few have gone full production. In production
deployments, it becomes clear that some features that work well in labs fall down at production volume. In production deployments, robustness has a premium over features.
Hosted On-Premises Solution – The Best of Both Worlds
Given all these challenges, enterprises are faced with the need to hire and train specialists just to manage their OpenStack environment. While this is probably a good idea in the long term (and a good place for IT to invest in training), it will be expensive in the short term. And even worse, it will actually slow things down--the exact opposite of what cloud development is supposed to be.
Fortunately, there is another option: hosted on-premises private cloud. In this model, the software vendor installs the OpenStack application on the customer’s premises, inside the customer data center on their existing hardware. Even better, the hosting company will remotely manage and administer the OpenStack system for the customer. The net result is that developers get APIs and on-demand infrastructure, IT Ops does not need to manage a complex system, and the enterprise gets the advantages of having true private cloud in the data center.
Cisco OpenStack® Private Cloud (formerly known as Metacloud) is one such solution. Metacloud pioneered the on-premises, managed OpenStack model back in 2011 (one year after OpenStack was released as open source). The founders were early adopters who ran giant-scale cloud-based applications and were keenly aware of the operational challenges. Cisco Systems acquired Metacloud in September 2014.
10 C97-733661-00 © 2015 Cisco and/or its affiliates. All rights reserved. Cisco Confidential
What Cisco OpenStack Private Cloud Provides
Design and Architect Platform Installation 24X7 Monitoring Problem Mitigation Maintenance Coordination Platform Updates Capacity Planning Cisco OpenStack® Private Cloud
Remote private cloud engineering and operations
Delivered “as a service”
In your data center, on your hardware (that meets minimum specifications)
Figure 6. OpenStack as-a-service
What separates Cisco OpenStack Private Cloud from any other hosted, managed OpenStack solution is the combination of:
● Technical expertise and experience running production clouds (not labs or PoCs)
● Advanced management and telemetry for remote monitoring of the cloud, which allows for proactive, SLA-driven support
● The OpenStack package they deploy is thoroughly tested for scale, security, and robustness. Any problematic or suspect features are disabled to avoid problems.
● Service-based pricing. Just like the public cloud, customers pay monthly for what they use.
● 99.95% SLA for availability, including 30-minute response to tickets and live migration of workloads.
● Multiple availability zones for tenant separation and security.
Figure 7. OpenStack on-premises, remotely managed
Cisco OpenStack Private Cloud combines the best of both worlds: the low management, infrastructure-as-code, service–based pricing of the public cloud with the security and control of an on-premises private cloud.
So how does Cisco OpenStack Private Cloud compare to public cloud providers? Below is a chart comparing the cost to deploy Cisco OpenStack Private Cloud (on purchased hardware) against Amazon AWS. Note that we are comparing both on-demand EC2 instances (the most expensive) as well as reserved instances. Note that in all cases Cisco OpenStack Private Cloud shows a lower TCO.
38 C97-733661-00 © 2015 Cisco and/or its affiliates. All rights reserved. Cisco Confidential
0.120 0.100 0.080 0.060 0.040 0.020 0.000
Cost Per Compute Hour – Cisco OpenStack® Private Cloud vs. Amazon EC2
Cisco OpenStack Private Cloud EC2 On Demand
EC2 Light 1yr. Resvd
EC2 Med 1yr. Resvd
EC2 Heavy 1yr. Resvd
A Real World Customer Example
As mentioned earlier, certain applications themselves are better suited for either public or private clouds (or even traditional virtualization). In most cases, enterprises will continue with the hybrid cloud approach. That is, some workloads will remain in public clouds, some in private clouds. This is also part of the Intercloud vision that we began with: the private cloud is a node on the larger Intercloud.
Tapjoy is a customer who has deployed both public and private clouds for their business. Tapjoy provides analysis and monetization solutions to mobile application vendors. They are currently serving over 450 million monthly users across more than 270,000 apps worldwide, accounting for roughly 1 trillion requests per year.
The services are very ‘compute heavy,’ and Tapjoy was an early adopter of AWS. They continue to deploy well over 1000 virtual machines on EC2. But a big part of their business revolved around analytics--especially around Hadoop jobs. The team wanted to bring these big data jobs in-house for better management, scale, and cost savings. The staff at Tapjoy decided to engage Cisco OpenStack Private Cloud (then Metacloud) to deploy and manage their OpenStack deployment. They believed that the time to learn and deploy their own OpenStack private cloud would be too lengthy and expensive, and could potentially create service disruptions as the team learned a new technology.
Thankfully, Metacloud was able to consult with the Tapjoy team to get their OpenStack private cloud deployed and operational in a relatively short period. DevOps Manager Wes Jossey has said that Cisco’s OpenStack Private Cloud is five times less expensive than Tapjoy’s previous deployment. As their business expands, Tapjoy simply adds hardware and Cisco deploys additional nodes.
The key takeaway from the Tapjoy experience is that there is a real need for both public and private clouds, even in large web-centric companies.
Throughout this paper we have tried to emphasize that cloud development is driving changes in the way IT must operate. The days of being the single control point are fading. IT’s new mission is to act as a broker of services: to ensure that given applications are deployed on the correct. In more and more cases, this will mean a cloud application.
Cloud development will become a commonplace occurrence for most enterprises, if it has not already. As this evolution happens, enterprises will realize there is a need for both public and private clouds in their strategy. OpenStack is the obvious solution for private clouds, yet its complexity makes adoption difficult and time consuming.
The provision of an on-premises, remotely managed OpenStack private cloud solution is an excellent option for enterprises. It benefits both top line strategic initiatives and bottom line cost savings. It affords the on-demand, API-driven elasticity required by cloud applications, while at the same time benefiting from security, dependability and cost savings from having the cloud on-premises.
For More Information
Read more about Cisco OpenStack Private Cloud on cisco.com, or contact your local account representative.