Why we developed StackOps Portal

October 15, 2013


Why we developed StackOps Portal

One question that I often get asked is why we developed Stackops Portal from scratch to replace Horizon as an OpenStack visual web management tool. There is no single answer, there is a whole set of them and it’s best to start at the beginning, I think:

During 2012 with our Community Distro we launched between 3,000 and 4,000 OpenStack-based private clouds. At first, they didn’t have Horizon as a visual management tool, so its arrival seemed to be a blessing: at last a tool that would lower the entry level to OpenStack for Cloud users! At the same time, we were implementing solutions for customers who were also beginning to use Horizon as a management tool. This is where the agonizing problems began. Here are just some of them:

  • The feature offered was very limited and did not cover all the existing features in the APIs. Things that clients ‘knew could be done’ were not on the interface. Sometimes the reason was simply time, and sometimes trying to maintain an interface that would work across all options offered by OpenStack. For example, there are features with XenServer that do not exist with KVM.
  • The changes made to suit customer requirements were expensive and costly in time and resources. Compared to other technologies it is much more difficult to find Python web developers than for other more web-oriented technologies.
  • Nobody could guarantee that the changes made could be incorporated into the main development branch of Horizon (this is obvious, communities work this way), to maintain a fork with our changes, and to combine them later proved impossible as we learned ‘the hard way’.
  • 90% of the bugs reported by our customers were directly due to Horizon, not to the OpenStack platform. During this learning period it became clear to us that OpenStack could be extremely stable if you were rigorous with the configurations and architecture, but that is not the case with Horizon.
  • While OpenStack is a 100 % API-based tool, Horizon overlaid these APIs with another layer of application that added extra complexity when new APIs were used i.e. it is strongly linked to Openstack APIs.
  • Our customers were asking for new features to be integrated into this application layer in Horizon attacking our clients APIs or our own. Horizon proved to be too cumbersome to add new APIs and management entities. It was either all or nothing. There was nothing granular.

So we concluded that we would have to build a new management interface that would tackle these problems directly. But how would we go about it?

  • Being a 100 % API-centric platform, Portal should be able to talk naturally with any API provided registered with Keystone services. When I say talk, I mean that it should manage any problem with CORS or access to other servers from the client without it being a security issue for the user.
  • No doubt it would have to be integrated with Keystone so that Authentication and Authorization would become an integral part of the solution. Each call to the API must be authenticated and filtered by roles before arriving at the service at the backend.
  • Portal should allow the deployment of ‘mini-apps’ that are completely independent of each other. A mini-app could be managing networks with Neutron on behalf of the administrators. If the Neutron API changes, but the Nova API does not, why rebuild and redeploy the entire web layer to modify the ‘mini-app? Therefore, Portal should be a container for mini-apps that have their own life cycle, independent of the rest.
  • These mini-apps should be able to be developed by web developers with the most common tools on the web. Therefore, these mini-apps are 100 % JavaScript applications. Any developer in the world who knows JavaScript and with a basic knowledge of how to attack a REST API can develop and maintain these mini-apps in Portal.
  • Portal and these mini-apps should move beyond the paradigm of web browsing page after page and adopt a fluid and agile way of working typical of the professional desktop tools that most System Administrators are used to. Therefore, Portal is a metaphor for the web desktop and each mini-app an RIA (Rich Interface Applications) user experience. Therefore, we use EXT -JS as a JavaScript development framework.

Portal was born from the needs identified in clients using Horizon and the problems they were suffering. However, I recognize that Portal would not be a complete tool if I hadn’t dreamed of a Cloud management tool capable of doing all of these things and that I had been unable to find, until now:

  • Manage not only your own clouds, but also those of third parties that meet OpenStack specifications and APIs. Once you’ve tried a StackOps Portal, you won’t want to use any other tool: the professional user experience is far superior.
  • Hybridize clouds and move your solutions from one cloud to another. Stackops Portal already includes significant hybridization capabilities.
  • Be different, stand out from the rest: customize your own user interface to suit the needs of each client. Colors, images, styles, etc.
  • Integrate existing services for my clients in Stackops Portal in a consistent manner. If my clients already have their own services accessed via APIs, why not build a new mini-app (or plug-in, as we call it) and integrate it in the main view?
  • Enable my clients to build their own mini-apps without our help. The creation of a plug-in is extremely simple, and once created, development is completely independent from StackOps: it is JavaScript tackling REST APIs.
  • Build an ecosystem of mini-apps that anyone can download and integrate into their website if they want to. If OpenStack is an ecosystem, let’s put it in the hands of our users in a simple and accessible way for once.

The easiest way to enjoy Stackops Portal is installing StackOps 360, the Openstack-based cloud platform by Stackops. It is also possible to install directly on Ubuntu OS pulling from our repositories. And if you want to install Stackops Portal on other operating systems like Debian, RedHat, Centos, Fedora, Windows, OSX, etc … if you just need to run a Java Virtual Machine version 7 (we use OpenJDK).


, ,


Subscribe to our RSS feed and social profiles to receive updates.

No comments yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: