Cinco errores a evitar en tu migración al cloud

¿Te han contado alguna experiencia en la que el viaje al cloud haya costado más tiempo del esperado? Pues en realidad no tiene por qué ser así. Cuando se decide pasar al cloud hay una serie de pasos que hay que dar y que se pueden resumir en 3 etapas: planificar, construir y, por último, gestionar el cloud. Obviamente, hay retos organizativos y técnicos inherentes a un viaje al cloud que lo convierten en una misión compleja en sí misma. En este artículo, examinamos 5 errores que debes evitar en tu migración a la nube y te ofrecemos recomendaciones para sortear los posibles obstáculos en el proceso.

1) No centrarse en un MVP funcional

El concepto de Producto Mínimo Viable (MVP) ha sido popularizado por el movimiento Lean Startup. El MVP se caracteriza por ser una versión de un producto con las características justas para que pueda ser utilizado. De este modo, se puede conocer el comportamiento del cliente desde el primer momento, verificar desde el principio si se cumplen los requisitos e iterar a partir de los comentarios hasta que el MVP se convierta en la solución perfecta.

¿Por qué te cuento esto? Podemos tomar ese mismo enfoque y aplicarlo a nuestro viaje al cloud: poner en marcha una versión MVP del proyecto en la nube e iterar a partir de ahí. Este enfoque nos permite abordar primero las hipótesis más arriesgadas y los mayores retos en primer lugar. De este modo, reducimos el riesgo global del proyecto y mantenemos el ciclo de retroalimentación lo más corto posible para pivotar y adaptarnos en función de la información que recibimos.

Lo complicado de un MVP es conseguir que se mantenga con un alcance razonable. Su valor reside precisamente en que al tener un alcance muy acotado, permite validar de forma muy ágil los aspectos que más se hayan priorizado inicialmente, iterando después de manera incremental hasta alcanzar todos los aspectos requeridos. La realización de un MVP no debe suponer que se descuiden aspectos como la calidad o las buenas prácticas de ingeniería, pero si que es verdad que la tendencia debe ser hacia la toma de decisiones y la realización de acciones con rapidez, frente a perderse en complicaciones innecesarias que ralenticen la validación de los objetivos priorizados.

Aquí tienes una serie de consejos prácticos para detectar este error:

• Está costando demasiado construir el MVP. En ese caso, elimina funcionalidades y reduce el alcance, basándote en datos analíticos o en el feedback de los usuarios.

• Está costando demasiado aplicar cambios. Pon el foco en mejorar el time-to-market. Reduce el tiempo por ciclo, mejorando la automatización de CI/CD para poder ejecutar el ciclo de aprendizaje con más frecuencia.

• Nadie puede ver el MVP. Un MVP necesita tener una URL pública. Tienes que ser capaz de exponer tu MVP para que otros puedan verlo y utilizarlo. Solo así podrás seguir mejorándolo.

  
  

2) Falta de conocimientos en el equipo

Tener suficientes conocimientos en torno al cloud es clave para el éxito de este viaje. Pero, ¿qué debes hacer si tu equipo no tiene experiencia con estas tecnologías? Obviamente, podrías contratar a personas con esa experiencia, pero eso tampoco resolverá el problema, ya que no tienen experiencia en tu proyecto.

Adquirir conocimientos nunca es una solución rápida. Se trata más bien de un tema cultural. El equipo tiene que estar totalmente capacitado y saber cómo funcionan la nube y los sistemas en cloud. Mi consejo: No pienses en el proyecto como un equipo con un ingeniero "estrella del rock" que haga toda la magia, sino como un equipo que solo trabajando unidos logrará el éxito, como lo haría una banda de rock 😉

¿Cómo hacerlo posible? Para que el aprendizaje forme parte de tu cultura hay varias formas de establecer un entorno de trabajo inspirador y próspero.

Una idea es establecer una sesión periódica de intercambio de conocimientos en la que alguien del equipo que haya estado trabajando en un tema específico comparta sus conocimientos con el resto de compañeros y los capacite. El resultado de estas sesiones también puede utilizarse para el onboarding de nuevos compañeros en el futuro.

