¿Qué es "Plataforma como servicio"? PaaS a fondo - Nobbot

¿Qué es “Plataforma como servicio”? PaaS a fondo

Esto no es PaaS

Una de las patas de la dichosa nube o Cloud Computing ha sido la aparición de la Plataforma como Servicio (o PaaS, del inglés Platform as a Service). La idea es la misma que aplicábamos al Software como Servicio pero aplicándola al Hardware: no queremos poseer una máquina simplemente por tenerla, queremos tener acceso los servicios que nos pueda ofrecer esa máquina. No es importante que esos servicios vengan de un servidor Intel Xeon de último modelo en Barcelona o de trece mil Pentium en una granja, si la experiencia es similar.

Este servicio, que abstrae del Hardware físico al cliente, es interesante para cualquier desarrollador web o empresa que quiera desarrollar para la web, y viene a reeemplazar a las empresas de hosting tradicionales. Quizás, también a los Administradores de Sistemas, ya que no hay sistema que controlar ni optimización posible más allá del código y sus algoritmos.

La Nube

Como es un paradigma que ha aparecido hace muy pocos años y que todavía no está demasiado definido, existen diferentes niveles o implementaciones. Por ejemplo, tenemos a Amazon y sus Web Services, que empezó vendiendo alojamiento barato de datos (S3 y SimpleDB) y amplió su propuesta con máquinas virtuales (EC2), siempre bajo la premisa de que la demanda es elástica (todo es dinámicamente ampliable) y que se cobra por uso.

Ligado al sector empresarial genérico, Salesforce creó Force.com, un servicio que podemos contratar bajo demanda y que nos permitirá realizar cualquier aplicación web empresarial en su plataforma. Debido a que estas aplicaciones web se consideran extensiones de la aplicación principal de Salesforce, existen bastantes restricciones sobre qué podemos crear, y limita su utilidad estrictamente al nicho que tan bien han sabido explotar.

Google, por su parte, lanzó hace exactamente un año su App Engine, que permite desarrollar y alojar aplicaciones web de terceros en su vasta infraestructura. Como restricciones, la aplicación debe estar escrita en Python (ahora también en Java) y además se limita a ciertas librerías, pero podemos acceder a varias APIs que realizan las tareas críticas de manera eficiente y transparente, como la manipulación de datos.

Aunque cobra por consumo, Google eligió una estrategia de precios muy agresiva al permitir aplicaciones medianas (aprox. 1 millón de visitas al día) ser alojadas sin ningún coste dentro de unos límites. Esto significa que un desarrollador web puede empezar una aplicación sin inversiones monetarias iniciales, y solo pagará el alojamiento cuando su aplicación sea lo suficientemente grande.

Amazon VS Google

En general, estas son las ventajas que podemos encontrar en un PaaS respecto a un servicio de alojamiento tradicional:

  • Escalabilidad garantizada. No te tienes que preocupar por modificar tu aplicación cuando crezca, ni cambiar el Hardware ni ampliar el número de servidores. De todo eso ya se preocupa otro.
  • Pago por consumo = inversión progresiva. Si un mes no tienes apenas visitas, tu factura en un PaaS será muy baja. Si tienes más visitas será más alta, pero siempre siguiendo una proporción, ya que solo pagas lo que usas.
  • Desarrollo más sencillo. Debido a que el sistema es escalable por defecto, las tareas propensas a ser ineficientes como el manejo de los datos tienen APIs asociadas. Normalmente son muy sencillas de usar, e incluso como en Force.com puedes crear completas aplicaciones sin ni siquiera escribir una línea de código.
  • Integración con el resto de la plataforma. Por ejemplo, con Google tienes integración con sus cuentas de usuario (p.e. Gmail), en Amazon los diferentes servicios se integran perfectamente y en Salesforce tienes acceso a sus diversas herramientas. Si además tenemos en cuenta que es muy sencillo interactuar con aplicaciones de terceros, prácticamente tenemos todo lo importante ya desarrollado.
  • Administración remota. Desde sus páginas web puedes administrar tus aplicaciones, modificar tus opciones y monitorizar tu aplicación “en caliente”.
  • Despliegue transparente. El despliegue/puesta en producción de una aplicación en un entorno PaaS es muy directo, y nos permite olvidarnos del infierno en que se puede convertir esta tarea.
  • Altísima disponibilidad del 99.999%. Si quieres un hosting que tenga tan pocas caídas como Amazon o Google… qué mejor que alojarte en Amazon o Google.

Por supuesto, también existen varias desventajas. Pocas, pero muy importantes:

  • Herramientas muy limitadas. En la mayoría de soluciones se limitan las herramientas disponibles (lenguajes, operaciones…) en aras de poder alcanzar un desarrollo sostenible. Por supuesto, existen soluciones más flexibles que están a un nivel más cercano al Hardware real, como las máquinas virtuales de Amazon, que más que PaaS son IaaS: Infraestructura como Servicio.
  • Mayor dependencia con el proveedor. Si ya cambiar de hosting es una tarea pesada, migrar de proveedor PaaS puede ser tu peor pesadilla, al menos por ahora. Como el PaaS es bastante novedoso, todavía tiene alguna carencia, y precisamente se está trabajando para solucionar este punto.

Ya sea para alojar datos, para realizar cálculos, para comunicarse o para, simplemente, desarrollar una aplicación web, el paradigma PaaS es probable que se imponga como la base de la nueva web. En la web actual, existen decenas de miles de proveedores que alojan aplicaciones y datos web, y en un futuro dominado por PaaS existirían muy poquitos proveedores capaces de ofrecer estos servicios.

Si el PaaS triunfa, parecería un paso atrás crear un oligopolio, pero es algo necesario que ha pasado con los servicios básicos: el agua, la electricidad, el gas… Y, dentro de poco, los recursos informáticos. La duda está en cómo lo regularán los gobiernos.

En AnexoM | ¿Qué es “Software como Servicio”? SaaS a fondo