Galería

Moto, buceo
y arquitecturas.

Tecnología, naturaleza y aventura. Lo que me apasiona dentro y fuera del trabajo.

Rutas en moto

Kilómetros que merecen la pena.

Concentraciones, rutas y momentos desde la silla. La moto como excusa para descubrir España.

Jesús Roales rodando en su moto cruiser por carretera secundaria
// Carretera secundaria · Castilla
En ruta

La moto como forma de estar en el presente. Carretera, horizonte y ninguna reunión en el calendario.

CruiserRutaCastilla
Concentración de motos en plaza mayor
// Plaza Mayor · España
Concentración motera

Una plaza llena de motos, terrazas y moteros. El ritual del café y el intercambio de rutas antes de salir.

ConcentraciónPlaza MayorComunidad
Motos aparcadas en plaza de tierra, diferentes modelos
// Plaza castellana · 2022
Quedada en la meseta

BMW, Suzuki, custom… la diversidad de motos como reflejo de la diversidad de quienes las montan.

QuedadaMesetaTodos los estilos
Exposición de motos clásicas y vintage en el interior de una iglesia histórica
// Iglesia histórica · 2024
Exposición de motos clásicas

Rieju, motos de los 50 y 60, piezas restauradas. Cuando el patrimonio mecánico se expone en el patrimonio arquitectónico.

Motos clásicasHistoriaRestauración
Motos custom aparcadas junto a fuente de piedra en plaza
// Fuente de piedra · 2025
Custom en la plaza

Choppers y custom bikes junto a una fuente medieval. El contraste entre la tradición de piedra y el cromo pulido.

CustomChopperPlaza medieval
Buceo

Bajo la superficie.

El silencio y la concentración bajo el agua no se parecen a nada más. Pecios, fauna y aguas mediterráneas.

Buceador enmarcado en el ojo de buey de un pecio
// Pecio · Mediterráneo
El ojo de buey

Exploración de un pecio. El metal oxidado y el agua azul crean una ventana hacia otro mundo. Una de las inmersiones más fotogénicas.

PecioWreck divingMediterráneo
Dos buceadores explorando la estructura de un barco hundido
// Pecio · Mediterráneo
Explorando el barco hundido

Navegando sobre la cubierta de un naufragio. La estructura metálica cubierta de organismos marinos y el azul infinito al fondo.

PecioExploraciónNaufragio
Jesús Roales en superficie con equipo de buceo, pulgar arriba
// Superficie · Mar Mediterráneo
Todo bien arriba

La señal universal del buceador satisfecho al salir. Equipo Cressi, agua transparente y ganas de volver a bajar.

SuperficieCressiMediterráneo
Pulpo común escondido en una oquedad submarina
// Fondo rocoso · Mediterráneo
El pulpo en su guarida

Encuentro cara a cara con un pulpo común. Camouflage perfecto en su agujero, rodeado de sus tentáculos con ventosas. Uno de los momentos más especiales bajo el agua.

FaunaPulpoFondo rocoso
Jesús Roales buceando en aguas verdes, primer plano
// Inmersión · Aguas atlánticas
En el fondo

Primer plano bajo el agua. Equipo Cressi completo, máscara amarilla y la concentración que da saber que estás en otro elemento.

SubmarinismoCressiInmersión
Arquitecturas Cloud

Patrones de referencia.

Arquitecturas multi-cloud alineadas con el Azure Well-Architected Framework. Cada patrón incluye las consideraciones críticas de despliegue que marcan la diferencia entre un proyecto exitoso y uno que falla en producción.

// ARCH 01
Enterprise Landing Zone — Hub-Spoke

Arquitectura de red Hub-Spoke para entornos enterprise multi-suscripción con Management Groups jerárquicos, Azure Policy centralizado, RBAC granular y conectividad privada. La base sobre la que se construye cualquier adopción cloud seria en el mercado enterprise.

