[{"content":"","date":"August 11, 2026","externalUrl":null,"permalink":"/en/categories/architecture/","section":"Categories","summary":"","title":"Architecture","type":"categories"},{"content":"","date":"11 de August de 2026","externalUrl":null,"permalink":"/es/categories/arquitectura/","section":"Categories","summary":"","title":"Arquitectura","type":"categories"},{"content":"","date":"11 de August de 2026","externalUrl":null,"permalink":"/es/tags/arquitectura-de-software/","section":"Tags","summary":"","title":"Arquitectura De Software","type":"tags"},{"content":"","date":"August 11, 2026","externalUrl":null,"permalink":"/en/authors/","section":"Authors","summary":"","title":"Authors","type":"authors"},{"content":"","date":"August 11, 2026","externalUrl":null,"permalink":"/en/categories/","section":"Categories","summary":"","title":"Categories","type":"categories"},{"content":"","date":"August 11, 2026","externalUrl":null,"permalink":"/en/tags/cloud-native/","section":"Tags","summary":"","title":"Cloud Native","type":"tags"},{"content":"","date":"11 de August de 2026","externalUrl":null,"permalink":"/es/tags/decisiones-t%C3%A9cnicas/","section":"Tags","summary":"","title":"Decisiones Técnicas","type":"tags"},{"content":"","date":"August 11, 2026","externalUrl":null,"permalink":"/en/tags/engineering-decisions/","section":"Tags","summary":"","title":"Engineering Decisions","type":"tags"},{"content":"","date":"August 11, 2026","externalUrl":null,"permalink":"/en/series/engineering-notes/","section":"Series","summary":"","title":"Engineering Notes","type":"series"},{"content":"","date":"August 11, 2026","externalUrl":null,"permalink":"/en/authors/jesus-aguirre/","section":"Authors","summary":"","title":"Jesus Aguirre","type":"authors"},{"content":"","date":"August 11, 2026","externalUrl":null,"permalink":"/en/series/","section":"Series","summary":"","title":"Series","type":"series"},{"content":"","date":"August 11, 2026","externalUrl":null,"permalink":"/en/tags/software-architecture/","section":"Tags","summary":"","title":"Software Architecture","type":"tags"},{"content":"","date":"August 11, 2026","externalUrl":null,"permalink":"/en/tags/","section":"Tags","summary":"","title":"Tags","type":"tags"},{"content":"","date":"August 11, 2026","externalUrl":null,"permalink":"/en/tags/technical-decisions/","section":"Tags","summary":"","title":"Technical Decisions","type":"tags"},{"content":" Key ideas # A technical decision does not start with a technology, but with a problem we need to understand. The same solution can be right or wrong depending on context, constraints, and team capacity. Comparing alternatives requires making visible what we gain and what we accept losing. A good decision does not seek a perfect answer; it seeks a reasonable answer for a particular situation. Engineering is not only about choosing tools, but also about understanding their consequences. A team maintains an application that has worked well for years. The business needs a new capability, the domain is beginning to grow, and every deployment requires more coordination. During a meeting, a familiar proposal emerges: split out a service, introduce events, and move operations to a more sophisticated platform.\nWithin minutes, the conversation stops being about the problem and starts revolving around tools. Microservices? Kubernetes? An event broker? Every option has solid arguments and enough documentation to defend it.\nI have seen this scene repeat itself in projects with very different needs. The moment that changes the conversation most does not happen when someone presents another technology, but when the team asks a more uncomfortable question:\nWhat changed in our context that made the current architecture no longer sufficient?\nSometimes the answer leads to a new service. Other times, better modularization, a simpler integration, or delegating part of the operation is enough. The lesson is the same: there is no correct answer without context.\nThe conversation changes when the question changes # Tools are easy to compare because they have visible features, metrics, and use cases. The real problem is usually less defined: perhaps we need to reduce delivery time, isolate failures, comply with a regulation, or allow two teams to work with greater autonomy.\nThat is why I try to start architecture reviews with the situation, not the product. Before asking which technology to use, I need to understand who has the problem, what outcome we expect, and under which conditions the solution must work. A list of tools answers none of those questions.\nThis does not mean ignoring technical experience. It means using it at the right time. Technology appears after understanding the problem, not before.\nConstraints are part of the design # For a long time, I interpreted constraints as things to remove in order to reach an ideal architecture. Practice taught me the opposite: time, budget, regulation, team experience, and operational capacity are design information.\nA small team may prefer a managed service so it can focus on the product. Another team, with strict control requirements and platform specialists, may operate the same capability internally. Both decisions can be correct because they respond to different constraints.\nWhen a proposal only works if we ignore the team\u0026rsquo;s real conditions, we do not have an architecture; we have an assumption.\nAn example: processing business events # Imagine that an operation needs to publish events without blocking its main flow. The team can operate a broker, use a managed service, or keep a synchronous integration while volume remains manageable. No alternative is inherently good.\nflowchart TD A[Problem: process events without blocking operations] --\u003e B{Viable options} B --\u003e C[Self-managed broker] B --\u003e D[Managed service] B --\u003e E[Synchronous processing] C --\u003e C1[Control / operational load] D --\u003e D1[Less operations / dependency] E --\u003e E1[Simplicity / less decoupling] C1 --\u003e F[Decision based on context and constraints] D1 --\u003e F E1 --\u003e F The decision changes when we answer specific questions:\nWhat level of availability does the operation need? Can we recover or replay events? What volume do we expect over the next few months? Who will support the platform when it fails? How much complexity can we take on today? If the team is small and delivery time is limited, reducing operational load may matter more than retaining full control. If there are particular security, cost, or performance requirements, the balance may change. Architecture emerges from that conversation, not from the name of the chosen product.\nFour decisions without a universal answer # The same tension appears in common engineering decisions. Framing them as a competition between technologies hides the variables that really matter:\nMonolith or microservices. The answer depends on domain boundaries, team autonomy, change frequency, and operational maturity. Synchronous integration vs. event-driven asynchronous integration. Temporal coupling, consistency, traceability, and how the business responds to partial failures all matter. Virtual machines or containers. Portability and deployment speed must be compared with isolation, the available platform, and team experience. Managed or self-managed. More control also means taking on maintenance, upgrades, observability, and incident response. These questions do not have one winning option for every system. They are useful because they force us to make explicit what each alternative solves and what cost it introduces.\nA practical framework for thinking about decisions # Over time, I have found it useful to structure the conversation in six steps. I do not see it as a rigid methodology, but as a way to prevent a technical preference from becoming a decision before it has been examined.\nflowchart LR P[Problem] --\u003e A[Context] A --\u003e B[Constraints] B --\u003e C[Alternatives] C --\u003e D[Trade-offs] D --\u003e E[Decision] E --\u003e F[Consequences] 1. Context: what problem are we solving? # Context describes the current situation, the people affected, and the outcome we seek. It matters because two technically similar systems can have completely different business and operational priorities.\n2. Constraints: within what limits must we decide? # Here we make time, budget, regulation, experience, and operational capacity visible. An alternative that cannot be sustained within those limits is not really an alternative.\n3. Alternatives: which paths are viable? # Comparing at least two options prevents us from confusing a preference with a decision. We do not need an extensive list; we need paths that solve the same problem and can be evaluated under the same conditions.\n4. Trade-offs: what do we gain and what do we accept losing? # More control usually brings more responsibility. Faster delivery may limit future flexibility, and a lower operational burden may increase dependence on a provider. Making this exchange visible allows us to discuss consequences instead of preferences.\n5. Decision: why does this alternative make sense now? # The decision should connect the chosen option with the context and its constraints. It does not claim that it will always be correct; it explains why it is reasonable with the information available today.\n6. Consequences: what changes after we choose? # Every decision creates work, risks, and new conditions. It is useful to define which signals would force us to revisit it: an increase in costs, a change in volume, new requirements, or operational capacity that did not exist before.\nRecording the decision preserves context # I have learned that a team\u0026rsquo;s memory compresses decisions. Months later, we remember which technology we chose, but not always the constraints that justified the choice. A small record can preserve that information without becoming a document that is difficult to maintain:\nid: ADR-001 status: accepted context: Process business events without blocking the main operation decision: Use a managed messaging solution drivers: - small team - limited delivery time - need for event recovery review_when: - significant cost increase - change in requirements - new operational capacity The value is not only in recording what we chose, but in remembering why we chose it and when we should revisit it.\nA good technical decision should also be explainable. Months later, someone will ask:\nWhy did we do this?\nThe most useful answer is not “because it was the recommended technology,” but an explanation that connects the problem, the options considered, and the accepted consequences. Architecture is also communication: if a decision cannot be explained, it will be difficult to operate, question, or evolve it as a team.\nContinuing the conversation # This way of analyzing decisions is the basis for future writing about how to apply this framework to different scenarios and discuss the trade-offs behind each alternative.\nConclusion # Tools will continue to change, and knowing them will remain part of the work. But knowing a technology is not the same as knowing when to use it.\nEngineering is not only about choosing tools. It is about understanding problems, evaluating alternatives, and consciously accepting the consequences of a decision.\nA technical decision is stronger when it can be explained, defended, and revisited. Not because it is perfect, but because it makes explicit the problem it solves, the limits it recognizes, and the consequences the team chooses to accept.\n","date":"August 11, 2026","externalUrl":null,"permalink":"/en/blog/technical-decisions-context/","section":"Blog","summary":"Tools expand our options; judgment helps us decide which ones make sense.","title":"Technical decisions do not fail because of a lack of tools","type":"blog"},{"content":"","date":"August 11, 2026","externalUrl":null,"permalink":"/en/tags/trade-offs/","section":"Tags","summary":"","title":"Trade-Offs","type":"tags"},{"content":" What I Do # I specialize in cloud-native architectures for mission-critical environments, designing and modernizing systems on Kubernetes and across AWS, GCP, and Azure. My focus is on:\nScalability and resilience in distributed systems Kubernetes ecosystems and enterprise modernization Microservices and Java-based architectures (Helidon, hexagonal/clean architecture) Building reliable systems that teams can depend on I\u0026rsquo;m skilled at translating technical concepts and collaborating effectively across teams to deliver production-grade solutions.\nCommunity # As Panama Java User Group (JUG) Leader and AWS Community Builder (Containers), I\u0026rsquo;m dedicated to:\nGrowing collaborative tech communities across Panama and LATAM Speaking at conferences (KCD Guatemala, KCD Costa Rica, KCD Colombia, KCD El Salvador, AWS Community Day Colombia, JConf México, DevFest Panamá) Optimizing developer experience on Kubernetes and cloud-native platforms ","date":"August 9, 2026","externalUrl":null,"permalink":"/en/","section":"","summary":"","title":"","type":"page"},{"content":"Short, practical notes on engineering decisions.\nContext before patterns. Trade-offs before prescriptions. Lessons from production over theory for its own sake.\nTopics include system design, distributed systems, Kubernetes, Java, cloud platforms, and reliability.\n","date":"August 9, 2026","externalUrl":null,"permalink":"/en/blog/","section":"Blog","summary":"","title":"Blog","type":"blog"},{"content":" Let\u0026rsquo;s Connect # If you want to collaborate on cloud-native solutions, discuss platform engineering, contribute to community initiatives, or explore infrastructure challenges, I\u0026rsquo;m easy to reach.\nBest Ways to Reach Me # LinkedIn — Jesus Aguirre GitHub — @aguirre-jes AWS Builder Center — @jeaguirre Email — infoaguirrejesus@proton.me What Helps Me Respond Quickly # A clear subject line and brief context Links to relevant resources (GitHub repo, issue, blog post, CFP) Your preferred timeline if it\u0026rsquo;s time-sensitive Let\u0026rsquo;s Talk # Have a specific opportunity or idea? Send a brief note with the context, objective, and expected timeline. I\u0026rsquo;ll respond as soon as possible.\n","date":"August 9, 2026","externalUrl":null,"permalink":"/en/contact/","section":"","summary":"","title":"Contact","type":"page"},{"content":"","date":"9 de August de 2026","externalUrl":null,"permalink":"/workshops/decisiones-ingenieria-001/","section":"Workshops","summary":"","title":"Decisiones de Ingeniería #001","type":"workshops"},{"content":"Updated August 9, 2026.\nWork # At Copa Airlines, I design solution architectures for digital products and critical operations. My focus is making technical decisions explicit: context, constraints, alternatives, trade-offs, and consequences.\nPractice # System design for distributed and cloud-native platforms. Kubernetes workloads, reliability, and operational simplicity. Java architectures, integration, and security. Community # I contribute as an AWS Community Builder (Containers) and lead the Panama Java User Group. I share practical lessons through talks, writing, and workshops for engineers working on production systems.\nLearning # I am deepening my work in distributed systems, cloud architecture, and security at scale. The goal is practical: improve decisions in production and explain them clearly.\n","date":"August 9, 2026","externalUrl":null,"permalink":"/en/now/","section":"","summary":"","title":"Now","type":"page"},{"content":" Profile # Solution Architect with 7+ years of experience across travel, banking, finance, and energy. I design cloud-native and distributed systems for critical operations, connecting business constraints with system design, data, integration, and delivery.\nExperience # Solution Architect II · Copa Airlines # April 2026–present\nDefine solution architectures for digital products and large-scale airline operations. Align system design, data models, and integrations with business, reliability, and operational constraints.\nSenior Systems Engineer III · Indra # March 2025–April 2026\nLed architecture and implementation for Java systems, distributed platforms, cloud infrastructure, and cybersecurity initiatives. Established technical standards and mentored engineering teams.\nSenior Systems Engineer II · Indra # March 2022–March 2025\nLed cloud migration and modernization for critical systems.\nReduced operational costs by 30% through an OCI migration, microservices, and DevOps practices. Led a distributed team of 10+ developers and introduced practices that reduced development time by 35%. Selected work # Cloud migration and microservices # Designed an OCI migration using microservices and Kubernetes. The work reduced operational costs by 30% and latency by 25% across critical infrastructure.\nTechnologies: OCI, Kubernetes, Microservices, Docker, DevOps\nDelivery and workload security on AKS # Implemented delivery workflows with Azure DevOps and secured AKS workloads using Key Vault and certificate management.\nTechnologies: Azure, AKS, Azure DevOps, Kubernetes, Security\nContact # LinkedIn: Jesus Aguirre Email: infoaguirrejesus@proton.me ","date":"August 9, 2026","externalUrl":null,"permalink":"/en/resume/","section":"","summary":"Solution Architect focused on cloud-native systems, distributed architectures, and technical decisions for critical operations.","title":"Resume","type":"page"},{"content":"Experiencias técnicas en vivo para profesionales de software que quieren desarrollar criterio mediante casos, contexto y discusión.\n","date":"9 de August de 2026","externalUrl":null,"permalink":"/workshops/","section":"Workshops","summary":"","title":"Workshops","type":"workshops"}]