I’m a fan of OpenStack and, as promised in some previous posts (for example in “Cloud SLAs: a technical point of view”), I’m going to explain why we are using OpenStack.
 
First of all, let me copy a very short and light explanation of OpenStack, without explaining neither its components nor its architecture, but underlying two main facts (that they found my reasons):
  • Established by NASA and Rackspace in 2010, the OpenStack open-source cloud project has done a remarkable job of attracting attention to itself over two short years. The project now lists over 150 participating companies including major players like Intel, Dell, HP, IBM, and Yahoo, and so on.
  • The OpenStack project as a whole is designed to “deliver a massively scalable cloud operating system” To achieve this, each of the constituent services are designed to work together to provide a complete Infrastructure as a Service (IaaS). This integration is facilitated through public application programming interfaces (APIs) that each service offers (and in turn can consume). While these APIs allow each of the services to use another service, it also allows an implementer to switch out any service as long as they maintain the API. These are (mostly) the same APIs that are available to end users of the cloud.
 
We’re using OpenStack not only for R&D projects (that are partially funded by the European Union Commission’s Programme as “RealCloud” and “CloudSpaces”) but also for making business. There are a lot of good reasons for it, all of them important, but I’d have to choose only one, right now I’d say “INTEROPERABILITY” (since the market is still too young for speaking of standardization).
 
Without doubts security is the most important Cloud risk, but not the only one (see my Spanish post ¿”Nubarrones” en la Nube? whose title means something like “Are dark clouds over the Cloud?”), and it’s starting to fade and lose importance(1) against others; in fact, as the time goes by, new risks are becoming more important for the CSOs of big companies (75% of them “are confident in security of their data currently stored in the cloud”, according to a recent VmWare report) that are already using Cloud Services (order implies nothing):
  • SLAs,
  • portability,
  • vendor lock-in,
  • standardization,
  • learning curve,
  • integration,
  • change management,
  • and so on.
 
And, as above shown, at least 3 or 4 of them are about to interoperability: how can we move our application (the one that we use to offer Cloud SaaS Services to internal or external customs) from an IaaS Provider to another, how can we combine different IaaS Providers services, or how to avoid becoming captive of any vendor; in fact the lack of interoperability between Cloud services generates what is known as vendor lock-in: a best decision made now, later may leave a customer trapped with an obsolete provider, simply because the cost to switch from one provider to another is prohibitively expensive. In summary, pricing, reliability, geographic location and compliance can vary between Clouds Providers. Moreover, business requirements will evolve over time, necessitating the ability to move between Clouds: whether public to private, private to public or between public cloud providers.
 
In fact, according to EU Commissioner for Digital Agenda, one of the most relevant policy actions, which should be included in the European Cloud Computing Strategy to create a “cloud friendly and proactive environment” in the EU, is “Promoting Standardization and Interoperability” as it is stated in both the “Quantitative Estimates of the Demand for Cloud Computing in Europe and the Likely Barriers to Take-up“ document, that is the result of a study carried out by IDC EMEA in the period October 2011-June 2012 on behalf of DG Connect of the European Commission, and in the “COMMUNICATION FROM THE COMMISSION TO THE EUROPEAN PARLIAMENT, THE COUNCIL, THE EUROPEAN ECONOMIC AND SOCIAL COMMITTEE AND THE COMMITTEE OF THE REGIONS, about Unleashing the Potential of Cloud Computing in Europe”.
 
Furthermore, I need also to remind that there are different ways of migrate an existing application to the cloud or to create a new one as the initial step to be able to offer to your customers (either internal, i.e. inside your company, or external, i.e. as a public service) a new SaaS (service). In a previous post (written in Spanish: “Migrando aplicaciones a la nube”) I analyze how some of them builds fake SaaS services, and others let’s build real SaaS services (i.e. services that accomplishes NIST’s Cloud Definition); and between the latter there are two main approaches:
  • In the first approach the application (that will support the SaaS) is build directly on an IaaS platform, taking advantage of IaaS APIS for allowing to the application to control by itself de infrastructures of the cloud, managing the underlying resources and asking for more resources when needed, or releasing what are not used (for example, when it detects the number of concurrent users is increasing it ask for and gets more computing resources, -virtual servers, storage resources, and so on)
  • In the second one, the application is build on PaaS Platform where it will run too.
 
Finally, getting to the point, no one doubts that Amazon is the main reference and competitor (and innovator) for Cloud Computing: Amazon cloud services (Amazon EC2, Amazon S3, and so on) keep growing both bare IaaS services and client application that call Amazon’s API: but in this case this new (or redesigned) application become captive of Amazon. Other proprietary solutions have the same problem: for example, virtualization specialist VMware is increasingly helping its customers to transform their corporate data centers into mini clouds, powered (of course) by VMware’s software, and if use its API’s for develop a real Cloud SaaS, you probably will go captive of them.
 
Someone could argue that was the reason why PaaS appeared: In fact, PaaS Providers are increasing their business as their platform are reaching more clients, however the application become captive of that platform too (Salesforce.com’s Force.com Google’s App Engine, Windows’ Azure). Of course, there are open PaaS initiatives as Cloud Foundry and its Cloud Foundry Core a program designed to preserve cloud application portability, (CFC is a baseline of common capabilities for the components of a PaaS offering that applications depend on, these capabilities include runtimes and services that are built with open development frameworks and technologies as Java, Ruby, MongoDB, MySQL, PostgreSQL, etc., that developers can use to build portable applications) but at the moment they are still immature and without a real industry support: an important point for granting interoperability (besides OpenFoundry, as above stated, is a PaaS platform, while OpenStack is an IaaS platform).
 
So, how companies can migrate existing applications or develop the new ones in the Cloud with becoming captive of one platform? Of course, the answer is interoperability: customers will be, in such way, able to easily move their applications from one OpenStack based IaaS provider to another without having to alter their own Cloud designed programs. They can even download a copy of OpenStack to run inside their own data center as well, which (in principle) makes it feasible to move computing jobs from a private data center to commercial clouds and back again, at will: Moreover, with OpenStack hybrid cloud construction becomes easy.
 
For some customers, this portability might be critical for the way they run their IT. For other, it’s simply an insurance policy; a comforting demonstration that they can move, but they think they won’t needed (could they be sure in this fast-changing IT world?). TISSAT as an IaaS Cloud Provider wants to offer that portability based freedom to our customers, and that’s one of the main reason we use OpenStack.
 
However OpenStack, is far from to be alone in providing open cloud infrastructure: those in need of some open source cloud infrastructure could also turn to Eucalyptus, OpenNebula, CloudStack, and others; but among all of them, OpenStack is my favorite open Cloud Platform, why? I promise to show my reasons about in one of the next posts comparing it against other open platform.
 
Note (1) Of course, Cloud Security concerns still remain high, but they are changing from infrastructure technology based security risks to laws and standard compliance related subjects what shows there’s higher confidence in the Cloud Service Provider and the solutions they use to offer their service. More details in the post “An infographic about Security and other Cloud Barriers”.