Alternative Interfaces for OpenStack

What might alternative user interfaces for OpenStack look like? If you’ve read my previous post on Composable OpenStack, you understand that there is more than one way to think about – and interact with – a cloud. Use cases – thus desired user interaction – vary even more than business models, and while Horizon’s OpenStack Dashboard admirably satisfies the Cloud Operator use case, there are many other use cases which it struggles to satisfy.

As a research exercise, I’ve collected and/or mocked user interfaces for the use cases I’ve outlined in my aforementioned blog post. These are intended to be illustrative, not proscriptive. Perhaps most importantly, these interfaces can – and should – be able to live side-by-side, with as little code duplication as possible.

Option 1: The multi-mega-cloud

I’m not certain anyone has ever tried to tackle the Mega-Ops user experience. Multiple clouds, dozens of global regions, thousands of pieces of hardware… it’s a daunting challenge to try to distill that into a single, usable, interface. I’ve taken a stab at it, however it’s probably far more useful to focus on specific users; A NOC’s security dashboard might be entirely separate from its capacity dashboard, and may even be managed in an entirely separate location.


Option 2: The single-cloud operator

This is the use case closest to Horizon’s OpenStack-Dashboard. Here, the customer knows they are interacting with a cloud – concepts such as instances, quotas, images, and network topologies are front and center, and both the cloud’s operator, and their customers, will find the concepts familiar and/or easy to grasp.


Option 3: Is there a cloud here somewhere?

I’ve taken a screenshot here of the signup page for, one of the keynote customers from the 2015 OpenStack Summit in Vancouver. Pantheon built their entire business on top of OpenStack and Containers, however this is entirely hidden from their customers; All they know is that they enter some parameters, ‘swipe’ their credit card, and have a wordpress blog ready to go.


Option 4: The Application Developer

This dashboard is designed for an application developer, someone who cares more about the components of their application, than about the underlying instances running these components. In fact, the developer implicitly trusts their cloud provider to configure these services in a way that will scale to meet their needs; After all, not every engineer can learn everything there is to know about every service in their application stack, as this breadth of knowledge comes at the cost of depth.

And yet, this is still a valid dashboard for OpenStack, especially its secondary services such as Trove and Sahara. In fact, this interface removes the source of computing power entirely; the resources could be provided via HyperVisors or via Containers, and the customer would never really know the difference.


Option 5: The Single-Service Deployer

The last use case is that of the single-service deployer, in which, for whatever reason, a single service such as Swift or Ironic are deployed entirely by themselves. Here, I’ve taken a screenshot of the Ironic Standalone UI, which attempts to meet that use case with no dependency on Horizon whatsoever.

Screen Shot 2016-04-06 at 2.25.37 PM

User Experience in the Agency World

After reading Subject To Change last weekend, I’ve actually noticed that my perceptions about certain projects have… well, changed. Maybe it’s because I’m far more conscious about the user experience we’re trying to create, and in the long run I think it’s going to serve me pretty well. One thing in particular jumped out at me though, which is that in many cases (and in the agency space in particular), you actually have two customers to worry about.

When designing an application strongly focused on UX, we too often fixate on the customer and not the client, even though the client has the proverbial power of the purse. By doing this we risk alienating them- what good is a simple, well designed customer experience if maintaining it is costly and unmanageable? Our client has just as much right to a simple UX as their customers do, and if an agency is incapable of delivering on that… well, I can’t imagine how they maintain positive client relationships.

Once I’d come to that conclusion, the natural extension was to realize that our client’s UX is as much process design as it is the design of the deliverable. An agency must be a joy to work with, from RFP to kickoff to design to delivery and post-launch maintenance. Finding the sweet spots on how many meetings to have and how much information to share is always tricky and requires personal skills worthy of a PhD in Psychology, and I as a developer certainly don’t have the wherewithal to analyze a client’s expectations (tacit or declared) in a 15 minute phonecall. Yet I do have control over the implementation and the deliverable, and to make absolutely certain future options are well researched and distributed. A solid knowledge of strategy and marketing are par for the course, since they assist communication of those ideas…

…and if it means that tech happens to be driving the project, who am I to complain!