Cloud infrastructure deployments are quickly ramping up to accommodate a wide variety of workloads across the telco world and to incorporate with IT organizations and large enterprises. In some cases, edge computing and cloud RAN are coming into play as well. As predicted, widespread cloud infrastructure is becoming mainstream (finally), and deployment teams are demanding the freedom to make cloud vendor and technology choices that match their requirements. These don’t necessarily reflect the long-term needs of their organization as a whole. So, how do you balance freedom of choice with overall capex efficiency and avoid opex-eating complexity?
One of the factors compounding this “freedom of choice” mess is the speed at which cloud technologies are transforming. Just look at the virtual machine (VM) versus containers debate. But that’s par for the course with this industry. The other factor is the abundance of available options to choose from and the varied strategies that can arise from these options. Do you go with a strategic partner integrator and let them handle the whole thing? Do you perhaps invest in a vertically integrated stack that packages everything neatly with a bow for you? Do you take the mix and match, best-of-breed approach and let your technical teams handle integration, compliance, and interoperability? Maybe you’ll stick to your preferred vendor and hope that its claims of openness live up to its promise.
Inevitably, discrete silos in your organization deciding to use different strategic partners and packaged solutions may have a significant effect on your results.
Each of these options has its pros and cons, from long-term service fees, to the inevitable lock-in, to what are often less than best-of-breed solutions. And when you dive into the world of open source solutions, even more choices and dilemmas arise. Your strategic partner may be based on OpenStack, but will you be waiting a year or more before the partner makes changes to its proprietary branch based on the latest release?
Some of the answers to these questions have become pretty obvious over the past several years of cloud infrastructure trials, PoCs, and initial, limited deployments. Avoid vendor lock-in and embrace open source-based, multi-vendor solutions (Just look at the fantastic multi-vendor deployments going on these days). Look for strategic partners that are dedicated to integrating and servicing the open source solutions on an upstream-first basis, giving you access to the innovation and agility of the open source community without any proprietary branches. And don’t try to manage it all on your own — navigating the complexity of a large open source-based stack is more than a full-time job.
A single, organization-wide approach to your Cloud infrastructure management and orchestration is one of the key building blocks to ensure that you can truly harness the flexibility and scalability of the cloud. NFV infrastructure and its management is where your hardware resources — whether compute, storage, or network — are abstracted for the cloud. As the interface between physical and virtual, it is where the rubber meets the road. The robustness, performance, and security of your cloud operations start here.
Many infrastructure management functions can be found today in OpenStack. Your organization may even have implemented some of them. As an open source project for creating public and private clouds, OpenStack provides the right starting point for the types of workloads we’re talking about. It gives you access to an open solution that is supported by a very robust community, which enables you to harness a level of energy and innovation that far surpasses what a single vendor can accomplish.
OpenStack, nonetheless, has its limitations. Many, but not all of them, are still being addressed by ongoing work groups. In some cases you will have use cases that require third-party solutions to be integrated with OpenStack, for virtual network function (VNF) integration, for instance.
Without going to a proprietary branch version of OpenStack, you still need to wrap it with software that can ease deployment with automated installations, a wide range of reference hardware profiles, and integrated SDN deployment — most of which are missing in the community release. You will also need tools and analytics that enable you to test, validate, optimize, and correlate the performance and viability of physical and virtual layers.
Operationally, it’s also more efficient to have a single-pane-of-glass GUI/UX (graphic user interface/user experience) that gathers together many disparate processes being carried out by different OpenStack modules, especially if it interfaces with an existing system that you are running. There is a great deal of maintenance and testing, patch management, backup and restore, and continuous integration/continuous delivery (CI/CD) that you probably want to avoid, looking for a service solution that provides a base level of operability from which you can start.
On the security front, OpenStack may need to be hardened to meet your industry’s or country’s standards such as ANSSI or EU GDPR. And if you are operating clouds that serve millions of users, as in the telecom sector, you will need to pay special attention to meeting stringent performance and availability requirements. For all sectors, enterprise or telco, your infrastructure needs to be highly secure; and it must include security groups, secure inter-module communications, API hardening, and the ability to create security zones for individual tenants.
If the short history of the digital revolution has taught us anything, it is to harness the power of platforms and avoid building isolated, standalone solutions. If the freedom to choose leads to sustainability, you need a solid cloud infrastructure management platform that provides serviceability and operability for a wide variety of workloads; a platform that is truly open, yet also fully secure and protected; that is simple to use and easily upgradeable. A platform that ensures you will benefit from the rapid pace of open source innovation while getting a production-ready solution. Only in this way can you ensure that freedom of choice does not come at the expense of what is good for the organization as a whole.
Comments