ANZ Banking Group has implemented what it calls its “API Mesh” platform, which represents the bank’s efforts to “think differently” about managing, publishing and consuming APIs.
The Mesh API as a concept was briefly introduced for the first time in a Kong case study as “a set of highly flexible, configuration-driven gateways and paths” that act as “a connective tissue between Availability Zones” – the data centers or clouds that host its applications.
“The Mesh API will allow applications that provide APIs 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 for development and testing ”, responsible for the technology area of enterprise integration services. Martin Brennan said in the case study.
The bank then provided many more details about the Mesh API at the Kong Digital Summit in late September, with the presentation appearing to coincide with the then imminent launch of the platform.
Product owner Nikki Renvoize said the API Mesh was built “mostly remotely” during the lockdowns in Melbourne and Sydney, “with the exception of a pleasant few months where we were able to use whiteboards in anybody”.
One of the reasons the Mesh API was created was to enable self-service capabilities for API providers and API consumers across all banking operations.
ANZ had an existing API management platform for which self-service capabilities had been successfully developed, but it was “limited to on-premises use” and was not designed for multi-cloud – the latter being a direction that the bank is now pursuing with some vigor.
“The banking industry in Australia has been a bit hesitant in its transition to the cloud – some have moved quickly, others more slowly,” said Brennan.
“Three or four years ago we had some resistance to moving things to the cloud, but now that the company has a better understanding of the possible benefits, the pace is picking up.
“The holder [API] The platform was not designed to be multicloud, and it gave us that decision point: extend or adapt the existing platform or start from scratch. “
A decision was made to start from scratch.
“We were able to build an entirely new platform,” Renvoize said. “It’s something you don’t often have to do in a large, regulated organization. “
Brennan said the number of app developers at the bank has traditionally eclipsed 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 meet some of their needs on their own and minimize the amount of work required to go through the centralized integration function.
“I saw the result of the centralized delivery of high friction integration within the bank and knew it was not going to scale to … the speed at which the bank needed to deliver,” he said. Brennan said.
“I had an idea in mind of the kind of experience we could deliver from an integration platform, and I knew that security, reliability and observability were going to be critical to the success of that platform. -form.
“What I didn’t know was how the team was going to do it.”
Brennan said ANZ had a “huge number of developers working on hundreds of applications in dozens of languages”, each with “varying levels of API capacity”.
“By comparison, the integration team 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 so that the organization could move quickly and innovate.
“We knew there were certain things that would be critical to our success. We had to minimize dependence on the small, centralized team.
“We also needed a really stable platform; blackouts in our industry affect people’s ability to shop and pay bills.
“And we needed application teams to be able to scale at their own pace and do things on their own. Things weren’t going to wait on a backlog of an integration team.
Renvoize said the result of the work is what the bank calls “API Mesh,” which it describes as a “hybrid multicloud and cloud platform that enables [developers] to access integration capabilities through hosting areas within the bank.
“The platform allows [API] consumers and [API] providers to access what’s local to them and be connected to all other areas, and that’s where our networking concept comes in, ”she said.
“We did this by placing a Kong Konnect [API] gateway in each location and developing secure and – importantly – pre-approved lanes between them.
“This model has enabled us to obtain a consistent consumption model regardless of the location of a [API] provider.
“If a consumer – let’s say it’s cloud-based – needs to consume two APIs, one is on-premises and the other is on-premises, they’ll have the same experience of consuming those two APIs. That is, they connect to the same gateway to access one of them, so there is no extra work to consume [an API] of a “foreign” zone.
Renvoize said the structure also meant that if an app changed its underlying hosting, all associated APIs could be easily reused from the new location.
“[API] consumers and suppliers only have to worry about the gateway at their location, ”she said.
Using the API Mesh platform, “an integrated user can deploy, update and manage the lifecycle of their APIs without any interaction from the platform team,” said Renvoize.
“Aside from the approvals when we get into production, that means they never wait for us,” she said.
“This effectively places integration services in their area of control.
“This takes the pressure off us and allows them to quickly iterate on integration services based on the rest of their development. “
The use of Kong to underpin the Mesh API builds on the work done by ANZ for open banking in Australia.
“Our first foray into Kong was part of our open banking platform,” said Brennan.
“It was a limited use case, but it had unpredictable use patterns. We weren’t sure if we were going to get one hit or 1000 hits a day.
“Also, the APIs presented through this platform were regulated by the industry, so we didn’t have a lot of variation and innovation going on.
“But it allowed us to familiarize ourselves with Kong, determine how we were going to deploy it, and demonstrate that we could operate it effectively.”