Otra posibilidad es implementar el pair programming como una vía de transmisión de conocimientos dentro del equipo. Además, el pair programming es una buena forma de abordar retos complejos, ya que ayuda a fomentar el debate sobre esos retos en cuestión y sus soluciones. Justo lo que necesitamos para nuestro viaje al cloud.

Estas pistas te pueden ayudar a detectar este error:

• Ciertos asuntos los realiza siempre la misma persona. Si determinados temas, como el testing o el monitoring, los realiza siempre la misma persona, introduce alguna forma de intercambio de conocimientos para eliminar ese cuello de botella.

• El equipo es prudente en exceso. Si el equipo procede con excesiva cautela podría deberse a la falta de conocimientos (también podría tener otras causas, por ejemplo, cuestiones culturales).

• Pregunta a tu equipo. ¿Tu equipo sabe en qué necesita ampliar conocimientos? Como equipo, ellos mismos pueden identificar las lagunas más importantes en cuanto a habilidades y experiencia que deben cubrirse. Lo ideal es registrar los resultados en una matriz de habilidades.

3) Enfoque cortoplacista

¿En el primer punto de este artículo hemos hablado del MVP y ahora decimos que el enfoque a corto plazo es un error? Aunque parezca paradójico, realmente es así y, de hecho, son aspectos compatibles.

Imagina que contratas como consultor a ese ingeniero “estrella del rock” que te ayuda a realizar este viaje al cloud y el objetivo es que el viaje se complete en 6 meses, que es cuando finaliza el contrato con ese consultor.

¿Sabes qué va a pasar? Si el tiempo apremia y el consultor tiene que elegir entre construir una solución óptima a largo plazo o tomar el camino rápido para terminar a tiempo el trabajo con éxito, la elección será clara: optará por la opción más rápida.

Y esta discrepancia es exactamente de lo que hay que tener cuidado: puede haber personas en un equipo que tengan objetivos diferentes y que conduzcan el proyecto de una manera que no sea sostenible.

¿Cómo evitar el riesgo de que algún miembro del equipo dé más importancia a sus objetivos personales que a los del propio equipo? Debes asegurarte de que todos los miembros del equipo están comprometidos con dos objetivos:

1. Finalizar el viaje al cloud lo antes posible.

2. Garantizar que la solución sea altamente mantenible y adaptable.

Cuando se trabaja con proveedores externos esto se puede mejorar buscando asociaciones a más largo plazo, lo que implica una colaboración continua durante todo el proceso de migración al cloud.

Aquí tienes algunos consejos prácticos para detectar este tercer error:

• El número de temas de deuda técnica identificados aumenta. Lo primero que debería hacer el equipo es empezar a hacer un seguimiento de la deuda técnica, si no se está haciendo ya. Y después, vigilar que esa deuda no aumente. Si aumenta, debes tratar de hablar y debatir formas de poder evitar ese incremento.

• El equipo suele estar en desacuerdo a la hora de tomar decisiones. En realidad la diversidad cultural y las discusiones abiertas ayudan. Sin embargo, si tomar decisiones se vuelve complicado, hay que ver si es porque los objetivos personales de los miembros del equipo no están alineados.

• Algunos miembros del equipo son demasiado obstinados. Un equipo sólo funciona bien si todos sus miembros trabajan en igualdad de condiciones. Si algunos miembros del equipo presionan excesivamente con sus opiniones y decisiones, se pierde el compromiso y la responsabilidad a largo plazo.

4) Pretender que todo funcione en la nube a toda costa

No todo el software de este planeta ha sido diseñado y construido para funcionar en la nube. Pero a menudo, la estrategia cloud de algunas organizaciones consiste en llevar todas las cargas de trabajo a la nube para acabar con las operaciones en local.

Esto puede hacer que los equipos prefieran optar por un enfoque de "lift & shift" en su viaje al cloud para trasladar rápidamente las cargas de trabajo a la nube y, a partir de ahí, mejorarlas. Sin embargo, a menudo esto hace que los viajes al cloud adopten los problemas de las aplicaciones on-premise, a los que se suman los retos propios del cloud.

