ANZ Banking Group Shows Off Its ‘API Mesh’ – Finance – Cloud – Software





ANZ Banking Group has resurrected what it calls 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 briefly introduced in a Kong case study as a “configuration-driven and highly flexible set of gateways and paths” that act as “connective tissues between availability zones” – the data centers or clouds that host the applications.

“The API Mesh enables the applications that APIs provide in the ecosystem to move independently of each other and reduce the friction associated with managing their API lifecycle, without relying on a centralized team during development and testing,” technology leader in enterprise integration services Martin Brennan said in the case study.

The bank went on to provide significantly more details about the API Mesh at the Kong Digital Summit in late September, with the presentation appearing to coincide with the platform’s then-impending go-live.

Product owner Nikki Renvoize said the API Mesh was built “mostly remotely” during lockdowns in Melbourne and Sydney, “except for a few nice months when we were able 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 within the banking business.

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 is a direction the bank is now pursuing with some vigor.

“Australia’s banking industry has been a bit reluctant to move to the cloud – some have moved fast, some slower,” Brennan said.

“Three to four years ago, we had quite a bit of resistance to moving things to the cloud, but now that the company better understands the potential benefits there, the pace is picking up.

“The Seated [API] platform was not designed to be multicloud, and it gave us that decision point: expand or adapt the existing platform or start over.”

It was decided to start over.

“We were in a position to build a greenfields platform,” Renvoize says. “This is something you don’t often experience in a large regulated organization.”

Brennan said the number of application developers at the bank has traditionally been smaller than the number of people assigned to enterprise integration services.

The bank wanted both developers and internal users of API services to be able to self-serve and minimize the amount of work required to go through the centralized integration function.

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

“I had an image in my mind of the kind of experience we could provide from an integration platform, and I knew that security, reliability and observability would be essential to the success of that platform.

“What I didn’t know was how the team was going to achieve it.”

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

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

“We had to rethink the way API management was delivered and change the interactions between the teams so that the organization could act and innovate quickly.

“There were a few things we knew would be critical to our success. We needed to minimize dependence on the small, centralized team.

“We also had to have a platform that was really stable; disruptions in our industry affect people’s ability to do their shopping and pay their bills.

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

Renvoize said the result of the work is what the bank calls “API Mesh,” which it describes as a “multicloud and cloud hybrid platform that enables [developers] to access integration options in the hosting zones within the bank.”

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

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

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

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

Renvoize said the structure also meant that if an application were to change the underlying hosting, all associated APIs could easily be reused from the new location.

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

By using the API Mesh platform, “an onboard user can deploy, update and manage the lifecycle of their APIs without interaction from the platform team,” according to Renvoize.

“Apart from approvals when we get to production, that means they never wait for us,” she said.

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

“It takes the pressure off us and allows them to quickly iterate the integration services in line with the rest of their development.”

Using Kong to support the API Mesh builds on the work ANZ did for open banking in Australia.

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

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

“In addition, the APIs presented through that platform were industry-regulated, so we didn’t have a lot of variety and innovation.

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




Leave a Reply

Your email address will not be published. Required fields are marked *