Hub-SpokeAzure FirewallExpressRouteAzure PolicyIaC
// Consideraciones de despliegue · WAF
  1. Planificar el espacio de direcciones ANTES del primer spoke — modificar CIDR en VNets con peerings activos requiere destruir y recrear. No hay marcha atrás sin downtime.
  2. Centralizar la inspección de tráfico con Azure Firewall y UDRs en cada spoke. Sin esta configuración, el tráfico lateral entre spokes no se inspeccionará.
  3. Desplegar Azure Firewall en múltiples Availability Zones para SLA elevado. Un firewall en zona única es un SPOF para toda la conectividad de la Landing Zone.
  4. Activar IDPS en modo Alert & Deny desde el primer día. No activarlo en producción después es casi imposible sin revisión exhaustiva de reglas.
  5. ExpressRoute: circuitos redundantes en ubicaciones de peering distintas y proveedores diferentes. Un solo circuito equivale a no tener redundancia real.
  6. Todo el despliegue en IaC (Bicep/Terraform) — los cambios manuales en reglas de firewall o NSGs son la principal fuente de deriva de configuración en entornos enterprise.
SeguridadFiabilidadExcelencia OperacionalCoste
Ver caso real → Proyecto 001
// ARCH 02
Zero Trust Architecture — Cloud Native

Modelo Zero Trust end-to-end: identidad como nuevo perímetro, acceso condicional basado en riesgo en tiempo real, microsegmentación de red y visibilidad total con SIEM/XDR. Compatible con los requisitos técnicos de DORA, NIS2 y regulación financiera europea.

Entra IDConditional AccessDefender XDRSentinelPurview
// Consideraciones de despliegue · WAF
  1. MFA resistente a phishing (FIDO2/passkeys) como primer control obligatorio — MFA estándar por SMS o TOTP es bypasseable. No es suficiente bajo DORA.
  2. Nunca confiar en la red corporativa como factor de seguridad — el modelo "inside = trusted" es la raíz de la mayoría de brechas laterales en entornos enterprise.
  3. Políticas de Acceso Condicional basadas en señales de riesgo (usuario, dispositivo, localización, aplicación) — las políticas estáticas no detectan sesiones comprometidas activas.
  4. Privileged Identity Management (PIM) sin excepción — eliminar cuentas con privilegios permanentes. El 80% de brechas exitosas escalan privilegios desde una cuenta comprometida.
  5. Correlación de señales en Sentinel desde día 1 — XDR sin SIEM central no permite detectar ataques que cruzan identidad, red y datos simultáneamente.
  6. DORA/NIS2: automatizar la notificación de incidentes — el plazo de 24h (DORA) o 72h (NIS2) no es compatible con procesos manuales de escalado y reporte.
SeguridadCumplimiento regulatorioFiabilidad
Ver caso real → Proyecto 002
// ARCH 03
GenAI Platform — Multi-Cloud & Agnóstica

Plataforma de IA generativa agnóstica de proveedor: orquestación de LLMs (OpenAI, Anthropic, Gemini, Llama), RAG sobre datos corporativos con control de acceso, guardrails de seguridad y governance end-to-end. ROI medible, sin vendor lock-in.

LLM OrchestrationRAG / Vector DBGuardrailsAPI ManagementData Governance
// Consideraciones de despliegue · WAF
  1. Implementar guardrails de input/output antes de producción — los LLMs sin restricciones son impredecibles. Los fallos de alucinación o prompt injection en producción son críticos.
  2. La chunking strategy y el embedding model son críticos para RAG — un mal chunking produce respuestas incorrectas aunque el modelo sea excelente. Evaluar con datos reales.
  3. Abstraer el acceso a LLMs con una capa de orquestación (LangChain, Semantic Kernel) — cambiar de proveedor de modelo sin esta capa requiere reescribir toda la aplicación.
  4. Verificar la región de procesamiento de los LLMs — en Europa, GDPR exige control sobre dónde se procesan los datos. No todos los modelos tienen endpoints en UE.
  5. Evaluar latencia vs coste por modelo — GPT-4o es 10-20x más caro que modelos intermedios. Para mayoría de casos de uso, modelos más ligeros dan >90% de la calidad.
  6. Monitorización de calidad continua con evaluaciones automáticas (RAGAS, LLM-as-judge) en CI/CD — la calidad de los LLMs degrada con actualizaciones del modelo base.
CosteSeguridadRendimientoExcelencia Operacional
Ver caso real → Proyecto 004
// ARCH 04
FinOps Platform — Multi-Cloud Visibility

Plataforma FinOps con visibilidad unificada en Azure, AWS y GCP: dashboards ejecutivos de chargeback, alertas de presupuesto, rightsizing automatizado con Dynatrace y Ansible, y optimización continua de reservas y Savings Plans.

