e-Valúame

Larga vida a las paas

Hace un par de semanas, Diego Mariño cofundador y CEO de Abiquo fue entrevistado en debug_mode=on. La entrevista, aunque es un poco larga,  merece la pena escucharla porque Diego es uno de los  pocos emprendedores españoles dentro del mercado cloud español y sabe de lo que habla. Además en la entrevista habla un poco sobre la oferta de Abiquo, su plan de internacionalización y por donde empezarán a expandirse y del cloud computing en general.

Una de la cosas que más me llamó la atención de la entrevista fue una declaración sobre las paas, a las que las augura un futuro negro debido a que su oferta deja al cliente cautivo , dependiente y al antojo de las mismas.  Para justificar su declaración puso el ejemplo de CogHead y su espantada hace ya algo más de 3 meses.

Bajo mi punto de vista, hay soluciones para no caer en un posible  lock-in de tu proveedor de paas.  Resumiendo lo que decía en este post , los criterios para elegir una paas pasan por:

  • La opción de Zoho  CreatorZoho ofrece la posibilidad de migrar las aplicaciones que se desarrollan en su plataforma a la plataforma Google App Engine y en el caso de que ocurra lo que a CogHead, siempre puedes llevarte el código a Google App Engine e incluso como el lenguaje utilizado por App Engine es Python (lenguaje bajo la licencia de codigo abierto) sería posible descargártelo a local y ejecutarlo en tu infraestructura si lo que deseas es huir de la paas(platform as a service) (ver los comentarios). El único “pero” de esta solución es que cuando Zoho ofreció  esta solución, había limitaciones sobre ciertos componentes y siempre te quedará la duda del grado de compatibilidad entre el lenguaje Zoho y Python.
  • Paas que ejecute código abierto como Java, Python, Ruby.- De hecho son muchas las paas que utilizan este tipos de lenguajes, se puede consultar en el  directorio cloud computing. Son todo ventajas porque puedes optar por ejecutarlo en la paas o en tu infraestructura y la compatibilidad será casí absoluta. Quizás su desventaja ante plataformas como Zoho sea la dificultad para desarrollar aplicaciones y por tanto el alto grado de conocimientos del desarrollador.
  • Paas que ejecute código propietario con opción de ejecución en tu infraestructura.- Hay algunas paas como BungeeConnect Velneo que ofrecen la posibilidad de utilizar su paas o tienes la posibilidad de utilizar el ejecutor de aplicaciones en tu infraestructura.

Sin pensar en que las paas lleguen a desaparecer,  si veo que las paas son la parte del cloud computing que más complicado tiene la «justa» justificación de su servicio. Me explico.

El servicio de las paas pasa por dejar tu aplicación en la plataforma y olvidarte del mantenimiento de la infraestructura esto es, te olvidas de escalabilidad, disponibilidad, mantenimiento de disco, mantenimiento del servidor de aplicaciones, BBDD, etc. Todo esto suponiendo que tu infraestructura la tienes contratada en la nube ( p.e. en Amazon), sino es así tambien te olvidarías de la inversión de hardware. Es decir que tu única preocupación es el correcto funcionamiento de la misma desde un punto vista funcional. Por tanto es evidente que es un servicio atractivo y que seguro que hay mercado pero ¿cuanto vale este servicio? ¿a partir de que momento merece la pena contratarlo?

Para poder responder a estas preguntas deberíamos saber lo que nos costaría mantener una infraestructura de este tipo y lo dividimos en varias rúbricas:

Coste de infraestructura.- Tienes opciones de todo tipo: servidores in-house, servidores dedicados externos, servidores virtuales, cloud hosting. Medible en cualquier caso.
Coste de licencias.- La parte del gasto correspondiente a las licencias (p.e.: servidor de aplicaciones o BBDD) es claro: tanto cuesta tanto pagas. Medible.
Coste personal.- La parte correspondiente a la cantidad de tiempo que dedica tu personal para mantenerla aunque es más jodida de calcular pero también es medible.

Ahora bien hay un conjunto de intangibles que tienen un efecto directo sobre el coste del personal pero que son difíciles de medir: la experiencia, conocimientos o competencias, rendimiento, destreza o talento, etc. de tu personal afectan en mayor o menor medida en su coste y pueden determinar la elección de una opción paas o in-house.  Y ahora las preguntas son: ¿El coste de personal es óptimo o podría ser más bajo con personal más cualificado? A pesar de tus gastos, ¿tienes un servicio de calidad?

A partir de aqui tienes argumentos o situaciones para defender ambas opciones. Es claro que una empresa paas cuya razón de ser o visión es la de ofrecer la máxima excelencia en estos servicios, uno de sus objetivos debe ser contar en su filas personal que maximizen aquellos intangible y por tanto puede tirarte más la opción de la paas, pero tambien es cierto que el cliente objetivo de las paas es personal técnico que puede contar con personal con pericia suficiente para mantener la infraestructura.

Creo que es imposible responder a las preguntas sobre si «paas si» o «paas no» sin ponerle números a todo esto y fijar una aplicación concreta, pero lo que está claro que de entrada genera una serie de incertidumbres que en las otras partes del cloud computing (iaas y saas) no es tán fácil encontrarlas y también tengo claro que no morirán por lock-in, ni porque no ofrezcan un servicio interesante.

Entradas relacionadas:

5 Responses to Larga vida a las paas

  1. Información Bitacoras.com…

    Valora en Bitacoras.com: Hace un par de semanas, Diego Mariño cofundador y CEO de Abiquo fue entrevistado en debug_mode=on. La entrevista aunque es un poco larga merece la pena escucharla porque Diego es uno de los  pocos emprendedores españoles de…

  2. plunchete dice:

    Hola,

    Sobre lo que comentas de Zoho a App Engine me gustaría hacer un par de puntualizaciones.

    No hay forma de bajar el código desplegado en App Engine, o al menos no una oficial.

    Python es libre pero en App Engine hay que usar las APIs de Google, con lo que el código no va a correr en otro sitio. Hay un proyecto que intenta emular las librerías de App Engine en cualquier otro entorno, pero no creo que sea una solución.

    Respecto a los estándares sí que estoy de acuerdo, de hecho el soporte de Google App Engine para Java funciona con las librerías esteandar, aunque estas por debajo llaman a las de Google, con lo que el vendor lock-in no se produce.

    La opción de PAAS gana puntos ya que no hay que preocuparse de las tareas de sistemas, optimizaciones o escalado en horizontal.

    Un saludo

  3. jcmmartin dice:

    Gracias plunchete. La verdad es que dejas «helao», osea que puedes subir el código pero no puedes bajártelo?
    Respecto a lo de Phyton, la verdad es que algo había oído pero no me acordé. Lo he corregido en el texto.
    Y respecto a lo de Java, si sé que tiene bastante restricciones (sandbox) pero trabaja con librerías standards.
    Gracia de nuevo.

    Un saludo

  4. […] y se agrava más en el mundo del saas, y en general dentro del universo del cloud computing. Aqui ya hemos hablado unas cuantas veces de ello , y es que esta claro que el hecho de que tus datos o tus aplicaciones o […]

  5. […] Open Choice Development, es decir, se trata de una Paas en la que podrás usar los lenguajes de programación  (Java, PHP, Groovy, Ruby), modelos  de diseño (JMX, POJO, OSGi) y  Frameworks (Java Enterprise Edition, Spring Framework, Seam, Struts, Google Web Toolkit)  de los más comunes, utilizados y abiertos, evitando asi el lock-in. […]

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos necesarios están marcados *