OpenStack Self-Service: Horizon or CMP?

April 26, 2017 Craig Peters

As an OpenStack project, Horizon shares many characteristics with other OpenStack projects, bringing with it both OpenStack’s strengths and weaknesses. Horizon is the UI dashboard for OpenStack. The purpose is to provide a human readable interface for the myriad projects in the OpenStack orbit.

It has an egalitarian ethos. The project technical lead can guide through providing a vision, and cajole through reviews and the way meetings are conducted, but not dictate a direction. It is a reasonable way to get started learning the APIs for OpenStack, to accomplish very specialized tasks on specifics projects (like set metadata on an image for Murano), or do the most basic things. The corollary is that Horizon falls far short of being an effective UI for the cloud.

Horizon is lacking in three areas that are critical for scale: Ease of use, RBAC, and cost visibility.

User Productivity and Ease of Use

It is easy to undervalue ease of use as an attribute for managing cloud resources. Your core users are developers after all who will become super users of whatever technology you put in front of them.

What this point of view misses is that while developers create the value, in order to realize that value for your organization, many others need to be able to use the cloud. For examples, That cool new accounting app isn’t very useful if operating it requires intimate knowledge of OpenStack Heat (or Ansible, Chef, or Puppet) used to manage it. And if it did, it wouldn’t be safe.

This is exactly the approach that Horizon takes - give users access to “Orchestration” in Horizon, which is the UI for the Heat project, allow them to upload Heat templates, and run them. This just isn’t usable for anyone but experts. As a UI framework, with plugins for each OpenStack project, it is complex to build sensible interactions between projects as they evolve independently.

Common task workflows are few. The result is a convoluted user experience dealing with jargon-filled screens. Given a diverse audience it is not difficult to predict the (bad) outcome. In order to combat this you can expect to undertake a major training effort. What is the real result? It is not the field of dreams… you’ve built it, and only a few of them came.

Scalr focuses on ease of use designed with the understanding that repeatability and reliability result from minimizing user error. The premise is that Self-Service should be based on the understanding that an enterprise has a wide spectrum of users. Some users need easy of use to be productive, and some need operational freedom. All of them need to be safe, responsible and cost-aware in their provisioning. Scalr’s approach is to match users with the provisioning method that makes them productive, and making sure those workflows are safe within company policy. The result is users getting what they expect - a faster moving cloud and ability to focus on what matters to them. All the while management and admins benefit from predictable, repeatable cloud workflows - whether it’s on OpenStack, AWS, Azure, GCP or VMware.

Access, Governance and Compliance

Horizon lacks even the most basic attributes required for managing self-service clouds, the first being role based access control (RBAC). The anchor of any enterprise governance approach is assuring that only users who should, can.

In order to restrict a user from taking an action, permissions on objects must be restricted through configuration of one or more policy.json files. Policy.json enables administrators very fine grained control on object permissions including anything from restricting access to certain flavors of instances, to controlling who can update images in Glance. These files must be 0) understood, 1) protected from user access, and 2) distributed and synchronized across all servers hosting OpenStack services.

There is no UI for policy.json, nor any simulator, so extensive testing must be employed. When errors are made in policy.json, debugging and correcting the issue is a Herculean task when more than a couple of servers are involved, especially in the context of a complex security environment. Given that baseline, OpenStack then has quotas for controlling how much of the core resources under management can be consumed by a project (vCPU, Memory, Storage, and VLANs).

There is a new federated model on Horizon (so to speak) for OpenStack. But even once you've mastered that at scale, you realize that you need to manage public cloud too! Oh and those pesky (massive) VMware racks too…

Scalr provides a robust cross-cloud model for RBAC and policy management. Policy management is accomplished through hierarchy making policies both inherited and overridable. This means that policies that work for one group and be leveraged, and modified only as needed, rather than forked as the policy.json model requires. While it does require some adaptation to use the Scalr abstraction for infrastructure, the benefits are enormous for governance and security. To learn more read on, or join us in our upcoming webinar.




User Understanding & Cost Optimization

Human behavior is affected by understanding the implication of our choices. Despite our cynical instincts to think that many users don’t care about cost, the truth is that people want to do the right thing. But they can only if you help them understand the implications of their actions. Horizon has no way of showing the cost of a 64 vCPU, 1 TB vRAM machine when compared to something that will just cover the need.

From the admin side, even if we find that pesky overspending machine, cotext is crucial. We have to be able to learn which application the machine belongs to, and what would be the consequences of terminating it.

Scalr can show the real cost of resources to users as they make their provisioning decisions, thus having a real impact on overprovisioning. After provisioning, safeguard like Reclamation policies and quotas kick in to prevent runaway cost due to abandonded applications.

These attributes of Horizon add up to make managing a large base of users needlessly costly and error prone. While OpenStack implementations often start with Horizon as the UI for learning, be very cautious about making Horizon generally available - once you’ve let the cat out of the bag, rolling back to a safer approach is possible, but challenging. Implementing a responsible workflow early on has helped enterprises avoid unnesseray spend (and unnessary headaches).

The primary alternative approach that enterprises have used to make OpenStack work at scale, is to hide all the cloud services through automation behind a custom built portal. This works for the completely baked apps, but locks away the cloud from a set of users who might otherwise be able to innovate.


Users are not binary - you aren’t born either a cloud superuser or a novice. As people use and learn, they come up with new ideas. In order to unlock the potential of the cloud you need to be able to give them the freedom to try new things, and to fail. But responsibly - within the guardrails provided by a robust cloud management platform.

Previous Article
What’s Business Agility and What Does it Have To Do With Cloud?

This post is for admins and DevOps engineers looking to solve the common problems that come with deploying ...

Next Article
Scalr ACLs: Creating IAM Policies Across Clouds
Scalr ACLs: Creating IAM Policies Across Clouds

IAM policies are documents that state permissions for a particular resource - whether this is an...