[PT-2026] Add speakers and sponsor page

content/events/2026-portugal/program.md

@@ -2,9 +2,13 @@
 Title = "Program"
 Type = "program"
 Description = "Program for devopsdays Portugal 2026"
-icons = "TRUE"
+Icons = "false"
 +++
 
-<hr />
-If Open Space is new to you, you may be interested in <a href="/pages/open-space-format">more details about Open Space</a>.
-<hr />
+<div class = "row">
+  <div class = "col">
+    <hr />
+    If Open Space is new to you, you may be interested in <a href="/pages/open-space-format">more details about Open Space</a>.
+    <hr />
+  </div>
+</div>

content/events/2026-portugal/program/axel-bornemann.md

@@ -0,0 +1,18 @@
++++
+Talk_date = ""
+Talk_start_time = ""
+Talk_end_time = ""
+Title = "Build High-Performing Teams by Unlocking Intrinsic Motivation"
+Type = "talk"
+Speakers = ["axel-bornemann"]
++++
+
+Teams that adopt cloud-native tooling do not always reach high performance; the bottleneck is often human, not technology.
+
+The first part gives a brief introduction to the DORA Accelerate metrics as a practical framework for understanding where a team stands today and for measuring meaningful progress over time.
+
+The main part of the session introduces the Self-Determination Theory (autonomy, competence, relatedness) to unlock engineers' intrinsic motivation. Practical methods are provided to address all three elements of self-determination and release the full potential of engineers to do their best work sustainably.
+
+Every method is grounded at the team level, giving attendees actionable ideas they can apply immediately.
+
+The talk closes with lessons learned from applying these ideas inside a corporate context, along with concrete first steps to get started.

content/events/2026-portugal/program/colin-lacy.md

@@ -0,0 +1,14 @@
++++
+Talk_date = ""
+Talk_start_time = ""
+Talk_end_time = ""
+Title = "If This Code Could Talk: Runtime Conditions for Platform Automation"
+Type = "talk"
+Speakers = ["colin-lacy", "lauri-apple"]
++++
+
+App developers want to write code, not YAML. And yet the step between “this application needs these integrations” and “the platform can safely deploy this application” remains mostly manual, fragmented and complicated. It’s no picnic for platform devs, either: The process of configuring database permissions, adjusting network policies, and fulfilling other tasks can lead to misalignment, coordination overhead, and details slipping through the cracks.
+
+This talk showcases the Runtime Conditions Profile Specification, which aims to close the communication gap between apps and platforms through code and automation. We’ll describe how the spec creates a common language for developer-platform interoperability—generating a declarative profile from application source that turns runtime integration requirements into platform action. You’ll see how profiles, extensions, and adapters drive provisioning, configuration wiring, network policy, Kubernetes deployment, and release-blocking feedback when integrations break. We’ll also cover automation that integrates with existing platform tools like Kratix and Crossplane to further simplify the workflow for app and platform devs alike.
+
+By the end, attendees will have a way to describe application integrations across app devs, platform engineers, and tooling so that you spend more time shipping and less time configuring.

content/events/2026-portugal/program/daniel-maher.md

@@ -0,0 +1,18 @@
++++
+Talk_date = ""
+Talk_start_time = ""
+Talk_end_time = ""
+Title = "Your Supply Chain has an Identity Problem"
+Type = "talk"
+Speakers = ["daniel-maher"]
++++
+
+This is a talk about three shifts every DevSecOps team needs to make: from asking whether a package is safe to asking what an identity is allowed to do; from trusting code at install time to verifying it continuously; and from leaning on manual review as the line of defense to building guardrails into the pipeline that scale with the work.
+
+The first shift is about how attackers get in. The most damaging attacks of the last two years almost all began the same way—not by breaking code, but by compromising the people and credentials trusted to publish it. Interpreted (correctly) as an IAM problem, the solutions are familiar to any DevOps practitioner: phishing-resistant authentication, scoped and short-lived credentials, principle of least privilege, and well-handled secrets. It also explains why AI agents matter so much here, as autonomous coding agents tend to be the most over-privileged and under-governed identities in any organization.
+
+The second shift follows from how fast a single compromise now spreads, and how well it can hide. The Shai-Hulud worms propagated through the registry on their own, and Sandworm went further, mutating on every machine it infected so that signature matching loses by design. Verifying trust continuously means provenance at build time and behavioral detection at runtime; in other words, judging code by what it is and what it does, not by whether it looks like something you've seen before. In the agent era this reaches the model itself: a prompt-injected tool description is just another piece of untrusted input flowing into something you trusted by default.
+
+The third shift is about keeping pace without burning out. When half of all organizations run a dependency the same day it's released, no team can hand-review (or hand-wave) their way to safety. Human judgment stays in the loop where it counts, but it can't be the thing inspecting every change. Guardrails that live in the pipeline, such as policy-as-code, release-age cooldowns, and blast-radius limits, let a team move at machine speed without exhausting the people running it. This is where "sustainable" stops being a slogan: grant trust narrowly, verify it continuously, and revoke it quickly.
+
+Everything in this talk is open-source and both vendor and ecosystem-neutral. Whether you write the pipelines or manage the folks who do, you'll leave with these lessons as a durable way to reason about supply-chain risk.

