White Paper
The Case for OpenStack in the Enterprise Private
Cloud
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 here).
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.
© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public.
Page 1 of 11
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 Intercloud
Native Cloud
Applications
Enterprise
Workloads
Big Data &
Analytics
Collaboration
& Video
Enterprise
Private
Clouds
WebEx
Portal
HCS
Meraki
Security
Intercloud
Partners
IaaS
PaaS
Cloud Services &
Applications
APIs
APIs
Microsoft
Suite aaS
Public
Clouds
DRaaS
APIs
Analytics
HANA aaS
vDesktop aaS
Energy
Management
© 2014 Cisco and/or its affiliates. All rights reserved.
Figure 1.
Cisco Confidential
16
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
© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public.
Page 2 of 11
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.
Application: Examples
!  Traditional
(dependencies,
statefull, scale-up,)
Server
Single
Server
!  Agile
out)
(cloudy, stateless, scale
Single
Application
Hypervisor
Many
Applications
Many
Servers
© 2014 Cisco and/or its affiliates. All rights reserved.
Figure 2.
Cisco Confidential
5
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
© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public.
Page 3 of 11
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.
© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public.
Page 4 of 11
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 cloudnative 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
© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public.
Page 5 of 11
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.
© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public.
Page 6 of 11
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.
© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public.
Page 7 of 11
Cisco Metapod™ 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 giantscale cloud-based applications and were keenly aware of the operational challenges. Cisco Systems acquired
Metacloud in September 2014.
Figure 6.
OpenStack as-a-service
What separates Cisco Metapod 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, SLAdriven 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.
●
Consulting and planning assistance for capacity management, security, and application architecture.
© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public.
Page 8 of 11
Figure 7.
OpenStack on-premises, remotely managed
Cisco Metapod 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 Metapod compare to public cloud providers? Below is a chart comparing the cost to deploy
Cisco Metapod (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 Metapod shows a lower
TCO.
Figure 8.
TCO Comparisons Calculated Over One Year
© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public.
Page 9 of 11
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 (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.
Conclusion
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, APIdriven elasticity required by cloud applications, while at the same time benefiting from security, dependability and
cost savings from having the cloud on-premises.
It may just be the best solution for a private cloud in the data center.
© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public.
Page 10 of 11
For More Information
Read more about Metapod features and benefits on cisco.com, or view Metapod technical tutorials on our
Community page.
Printed in USA
© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public.
CXX-XXXXXX-XX
10/11
Page 11 of 11