OpenStack Cloud and StackOps 360

OpenStack Cloud and StackOps 360 started journey in 2010 when StackOps offered an initial distribution of OpenStack to the public. The mission of the Spanish company, StackOps is to make OpenStack as easy as possible for the adoption of OpenStack components, addressing both the small service providers and large enterprise companies.

 

OpenStack Cloud and StackOps 360 : The Spirit of Easy and Accessible OpenStack

 

Keeping the spirit of easy and accessible OpenStack, StackOps now offers its customers a suite of tools, grouped under the name of StackOps 360.

This arsenal includes four different tools: a system for automated deployment, a package-mix for high availability to meet the stringent terms of the SLA subscribed to the customers, a payment structure to set the pay per use and StackOps Portal, a framework for visual development.

 

OpenStack Cloud and StackOps 360 : Simplifying the Development

 

The automation tool, StackOps Automation tool, is thought of as an abstraction of OpenStack to meet the needs of IT administrators who do not have the time or the opportunity to participate in an educational training on the platform. In the same way, the tool is designed to collect chargeback metrics and usage statistics directly from a user-level superimposed on OpenStack, as well as in the infrastructure itself. In this way there is an opportunity to create special packages to offer, based on some characteristics of the infrastructure hardware, such as CPU, RAM, etc.

StackOps Portal, however, is a user interface developed in HTML5 with which one can manage any public or private clouds, independently of the distribution OpenStack used by the developer.

With this instrument, StackOps wants to overcome the main competitor Nebula, indicating the main limitation in the offer is too specialized, based on a hardware controller and an interface that allows one to manage, not its cloud at a glance. At the same time, unlike many other competitors, it does not rely on third party products such as Puppet or Chef to manage the steps of solution deployment. This choice stems from the belief that it is risky to rely on these tools and in any case would force the learning curve upward. The decision would then prevent the adoption by the desire to make simple StackOps, with which it is possible, to package OpenStack cloud infrastructure without having to know anything about the platform.

StackOps thus aims to simplify the development of cloud infrastructure, even in opposition to services and platforms such as those proposed by OnApp.

This Article Has Been Shared 3389 Times!

Facebook Twitter Google+ Pinterest