content/events/2026-portugal/program/filipe-revez.md

@@ -0,0 +1,20 @@
++++
+Talk_date = ""
+Talk_start_time = ""
+Talk_end_time = ""
+Title = "Highly Available, Barely Running - Multi-Region HA That Doesn't Cost Twice"
+Type = "talk"
+Speakers = ["filipe-revez", "pedro-cachaldora"]
++++
+
+High availability is usually designed as an architecture problem and paid for as a finance problem. The reference diagrams look clean — two regions, two providers, traffic balanced between them — and then somebody runs the numbers on keeping a second environment permanently warm.
+
+Unfortunately, the compromise most organisations settle on is worse than either extreme. A standby region gets provisioned, sized for a peak it will probably never see, left running at partial capacity, and quietly never exercised. It costs real money every month, and nobody is entirely confident it works.
+
+Every platform team knows the moment. The DR plan is a document, the failover is theoretical, and the only honest answer to "have we actually tried it?" is "not since the last audit."
+
+This talk explores an open-source approach to multi-region and multi-cloud high availability where standby capacity costs close to nothing until the moment it is needed. We will show how Flux keeps every cluster reconciled to the same declarative state, how KEDA lets workloads sit at zero and come up on demand, and how K8GB handles global DNS-based failover between clusters and providers — with no proprietary global load balancer anywhere in the failover path.
+
+Drawing from real deployments, we will walk through the architecture and be specific about the trade-offs: what DNS-based failover can and cannot guarantee, what recovery time actually looks like when your standby starts from zero, how stateful workloads change the picture, and the failure modes we ran into. We will also be clear about where this pattern does not fit and where a managed global load balancer is still the better answer.
+
+Attendees will learn a concrete, vendor-neutral pattern for multi-region resilience, how to reason about the cost and recovery-time trade-off deliberately rather than by default, and how to build a failover that is cheap enough that you can afford to test it regularly.

content/events/2026-portugal/program/gerrard-ezeugwa.md

@@ -0,0 +1,20 @@
++++
+Talk_date = ""
+Talk_start_time = ""
+Talk_end_time = ""
+Title = "How We Reduced Costs By Migrating Across Clouds:  Lessons from a Real World Platform Migration."
+Type = "talk"
+Speakers = ["gerrard-ezeugwa"]
++++
+
+This is the story of how we decided to move from one cloud solutions provider to another, after years of questioning our monthly cloud expenditure and responding to multiple questions from our finance department.
+
+We understood the magnitude of the task, and so we rolled up our sleeves and got to work. What began as a series of meetings with cloud providers where we had conversations on technology, architecture, support and commercial models, evolved into a proof of concept: migrating our uat environment to a new cloud platform.
+
+From there, the scope grew rapidly. What started as a Kubernetes migration soon expanded to object storage, networking, DNS and hosted zones, container registries, identity and access management, CI/CD pipelines, database and other supporting services. Before long, we were planning and executing Production migration. This all happened while keeping the business running.
+
+Some decisions saved us weeks of effort. Others created unexpected problems for us. We learned not only the dependencies between resources, but also the sequence in which to move them to minimise disruption
+
+This talk is not about why one cloud provider is better than the other. It is a candid account of engineering decisions. It is also about the mistakes we made and how we learned from them in a real-world cloud migration effort driven by cost optimisation.
+
+Whether you are planning a cloud migration, questioning your cloud bill or simply planning a large-scale infrastructure change, you will leave with practical lessons that apply regardless of the cloud provider you use.

content/events/2026-portugal/program/gina-adzani.md

