Private Cloud: 7 Major Risks You May Not Know About
Building a private cloud in your on-premises data center can be a game changer. “Private cloud” implies the power of on-demand computing, at your disposal, with complete flexibility to construct a technical solution that will suit your specific application needs. A private cloud releases your dependence on the whims of providers like Amazon Web Services (AWS) and Microsoft Azure, letting you do things your way, like storing data locally and managing compliance easily; and, in many cases, generate huge cost savings.
However, private clouds come with a unique set of challenges. Adopting a private cloud exposes your organization to several risks, some of which are not well known. What are those risks, and could they affect your decision to go private or public?
We cover seven risks that can be significant for your private cloud project—and some possible solutions that can help you mitigate them.
At the End of the Day—the Private Cloud is Still a Cloud
Many enterprises look to private cloud initiatives as a cure to the perceived problems of public cloud solutions, but it’s important to realize a private cloud uses the same, or very similar, infrastructure as a public cloud––from commodity hardware, through to virtualization using hypervisors like VMware ESXi or keyboard, video, and mouse (KVM), to Virtual Infrastructure Management (VIM) and Management and Orchestration (MANO), provided by software like VMware vRealize® or OpenStack.
The problems we perceive with the public cloud—low visibility into traffic and activity, security concerns, and so on—all exist on the private cloud as well. However, while many of these concerns are the public cloud provider’s responsibility, when you go public, they become your responsibility when you go private.
Public cloud vendors, for whom cloud is a core business, are expected to have a skilled workforce to operate cloud technology and deal with issues. Does your IT staff has the same level of expertise? How much will it cost to train them on new technologies, such as OpenStack, or hire new cloud experts?
How will you deal with security in your private cloud—from patch management to policy updates to adoption of new technology, which may create new vulnerabilities and expose your infrastructure to new threat vectors?
It is true that within your data center you will have much more power and flexibility to solve the issues important to you. But to begin with, you might face exactly the same problems.
Risk #1: Security Breaches
On the public cloud, responsibility for security is shared between the cloud vendor and the organization consuming cloud services. Whatever happens inside the virtual machine (VM) is your responsibility, while the physical hardware, virtualization, and cloud services are managed and secured by the cloud provider.
A private cloud can actually be less secure than a public cloud. Public cloud providers have years of experience and top notch expertise in security, and in many cases they will have fine-honed strategies, techniques, and tools to secure the various layers of the cloud stack. It’s true of course that public clouds are a bigger target for hackers, but the cloud vendors have an excellent understanding of cloud security concerns and how to mitigate them, which, as a private enterprise, you will have to learn.
Another point of concern is hybrid clouds, a growing use case. Security in a hybrid cloud is even more complex. When you shift workloads from the private to the public cloud—which can happen on-demand—how do you extend security from your private data center into the public cloud? There will inevitably be a transition from your internal security systems to those offered on the public cloud. In this transition, as traffic and apps are passed over from one system to another, there is a major risk of a “security lapse” that invites breaches. This is not an easy problem to solve.
Risk #2: Performance Problems
Performance is a well-known concern in virtualized environments. Because of the highly dynamic nature of the environment, it is difficult to predict how changing loads at the infrastructure level will effect application performance and user experience.
In the public cloud, users know how many machine instances they have and their compute resources, but there are many other things that can impact performance—network bandwidth, latency and jitter, noisy neighbors on shared compute resources, access to important resources and services and the speed of that access, and more. For more details on performance risks on the public cloud, see our related page: “VPC: Are You Getting Your Money’s Worth?”
On the private cloud, you have much more flexibility in how the cloud is built. You can select the hardware and software components, network infrastructure, and topology that will give you optimal performance for your use case. But who says you will really get the theoretical performance you think you’ll get?
Just like public cloud vendors cannot always deliver the performance users need due to the complexities of virtualized and dynamically-changing infrastructures, in your private cloud you also won’t always meet your theoretical performance goal.
Hidden bottlenecks can occur in virtualized systems, and performance might vary depending on the current mix of workloads, software upgrades from VMware, OpenStack, or other elements of the system, and many other factors. Are you sure that your infrastructure will perform under all use cases and environment conditions, including when it is upgraded?
A key step to mitigating this risk is having a continuous process in place to validate your performance. With every deployment you should have a way to perform a clear-cut and realistic performance test, preferably an automated one, which can expose issues at an early stage. Not having such a process exposes your organization to the risk of unpredictable performance problems.
Risk #3: Expertise and Learning Curve
Private clouds have been around for a while, and many are built using VMware’s software infrastructure, which is well known and has a large user base. However, more and more private cloud projects are opting for the powerful and lower cost option represented by open source platforms. OpenStack is emerging as the new de facto standard for private clouds—and this platform represents a big unknown.
If you do not have accomplished OpenStack experts on your team—and there are not too many of those out there—it will be extremely challenging to get an OpenStack project off the ground. In the OpenStack User Survey 2016, users commented on the difficulty and complexity of working with OpenStack, although the platform is improving in maturity. If you do not do it right at the early stages of an OpenStack deployment, things might break later. This might impact your ability to build the private clouds with the precise capabilities you need and meet your timelines for milestones during the project.
Risk #4: Lack of Visibility
One of the reasons to move from the public to the private cloud is to gain additional visibility into what’s happening in the cloud. A common perception is that once it is in your own data center, you will have much higher visibility into things like workloads, usage, traffic, and performance.
In the public cloud there is no easy solution to get visibility of your network traffic at the packet level. Existing monitoring tools, like Amazon’s CloudWatch and CloudTrail, do not let you “look inside the packets” to perform advanced diagnosis of network issues and prevent security problems.
On the private cloud, the situation is not much better. You’ll face the problem of “east–west traffic”—network traffic flowing between virtual machines (VMs), which does not touch a physical wire, and is thus completely invisible to traditional monitoring tools. East–west traffic can account for 80% or more of the traffic in a virtualized data center, creating a huge blind spot for IT teams.
A solution is needed for complete east–west traffic visibility across the entire virtualized data center infrastructure, where traffic to and from individual users and applications can be accessed and routed to analytics tools for performing analysis and reporting on issues.
Risk #5: Limited Scale
Many enterprises build a private cloud, as opposed to staying with a regular data center, to gain the power of on-demand computing and be able to develop enterprise applications and services faster. Though, at the end of the day, your private cloud’s capacity will be constrained by your budget.
What happens if application usage is much higher than you expect? For example, if you run a customer-facing service and there is an “explosion” of usage, how will your cloud support it? Or, to take another example, if you have internal enterprise service and adoption across the enterprise is much higher than expected, or data volumes increase expectations, what changes will be required in your private cloud?
You cannot buy an endless amount of computing resources to support the private cloud’s workloads, and it doesn’t make economic sense to buy large numbers of machines to support one off-peak load.
The classic solution to this problem is a hybrid cloud, enabling “cloud bursting” from the private cloud to the public cloud, in case workloads overshoot your local resources. But setting up a hybrid cloud adds cost and complexity to your private cloud project. Furthermore, a common reason to build a private cloud in the first place is compliance with internal policies or external regulations. For example, there might be an internal policy that highly confidential data must be located on-premises and must not leak to the public cloud, or a legal requirement that data cannot leave the country. Using a hybrid cloud for peak loading in these scenarios might be problematic—how do you make sure only non-sensitive workloads are load balanced between private and public clouds, while keeping your confidential or regulation-affected information on-premises?
If a hybrid cloud is not a valid solution, you’ll be exposed to the risk of overshooting your capacity, thus losing the economies of scale and cost savings that led you to build your private cloud in the first place.
Risk #6: Limited Services
This does not only apply to scale or cloud services and capabilities. On a public cloud like Amazon EC2 or Microsoft Azure, you have access to a plethora of cloud services, both native and third-party, which operate at the click of a button and give you everything from advanced management capabilities to auto scaling and high availability, storage services, instant provisioning of databases and big data clusters, and so on.
You can get most of these capabilities on the private cloud, but you have to plan for them and spend the time and money integrating and deploying these features. In some cases, you even have to build capabilities from scratch. In particular, high availability and resilience features provided by cloud services like Amazon AWS are difficult to recreate in-house. A feature like Multi-AZ, which allows you to maintain replicas of machine instances in a different data center, will not be possible in most private clouds.
The bottom line is that in a private cloud, you only have it if you built it. If you didn’t include a certain feature or functionality in your project scope, you will be limited in your ability to innovate on the private cloud.
Risk #7: Data Loss
According to data from Veritas* on 6,000 sources of risk to enterprise data, many private cloud implementations are exposed to major risk of data loss. Within three layers data loss can occur: the hypervisor layer, the virtual machine layer, and the disaster recovery or backup system layer. Due to the dynamic nature of a private cloud, traditional techniques for safeguarding data may not be enough, and may not function in predictable ways across all scenarios. There are also numerous possible misconfiguration scenarios that can have disastrous consequences.
Here are a few common examples, out of many mentioned in the Veritas study:
- Running multiple versions of VMware ESX, with some using virtual machine file system (VMFS) options unsupported by earlier versions, can lead to some VMs failing, data loss, and downtime.
- If a critical application is running on two VMs, with one live copy and one backup copy, and one of those fails, there will typically be an automatic failover. If that failover instantiates the backup on the same physical host as the live copy, there is a single point of failure.
- If there is a high performance RAID 1 for production data and a lower performance RAID 5 for archiving and staging, there might be a mismatch in which some VMs write production to the lower-performance storage, causing performance degradation or data loss.
Mitigating Private Cloud Risk with Ixia
Ixia is a leader in cloud and network testing, visibility, and security, with a strong track record in testing and validating virtualized network devices and infrastructures. Many of the leading cloud vendors and enterprises running major workloads on private clouds are testing and validating their implementations with Ixia.
The root cause of some of the private cloud concerns we highlighted above is unknown. IT organizations have limited experience with private clouds, how they function, and what might happen under various scenarios.
Ixia offers a unique methodology for emulating these scenarios and testing them under realistic conditions. This can be done while systems are still under development, and also on a continuous basis in production. Continuous testing can help organizations discover technical solutions and operational processes that will identify potential problems in the private cloud implementation and address them before they cause damage. Ixia can also help provide comprehensive visibility into east–west traffic flowing inside modern data centers and private clouds, allowing IT teams to diagnose performance issues, identify security breaches, and more.
We have prepared a quick guide showing how to easily perform continuous testing and monitoring of a private cloud, mitigating risk to make sure you get the most out of your investment, using Ixia solutions.