OpenStack State of the Union for Service Providers
Throughout my last several jobs I’ve been meeting with service providers (SP/CSP/MSP) from Iceland to Tokyo and they are all aware that an 800 pound Gorilla, the Public Cloud, is coming for them. For a while now they have all tried to play dead but the Gorilla does not care and it is still sprinting in their direction. In all my travels one thing is for sure, service providers must acknowledge that something drastic needs to change. How can they get there?
Part of my job today is visiting with customers to educate them on what OpenStack is, what its capabilities are, and where they can integrate their existing infrastructure stacks. One thing is certain, to engage against public cloud vendors, the service provider will need to revisit and rework their cloud offerings to focus on software defined technology and automation.
When one looks at the public cloud ecosystem, one of the largest competitive advantages is the platform’s automation capabilities. Unfortunately, a lot of service providers today leverage antiquated hardware and software infrastructures. I've met several service providers recently with legacy infrastructures who sadly believe that the concept of automation comes down to how fast their engineers can swivel in their chairs. To be competitive in today’s market against large public clouds, service providers are investigating frameworks such as OpenStack to regain proper architectural footing.
The DIY OpenStack Approach
Occasionally, I come across very sophisticated service providers who have built out their own OpenStack clouds. Usually it goes something like this:
Me: “That’s great that you are running OpenStack today. How has it been for you so far?”
Them: “It has been a nightmare. It took us weeks to figure out how to get it set up and our engineers are using IRC and forums for support.”
Me: “Yikes!”
My assumption is many of you out there own or rent your home, on which you provide basic maintenance. I’d argue that most of us are not mechanical or structural engineers and have no idea on how the home is actually put together - nor should we have to.
OpenStack shares a similarity to the home analogy. OpenStack relies on numerous complex open source projects that have been glued together through elaborate APIs with which even the most senior infrastructure engineers struggle. From a financial perspective, going down this path initially will likely have significant revenue impacts because of missed business objectives due to slipped deadlines. The DIY approach is where a lot people begin their journey with OpenStack and generally fail, which leaves an incredibly poor taste in their mouths.
A service provider’s primary business objective is to help architect and reliably host their customer’s applications. The key to success when running OpenStack is to leverage a vendor that has packaged up all the necessary bits of code and will provide the service provider the enterprise support that is required to run their business. Please leave supporting and packaging OpenStack to a trusted vendor.
What OpenStack Delivers
OpenStack today delivers a framework that can provide customers a way to simplify heterogeneous technology infrastructures by abstracting their various programming interfaces into one common unified framework or API. Increasing a data center’s operational efficiency is the name of the game.
From a network perspective, OpenStack now delivers ways to integrate with common devices such as F5 Big-IP, Cisco Nexus, Citrix Netscaler, and Arista switches (many more are coming). When looking at storage, everyone from EMC, NetApp, Coraid, to Nexenta has integrated with OpenStack. From a Hypervisor perspective you can have options such as VMWare, KVM, Xen, and HyperV. A service provider can take a completely infrastructure agnostic approach in the datacenter and let OpenStack do all the heavy lifting.
According to OpenStack Atlanta User Survey, the number one business driver for using OpenStack is avoiding getting locked into one vendor's platform. Service providers rely on working with hardware and software partners that do not point fingers at each other while fighting fires. They must also be able to establish deep strategic relationships that allow service providers to drive a vendor’s future product roadmaps. When these relationships are not possible it is extremely difficult for a service provider to succeed. OpenStack provides service providers the flexibility to break free from vendors anytime and choose what mix of hardware and software works the best for them and their customers.
Exciting Projects for Service Providers
OpenStack consists of roughly a dozen projects, but outside of the core, some are of more interest to service providers than others, including:
Heat
In my past, I worked at Carpathia Hosting building out enterprise cloud offerings. Around 2009, I worked with a startup that provided VM lifecycle management and had a capability similar to the OpenStack Heat project. Basically, I wanted a way to describe my datacenter through some sort of blueprint, or code I could save. From there, I wanted to be able to programmatically instantiate new datacenter bricks from that blueprint quickly. To say it another way, this startup had a tool that gave me a way to build a datacenter Class and then I was able to instantiate new Objects - very cool! Heat works in the exact same manner. It is a way to orchestrate your OpenStack environment using templates that are compatible with AWS’ Cloudformation. I would highly recommend that all OpenStack deployments leverage a Heat template to facilitate high levels of automation. You can also find a good Heat tutorial here.
Ceilometer
All service providers need a way to determine how many resources are being consumed and for how long. As mentioned previously, if you have a hardware agnostic environment and have disparate network and storage types, a single unified way to track resource utilization is necessary to facilitate simplified monitoring and management. Ceilometer is the project within OpenStack that a service provider uses to provide metering data that can be later snapped into a billing system. For more information see the documentation.
Ironic
A lot of service providers have various (often complex and headache inducing) ways to automate the builds of their bare metal servers but OpenStack is now incubating a project, Ironic, that will give them this capability using one common API. Companies such as Rackspace have announced their intentions to roll out their own version of Ironic which they call OnMetal. The value behind this project is more than a common API; service providers will be able to leverage all of OpenStack’s capabilities such as metering, orchestration, block storage, and more with bare metal servers.
Ironic grew out of the Nova Bare Metal project, which has since been deprecated. Being that Ironic is still in incubation stage, the team officially considers it as a “stable beta” for the Icehouse release. The team is still working on building user consumable documentation and vigorously closing bugs. The goal is to have Ironic available for the Juno release of OpenStack but this may get pushed further. From a maturity standpoint, this project is something to keep an eye on and begin playing with within the lab but is definitely not production grade. Overall, I’m personally very excited about this project and the impact it will have for service providers.
What is OpenStack Missing?
OpenStack is rapidly maturing and will continue to do so. The OpenStack community, as well as vendors who play in this space, are all working to make all the core capabilities easier to consume for customers, but gaps still exist.
Reference Architectures
One the most significant challenges is that finding reference architectures relevant to your use case. If you attend any Summit there will be fantastic sessions but the major takeaway is, “What architecture do I go with?”
Vendors are contributing a lot of code and trying to make OpenStack play with their solutions but unfortunately there doesn’t appear to be the Gold Standard for service providers to leverage. For now, the most common architectures seem to be utilizing Ceph from a storage perspective, KVM for a hypervisor/compute, and pinning down a standard network option is unobtanium.
High Availability
Most of the services within OpenStack are now able to be protected via HA. Note, I used the word most. A lot of service providers today have customers that have legacy or lazy applications that require the underlying infrastructure to provide HA. OpenStack today doesn’t provide an out of the box method for providing full infrastructure HA; it wasn’t designed to. To be a bit more succinct, OpenStack today does not provide HA for actual Nova compute nodes -- if the compute nodes themselves go down, their VMs will not failover to other nodes automatically. OpenStack takes the same approach Netflix does and relies on developers to build HA into their applications. A truly cloud enabled application should be able to sustain any infrastructure failure.
The beauty of technology is that all problems can be solved. If HA is demanded by a customer they can leverage a different hypervisor that provides HA natively, such as VMWare, which supports great features such as DRS. Customers looking to stay with KVM can leverage something like Nagios or Zabbix to monitor these devices and even automatically restart services.
To read more about this issue, please check out my colleague Dmitriy Novakovskiy's blog about missing features in OpenStack.
Billing
Who needs billing? Just kidding. As mentioned above, OpenStack today provides a project, Ceilometer, that monitors resources being utilized. One of the challenges today is that a lot of service providers have their own billing systems in place and often, these are typically totally custom solutions. The greater community likely won’t be venturing to create any official billing system so customers are best working with a vendor who is willing to integrate with their existing accounting system.
Service Providers - Make it Happen
Service providers play in one of the most difficult verticals because of the amount of competition. Every so often major technological shifts happen that will allow a business to increase their agility and operational efficiency -- OpenStack seems to be the best wave to ride into the future.
To sum everything up, there are several key tenets that a service provider should focus on.
Avoid vendor lock-in.
Embrace automation and orchestration.
Do not try and build it on your own, it’s a big bag of hurt and you’ll end up with FrankenStack.
Work with a hardware and software neutral vendor that will help you build a solution that meets your needs.
Go Deploy OpenStack!