Por ejemplo, una aplicación que requiera acceso a un sistema de archivos no es de entrada una buena candidata para moverla al cloud. Sería más conveniente rediseñarla y reconstruir el servicio previamente para aprovechar las capacidades del cloud.

Aquí tienes algunos consejos prácticos sobre cómo puedes detectar este problema:

• Necesitas tener sistemas de archivos en la nube. Los sistemas de archivos causan muchos problemas en lo que respecta a la alta disponibilidad y escalabilidad. Si esto no es un problema para ti y puedes asumir tiempos de inactividad, sigue adelante con los sistemas de archivos. De lo contrario, rediseña la arquitectura y reconstruye.

• Tienes que contenerizar el software disponible por ti mismo. Si el proveedor no proporciona una versión del software para la nube, no intentes contenerizar la aplicación y ejecutarla en la nube: simplemente vuelve a diseñar y elige otro proveedor.

• No quieres tocar el código de la aplicación. En una plataforma cloud, hay que diseñar teniendo en cuenta la posibilidad de fallos y las aplicaciones tienen que ser resilientes ante diferentes tipos de fallos. Es muy poco probable que una aplicación no diseñada para cloud tenga estas cualidades incorporadas. Por eso, mejorar el código de la aplicación existente ayudará a que el viaje al cloud sea más sencillo.

5) Dependencia de los sistemas on-premise

Es raro que un componente no tenga conexión con otros sistemas. Cuando se traslada a la nube, esos otros sistemas a menudo no están todavía allí. Esto hace que los equipos de ingeniería dediquen tiempo a salvar la distancia entre los sistemas on-premise y su aplicación, que ahora se ejecuta en una plataforma en cloud, ya sea temporal o permanentemente.

Cerrar esta brecha puede requerir mucho trabajo, ya que obliga a los técnicos a configurar y mantener una conexión de red con un data center en local, donde el equipo generalmente no tiene control sobre la configuración de la red. Por eso, los túneles VPN, los certificados, los usuarios técnicos y el resto de aspectos técnicos deben configurarse y mantenerse conjuntamente con el equipo de operaciones IT on-premise.

Además, aunque la gestión centralizada de certificados y DNS funciona bien cuando se trata de sistemas on-premise, no funciona igual de bien cuando se trata de un enfoque cloud. A menudo, el equipo central de operaciones IT continúa con sus procesos para la gestión tradicional del data center y los equipos que se encargan de migrar las soluciones al cloud se ven frenados por procesos lentos y manuales, a la hora de poner en marcha y ejecutar sus aplicaciones.

Aquí tienes algunos consejos prácticos para detectar este último error:

• Tu equipo pasa mucho tiempo tratando temas relacionados con sistemas on-premise. Si tu objetivo es construir una solución para la nube, pero la mayor parte de la energía de ingeniería se gasta en tratar temas relacionados con sistemas on-premise, entonces será mejor rediseñar la aplicación para depender menos de esos servicios en local.

• Tu equipo no puede utilizar el autoservicio. En una configuración correcta del cloud, los equipos pueden valerse del autoservicio para avanzar de forma rápida y crear las soluciones que necesitan. Si los equipos se encuentran con muchos procesos que no son de autoservicio, aún puede haber un enorme potencial para agilizar estos procesos si se utilizan equipos de plataforma.

Conclusión

Cuando se empieza a trabajar en la nube, hay que evitar muchos errores para que los equipos puedan lograr resultados rápidamente y crear soluciones sostenibles. En muchos casos, no tiene sentido seguir un enfoque de "lift & shift" en el viaje al cloud, sino más bien rediseñar y reconstruir una solución para que sea cloud nativa desde el principio. Hacerlo puede acelerar en gran medida a un equipo de desarrollo, siempre que exista una cultura de intercambio de conocimientos para que el equipo pueda iterar y mejorar por sí mismo.