Algunas claves para proyectos de adopción cloud
En Flux IT nos especializamos en soluciones digitales. Gran parte de ellas implican el desarrollo de software, la gestión de proyectos y el diseño de experiencia.
Muchos proyectos implican, además, la adopción de nuevas tecnologías por parte del cliente, con sus propias curvas de aprendizaje e idiosincrasias frente al desafío tecnológico. Como partners tecnológicos, les brindamos apoyo en el proceso, tanto en la transformación cultural como en la implementación en sí de la misma. Comprendemos que la adopción de nuevas tecnologías constituye tanto un desafío técnico como de equipo.
Bajo ese marco, en este artículo les compartimos algunas breves reflexiones sobre proyectos que implican la adopción de cloud.
Cloud architecture como parte de la arquitectura en general
Esta es una consideración casi siempre válida, excepto en proyectos donde hay problemas muy específicos en relación con el cloud provider.
Hemos notado que muchas personas que trabajan como Architects tienden a pensar directamente en productos del cloud provider antes de pensar en architectural patterns o incluso en capacidades arquitectónicas.
En Flux IT, al tener gran variedad de proyectos y, además, al trabajar en la formación de roles que puedan tomar decisiones arquitectónicas, tendemos a dividir instancias en las que se “modela” y se “conceptualiza” de aquellos viewpoints arquitectónicos más vinculados al despliegue.
Es probable que esta consideración no sea válida para todas las organizaciones que elijan modos de hacer arquitectura más ligados al cloud provider; pero en empresas con múltiples clientes, con diferentes improntas culturales e incluso con tecnologías legadas, la capacidad de poder observar a la arquitectura más allá de un cloud provider específico es un factor cada vez más preponderante y estructural al modo de trabajo.
Esto, cabe aclarar, no excluye conocer los bits y bytes de un cloud provider, sino que apunta a un modo escalable y administrado de producción de arquitecturas, tanto en instancias de preventa como en proyectos ongoing.
El factor cultural
Cada cliente en Flux IT tiene diferentes grados de permeabilidad y adopción de las tecnologías cloud. Es crucial, para nuestra compañía, plantear proyectos y soluciones que sean factibles en el estado dado de una organización, pero que también siempre planteen una evolución.
Para esto es siempre fundamental considerar la conformación de equipos y el aspecto cultural de las organizaciones. Cloud, como cualquier otra tecnología que se incorpore, tiene impacto en los equipos, que deberán adoptar un proceso de transformación de sí mismos que va desde las capacidades técnicas hasta nuevas disposiciones de roles.
Muchas veces este es un aspecto más preponderante que el aspecto técnico en sí mismo. Proyectos a priori simples muestran riesgos y problemas por no diagnosticar bien los factores culturales. Inclusive, estos factores no se suelen considerar en toda su dimensión.
Para ejemplificar, en muchas situaciones múltiples SysAdmins (e inclusive diferentes roles como networking, infra, seguridad informática, etc.) en ambientes mayormente on premise, tienden a pensar cloud como “lo mismo” pero en otro entorno de ejecución. Incluso más allá de que existan decisiones a niveles estratégicos de adoptar cloud, el desfasaje entre la intención y el hecho es algo que una buena gestión de proyecto (y un buen partner tecnológico) debe acompañar.
En la misma línea, podemos incorporar al aprendizaje de la funcionalidad de los servicios managed y la decisión sobre su utilización en servicios core. La decisión se basa en el conocimiento de los productos, pero también en el de los sistemas actuales y, en general, implicará modificaciones y trade-offs.
Adaptar y evolucionar
Es de suma importancia elaborar arquitecturas adaptadas tanto al presente del equipo como a una proyección futura. Una solución inadministrable para el equipo actual del cliente, ya sea por conocimientos o por la complejidad de la misma, está lejos de ser una solución.
A su vez, un partner tecnológico ofrece el valor agregado de tener la mirada hacia el futuro. Es decir, arquitectura y modelo operativo deben acompañar el presente y el futuro.
Por ejemplo, la decisión de migrar servicios críticos a la nube termina siendo ejecutada incrementalmente en diferentes etapas de operación y de entorno de ejecución. En esta transición, el mismo equipo descubre, si no los tenía, sus requerimientos de reliability. La traducción del mundo on premise al mundo cloud de estos factores es parte del conocimiento técnico fundamental, pero al mismo tiempo, es parte de la transformación cultural anteriormente mencionada.
La evolución a cloud también puede conllevar a tomar un compromiso hacia la corrección de sistemas legados a través del uso de servicios managed que, en sí, permiten implementaciones de architectural patterns ya conocidos. Esto se basa en la evaluación de costo/beneficio de la corrección de los problemas arquitectónicos previos. Un elemento importante aquí, para cada componente de la arquitectura, es cómo elegir cuándo utilizar soluciones agnósticas al cloud provider y cuándo no.
El mundo híbrido tiene sus complejidades
La coexistencia de ambientes cloud y on premise tiene sus especificidades y se suele encontrar mucho en clientes con mucha trayectoria en el mercado.
Medir las latencias se vuelve crucial y puede impactar incluso en algunas reingenierías. Los problemas surgen, en gran medida, al no ponderar el riesgo de utilizar internet en lugar de la red interna. Otro problema que se suele ver es pensar la arquitectura networking sin comprender completamente las múltiples posibilidades que ofrecen los productos managed de los cloud providers. Una alerta adicional es que sistemas que, siendo on premise, no puedan ser migrados a cloud, pueden generar constraints que requieran reingenierías o incluso limitaciones en la evolución futura.
El costo
Este es un factor fundamental, especialmente en mi país, Argentina. Muchas organizaciones realizan sus primeras implementaciones cloud tal vez con una evaluación mejorable de lo que terminará representando este costo en su operación.
En general, calcular el costo con exactitud es difícil y, además, es algo cambiante respecto de la etapa del proyecto y del equipo. Una buena práctica que aplicamos en nuestros proyectos es incorporar el costo cloud como un costo del modelo de negocios, especialmente vinculado a la variabilidad del volumen de éste. La tensión del costo en divisa extranjera contra facturaciones en moneda local puede transformarse en un riesgo en el tiempo. Por eso, nuestra observación es que este es un factor que debe ser tenido en cuenta desde los inicios.
Actualmente aparecen algunas empresas que hacen el camino de ser full cloud a volver a on premise. Declaran también grandes ahorros en costo luego de haber decidido ir a on premise. Sin embargo, son empresas ubicadas en Europa o Estados Unidos, donde no hay un efecto de dolarización de la economía y que, a su vez, han logrado altos niveles de madurez en su modelo de operación.
Esto nos retorna a puntos anteriores: tanto la hibridez como las soluciones cloud agnósticas al provider no solamente son una transición sino el modo de adoptar cloud de una manera económica y técnicamente conveniente.
Esperamos que este haya sido un aporte para pensar arquitecturas y gestión de proyectos que implican la adopción de cloud. Como en toda adopción, conviven un aspecto disruptivo y un aspecto de continuidad, tanto para los equipos como para el modo de diseñar soluciones técnicas. Los principios arquitectónicos se mantienen, pero hay mucha diferencia en que el foco del conocimiento pasa a estar en la comprensión profunda de los servicios managed y en el aprendizaje metodológico para aprovechar eficientemente las ventajas. Esto repercute en equipos que, aun teniendo grandes skills técnicos, deben adaptar su conocimiento al nuevo contexto.
