Tras llevar trabajando varios años en Consultoría Estratégica, hay un momento en el que te das cuenta de que sabes gestionar un proyecto de millones de euros… pero no tienes ni idea de lo que ocurre “debajo del capó”. Y fue el primer paso que me llevó a meterme en un reto llamado Cloud Resume Challenge.

Soy ingeniero informático, con un máster en ingeniería informática y una lista de intereses que van desde las finanzas y la inversión hasta el emprendimiento y la tecnología. Pero al terminar la carrera tuve claro que no quería seguir el camino típico de la programación pura.

Me atraía la consultoría. La idea de saltar de proyecto en proyecto, cada pocos meses, en entornos nuevos donde no podías acomodarte. Un sitio donde aprender mucho y rápido.

Pronto me di cuenta de que lo que más me interesaba eran los proyectos que me permitieran entender cómo funcionan las empresas desde dentro. Por eso pensé que trabajar en diseño de procesos funcionales, sobre todo en torno a ERPs, podría ser un buen punto de partida.

La realidad fue otra. Los proyectos de ERP no duran meses… duran años. Y para progresar ahí, lo habitual es especializarte en un área concreta: Finanzas, Compras, Ventas, Logística… e incluso peor aún cuando tienes además que cerrar a un sector de la industria en específico.

Pasé por varios proyectos de transformación de ERPs, a veces trabajando como consultor funcional y otros como consultor estratégico, pero ambos siempre me dejaban con la misma sensación:

• Si me especializo solo en gestión, entonces me quedo ciego ante lo que realmente se está construyendo. Olvídate de tomar jamás cualquier decisión estratégica puesto que careces del conocimiento necesario.
• Si me centro en lo funcional, acabo encerrado con el ERP de turno, en un módulo concreto y para un tipo de cliente en concreto. Además, se dificulta la extrapolación de conocimientos. Alguien que ha usado Python para proyectos de Data, puede reutilizar su conocimientos para, por ejemplo, proyectos de IA u otros lenguajes similares. Sin embargo, lo que sepas de SAP FI, se queda en SAP y en FI.

El cambio además me resultó bastante complicado: cuando entras en consultoría siendo junior, no es tan sencillo que elijas tú a dónde ir. El manager o socio te colocará donde le encajes mejor… no a dónde quieras hacer carrera.

¿Cómo Realizo el Cambio a Cloud?

Tenía claro que, si me metía en esto, no quería caer en el Tutorial Hell.
Ese bucle infinito en el que encadenas cursos, certificaciones y vídeos mientras tomas apuntes… pero sin exponerte a ningún caso real.

La mayoría de esos recursos te llevan de la mano, paso a paso. Aunque pueda parecer cómodo al principio, no te preparan para lo que de verdad pasa en un entorno de trabajo: problemas sin una solución determinada, sistemas con piezas únicas y requisitos que cambian sobre la marcha.

Sabía desde el principio que no quería memorizar recetas, tenía claro que «el hambre, agudiza el ingenio«. Creo que, resolviendo proyectos por ti solo, investigar posibles alternativas e intentar sacarte las castañas del fuego cuando estás atascado en algún problema, era la manera más segura de lograr que los nuevos conocimientos se asienten en mi cabeza.

Por eso, con la base que ya tenía gracias a la certificación AZ-900 y mi formación académica, decidí que lo mejor era ponerme manos a la obra cuanto antes. Sin embargo, no tardé ni medio segundo en encontrar el primer escollo.

AWS, Azure, Google… ¿Cuál elijo?

Otra vez me vi en la misma casilla de salida que con los ERPs: horas y horas investigando para decidir “la mejor” tecnología en la que invertir mi tiempo y carrera.

¿AWS? Sé que es la pionera y con más cuota de mercado.
¿Azure? Estoy leyendo que está creciendo rápido y tiene muy buena proyección con el ecosistema de Microsoft.
¿Google Cloud? Tiene un enfoque más sencillo pero un gran potencial en inteligencia artificial.

Al final decidí elegir la que más me atrajera o ya conociera un poco.

Muchas empresas trabajan con varias nubes y la mayoría de conceptos que aprendes en una son perfectamente extrapolables a las demás. No son solo herramientas, son fundamentos que puedes aplicar en otros entornos e incluso en áreas fuera del Cloud.

En mi caso, la decisión fue fácil: ya había estudiado Azure y tenía mi AZ-900, así que era cuestión de aprovechar ese punto de partida.

Vale, entonces ¿Cómo comenzamos?

Investigando por mi cuenta me topé con cloudresumechallenge.dev, una web que aparecía en varios foros y artículos. Venden libros con retos prácticos para AWS, Azure y Google Cloud a precios muy razonables: 15 € cada uno o 25 € el pack completo.

Me llamó mucho la atención su filosofía: En vez de darte un tutorial tutorial paso a paso con lo que tienes que hacer y el código que tienes que pegar, te proponen una serie de desafíos encadenados, cada uno pensado para enseñarte un concepto nuevo y empujarte a buscarte la vida.

Era justo lo que estaba buscando, un proyecto propio, donde cualquier avance pudiese considerarse mío y donde aprendiera a lidiar con bloqueos.

En qué consiste el Challenge Book

Personalmente, diría que el libro se asemeja mucho a como si un cliente te dejara encima de la mesa un pliego de requisitos y tú tuvieras que averiguar cómo cumplirlos.

En la versión de Azure, el reto se divide en seis grandes bloques. La idea es que los puedas completar en unas seis semanas, aunque el ritmo lo marcas tú:

1. Certificación – Empiezas validando tu base con la AZ-900 (o una más avanzada si ya vienes con rodaje).
2. Front-end – Construyes tu currículum en HTML/CSS y lo publicas como un sitio estático en Azure, con HTTPS y dominio propio.
3. Back-end y base de datos – Le das vida con un contador de visitas usando una API en Azure Functions y Cosmos DB.
4. Integración – Conectas todo para que el contador se muestre en la web y añades tests automatizados.
5. Automatización – Implementas infraestructura como código y despliegues automáticos con GitHub Actions.

Parece lineal y simple… pero me pareció muy interesante la parte de los Mods.
Son como extensiones o misiones secundarias para adaptar el reto al área en la que te quieras especializar. En mi caso, estoy realizando todos porque me parece interesante entender ligeramente qué podría esperar de cada rama:

• Si tiras más por desarrollo, te pide añadir frameworks front-end y APIs más complejas.
• Si eres de DevOps, te metes en monitorización, multi-entorno y pipelines avanzados.
• Si te llama la seguridad, trabajas con DNSSEC, WAF y políticas de acceso mínimo.
• Si apuntas a arquitectura de soluciones, haces diagramas, comparas arquitecturas y analizas costes.
• Si quieres ir hacia Data o IA, puedes montar pipelines de datos o integrar Azure OpenAI.

En la próxima entrada comentaré en mayor detalle la parte técnica: cómo estoy montando la arquitectura en Azure, qué servicios estoy usando, tema de costes, qué me está sorprendiendo más y los errores con los que me estoy encontrando. Espero que mi experiencia le sirva a alguien que se encuentre en mi situación y también me gustaría conocer vuestras opiniones.