Cinco trucos para 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 y que lo convierten en una misión compleja en sí misma. En este artículo, examinamos 5 errores que debes evitar en tu viaje al cloud y exponemos formas de evitar obstáculos de más en ese viaje.

1) Centrarse en un MVP que no funciona

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 mínima 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 difícil de un MVP es evitar que se infle. Siempre tiene que ser mínimo y en paralelo el objetivo final es aprender e iterar permitiendo una versión final que satisfaga todas las necesidades. Sin embargo, el MVP no supone descuidar la calidad o una buena ingeniería, sino que el sesgo tiene que ser hacia la toma de decisiones y la realización de acciones cuando veamos que son necesarias, en lugar de complicar demasiado el tema, investigar y planificar todo confiando en suposiciones.

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 los datos de análisis o en los comentarios de los usuarios.

• Está costando demasiado aplicar los cambios. Pon el foco en mejorar el time-to-market. Reduce el tiempo del 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é 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 por otro lado 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 líder, como si fuera una estrella del rock, que va a hacer él 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 las pruebas o la supervisión, los realiza siempre la misma persona, introduce alguna forma de intercambio de conocimientos para eliminar ese cuello de botella.

• El equipo es precavido. Si el equipo procede con cierta 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, puede 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 a corto plazo

¿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, los dos van de la mano.

Imagina que contratas a ese consultor 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, cuando el contrato con este consultor termina.

¿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 el trabajo con éxito, está bastante claro qué decisión tomará el consultor.

Y esta controversia es exactamente lo que hay que tener en cuenta: puede haber personas en un equipo que tengan objetivos diferentes 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 sostenible y adaptable.

Cuando se trabaja con proveedores externos se puede mejorar esto buscando asociaciones a largo plazo de colaboración a lo largo del viaje 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 discutir 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. Pero si se hace difícil tomar decisiones, hay que ver si es porque los objetivos personales de los miembros del equipo no están alineados.

• Algunos miembros del equipo son demasiado insistentes. Un equipo sólo funciona bien si todos sus miembros trabajan en igualdad de condiciones. Si algunos miembros del equipo insisten demasiado en sus opiniones y decisiones, se pierde el compromiso y la propiedad 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. A menudo, siguiendo la estrategia cloud de una organización, todas las cargas de trabajo deben trasladarse a la nube para acabar con las operaciones en local.

Esto hace que los equipos prefieran a menudo 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í, luego mejorar. 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 una buena candidata para moverla al cloud, sino que hay que rediseñar y reconstruir el servicio desde el principio para aprovechar las capacidades del cloud.

Para detectar y evitar este error, aquí tienes estos consejos:

• Necesitas tener sistemas de archivos en la nube. Los sistemas de archivos causan muchos problemas cuando se trata de 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, reordena 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 los fallos y las aplicaciones tienen que ser resistentes a múltiples 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. Salvar esta brecha puede suponer una gran cantidad de trabajo, ya que obliga a los técnicos a configurar y mantener una conexión de red con un data center en local, donde normalmente el propio equipo no puede cambiar la configuración de red. Por eso, los 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 en local. Además, aunque la gestión centralizada de certificados y DNS haya funcionado bien en los sistemas on-premise, no funciona igual de bien en los sistemas en cloud. Pero 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 tienen que trabajar con procesos lentos y manuales para 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 hay 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 reajustar 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.