Azure Cost MgmtAWS Cost ExplorerDynatraceAnsiblePower BI
// Consideraciones de despliegue · WAF
  1. Tagging obligatorio como prerequisito absoluto — sin etiquetado consistente el chargeback es imposible. Implementar con Policy/SCP antes de desplegar el primer recurso.
  2. Definir KPIs FinOps antes de empezar: coste/unidad de negocio, % recursos etiquetados, % utilización de reservas. Sin métricas baseline, no hay mejora medible.
  3. Reservas y Savings Plans: analizar 12 meses de uso antes de comprometerse — el sobrecommitment es más caro que el pago por uso. Empezar con compromisos cortos (1 año).
  4. Rightsizing: período de observación de 30 días antes de aplicar — ajustar recursos en producción sin datos históricos suficientes genera incidentes de rendimiento.
  5. Apagado automático de entornos no-productivos con lógica de excepciones — sin excepciones documentadas, los desarrolladores desactivan el sistema completo después del primer fallo.
  6. FinOps es cultura, no solo herramienta — los equipos de desarrollo deben ver el coste como métrica de calidad. Publicar dashboards de coste por equipo genera cambio de comportamiento.
Optimización de CosteExcelencia OperacionalRendimiento
Ver caso real → Proyecto 006
// ARCH 05
Sovereign Cloud Architecture — Europe

Arquitectura de nube soberana para sectores regulados europeos: aislamiento operativo completo, residencia de datos en UE, personal técnico europeo y cumplimiento demostrable bajo GDPR, NIS2, DORA y Cyber Resilience Act.

AWS ESCAzure SovereignBSI C5ENS AltoPolicy-as-Code
// Consideraciones de despliegue · WAF
  1. Residencia de datos ≠ Soberanía operativa — verificar que el personal con acceso privilegiado sea europeo. Datos en Europa con acceso desde EE.UU. no es nube soberana.
  2. CLOUD Act americana aplica incluso a datos en Europa — los CSPs americanos están sujetos a la ley americana globalmente. Evaluación jurídica independiente es obligatoria.
  3. NIS2/DORA: mapear todos los sistemas críticos antes del diseño — las multas por incumplimiento alcanzan el 2% del volumen de negocio global anual.
  4. Probar la autonomía operativa periódicamente — simular la operación sin conectividad al proveedor para verificar que la independencia declarada es real, no teórica.
  5. Certificaciones BSI C5 o ENS Alto como evidencia ante reguladores — las declaraciones contractuales no son suficientes para auditores de CNMV, BdE o ENISA.
  6. Facturación separada del cloud estándar obligatoria para trazabilidad y auditoría regulatoria. Sin segregación de facturación, el cumplimiento es imposible de demostrar.
SeguridadCumplimientoFiabilidad
Ver caso real → Proyecto 007
// ARCH 06
Cloud-Native Modernisation — Containers & K8s

Hoja de ruta de modernización progresiva de legacy a cloud-native: lift & shift inicial con AVS/IaaS, refactoring incremental a microservicios, adopción de Kubernetes/OpenShift y pipelines CI/CD. Sin big bang, sin interrupciones de producción.

AKS / OpenShiftAzure Container RegistryHelmGitHub ActionsAzure Monitor
// Consideraciones de despliegue · AKS WAF
  1. Estrategia lift-and-shift primero con IaaS — modernizar aplicaciones directamente en cloud es más arriesgado que migrarlas primero y modernizarlas después en entorno cloud estable.
  2. Clústeres AKS privados con API server allowlist — exponer el API server a internet es un riesgo crítico. El 40% de incidentes en Kubernetes provienen de APIs expuestos.
  3. Node pools dedicados: separar cargas de sistema de aplicación (mínimo 2 nodos por pool). La contaminación de recursos entre workloads afecta a la estabilidad del plano de control.
  4. Nodos distribuidos en múltiples Availability Zones — un nodo en zona única es un SPOF para aplicaciones críticas. AZ deployment es gratuito y obligatorio en producción.
  5. Solo imágenes firmadas de registros privados (ACR/Quay) — los ataques de supply chain son el vector de crecimiento más rápido en entornos containerizados.
  6. Cluster Autoscaler + HPA configurados antes de ir a producción — el escalado manual no es operativamente viable. Sin autoscaling, los picos de tráfico causan indisponibilidad.
FiabilidadSeguridadRendimientoCoste
Ver caso real → Proyecto 005
Volver al inicio