While some commentators in tech say that microservices architecture has seen its heyday, in reality, it’s still foundational to some massive distributed digital systems, from Netflix, to Amazon, SoundCloud, and beyond.

But how exactly do you operationalize thousands of distributed microservices living in various environments? Successful microservices adoption tales often revolve around using service mesh, an architecture that typically provides sidecar proxies around each microservice and provides a control plane for managing them.

One case in point is ING Bank. Engineers at ING Bank have been using service mesh to support over 2,000 microservices across its vast hybrid cloud environment. Their service mesh architecture is helping ING Bank deliver standardized components for zero-trust security, dynamic service discovery, and beyond.

As Jens Kat, developer engineer, ING Bank, writes on the company’s Medium blog, “The service mesh is invisible but essential, handling security, observability, resiliency, traffic management and governance so that developers can focus on business value.”

Below, we’ll briefly review their journey, and look at key takeaways and lessons learned from over the past nine years of implementing and refining service mesh in practice in a global-scale financial services environment.

The Journey Began Nine Years Ago

Nine years ago, ING began transitioning from a service-oriented architecture (SOA) into a microservices architecture using more modern RESTful APIs. In 2017, Nordic APIs covered this initial design phase. As Flavia Sequeira, then Platform Architect at ING Bank, shared at Platform Summit, the shift required a mindset change from API doing to API thinking.

Yet, microservices come with a core concern: How are they networked? This drove ING Bank toward service mesh, or, as Kat describes it in 2026, “a dedicated networking layer.” As he explains, the goal was to move away from a single point of failure, increase autonomy, and to enable a zero-trust approach for its microservices with organizational-wide components.

Core Lessons Learned

Through nearly a decade of experimentation and refinement, ING Bank has emerged with a service mesh that is a helpful network abstraction. But it took some trial and error along the way. Here’s a distillation of takeaways from their case study.

1. Don’t Make Developers Reimplement Requirements

Microservices come with a lot of baggage around networking and traffic management. A distributed architecture needs independent requirements for each service, like monitoring, authentication and authorization, mutual transport layer security (mTLS), and methods to enforce service-level agreements (SLAs).

These components should be reused across microservices, otherwise you risk wasting time reinventing the wheel for each implementation. As Kat writes, “There is lots of room for interpretation if you don’t make the requirements rock-hard.”

As such, ING Bank quickly learned that it was best for developer experience to streamline the process of adding these requirements to their applications, and automating away complexity when possible. They did this by providing a default implementation to get started, and a conformance testing tool to make sure they worked in practice.

2. Stick With What You Know

Another lesson learned is to use technology that your organization is already familiar with. ING Bank’s journey shows how service mesh can be implemented as a custom architecture versus an off-the-shelf tool. In their case, their custom architecture isn’t purely sidecar-based. They use both a Java framework and sidecar proxy.

Given that most of ING’s infrastructure is coded in Java, engineers were more prepared to take it on. “The cool thing with economies of scale is that the thing you develop, and support becomes cheaper the more it is used,” writes Kat.

3. Standardize Your Discovery

If you’re dealing with thousands of microservices, you run into an issue where you’re tracking various forms of tribal knowledge. “The first thing we need to stop is the backchannels like mail, wikis, or other means that will lead very fast to outdated and incorrect information,” writes Kat.

To solve this, ING Bank engineers began describing endpoints using OpenAPI to ensure documentation is up to date, and they created an API marketplace. The marketplace acts as an authority for discovering services, including API endpoint-level discovery rather than just service-level discovery.

It also defines what API endpoints microservices are allowed to access, dictating their authorization and identity strategy. This is part of a governance plane that issues signed JSON Web Tokens (JWTs) for services to use when calling API endpoints.

4. Avoid Central Bottlenecks When Possible

Service mesh helps apply common boilerplate necessities across workloads, no matter if they’re sitting in various public or private clouds. However, ING Bank has made specific choices to enhance efficiency when possible.

ING Bank’s service mesh architecture separates things into a governance plane (the developer portal and API marketplace), a control plane (for service discovery), and a data plane (the actual workloads). Instead of your typical centralized or unified control plane for service mesh, like how Istio is designed, they opt for a pull-based control plane for distributing routing and discovery data.

They’ve also discovered that using a client-side load balancer reduces reliance on centralized load balancers and enables smarter, client-side routing decisions. “This allows us to scale to thousands of workloads without memory overhead on the workloads,” writes Kat.

5. Great Tech Needs Internal Collaboration

For a new platform to succeed at a multi-national scale, you really need to evangelize it. Kat shares that ING Bank uses enabler teams in specific countries that act as experts. This helps distribute the knowledge and support.

But beyond promotion, ING Bank encourages collaboration and what Kat calls “a community of practice.” They have bi-weekly meetings and an internal Q&A platform to share knowledge, best practices, and keep everyone on the same page by showcasing demos that engineers are creating. They also encourage contributions and PRs to keep the mesh active.

ING Bank: A Case Study for Microservices At Scale

Today, 1700 workloads use the components developed for ING Bank’s service mesh, across 2200 applications and 850 teams in production. The framework and sidecar features they’ve developed are helping onboard new teams quickly. It’s made microservices more manageable and helped them support deploying across a global multi-cloud hybrid environment.

As Kat describes, it’s benefited their security posture. “A service mesh is for us a must-have, we are strict on identity and locking down access, so we have audit trails and a manageable authorization scheme.”

All that said, microservices architecture at scale requires careful diligence. And rolling out a service mesh takes care. By automating what you can, following the tips above, and rolling out changes effectively, platform and DevOps teams are better positioned to create service meshes that realize end benefits.