Juan Herreros
Principal Platform Engineer @ Banking Circle
Actions
I'm Juan, a Platform Engineering enthusiast.
I am working for Banking Circle, as the Team Lead in our Cloud Native Technology team.
When I'm not working, I'm most likely rehearsing or performing improv comedy.
Area of Expertise
Who Owns the Upgrade? Automating Fleet-Wide Helm Rollouts Without Breaking Prod
Many Platform Engineering teams maintain a set of abstractions which development teams use to deploy their applications - often in the shape of a Helm chart.
Even after the chart is mature, the Platform team needs to introduce bug fixes, security patches, the occasional improvement.
For an app team to onboard each of this changes, they need to read the changelog, decide if it's safe, bump a version, run a deploy.
In Banking Circle, we had around 200 applications across 25 teams. With an average of 8 chart releases a month and 30 min needed to onboard each release on any app, we were wasting hundreds of engineer-hours a month. Moreover, as you can imagine, not every update reached every app, so fleets quietly drifted out of date. It also left us non-compliant, because security wanted periodic redeploys nobody had time to run.
So we flipped ownership. This talk is about the Blueprint Update Orchestrator (BUO): a GitOps-native system that makes the Platform team own chart versions, and pushes non-breaking upgrades to hundreds of apps automatically, without ever touching a team's `values.yaml`, and without opening a PR.
BUO stages rollouts through test apps, dev, and regional prod with change-approval gates, and every change lands as a signed Git commit with a full audit trail. Only minor/patch versions auto-apply, breaking changes still go through an explicit migration path, and any team can opt out.
Pushing chart upgrades to production on a schedule sounds reckless. It turned out to be safer. By upgrading continuously instead of in rare big jumps, we surfaced bugs minutes after they were introduced.
We'll share the skepticism we hit, how we hardened testing before flipping the switch, and how reluctant developers came around once the system kept quietly working.
Infrastructure as code, from templates to APIs: A Platform Engineering Story
After a rough start with a building-blocks-based approach, Banking Circle transitioned to exposing a single interface to which teams can submit a single configuration file with which they handle all the infrastructure they need.
Crossplane y Helm: juntos, revueltos, mezclados y agitados
Crossplane y Helm son dos herramientas clave del ecosistema CNCF. Al combinarlas, podemos ofrecer a nuestros usuarios una experiencia de auto-servicio para desplegar sus aplicaciones sin que tengan que ser expertos en Kubernetes o infraestructura.
En esta charla exploraremos cómo usar Helm y Crossplane juntos para construir abstracciones de plataforma efectivas y sostenibles. Tras una breve introducción a ambas herramientas, profundizaremos en tres patrones de integración:
- Helm-in-Crossplane: Usando el provider-helm para empaquetar plantillas Helm como recursos gestionados y exponerlas como CRDs.
- Crossplane-in-Helm: Incorporando recursos de infraestructura (dentro y fuera del clúster) directamente en el despliegue de una aplicación.
- Crossplane-in-Helm-in-Crossplane: La combinación definitiva: una abstracción de plataforma que incluye todo lo necesario, empaquetado y listo para el auto-servicio.
La sesión incluirá ejemplos prácticos y lecciones aprendidas del mundo real.
Please note that Sessionize is not responsible for the accuracy or validity of the data provided by speakers. If you suspect this profile to be fake or spam, please let us know.
Jump to top