OpenStack APIs: The good, the bad, and the ugly

Do people like OpenStack? Is it easy to use?

When we set out to answer these questions, we found arguably contentious talk by Praveen Yalagandula on The Good, The Bad, and The Ugly of the OpenStack APIs: An Application Developer's View at OpenStack Summit Tokyo this month. In this interview, Praveen shares how Avi Networks delivers OpenStack solutions to its customers and brings the practitioner's perspective. The talk turned out to be insightful with practical views on OpenStack adaptation and its enterprise readiness.

Tell us a bit about your role and your experiences with OpenStack.

As part of the engineering team at Avi Networks, one of my roles has been to design and develop the integration of Avi's next-gen ADC with OpenStack components. Our architecture is based on SDN principles: the logically centralized Avi Controller orchestrating fast and efficient data plane workers, which we call service engines.

The solid core APIs of OpenStack with respect to provisioning compute and network resources (Nova and Neutron) worked great for us from the perspective of achieving elasticity: when the workload is high, the Avi Controller could easily create more data plane VMs and plug them into right networks; and when the load goes down, it could as well scale in to reduce the resource consumption. Another great aspect of the OpenStack APIs is the support for multi-tenancy and this made it easy for us to provide tenant isolation in our product—each tenant can have their own one or more sets of Service Engines and the administrators can let users configure the load balancers whatever way they want. This is not really possible with hardware based load balancing solutions.

On the other hand, achieving high availability and high performance for our solution in OpenStack was not a smooth sail. For example, as OpenStack services lack a good notification support via APIs, we had to resort to using periodic checks. Also, due to the lack of API support to turn off some of the checks done in the networking stack on hypervisors, achieving high performance with reference implementation was not that easy. Many of these aspects are getting better though as the OpenStack itself is maturing.

Do you believe OpenStack is enterprise-ready? Could you share with us on the kind of enterprises that choose OpenStack and their typical use cases? Why should someone go for OpenStack when there are many easy to use public clouds available?

I would say it is getting close but is not there fully yet. When we started working on OpenStack integration almost one-and-half years ago, though many enterprises were considering and experimenting with it, the ones that were really successful were the ones with fully committed engineer-turned-DevOps teams. At other places, we had to spend a lot more time debugging the actual OpenStack deployments before even getting to deploying Avi Networks solution in their environments. But, as the OpenStack stability has matured, we now see wider adoption and more stable installations where we can just walk in and enable enterprise-grade LBaaS in less than one hour.

The kind of applications that these deployments are running are all over the place—internal IT applications to public-facing websites. The key driving factor in these deployments is self-service provisioning through full-stack automation. Most enterprises want to achieve Amazon AWS-like elasticity and operational simplicity in an on-premise private cloud. Security and regulatory concerns associated with public clouds is one reason for driving OpenStack private cloud adoption. Another important reason for enterprises to move their applications to OpenStack, instead of moving to public clouds, is that the required changes in these (legacy) applications are much less—they can mold their OpenStack installation as they need. For example, they can use VLANs as the underlay network and thus connect to existing DB servers outside OpenStack while using the OpenStack VMs for the application logic.

Approaching the use cases from the other side, why should someone not choose OpenStack? What are some of the anti-patterns or OpenStack failures that you have seen? Which other open source tools can be used when OpenStack is not suitable?

While virtualization is great in multiplexing resources among different applications with different operating system requirements, the overheads of virtualization are pretty high. One of the other recent patterns that is gaining tremendous momentum is container-based ecosystems, where the virtualization overheads are pretty low. As I understand, it is a great environment for Linux-based distributed applications but does not yet have as strong primitives as OpenStack for multi-tenancy aspects (especially isolation).

Setting up OpenStack is not easy. How can an enterprise correctly estimate its OpenStack requirements and measure the ROI on OpenStack adoption?

I agree that setting it up is not that easy especially if you are just starting from the open source components. You can build your own Chef/Puppet tool chains, but that adds to the cost. You can use third-party free tools but they all come with restrictions in terms of the types of deployments they support or the version of the OpenStack. Enterprises need to have a dedicated, well-resourced team that understands both the internal application requirements and the complexity of setting up an OpenStack cloud. My advice would be to architect one site/region blueprint and then replicate it several times as needed for scaling out.

You have articulated your view on the good, bad and ugly of the OpenStack APIs. What is the right way to address the pain points and missing API? Should an enterprise attempt to fix the issues themselves or work with the community to be included in official releases?

Ideally, the answer is to work with the community to work on the fixes and to be included in the official releases. In our case, we have been fixing bugs and suggesting changes to make the APIs better. But because of the type of application we are building—a high-performance network service—some of the issues that we run into with APIs are due to some of the less-used features of APIs that haven't seen much usage in other applications. And hence there is limited interest in the general community to fix them. Our solution for this has been to go around some of the issues and find some other ways to overcome them.

Would you say OpenStack is enterprise-friendly in terms of documentation, community support, and customer change requests? What more can we do in this area?

Documentation for developers I would say is pretty horrible. For example, it is hard to find the semantics of all the APIs supported by different services—and that also leads to the fact that different plugins could implement the APIs in whatever fashion they want, as nothing is mandated by the API guide. So as a community, one thing we can do is to mandate what is expected to happen for each API. Maybe we can develop a benchmark test suite with full coverage of API with all options and ensure that any plugin can declare to be OpenStack API complaint only when it can run successfully against that benchmark suite. Indeed, the OpenStack Foundation could fund such an effort (as most engineers would not find that fancy enough to contribute) and charge the vendors for certification.

This article is part of the Speaker Interview Series for OpenStack Summit Tokyo, a four-day conference for developers, users, and administrators of OpenStack cloud software.