5 ingredientes clave para un viaje exitoso a la nube

Imagina un equipo de desarrollo de software de 5 a 10 personas que:

• Lanza nuevas funcionalidades de manera constante y a tiempo
• Se entera de las caídas antes que sus clientes
• Corrige bugs rápidamente — y por "corregir" me refiero a corregirlos en producción, no en la rama main de git
• Tiene capacidad para investigar e incursionar en nuevas tecnologías

¡Y lo logra durante años sin quedarse sin energía!

¿Suena demasiado bueno para ser cierto? Veámoslo. Así arrancaría yo un proyecto nuevo hoy. Será un proyecto en la nube, sobre GCP en mi caso.

La seguridad suele pasarse por alto. Los desarrolladores la consideran difícil y la estudian apenas lo necesario para superar los valores por defecto mínimos de la nube y empezar a construir. Al final, tus clientes no compran seguridad — compran funcionalidades; y para ellos, la seguridad del producto se da por sentada.

Lamentablemente, ese enfoque lleva rápidamente a malos hábitos: ¿alguien dijo "llaves de seguridad en un repo de git público"? : )

Puntos clave:

• Mantén una base de seguridad dentro del equipo en torno a la tecnología que usas. Por ejemplo, si arrancas en una nube nueva, asegúrate de que todos (no solo la gente de DevOps) conozcan lo básico. Con GCP, por ejemplo, un desarrollador promedio puede familiarizarse con el modelo de seguridad en pocas horas.
• Ten una persona de referencia que mentoree sobre las mejores prácticas de seguridad. Si no la tienes en tu equipo, Google, en nuestro ejemplo, tiene partners a los que se les paga justamente para ser tu caja de resonancia en el tema.

Recuerda el modelo de responsabilidad compartida de las nubes: ellas proveen los bloques de construcción seguros, pero a ti te toca componerlos de manera segura.

Una vez que entiendas tus cimientos de seguridad, puedes empezar a diseñar la arquitectura.

Todos soñamos con que nuestras empresas se conviertan en el próximo Twitter, Uber o Google. Pero ninguna de ellas nació con escala global de un día para otro.

El reto está en arrancar pequeño y, al mismo tiempo, dejar siempre espacio para crecer. Para lograrlo, sugiero tener un pequeño grupo de trabajo dentro del equipo encargado de evitar que se caiga demasiado en el pensamiento táctico — algo que ocurre de manera natural cuando entras en modo "sacar funcionalidades a destajo". Este grupo se asegurará de que se tomen los trade-offs correctos. Por ejemplo:

• Una vez desarrollé un gestor de batch jobs para la base de datos ElasticSearch. Implementarlo en modo activo/activo y con escalamiento horizontal hubiera costado 10 veces más esfuerzo; en cambio, una versión singleton podía soportar un crecimiento de carga de 100 veces, y no pasaba nada si quedaba fuera de línea por 10 o 15 minutos por un bug o un mantenimiento.

En este caso elegimos conscientemente tener un único punto de falla en nuestra configuración porque era suficiente para las necesidades del negocio.

• Como estrategia, quizá quieras desarrollar un producto cloud-agnostic. Puedes elegir Kubernetes (K8s) como plataforma de aplicaciones y, solo con eso, ya cubres cerca del 80% del objetivo. Sin embargo, sigues conectándote con servicios fuera de K8s de tus proveedores de nube, como Load Balancers, colas de mensajes, etc.; y le tocará a tu grupo de arquitectura asegurarse de que no se elija un servicio exclusivo de un proveedor en plena presión de un deadline. Y cuando ocurra, que sea una decisión consciente y bien documentada.

Tus tech leads más senior asumirán este rol de forma natural, pero conviene formalizarlo y asegurarse de que sus voces se escuchen. Las reuniones post-mortem que arrancan con "te lo dije hace medio año, esto se iba a romper" son señal de que tu grupo de arquitectura necesita ajustes finos. El tema central es "confiar en los equipos".

Para que el grupo de arquitectura funcione, y para que todo el equipo se beneficie, es crucial que los Product Owners y la gerencia confíen en que los desarrolladores actúan con las mejores intenciones. Los desarrolladores responsables tienden a ceder ante la presión de las funcionalidades con bastante facilidad, lo que rápidamente degenera en el modo "te lo dije…".

Lo anterior puede sonar un poco radical, pero espero haber captado tu atención. La trampa clásica es "primero las funcionalidades, después las pruebas". Bajo presión de deadline, las pruebas suelen ser lo primero en recortarse.

Déjame compartir una historia personal. Tuve un proyecto con una arquitectura excelente al que solo le faltaba una pieza: invertimos cero tiempo en pensar cómo íbamos a probar nuestro producto. En el quinto sprint nos dimos cuenta de que constantemente gastábamos 2 o 3 días antes del review en una "locura de integración" que se volvía peor sprint a sprint. Nuestro segundo error fue que no supimos salir del frenesí de funcionalidades y comunicarle con claridad al product management que necesitábamos volver al pizarrón y ajustar el diseño en torno al CI (recuerda lo de "confiar en los equipos" del capítulo anterior). Un año después estábamos con un CI parchado que se rompía más veces de las que funcionaba y era una fuente constante de frustración para los desarrolladores. Esa gran bola de barro creció tanto que, incluso con carta blanca para invertir y arreglarlo, no logramos ponernos de acuerdo en el equipo sobre cuál era la mejor forma de rediseñarlo.