@@ -0,0 +1,23 @@
++++
+Talk_date = ""
+Talk_start_time = ""
+Talk_end_time = ""
+Title = "Ingress-Nginx: The Day After"
+Type = "talk"
+Speakers = ["gina-adzani", "julien-salleyron"]
++++
+
+In March 2026, Ingress-NGINX reached its end of life: no new releases, no security patches, and no support.
+
+If you're still running it in production, you need a migration strategy—and fast!
+
+The challenge? Most paths forward require substantial config rewrites: annotation remapping, manual conversions, and lengthy test cycles.
+
+In this talk, Emile Vauge (Traefik Creator) and Nicolas Mengin (Traefik Maintainer) will show how Traefik's Ingress-NGINX Provider can simplify that journey. It brings true drop-in compatibility to Traefik OSS, allowing your existing ingress configurations to run unchanged.
+
+We'll present a pragmatic two-phase migration path: move safely today, and modernize to the Gateway API on your own schedule.
+
+Key Takeaways:
+- What really separates drop-in replacements from traditional migration guides
+- How to move off Ingress-NGINX in weeks instead of months
+- How to approach Gateway API adoption without deadline pressure

content/events/2026-portugal/program/ilia-dubovskii.md

@@ -0,0 +1,40 @@
++++
+Talk_date = ""
+Talk_start_time = ""
+Talk_end_time = ""
+Title = "Autonomous DevOps: Engineering Systems That Don’t Need Our Attention"
+Type = "talk"
+Speakers = ["ilia-dubovskii"]
++++
+
+For decades, DevOps has focused on automation.
+
+We built CI/CD pipelines, Infrastructure as Code, observability platforms, and deployment systems that execute work reliably and consistently.
+
+But automation still depends on human attention.
+
+Someone reviews the dashboards.
+Someone investigates the alerts.
+Someone decides whether an infrastructure change is safe.
+Someone maintains the honeypots.
+Someone keeps Infrastructure as Code aligned with reality.
+
+As our systems continue to grow, human attention - not compute - has become the scarce resource.
+
+This talk introduces Autonomous DevOps: an approach to engineering operational systems that no longer require our limited focus for routine decisions while remaining observable, auditable and trustworthy.
+
+Autonomy does not mean giving AI unrestricted control.
+
+It means identifying operational tasks that are verifiable, reversible and contained, allowing them to execute safely within clearly defined boundaries while humans remain responsible for the strategy, architecture and exceptions.
+
+Using practical examples - including autonomous honeypot management, Infrastructure as Code coverage, infrastructure rightsizing and observability noise suppression - we’ll explore how DevOps teams can gradually move from automation to autonomy without compromising reliability or security.
+
+Finally, we’ll look at why Trust Engineering becomes the foundation that makes Autonomous DevOps possible.
+
+Key Takeaways
+
+* What Autonomous DevOps is and why it extends traditional automation.
+* Why human attention has become the limiting factor in operating cloud-native systems.
+* A practical framework based on verifiable, reversible and contained operations.
+* Real-world examples of autonomous operational workflows.
+* How Trust Engineering provides the guardrails that make autonomy practical.

content/events/2026-portugal/program/jeremy-meiss.md

@@ -0,0 +1,11 @@
++++
+Talk_date = ""
+Talk_start_time = ""
+Talk_end_time = ""
+Title = "Developer Experience is more than just Productivity metrics"
+Type = "talk"
+Speakers = ["jeremy-meiss"]
++++
+
+With everything changing in tech at a frenetic pace, the emphasis on developer productivity has overshadowed the true essence of developer experience (DevEx). While frameworks like SPACE, getDX, and DORA metrics provide valuable insights, they often miss the mark on capturing developers' real, day-to-day experiences using tools and services, instead focusing strictly on the bottom line for the company. Meanwhile, developers and practitioners are job-hopping more than ever.
+This talk will explore the origins and evolution of "developer experience," dissect popular frameworks, and advocate for a more balanced approach that values the practitioner's perspective. At the end we will set a path towards integrating top-down metrics with bottom-up feedback, ensuring an approach to developer experience that fosters innovation and satisfaction.

content/events/2026-portugal/program/joep-piscaer.md

