ANZ Banking Group shows off its 'API Mesh'

ANZ Banking Group has stood up what it is calling its ‘API Mesh’ platform, which represents the bank’s efforts to “think differently” about API management, publishing and consumption.

The API Mesh as a concept was first introduced briefly in a Kong case study as a “configuration-driven and highly flexible set of gateways and pathways” that act as “connective tissue between availability zones” - the data centres or clouds that host its applications.

“The API Mesh will enable the applications that provide APIs into the ecosystem to move independently of each other and reduce the friction involved with managing their API lifecycle, without dependency on a centralised team during development and testing,” technology area lead in enterprise integration services Martin Brennan said in the case study.

The bank then provided substantially more detail on the API Mesh at the Kong Digital Summit in late September, with the presentation appearing to coincide with the platform’s then imminent go-live.

Product owner Nikki Renvoize said the API Mesh was built “mostly remotely” during lockdowns in Melbourne and Sydney, “bar a couple of sweet months where we got to use whiteboards in person.”

One of the reasons the API Mesh was created was to enable self-service capabilities for both API providers and API consumers across the bank’s operations.

ANZ had an existing API management platform for which self-service capabilities had been successfully built, but it was “limited to on-premises” use and not designed for multi-cloud - the latter being a direction the bank is now pursuing with some vigour.

“The banking industry in Australia has been a little hesitant in its moves to cloud - some have moved fast, others slower,” Brennan said.

“Three-to-four years ago we had quite a resistance to moving things into the cloud, but now that the business is getting better at understanding the possible benefits there, the pace is picking up. 

“The incumbent [API] platform wasn’t designed to be multicloud, and it gave us that decision point - extend or adapt the existing platform or start afresh.”

A decision was taken to start afresh.

“We were in a position to build a greenfields platform,” Renvoize said. “This is something that you don’t often get to do in a large regulated organisation.”

Brennan said that the number of application developers at the bank traditionally dwarfed the number of people assigned to enterprise integration services.

The bank wanted developers as well as internal consumers of API services to be able to self-serve some of their needs, and to minimise the amount of work that needed to run through the centralised integration function.

“I’ve seen the result of centralised high-friction integration delivery within the bank and I knew it wasn’t going to scale to ... the speed the bank needed to deliver at,” Brennan said.

“I had a picture in my mind of the sort of experience that we could offer from an integration platform, and I knew that security, reliability and observability were going to be essential to the success of that platform. 

“What I didnt know was how the team was going to achieve it.”

Brennan said that ANZ had a “huge number of developers working on hundreds of applications in dozens of languages”, each with “varying levels of API capability”.

“The integration team by comparison is very small - less than 200 people including our delivery partners,” he said. 

“We had to think differently about the way API management was delivered and change the interactions between the teams for the organisation to be able to move fast and innovate.

“There were a few things we knew would be critical to our success. We needed to minimise the dependency on the small, centralised team. 

“We also needed to have a platform that was really stable; outages in our industry impact people’s ability to buy their groceries and pay their bills. 

“And we needed the application teams to be able to move at their own pace and do things for themselves. Things weren’t going to wait around on a backlog from an integration team.”

Renvoize said the result of the work is what the bank calls ‘API Mesh’, which she describes as a “multicloud and cloud hybrid platform that allows [developers] to access integration capabilities across the hosting zones within the bank.”

“The platform allows [API] consumers and [API] providers to access what is local to them and be connected to all other zones, and this is where our mesh concept comes in,” she said.

“We did this by placing a Kong Konnect [API] gateway in each location and developing secure and - this is important - pre-approved pathways between them.

“This model allowed us to achieve a consistent consumption pattern regardless of the location of an [API] provider. 

“If a consumer - let’s say they’re cloud-based - needs to consume two APIs, one is local to them and one is based on-premises, they’ll have the same experience of consuming both of those APIs. That is to say, they connect into the same gateway to get access to either of them, so there’s no additional work to consume [an API] from a ‘foreign’ zone.”

Renvoize said that the structure also meant that if an application changed its underlying hosting, any associated APIs could be easily re-consumed from the new location.

“[API] consumers and providers need to only worry about the gateway in their location,” she said.

By using the API Mesh platform, “an onboarded user can deploy, update and manage the lifecycle of their APIs with zero interaction from the platform team,” Renvoize said.

“Aside from approvals when we get to production, this means they are never waiting on us,” she said.

“This effectively brings integration services into their realm of control. 

“It reduces the pressure on us, and it allows them to rapidly iterate the integration services in line with the rest of their development.”

The use of Kong to underpin the API Mesh builds on work ANZ did for open banking in Australia.

“Our first foray into Kong was part of our open banking platform,” Brennan said.

“It was a limited use case but it had unpredictable usage patterns. We didn’t know if we were going to get one hit or 1000 hits a day. 

“Also, the APIs that were presented through that platform were industry regulated so we didn’t have much in the way of variation and innovation going on.

“But it did allow us to come up to speed with Kong, work out how we were going to deploy it, and demonstrate that we could operate it effectively.”