Cuando incorporas CI y CD en tu arquitectura central, pasan dos cosas:

• Empezarás a preguntarte cómo sé que el sistema está funcionando. Eso te llevará naturalmente a instrumentar tu código para obtener métricas operativas.
• Cuando te toque depurar fallas nocturnas del CI, desarrollarás tanto las habilidades como las herramientas (por ejemplo, una buena recolección de logs y datos de tracing) para analizar y resolver problemas que ya ocurrieron. Justo el tipo de habilidades y técnicas que tu equipo necesitará para depurar caídas en producción.

Como efecto secundario, tendrás sistemas de logging y monitoreo en marcha incluso antes de salir a producción. Una advertencia sobre los frameworks de monitoreo y logging: su costo operativo, sea SaaS o casero, puede volverse significativo muy rápido — recomiendo encarecidamente estimar los costos potenciales y tenerlos en cuenta en la decisión.

Una vez que tengas tu práctica de CI establecida a tu gusto, recién entonces puedes darte el lujo ocasional de "primero las funcionalidades, después las pruebas". Y por "después" me refiero a "el próximo sprint", salvo que se trate de una funcionalidad de demo desechable y de una sola vez que vas a desactivar con feature flags.

Cada nube tiene sus propios servicios nativos de monitoreo y logging que pueden o no ser la mejor opción para ti. Con K8s, la parte de CD está bastante resuelta, pero la parte de CI requerirá una buena investigación de tu lado. Cada uno de los tres grandes hyperscalers ofrece herramientas de CI, pero, francamente, ese no es su fuerte.

"Tú lo construyes, tú lo operas" es un hecho en las empresas pequeñas, simplemente porque no hay un muro de SRE al otro lado para tirarle las cosas. Así que la pregunta no es quién es dueño de producción, sino cómo se vive ser dueño del workload de producción.

Lo bueno es que, si te ocupaste de los pasos anteriores, el ownership de producción va a salir muy natural para tu equipo. Veamos por qué:

• Empezaste por la seguridad, así que ya debes tener separación de perímetros. Sabes dónde buscar los problemas; situaciones del estilo "el código de desarrollo se conecta sin querer a la base de datos de producción y arma un desastre" simplemente no están sobre la mesa.
• Tu arquitectura es realista y se ajusta a tu equipo. Es clara y fácil de entender. Por ejemplo, no mantienes sistemas distribuidos complejos a menos que sea necesario y puedas dominarlos. Con tus herramientas de observabilidad encuentras rápido el origen de los problemas.
• Tu CI es estable y confiable, y tu CD fluye sin fricciones. Por eso, cuando hay un bug que corregir, los procesos de pruebas y despliegue son rápidos, fáciles y libres de carga cognitiva o estrés. Esto minimiza el desgaste por bugs y evita caer en una situación de Mantenimiento Continuo.

Tus aplicaciones ya tienen observabilidad incorporada, así que solo te queda configurar dashboards de monitoreo y definir alertas.

Un aspecto menos obvio del ownership de producción, especialmente para los desarrolladores, es el costo de operar tu producto. Personalmente creo que los desarrolladores deberían conocer los modelos de facturación de la nube y cuánto dinero consume su software, por las siguientes razones:

Evita sorpresas en la factura

Necesitas entender el modelo de facturación de la nube para diseñar bien tu sistema (¿alguien dijo bill shock?), tanto la arquitectura de la aplicación como la de CI/CD. Para cerrar el círculo, configura presupuestos y alertas de facturación.

Conoce tu Costo Unitario

Para la gente de producto y de ventas es valiosísimo conocer tu "costo unitario". Por ejemplo, si tu producto monitorea dispositivos edge, el "costo unitario" es cuánto aporta cada dispositivo monitoreado a tu factura de la nube. Esa cifra es muy útil para construir modelos de negocio y sacarle la incertidumbre a la planificación de capacidad.

Con tus métricas de aplicación en marcha, suele ser fácil atribuir la lógica de tu app a los costos mediante un análisis más profundo de los datos de facturación.

Adoramos nuestros bits, bytes y la lógica formal, pero al final somos un grupo de seres humanos trabajando juntos.

Nos sumamos a las startups porque creemos en algo y nos entusiasma.

Managers: confíen en que sus desarrolladores actúan con las mejores intenciones. Cuestionen sus ideas, pero déjenles espacio para innovar. Estén atentos a las señales de que sus desarrolladores están entrando en modo defensivo: a partir de ahí, cada funcionalidad se vuelve, de repente, complicadísima de implementar y el proyecto empieza a estancarse.

Podemos hablar de nubes y tecnología todo el día, pero si el trabajo no se disfruta, la innovación no dura.