Interoperability: a key feature (even a must) to ask your Cloud Service Provider for. (& OpenStack)

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⁽¹⁾ 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”.

¿Cuándo tiene sentido desarrollar sobre PaaS (Plataform as a Service)?

Como aclaraba en el comentario del 21 de febrero, un cliente que usa servicios PaaS (Platform as a Servicios) ofrecidos por un Proveedor de Servicios Cloud, renuncia a desarrollar y ejecutar sus propias aplicaciones en su propio entorno, y en su lugar lo hace sobre un entorno ajeno al suyo ofrecido por el proveedor del servicio. Es decir, el cliente no gestiona ni controla la infraestructura (ni servidores, ni sistemas operativos, ni almacenamiento, ni ningún tipo de elementos de red o seguridad, etc.) NI EL ENTORNO DE DESARROLLO (la propia plataforma de desarrollo, controlador de versiones, servidor de aplicaciones, etc.), pero sí tiene el control de las aplicaciones desplegadas y de la configuración del entorno de ejecución de las mismas (BB.DD. y otro middelware, aunque esta última parte es una frontera difusa que dependiendo del Provedor de PaaS viene ya dado e impuesto por él, o es libre, o en otros casos solo seleccionable entre ciertas opciones) y la responsabilidad de realizar todos los trabajos de operación y mantenimiento correspondientes a dicho nivel de control.

De lo expuesto se deduce que este tipo de servicios están destinados, fundamentalmente, a los Departamentos TIC de las empresas.

Con diferencia, este tipo de servicios son probablemente los menos desarrollados y los menos usados en estos momentos; no obstante, a continuación vamos a exponer unas líneas generales para ayudar a discernir cuando puede tener sentido usarlos, y cuando no:

DONDE PUEDE TENER MÁS SENTIDO:

• Donde múltiples empresas desarrolladoras trabajen en un mismo proyecto.
• Donde terceras partes externas necesiten interactuar con los procesos de desarrollo.
• Desarrollos que quieren sacar ventaja de una fuente de datos ya existente o una lógica de negocio ya desarrollada y que se pretende aprovechar.
• Desarrollos sobre un entorno de programación que no es el habitual en la empresa, y en el que probablemente nunca se vuelva a trabajar.

Ejemplos comerciales de este tipo de servicios Cloud son: Google App Engine, la plataforma Force.com de SalesForce, los Microsoft Azzure Services, o la empresa Heroku que ofrece distintos entornos de programación y despliegue de software como son: Java, Ruby, Python, Node.js, Clojure, Scala, etc.

DONDE PUEDE NO SER LA MEJOR SOLUCIÓN:

• Cuando la aplicación necesite ser altamente portable (refiriéndose al sitio donde está alojada).
• Cuando se necesiten usar lenguajes o enfoques propietarios que incidan en el proceso de desarrollo.
• Cuando las prestaciones de una aplicación requieran de la customización del hardware o software subyacente desde la misma aplicación.

Cloud Computing: taxonomía por niveles (o modelos) de servicio (IaaS, PaaS y SaaS)

Uno de los aspectos en los que actualmente practicamente todo el mundo está de acuerdo es en distiguir dentro del Cloud Computing 3 niveles de servicio (o, según la fuente literaria, “modelos de servicio”) que puede prestar el proveedor del Cloud Computing (aunque algunos añaden, como otro día comentaremos, otros niveles de servicio como el CaaS, etc.) y que se diferencian entre sí fundamentalmente por el grado de visión, control (y preocupación) al que el usuario del servicio tiene acceso: aplicaciones (SaaS), plataformas (PaaS) e infraestructuras (IaaS). Cada segmento tiene un propósito diferente y ofrece diferentes productos para empresas y particulares.

• IaaS: Cloud Infrastructure as a Service provee acceso a grupos de recursos hardware virtualizados, incluyendo máquinas, almacenamiento y redes. Con IaaS los clientes renuncian a usar sus propios equipos físicos, sino que usan los recursos virtuales que le proporciona el Proveedor de Servicios Cloud y sobre dichas infraestructuras el cliente es responsable de la instalación, mantenimiento, y ejecución de su propia pila (stack) de aplicaciones. Es decir, el cliente no gestiona ni controla la infraestructura subyacente (servidores, SAN, routers, switches, etc.), pero tiene control sobre los sistemas operativos, política de almacenamiento, aplicaciones desplegadas y posiblemente un control limitado sobre algunos (pocos y concretos) componentes de red (típicamente, por ejemplo, los firewall o los antispam).

Ejemplos comerciales de IaaS: Amazon Web Services (AWS EC2, AWS S3), Rackspace Cloud, GoGrid, etc.

• PaaS: Cloud Plataform as a Service provee acceso a un entorno de programación y ejecución que se sustenta sobre una infraestructura escalable de componentes hardware y de middleware, sobre la que el cliente no tiene ningún conocimiento ni control. Con PaaS los clientes desarrollan y ejecutan sus propias aplicaciones sobre un entorno ajeno al cliente ofrecido por el proveedor del servicio. Es decir, el cliente no gestiona ni controla la infraestructura (ni servidores, ni sistemas operativos, ni almacenamiento, ni ningún tipo de elementos de red o seguridad, etc.), pero tiene control de las aplicaciones desplegadas y de la configuración del entorno de ejecución de las mismas (BB.DD. y otro middelware).

Ejemplos comerciales de PaaS: Google App Engine, Force.com (de SalesForce), Microsoft Azzure Services, etc.

• SaaS: Cloud Software as a Service provee acceso a una colección de programas de aplicación. Los proveedores SaaS ofrecen a los usuarios acceso a un conjunto de aplicaciones específicas que son ejecutadas en las infraestructuras del proveedor y controladas por él. En muchas ocasiones también se le denomina “software bajo demanda” (dependiendo de la forma de pago). Es decir, el cliente no tiene acceso ni control a la Plataforma subyacente ni siquiera, en general, de las capacidades y funcionalidades de la aplicación con la única posible excepción de poder modificar aquellos parámetros de configuración de la aplicación destinados de forma específica para el usuario y su personalización.

Ejemplos comerciales de SaaS: WebMail (gmail, yahoo, etc.), SalesForce, Google Docs, Office 365, etc.

El siguiente esquema pretende aclarar las ideas anteriores, enfatizando en su lado izquierdo en la estructura de como unos servicios se construyen sobre los otros, y en su parte derecha dejando claro el nivel de sevico, es decir hasta donde alcanzan los trabajos y responsabilidades del Proveedor de Servicios Coud en cada uno de los 3 modelos (niveles) de servicio:

Niveles (o Modelos) de Servicio en Cloud Computing

En los próximos días profundizaremos con más detalle en cada uno de estos modelos de servicios, viendo a qué tipo de clientes va dirigido y analizando en qué casos tiene sentido su adopción y en cuáles no.