Esta es quizás una de las preguntas MÁS IGNORADAS por las empresas cuando están en el proceso de decidir si quieren poner parte de sus aplicaciones en la nube o no – o todas. En este post vamos a tratar el porque es importante definir como vamos a movernos a la nube, que aplicaciones vamos a llevar a la nube y que problemas voy a encontrar si voy a la nube sin ninguna estrategia.
Ahora si, voy para la nube
En la mayoría de los casos, la decisión de moverse a la nube parece ser una decisión bien pensada; sin embargo, cuando uno investiga más a fondo se da cuenta de que es una decisión bien pensada desde el punto de vista administrativo y no desde el punto de vista técnico. Esto principalmente porque el ahorro en costos se puede ver sin mucho esfuerzo, y por supuesto la empresas siempre buscan donde ahorrar recursos; sin embargo, a nivel técnico parece ser que es una decisión más bien obligada, en donde queda poco margen de maniobra ya que es difícil justificar el esfuerzo y las ventajas – desventajas de moverse a este modelo.
Normalmente el técnico recibe una charla rápida, analiza el ambiente de desarrollo – que si es con Azure es bastante transparente ya que se desarrolla en Visual Studio – y ya se siente listo para decir, “si, vamos para la nube”. En realidad cuando se enfoca el problema desde el punto de vista “vamos a poner una aplicación” no se ve ningún inconveniente en dar el paso; sin embargo, cuando esta aplicación tenga que integrarse con otras aplicaciones que corren en la empresa –> On Premises <— entonces es cuando se empieza a ver los problemas de mantenimiento e integración.
En la nube no hay problemas – ¿En serio?
Otro mito relacionado con pasarse a la nube, se da cuando las empresas que nos ofrecen la plataforma nos venden la idea de que al estar en la nube nuestros sistemas serán más estables, ya que ellos son responsables del manejo de esta plataforma y además, si ocurre un problema en la máquina( s ) que “hostean” la aplicación el sistema automáticamente mueve la aplicación hacia otra instancia – máquina virtual – en donde se ejecutará de nuevo sin problemas. Sin embargo, aunque es seguro que el ambiente en la nube de la plataforma que seleccionemos va a estar optimizado, no podemos esperar que los errores de nuestras aplicaciones se borren “mágicamente” solamente por el hecho de que ahora corren en la nube; de hecho, si nuestra aplicación tiene problemas ejecutándose “on premises” tendrá los mismos problemas ejecutándose en la nube con el agravante de que ahora no se puede entrar al servidor a realizar todo tipo de acciones que le permitan al responsable de la misma hacerla funcionar.
Igualmente al estar nuestra aplicación corriendo en la nube, tenemos que tener claro que que nuestras aplicaciones van a depender de la conectividad y su latencia – el tema de como trabajar offline con la nube lo trataremos en otro post – y esto va a conllevar a que la comunicación no sea tan rápida como la comunicación que se hace entre aplicaciones que están dentro de un datacenter local – o aún en el mismo país – este tema es muy relevante por eso estaremos tratando el tema de la localización geográfica a la hora de crear instancias en la nube en post posteriores.
¿Entonces como paso a la nube?
Como en todo paso tan relevante, se debe establecer un orden de migración, tomando en cuenta las necesidades actuales de la aplicación y el impacto que va a tener esta migración en las aplicaciones que van a residir dentro de la empresa. Por ejemplo, un muy mal candidato para iniciar el paso a la nube es una aplicación que interactúe mucho con aplicaciones locales, ya que esto va a crear muchos puntos de conexión que van a ser muy difíciles de mantener – Esta es la razón por la cual normalmente los ejemplos en la nube son aplicaciones aisladas con silos de información que no interactúan prácticamente con ninguna otra aplicación. Además, si la empresa no tiene una arquitectura Orientada a Servicios, debe de establecer muy cuidadosamente los pasos a seguir, ya que sin un ESB pasarse a la nube puede convertirse en un tema muy doloroso – algo que trataremos en el próximo post.
Otro punto relevante asociado con el tema anterior es el transporte de datos desde la nube hacia la infraestructura local – on premises – que tiene la empresa. A la hora de seleccionar la aplicación debemos buscar una en donde el transporte de datos entre ambas plataformas no sea exhaustivo ya que el usuario final va a notar el atraso en esta integración lo que podría generar que el usuario empiece a quejarse dando a entender que la plataforma actual es más lenta que la anterior, lo cual puede ser cierto considerando que la comunicación siempre va a tener una latencia al utilizar comunicación a través de http; la idea por lo tanto es que nuestras primeras aplicaciones en la nube sean de poco tránsito de integración. Desde el punto de vista costos también impacta ya que la mayoría de plataformas en la nube cobran por transacción saliente y transacción entrante.
Un punto que casi nadie toca es el tema relacionado con el llamado “vendor lock” de las plataformas PAAS en el “cloud computing”. Esto implica que si desarrollamos o modificamos una aplicación para que corra en una aplicación – por ejemplo Azure – no será fácilmente portable a otra plataforma como por ejemplo AWS. Creo que al final habrá una tendencia más orientada hacia IAAS que hacia PAAS, ya que esta última “amarra” más al cliente que el IAAS. Aquí debemos buscar una aplicación que no tenga tanta complejidad y no requiera muchas modificaciones específicas a la plataforma, ya que si esta no nos funciona entonces podremos llevarla prácticamente igual a otra plataforma que deseemos probar.
El último punto que vamos a tratar es la seguridad. Este es un tema que merece un post completo aparte y que estaremos realizando en un futuro cercano, sin embargo; al inicio de cada proyecto siempre se debe generar confianza con la plataforma que se esta utilizando – y eso no solo para proyectos en la nube – y por lo tanto debemos escoger un proyecto que no tenga datos sensibles no por que la nube sea insegura, si no porque debemos demostrarle al usuario que la nube es tan confiable como cualquier otro sitio web donde se procesen datos muy sensibles.
No hay comentarios:
Publicar un comentario