[{"content":"","date":"11 de agosto de 2026","externalUrl":null,"permalink":"/es/categories/arquitectura/","section":"Categories","summary":"","title":"Arquitectura","type":"categories"},{"content":"","date":"11 de agosto de 2026","externalUrl":null,"permalink":"/es/tags/arquitectura-de-software/","section":"Tags","summary":"","title":"Arquitectura De Software","type":"tags"},{"content":"","date":"11 de agosto de 2026","externalUrl":null,"permalink":"/es/authors/","section":"Authors","summary":"","title":"Authors","type":"authors"},{"content":"","date":"11 de agosto de 2026","externalUrl":null,"permalink":"/es/categories/","section":"Categories","summary":"","title":"Categories","type":"categories"},{"content":"","date":"11 de agosto de 2026","externalUrl":null,"permalink":"/es/tags/cloud-native/","section":"Tags","summary":"","title":"Cloud Native","type":"tags"},{"content":"","date":"11 de agosto de 2026","externalUrl":null,"permalink":"/es/tags/decisiones-t%C3%A9cnicas/","section":"Tags","summary":"","title":"Decisiones Técnicas","type":"tags"},{"content":"","date":"11 de agosto de 2026","externalUrl":null,"permalink":"/es/tags/engineering-decisions/","section":"Tags","summary":"","title":"Engineering Decisions","type":"tags"},{"content":"","date":"11 de agosto de 2026","externalUrl":null,"permalink":"/es/series/engineering-notes/","section":"Series","summary":"","title":"Engineering Notes","type":"series"},{"content":"","date":"11 de agosto de 2026","externalUrl":null,"permalink":"/es/authors/jesus-aguirre/","section":"Authors","summary":"","title":"Jesus Aguirre","type":"authors"},{"content":" Ideas clave # Una decisión técnica no empieza con una tecnología, sino con un problema que necesitamos entender. La misma solución puede ser correcta o incorrecta según el contexto, las restricciones y la capacidad del equipo. Comparar alternativas exige hacer visible qué ganamos y qué estamos aceptando perder. Una buena decisión no busca una respuesta perfecta; busca una respuesta razonable para una situación determinada. La ingeniería no consiste solamente en elegir herramientas, sino en comprender sus consecuencias. Un equipo mantiene una aplicación que ha funcionado bien durante años. El negocio necesita una nueva capacidad, el dominio comienza a crecer y cada despliegue exige más coordinación. En una reunión aparece una propuesta conocida: separar un servicio, introducir eventos y mover la operación a una plataforma más sofisticada.\nEn pocos minutos la conversación deja de tratar sobre el problema y empieza a girar alrededor de herramientas. ¿Microservicios? ¿Kubernetes? ¿Un broker de eventos? Cada opción tiene argumentos sólidos y documentación suficiente para defenderla.\nHe visto esta escena repetirse en proyectos con necesidades muy distintas. El momento que más cambia la conversación no ocurre cuando alguien presenta otra tecnología, sino cuando el equipo hace una pregunta más incómoda:\n¿Qué cambió en nuestro contexto para que la arquitectura actual dejara de ser suficiente?\nA veces la respuesta conduce a un nuevo servicio. Otras veces basta con modularizar mejor, simplificar una integración o delegar parte de la operación. La lección es la misma: no existe una respuesta correcta sin contexto.\nLa conversación cambia cuando cambia la pregunta # Las herramientas son fáciles de comparar porque tienen funcionalidades, métricas y casos de uso visibles. El problema real suele estar menos definido: quizá necesitamos reducir el tiempo de entrega, aislar fallos, cumplir una regulación o permitir que dos equipos trabajen con mayor autonomía.\nPor eso intento que las revisiones de arquitectura comiencen con la situación y no con el producto. Antes de preguntar qué tecnología utilizar, necesito entender quién tiene el problema, qué resultado esperamos y bajo qué condiciones debe funcionar la solución. Una lista de herramientas no responde ninguna de esas preguntas.\nEsto no significa ignorar la experiencia técnica. Significa utilizarla en el momento correcto. La tecnología aparece después de comprender el problema, no antes.\nLas restricciones son parte del diseño # Durante mucho tiempo interpreté las restricciones como algo que debía eliminarse para llegar a una arquitectura ideal. La práctica me enseñó lo contrario: tiempo, presupuesto, regulación, experiencia del equipo y capacidad operativa son información de diseño.\nUn equipo pequeño puede preferir un servicio administrado para concentrarse en el producto. Otro, con requisitos estrictos de control y especialistas en plataforma, puede operar la misma capacidad internamente. Las dos decisiones pueden ser correctas porque responden a restricciones diferentes.\nCuando una propuesta solo funciona si ignoramos las condiciones reales del equipo, no tenemos una arquitectura; tenemos un supuesto.\nUn ejemplo: procesar eventos de negocio # Imaginemos que una operación necesita publicar eventos sin bloquear su flujo principal. El equipo puede operar un broker, utilizar un servicio administrado o mantener una integración síncrona mientras el volumen sea manejable. Ninguna alternativa es buena por definición.\nflowchart TD A[Problema: procesar eventos sin bloquear la operación] --\u003e B{Opciones viables} B --\u003e C[Broker autogestionado] B --\u003e D[Servicio administrado] B --\u003e E[Procesamiento síncrono] C --\u003e C1[Control / carga operativa] D --\u003e D1[Menos operación / dependencia] E --\u003e E1[Simplicidad / menor desacoplamiento] C1 --\u003e F[Decisión según contexto y restricciones] D1 --\u003e F E1 --\u003e F La decisión cambia al responder preguntas concretas:\n¿Qué nivel de disponibilidad necesita la operación? ¿Podemos recuperar o reprocesar eventos? ¿Qué volumen esperamos durante los próximos meses? ¿Quién atenderá la plataforma cuando falle? ¿Cuánta complejidad podemos asumir hoy? Si el equipo es pequeño y el tiempo de entrega es limitado, reducir la carga operativa puede ser más importante que conservar control total. Si existen requisitos particulares de seguridad, costo o rendimiento, el balance puede cambiar. La arquitectura aparece en esa conversación, no en el nombre del producto elegido.\nCuatro decisiones sin una respuesta universal # La misma tensión aparece en decisiones comunes de ingeniería. Formularlas como una competencia entre tecnologías oculta las variables que realmente importan:\nMonolito o Microservicios. La respuesta depende de los límites del dominio, la autonomía de los equipos, la frecuencia de cambio y la madurez operativa. Integración síncrona vs integración asíncrona basada en eventos. Importan el acoplamiento temporal, la consistencia, la trazabilidad y la forma en que el negocio responde a fallos parciales. Máquinas Virtuales o Containers. La portabilidad y la velocidad de despliegue deben compararse con el aislamiento, la plataforma disponible y la experiencia del equipo. Managed o Self-Managed. Más control también significa asumir mantenimiento, actualizaciones, observabilidad y respuesta ante incidentes. Estas preguntas no tienen una opción ganadora para todos los sistemas. Son útiles porque obligan a hacer explícito lo que cada alternativa resuelve y el costo que introduce.\nUn marco práctico para pensar decisiones # Con el tiempo he encontrado útil ordenar la conversación en seis pasos. No lo veo como una metodología rígida, sino como una forma de evitar que una preferencia técnica se convierta en una decisión sin haber sido examinada.\nflowchart LR P[Problema] --\u003e A[Contexto] A --\u003e B[Restricciones] B --\u003e C[Alternativas] C --\u003e D[Trade-offs] D --\u003e E[Decisión] E --\u003e F[Consecuencias] 1. Contexto: ¿qué problema estamos resolviendo? # El contexto describe la situación actual, las personas afectadas y el resultado que buscamos. Importa porque dos sistemas técnicamente parecidos pueden tener prioridades de negocio y operación completamente diferentes.\n2. Restricciones: ¿dentro de qué límites debemos decidir? # Aquí hacemos visibles el tiempo, el presupuesto, la regulación, la experiencia y la capacidad operativa. Una alternativa que no puede sostenerse bajo esos límites no es realmente una alternativa.\n3. Alternativas: ¿qué caminos son viables? # Comparar al menos dos opciones evita confundir una preferencia con una decisión. No necesitamos una lista extensa; necesitamos caminos que resuelvan el mismo problema y puedan evaluarse bajo las mismas condiciones.\n4. Trade-offs: ¿qué ganamos y qué aceptamos perder? # Más control suele traer más responsabilidad. Una entrega rápida puede limitar flexibilidad futura y una menor carga operativa puede aumentar la dependencia de un proveedor. Hacer visible ese intercambio permite discutir consecuencias en lugar de gustos.\n5. Decisión: ¿por qué esta alternativa tiene sentido ahora? # La decisión debe conectar la opción elegida con el contexto y sus restricciones. No afirma que será correcta para siempre; explica por qué es razonable con la información disponible hoy.\n6. Consecuencias: ¿qué cambia después de elegir? # Toda decisión crea trabajo, riesgos y nuevas condiciones. Conviene definir qué señales obligarían a revisarla: un aumento de costos, un cambio de volumen, nuevos requisitos o una capacidad operativa que antes no existía.\nRegistrar la decisión conserva el contexto # He aprendido que la memoria de un equipo comprime las decisiones. Meses después recordamos qué tecnología elegimos, pero no siempre las restricciones que justificaron la elección. Un registro pequeño puede conservar esa información sin convertirse en un documento difícil de mantener:\nid: ADR-001 status: accepted context: Procesar eventos de negocio sin bloquear la operación principal decision: Usar una solución administrada de mensajería drivers: - equipo pequeño - tiempo limitado de entrega - necesidad de recuperación de eventos review_when: - aumento significativo de costos - cambio en requisitos - nueva capacidad operativa El valor no está solamente en registrar qué elegimos, sino en recordar por qué lo elegimos y cuándo deberíamos revisarlo.\nUna buena decisión técnica también debe poder explicarse. Meses después alguien preguntará:\n¿Por qué hicimos esto?\nLa respuesta más útil no es “porque era la tecnología recomendada”, sino una explicación que conecte el problema, las opciones consideradas y las consecuencias aceptadas. La arquitectura también es comunicación: si una decisión no puede explicarse, será difícil operarla, cuestionarla o evolucionarla en equipo.\nContinuando la conversación # Esta forma de analizar decisiones es la base de Decisiones de Ingeniería #001, un workshop técnico virtual en vivo donde aplicaremos este marco sobre diferentes escenarios y discutiremos los trade-offs detrás de cada alternativa.\nConclusión # Las herramientas continuarán cambiando y conocerlas seguirá siendo parte del trabajo. Pero conocer una tecnología no es lo mismo que saber cuándo utilizarla.\nLa ingeniería no consiste solamente en elegir herramientas. Consiste en entender problemas, evaluar alternativas y asumir conscientemente las consecuencias de una decisión.\nUna decisión técnica es más fuerte cuando puede explicarse, defenderse y revisarse. No porque sea perfecta, sino porque hace explícitos el problema que resuelve, los límites que reconoce y las consecuencias que el equipo decide asumir.\n","date":"11 de agosto de 2026","externalUrl":null,"permalink":"/es/blog/decisiones-tecnicas-contexto/","section":"Blog","summary":"Las herramientas amplían nuestras opciones; el criterio nos ayuda a decidir cuáles tienen sentido.","title":"Las decisiones técnicas no fallan por falta de herramientas","type":"blog"},{"content":"","date":"11 de agosto de 2026","externalUrl":null,"permalink":"/es/series/","section":"Series","summary":"","title":"Series","type":"series"},{"content":"","date":"11 de agosto de 2026","externalUrl":null,"permalink":"/es/tags/","section":"Tags","summary":"","title":"Tags","type":"tags"},{"content":"","date":"11 de agosto de 2026","externalUrl":null,"permalink":"/es/tags/trade-offs/","section":"Tags","summary":"","title":"Trade-Offs","type":"tags"},{"content":" Lo que hago # Me especializo en arquitecturas cloud-native para entornos de misión crítica, diseñando y modernizando sistemas sobre Kubernetes y en AWS, GCP y Azure. Mi trabajo se enfoca en:\nEscalabilidad y resiliencia en sistemas distribuidos Ecosistemas Kubernetes y modernización empresarial Microservicios y arquitecturas basadas en Java (Helidon, arquitectura hexagonal y clean architecture) Construcción de sistemas confiables en los que los equipos puedan apoyarse Tengo experiencia traduciendo conceptos técnicos y colaborando con equipos diversos para entregar soluciones listas para producción.\nComunidad # Como líder del Panama Java User Group (JUG) y AWS Community Builder (Containers), dedico parte de mi trabajo a:\nImpulsar comunidades técnicas colaborativas en Panamá y Latinoamérica Participar como speaker en conferencias como KCD Guatemala, KCD Costa Rica, KCD Colombia, KCD El Salvador, AWS Community Day Colombia, JConf México y DevFest Panamá Mejorar la experiencia de desarrollo sobre Kubernetes y plataformas cloud-native ","date":"9 de agosto de 2026","externalUrl":null,"permalink":"/es/","section":"","summary":"","title":"","type":"page"},{"content":"Actualizado el 9 de agosto de 2026.\nTrabajo # En Copa Airlines diseño arquitecturas para productos digitales y operaciones críticas. Mi foco es hacer explícitas las decisiones técnicas: contexto, restricciones, alternativas, trade-offs y consecuencias.\nPráctica # Diseño de sistemas para plataformas distribuidas y cloud-native. Cargas en Kubernetes, confiabilidad y simplicidad operativa. Arquitecturas Java, integración y seguridad. Comunidad # Contribuyo como AWS Community Builder (Containers) y lidero el Panama Java User Group. Comparto aprendizajes prácticos mediante conferencias, escritura y workshops para profesionales que trabajan con sistemas en producción.\nAprendizaje # Profundizo en sistemas distribuidos, arquitectura cloud y seguridad a escala. El objetivo es práctico: mejorar decisiones en producción y explicarlas con claridad.\n","date":"9 de agosto de 2026","externalUrl":null,"permalink":"/es/now/","section":"","summary":"","title":"Ahora","type":"page"},{"content":"Notas breves y prácticas sobre decisiones de ingeniería.\nContexto antes que patrones. Trade-offs antes que recetas. Lecciones de producción antes que teoría sin aplicación.\nTemas: diseño de sistemas, sistemas distribuidos, Kubernetes, Java, plataformas cloud y confiabilidad.\n","date":"9 de agosto de 2026","externalUrl":null,"permalink":"/es/blog/","section":"Blog","summary":"","title":"Blog","type":"blog"},{"content":" Conversemos # Si quieres colaborar en soluciones cloud-native, conversar sobre platform engineering, contribuir a iniciativas de comunidad o explorar desafíos de infraestructura, puedes contactarme fácilmente.\nDónde encontrarme # LinkedIn — Jesus Aguirre GitHub — @aguirre-jes AWS Builder Center — @jeaguirre Email — infoaguirrejesus@proton.me Información que me ayuda a responder # Un asunto claro y contexto breve Enlaces a recursos relevantes —repositorio, issue, artículo o CFP— El plazo esperado, cuando exista una fecha importante Hablemos # ¿Tienes una oportunidad o una idea concreta? Envíame una nota breve indicando quién, qué y cuándo, y responderé tan pronto como sea posible.\n","date":"9 de agosto de 2026","externalUrl":null,"permalink":"/es/contact/","section":"","summary":"","title":"Contacto","type":"page"},{"content":" Perfil # Arquitecto de Soluciones con más de 7 años de experiencia en viajes, banca, finanzas y energía. Diseño sistemas cloud-native y distribuidos para operaciones críticas, conectando las restricciones del negocio con el diseño, los datos, las integraciones y la entrega.\nExperiencia # Solution Architect II · Copa Airlines # Abril de 2026–actualidad\nDefino arquitecturas para productos digitales y operaciones aéreas de gran escala. Alineo el diseño de sistemas, los modelos de datos y las integraciones con las restricciones del negocio, la confiabilidad y la operación.\nSenior Systems Engineer III · Indra # Marzo de 2025–abril de 2026\nLideré arquitectura e implementación para sistemas Java, plataformas distribuidas, infraestructura cloud e iniciativas de ciberseguridad. Establecí estándares técnicos y acompañé a equipos de ingeniería.\nSenior Systems Engineer II · Indra # Marzo de 2022–marzo de 2025\nLideré la migración y modernización de sistemas críticos.\nReduje los costos operativos en un 30 % mediante una migración a OCI, microservicios y prácticas DevOps. Lideré un equipo distribuido de más de 10 desarrolladores e introduje prácticas que redujeron el tiempo de desarrollo en un 35 %. Trabajo seleccionado # Migración cloud y microservicios # Diseñé una migración a OCI con microservicios y Kubernetes. El trabajo redujo los costos operativos en un 30 % y la latencia en un 25 % sobre infraestructura crítica.\nTecnologías: OCI, Kubernetes, microservicios, Docker, DevOps\nEntrega y seguridad de cargas en AKS # Implementé flujos de entrega con Azure DevOps y protegí cargas en AKS mediante Key Vault y gestión de certificados.\nTecnologías: Azure, AKS, Azure DevOps, Kubernetes, seguridad\nContacto # LinkedIn: Jesus Aguirre Email: infoaguirrejesus@proton.me ","date":"9 de agosto de 2026","externalUrl":null,"permalink":"/es/resume/","section":"","summary":"Arquitecto de Soluciones enfocado en sistemas cloud-native, arquitecturas distribuidas y decisiones técnicas para operaciones críticas.","title":"Currículum","type":"page"},{"content":"","date":"9 de agosto de 2026","externalUrl":null,"permalink":"/workshops/decisiones-ingenieria-001/","section":"Workshops","summary":"","title":"Decisiones de Ingeniería #001","type":"workshops"},{"content":"Experiencias técnicas en vivo para profesionales de software que quieren desarrollar criterio mediante casos, contexto y discusión.\n","date":"9 de agosto de 2026","externalUrl":null,"permalink":"/workshops/","section":"Workshops","summary":"","title":"Workshops","type":"workshops"}]