ING’s private cloud has been around for over a decade, and its cloud native portfolio is approaching almost a decade in the making. Built on open source standards and cloud native technologies early in the European banking journey, it powers the vast majority of the bank’s workloads today. Kubernetes was adopted early, and it is consumable as namespace-as-a-service to date. Early on, we strived to enable full self-service via API’s for our application teams. We even set up an internal open source committee and iteratively released projects wherever it created value. Some of the best infrastructure engineers in Europe built and refined this stack, and let us say it loudly: it delivers.
Being early also means seeing the next chapter before much of the industry, especially in FSI.
Like all technology, cloud native technology evolves in layers. Nothing is wrong: the platform simply grows and matures, year after year. Take the examples of Ingress Patterns, RBAC & Network policies, and so on… None of these are failures. Each was a good decision at the time. The compound result is what I call **layered legacy**: a stack that works, but becomes less flexible, less adaptable and more expensive to maintain by the day. Suddenly, thirty solid interfaces feel like thirty different products.
This is what sustained success looks like: a platform that has served countless teams, currently running thousands of applications and services. The challenge is how to keep the platform evolving while making the developer experience simpler, safer, and faster for the engineers who build on top of it, and staying aligned with the requirements of a global organization, from compliance and risk to security and external entities like the ECB, etc.
2026: The year of the rising platform
2As we plan on the next iteration of our infrastructure, we are expanding what our private cloud can be – not by changing its foundations, but by evolving how it is experienced and operated. The same open-source standards and cloud native technologies remain at the core. What’s changing is the model around them: shifting from a powerful container and IaaS platform to a portfolio of advanced products, delivered through a modern internal developer platform (IDP).
First, we are building a fully capable IDP designed around the engineers who consume infrastructure. That means a cohesive self-service experience where the recommended way is also the easiest way. This built on modern pipelines and integrated with agentic workflows that help teams move from idea to production faster, while staying aligned with engineering requirements.
Second, we are evolving our infrastructure into its next form: a well-defined set of products, engineered to deliver our core foundational capabilities. Each capability becomes something teams can adopt with confidence: it has an owner, a clear contract, semantic versioning, a lifecycle, a reliability target, and a cost-per-unit metric.
A hard truth: without product discipline, even the best self-service architecture turns into a YAML vending machine (or worse) – provisioning with no ownership behind it. Product discipline is what separates a platform that compounds from one that just grows.
Kubernetes is central to that shift – not as “containers,” but as an operating model and we are embracing Kubernetes to its full potential in two ways:
- A standardised interface. Products are requested and managed through stable, versioned APIs. Kubernetes gives us that language. A team requesting a managed data capability interacts with a single custom resource, whether it’s provisioned on Kubernetes, a cloud provider, or on premises is an implementation of detail. The contract stays the same.
- An enhanced control loop. Kubernetes offers a powerful reconciliation engine, and operators let us encode operational knowledge as continuously running automation. Provisioning, upscaling/downscaling, failover, certificate renewal – all spread across nodes. That is what we believe will allow managed products to truly scale.
Put together, this is the direction: a modern IDP that empowers consumers through pipelines and agentic workflows, and an infrastructure layer that behaves like a product portfolio – built on open source and cloud native principles, and expressed through Kubernetes primitives and key concepts, so services can be delivered and operated with more consistency, speed, and confidence.
Optionality and open source underpin the whole approach. OCI images, Kubernetes APIs, CRDs and Operators – standards that give us control over our upgrade cadence, auditability of what reaches production, reduced concentration risk, and the capability to change dependencies if dictated by geo-political circumstances.
2030: The future we envision
It’s Monday morning. An application team needs to ship a new service.
They open the backstage IDP and select a template that matches their workload. They choose hardened base images, pick the infrastructural and architectural components the service needs, paste the repository URL, and click “provision.”
Within minutes, the platform assembles the full blueprint and deploys the complete architecture into a test environment: the application scaffolding, the connectivity defaults, the required guardrails, and the monitoring signals. Predefined policy validation, identity, and tenancy controls run automatically before anything is scheduled. Moments later, the team receives confirmation: “Your test environment is ready.”
Time elapsed: minutes, not weeks. No hidden steps. The same templates and golden paths that accelerate delivery also ensure consistency and repeatability and enable promotion to the next environment all the way to the production stage.
The platform portfolio has doubled. The headcount has not. The experience stays consistent because the infrastructure layer behaves like products, and operational knowledge compounds through software and automation – not through repeated human effort.
This is what happens when a decade of cloud native investment meets product discipline built on open standards, guided by platform principles, driven by the engineers who use it.
If your organisation benefits from the open source projects that power this, Kubernetes, OCI, OpenTelemetry, and many others, contribute back. Not as charity. As a strategy.
And if you are at KubeCon EU 2026 in Amsterdam, come visit us at the ING Booth (799). We would love to continue the conversation!