Cuando se desarrolla una aplicación, a la hora de decidir dónde y cómo alojarla, conviene tener en cuenta diversos factores como son el rendimiento, la seguridad, la regulación, la geolocalización, los data centers existentes y, por supuesto, el sempiterno coste asociado (que, en muchas ocasiones, determina decisiones de diseño).
Pero no sólo debemos pensar en el momento de desarrollo, sino también en las necesidades de monitorización y gestión que tendremos cuando la aplicación ya esté en producción sin olvidar, por supuesto, que los entornos de preproducción y desarrollo deben cumplir correctamente su cometido, que es garantizar el éxito del paso a producción. Podría parecer obvio pero no siempre ocurre… Hace algunos meses ya un director de informática me dijo: “Aunque lo haya probado en preproducción, siempre que lo voy a subir a producción cruzo los dedos porque no tengo garantía cien por cien de que vaya a funcionar”. Fue él quien me inspiró para escribir un post anterior en el que hablaba sobre cómo reducir la distancia entre desarrollo y el time to market y por qué, para conseguirlo, la automatización del paso a producción es clave.
Por otro lado, en la fase de producción la demanda y consumo de la aplicación determina el tipo de cloud necesario: no es lo mismo una aplicación que maneja datos sensibles (medios de pago) que exige entornos dedicados (cloud privada) que una aplicación de juegos o social media, con usuarios geográficamente distribuidos, que requerirá la versatilidad y capilaridad geográfica que ofrece la cloud pública.
Cuando se desarrollan aplicaciones también es importante tener en cuenta la variable de la elasticidad, que es la cualidad que permite que la aplicación se adapte a la forma de la infraestructura tecnológica en la que se alojará, ya sea “en casa” o externalizada en un proveedor de servicios cloud. Curiosamente, la tan elogiada elasticidad en los entornos cloud pone a prueba el coeficiente de elasticidad de la misma (¿ironía tal vez?): en aquellos casos en los que el diseño de la aplicación está fuertemente ligado a la infraestructura no siempre es tan elástica. En más de un proyecto he visto la necesidad de cambios en la configuración del hardware o reescritura de parte del código de la aplicación (pero este asunto daría para otro post). El termino de cloud-enabled apps, que describe la importancia de no olvidar que cuando desarrollamos aplicaciones que serán desplegadas en un entorno cloud hay que tener en mente los principios de la misma (elasticidad, multitenancy…) nos da una pista sobre cómo resolverlo.
Como veis, el árbol de decisiones a la hora de desarrollar nuevas aplicaciones, ofrece diferentes ramas, y la continua expansión de la adopción de cloud en la industria TI lo simplifica, con capas superiores de tecnología que permiten la gestión integral de las distintas formas de cloud: tanto privadas, que se construyen con opciones de distintos fabricantes (VMWARE, HyperV, OpenSack…), como públicas. La clave reside en cómo interconectarlas para sacar el máximo partido de cada una de ellas y engranarlas para que el todo sea mayor que la suma de las partes.
Y os preguntaréis: “¿Cómo orquestar mis clouds? (como cuando preguntamos a Google un how to orchestrate my clouds…?). Posiblemente os surjan dudas respecto al alojamiento de las aplicaciones: tendréis algunas alojadas en vuestros data centers que no podéis modificar (o más tradicionales, no preparadas para cloud) pero el entorno de test está ya en la nube y resulta complicado correlarlo con producción … Además, con tantas opciones de proveedores cloud, ¿cómo estar seguros de hacer la elección acertada? Y si queréis cambiar de proveedor cloud ¿cómo debéis desarrollar las aplicaciones? Y yo os respondo: “¿Por qué elegir, cuando es posible tenerlo todo?”
O, dicho de otra forma, la respuesta a este “how to” nos la proporcionarán, en un futuro, los entornos multicloud con un marco único de gestión y monitorización de las distintas cloud ya sean públicas, privadas o híbridas. Además, estos nuevos marcos convergentes no sólo incluirán la gestión, sino también interoperabilidad real entre las mismas, con la posibilidad de disponer de integración de catálogos, movimiento de cargas entre clouds e incluso el cloud bursting un modelo de implementación de aplicaciones que permite que cuando la cloud privada se quede sin recursos de computación se sirvan otros nuevos de forma automática desde otras clouds que pertenezcan al mismo ecosistema orquestado. Para que todo esto se engrane con la precisión de un reloj suizo, no debemos olvidar también que es preciso elegir estrategias de desarrollo de aplicación (el cloud enabled apps que comentaba) alineadas con los valores que caracterizan al paradigma cloud. Como predicción, todo esto dará lugar, en el futuro, a modelos convergentes en los que se podrá balancear no sólo la capa de infraestructura, sino también el movimiento de aplicaciones entre clouds.
Imagen: muha
Soluciones y Sectores
Te puede interesar
-
Edificios sostenibles para un turismo más inteligente y competitivo
El sector turístico representó el año pasado el 12,2% del PIB en España. Se trata, por tanto, de un ...
-
La capacitación en industria 4.0, condición sine qua non para su transformación
Recientemente leía un artículo sobre “Desafíos de la industria europea en la nueva coyuntura socioeconómica”. En él se apuntaba, ...
-
Hospitalización domiciliaria: un nuevo paradigma en la gestión de pacientes crónicos
Como explicaba en un post anterior, asistimos a la transformación de la atención médica para mejorar la calidad de ...
