Cloud Native September
Registration questions
Answer these questions to complete your registration.
Whether you are a seasoned developer, a cloud computing enthusiast, or simply curious about the scene, this event is the perfect opportunity to connect with like-minded individuals in Manchester.
We are back at Booking.com so thanks again for their sponsorship but also please ensure to provide your full name and bring ID to enter the building. Feel free to email organisers directly on contact@cloudnativemcr.co.uk to provide your full name if you do not want to include it in your profile here.
To find the location please use: https://what3words.com/salon.swim.brass
| Time | Description |
|---|---|
| 18:30 | Networking with food and drinks |
| 19:00 | Designing Resilient Cloud-Native Systems: Lessons from Real-World Architectures - Emmanuela Opurum |
| 19:30 | Break |
| 20:00 | Modernising Kubernetes access at Booking: A journey from SSO to OIDC - Milap Anwani |
| 20:20 | Break |
| 20:30 | AI-Powered client-go Upgrades with Usage-First Scanning - Sachin Sachdeva |
| 20:50 | End |
-
7:00 PM - 7:30 PM BST
Designing Resilient Cloud-Native Systems: Lessons from Real-World Architectures
in-personModern cloud-native systems promise scalability and resilience, but in practice, many architectures fail under real-world conditions.
In this session, I’ll share practical lessons from designing and working with distributed, cloud-native systems across multi-cloud environments.
We’ll cover:
-Core principles of cloud-native architecture (containers, microservices, APIs) -Designing for resilience: fault tolerance, retries, circuit breakers -Common failure patterns in Kubernetes-based systems Observability strategies (logs, metrics, tracing) -CI/CD and deployment strategies for cloud-native applications Real-world trade-offs: complexity vs scalability
This talk focuses on practical architecture decisions and lessons learned from real systems, what works, what breaks, and how to design systems that survive production.
Attendees will leave with a clearer understanding of how to design and operate resilient cloud-native systems.
SPEAKERS -
8:00 PM - 8:20 PM BST
Modernising Kubernetes access at Booking: A journey from SSO to OIDC
in-personThe Booking Kubernetes Service (BKS) is a Platform as a service (PaaS) created at Booking.com to facilitate rapid development and innovation. We currently run 68 Kubernetes clusters on BKS, out of which 53 are AWS clusters while 15 are on-premise.
Managing authentication and authorization at scale is one of the quieter challenges of running Kubernetes in a large enterprise. In this talk, we discuss how we replaced the legacy SSO approach in our on-premise clusters with OIDC integration, where we cover:
- The legacy SSO architecture
- The need to move away from it
- The new OIDC based architecture (which EKS clusters already use)
- The journey of migrating across all on premise clusters without disrupting thousands of engineers, and what we learned along the way.
You'll leave with a clearer picture of the trade-offs between our old and new auth approaches, and a practical blueprint for modernizing access control in your own environment.
SPEAKERS -
8:30 PM - 8:50 PM BST
AI-Powered client-go Upgrades with Usage-First Scanning
in-personIf you maintain Kubernetes controllers or operators, you've probably felt this: a new k8s version drops, k8s client-go ships alongside it, and suddenly you're reading a changelog that lists every API change across 200+ packages — because it has no way of knowing you only use a fraction of them. Then you do it for co-versioned modules such as k8s.io/api and k8s.io/apimachinery. Then you write the fixes, untangle the dependency conflicts, and open the merge requests. All by hand.
At Booking.com, this cycle cost us three weeks per upgrade — as k8s releases every new version 3 times a year, its nine weeks of engineer time annually on work that isn't hard, just relentlessly manual and easy to get wrong.
The fix was to invert the problem. Instead of starting from the library, start from your code. Go's own type-checker gives you an exact usage fingerprint — which symbols your codebase actually calls, references, or embeds. Diff only those. The noise disappears entirely: 200+ packages in client-go, 25 that BKS uses, 6 breaking changes that actually matter. These are the real figures we got during client-go upgrade from v0.30.14 to v0.32.13.
This talk walks through the six-module pipeline we built on this insight:
- Usage-first static analysis — exact symbol fingerprint of what your codebase calls, references, and embeds
- Targeted symbol diffing between Git tags, scoped only to symbols in use
- File-and-line impact mapping across multi-module repositories with severity classification
- Deterministic dependency conflict resolution — no AI involved
- Compiler-verified AI-generated source patches with build and test gates
- Automated merge request creation with full context
We'll cover a real production run: v0.30.14 to v0.32.13, 13 repositories, 11 merge requests, all green. Three weeks reduced to 30 minutes of async review per upgrade cycle.
Attendees will leave with a reusable mental model — usage-first analysis over library-first noise — and a concrete understanding of where deterministic automation ends, where AI fits, and how to verify that it got it right.