@@ -0,0 +1,24 @@
++++
+Talk_date = ""
+Talk_start_time = ""
+Talk_end_time = ""
+Title = "If You Feel Behind, You’re Probably Paying Attention"
+Type = "talk"
+Speakers = ["joep-piscaer"]
++++
+
+Impostor syndrome is usually framed as a personal failing: a lack of confidence, a mindset problem, something you need to “work through.” But what if the problem isn't you?
+
+You’re not inexperienced. You’re not lazy. You're not bad at your job. I realized something else was going on: no one’s real experience matches the cloud-native story we tell in public.
+
+In the cloud-native world, operators and admins are surrounded by a constant narrative of effortless success: platforms that scale cleanly, teams that “just adopt Kubernetes,” architectures that assume infinite time, talent, and budget. Conference talks are polished. Case studies are sanitized. Failure is implied to be a 'you' problem.
+
+Yet privately, most practitioners are struggling. Technology is complex. Platforms and systems are brittle. Toolchains are overwhelming. Upgrades are painful projects. On-call is exhausting. And almost no one’s lived experience matches what the industry claims is normal.
+
+This talk argues that what we’re experiencing isn’t just impostor syndrome — it’s pluralistic ignorance amplified by burnout. Everyone is struggling to keep up, but no one admits it, because admitting it feels like failure. So we stay quiet. We internalize the gap. We blame ourselves. We work harder and harder, up to, and beyond our breaking point.
+
+At this event, I want to say the quiet part out loud and break that silence together.
+
+This talk is for operators who keep real systems running, who are tired of pretending and who want honesty instead of hype. We’ll examine how hype amplifies self-doubt, why feeling “behind” is often a sign of realism, and how collective honesty—not more expertise—is the missing ingredient in the cloud-native ecosystem.
+
+If you’ve ever thought “everyone else seems to have this figured out” — this talk is for you.

content/events/2026-portugal/program/julien-salleyron.md

@@ -0,0 +1,23 @@
++++
+Talk_date = ""
+Talk_start_time = ""
+Talk_end_time = ""
+Title = "Ingress-Nginx: The Day After"
+Type = "talk"
+Speakers = ["julien-salleyron", "gina-adzani"]
++++
+
+In March 2026, Ingress-NGINX reached its end of life: no new releases, no security patches, and no support.
+
+If you're still running it in production, you need a migration strategy—and fast!
+
+The challenge? Most paths forward require substantial config rewrites: annotation remapping, manual conversions, and lengthy test cycles.
+
+In this talk, Emile Vauge (Traefik Creator) and Nicolas Mengin (Traefik Maintainer) will show how Traefik's Ingress-NGINX Provider can simplify that journey. It brings true drop-in compatibility to Traefik OSS, allowing your existing ingress configurations to run unchanged.
+
+We'll present a pragmatic two-phase migration path: move safely today, and modernize to the Gateway API on your own schedule.
+
+Key Takeaways:
+- What really separates drop-in replacements from traditional migration guides
+- How to move off Ingress-NGINX in weeks instead of months
+- How to approach Gateway API adoption without deadline pressure

content/events/2026-portugal/program/julius-omoleye.md

@@ -0,0 +1,16 @@
++++
+Talk_date = ""
+Talk_start_time = ""
+Talk_end_time = ""
+Title = "Beyond Deployments: Using Kargo to Promote Platform Changes Across Environments"
+Type = "talk"
+Speakers = ["julius-omoleye"]
++++
+
+Most teams have adopted GitOps for deploying applications, yet many still rely on manual processes when promoting changes between environments.
+
+Whether it's service versions, configuration updates, platform settings, or operational artifacts, moving changes from development to production often involves custom scripts, spreadsheets, approval emails, and human intervention. These processes increase risk, reduce visibility, and make it difficult to answer a simple question: "What exactly changed, and how did it get here?"
+
+In this session, I'll share how we implemented Kargo to create repeatable promotion workflows across multiple environments, enabling teams to safely move changes from development to staging and production while maintaining Git as the source of truth.
+
+We'll explore how Kargo can be used for more than application deployments, including configuration promotion, service version management, environment synchronization, and operational change tracking.

content/events/2026-portugal/program/juraci-paixao.md

@@ -0,0 +1,10 @@
++++
+Talk_date = ""
+Talk_start_time = ""
+Talk_end_time = ""
+Title = "Keynote: Your telemetry has a new reader"
+Type = "talk"
+Speakers = ["juraci-paixao"]
++++
+
+For fifteen years, we designed telemetry for humans reading dashboards. Today, coding agents and incident response agents read it first, and they take every log line at face value. This keynote draws on a year of conversations with platform teams to show what breaks when agents consume bad telemetry, what machine-readable telemetry looks like, and why trusting the agent starts with trusting the data.