Qué hago
Servicios
Ingeniería de cloud y plataforma — la infraestructura sobre la que despliegan los equipos, los pipelines por los que publican y las migraciones que los llevan hasta ahí.
Veinticinco años en IT, automatización de infraestructura desde 2017, en finanzas, energía, medios, petróleo y gas, ciberinteligencia, edición y tecnología de consumo. Lo que hay debajo es para lo que se suele contratar esa experiencia.
Ingeniería de cloud y plataforma
Arquitectura y automatización de AWS con Terraform y Terragrunt. Diseño multicuenta, identidad y accesos como código, redes, secretos fuera del control de versiones, y la base que hereda cada workload.
En organizaciones grandes esto es tanto proceso como tecnología: decidir qué recibe un equipo por defecto, qué puede cambiar y quién aprueba el resto, y luego escribirlo en código para que sobreviva a las personas que lo acordaron.
Kubernetes
Diseño y operación de clusters, autoscaling que responde a la demanda real en lugar de a un número fijo de réplicas, dimensionado de recursos a partir de uso medido, y el modelo de despliegue que lo rodea. También la mitad poco lucida: por qué reinician los pods, adónde se va la memoria y qué pasa de verdad en hora punta.
CI/CD y herramientas de desarrollo
Pipelines de build y de release, y las plataformas sobre las que corren: GitHub Actions, GitLab, Jenkins, y migraciones entre ellas. Repositorios de artefactos, controles de calidad de código y automatización de releases.
He movido organizaciones enteras de un sistema de build a otro y de un control de versiones a otro, y eso me enseñó que la herramienta es la parte fácil. El trabajo está en que cientos de pipelines existentes sigan funcionando mientras el suelo se mueve, y en darle a la gente un camino que no le obligue a reaprender cómo se despliega.
Migraciones
De on-premise a cloud. De máquinas virtuales a contenedores. De un sistema de build, una cuenta de cloud o una región a otra. El primer servicio que se le saca a un monolito. Una base de datos a infraestructura gestionada. Hosting heredado a algo que se mantiene solo.
El método es el mismo en todos los casos: inventariar lo que hay, averiguar qué depende de ello, mover en incrementos lo bastante pequeños como para poder deshacerlos, y verificar cada uno antes del siguiente. Nada se mueve de golpe, y lo viejo se queda caliente hasta que lo nuevo esté probado.
Infraestructura como código
Todo definido en código y bajo control de versiones: servidores, registros DNS, certificados, políticas de acceso, pipelines. No por elegancia, sino porque el resultado es reproducible, revisable y se le puede entregar a otra persona.
Incluye rescatar infraestructuras montadas a mano: importar a código los recursos que ya existen sin downtime, que es un punto de partida sorprendentemente habitual.
Observabilidad y coste
Monitorización y alertas que responden preguntas reales en lugar de llenar un dashboard. Revisiones de gasto en cloud que identifican qué está inflando de verdad la factura, redimensionado según uso medido, y estrategia de compromisos de consumo. Una primera pasada suele encontrar entre un quinto y un tercio de la factura.
Entrega de aplicaciones
Una sola plataforma para muchos workloads, en lugar de un montaje distinto para cada uno: APIs y servicios detrás de un gateway o un balanceador, workers en segundo plano, tareas programadas, sitios estáticos en un CDN. Cada uno se añade con configuración, y el enrutado, los certificados, el deploy y la monitorización funcionan igual sea lo que sea.
El valor está en que todo sea igual. El décimo workload cuesta un fichero de configuración en vez de un proyecto, y nadie tiene que acordarse de que uno de ellos es especial.
Suele tomar dos formas: una plataforma interna sobre la que despliegan varios equipos, y un conjunto de sitios o endpoints públicos que nadie tiene tiempo de atender uno a uno.
Cómo se suelen plantear los encargos
Primero un discovery, presupuestado aparte. Un trabajo corto y cerrado para establecer qué hay realmente antes de que nadie se comprometa a una cifra. Poner precio al resto antes de eso es adivinar por las dos partes, y no deberías pagar por adivinanzas.
Después, fases con algo utilizable al final de cada una, no una construcción larga con una única fecha de entrega. El traspaso, la documentación y la formación son parte del trabajo, no un extra opcional. El soporte posterior está disponible, pero nunca se da por hecho.