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 pantheon.io, 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.
