ANZ is rebuilding the internal developer platform used by its software engineers to code and deliver new features for its consumer digital banking service, ANZ Plus.
ANZ’s Michael Fornaro.
ANZ Plus went live in March last year, and is the customer-facing part of a transformation programme the bank started in 2019 under the moniker ANZx.
Speaking at Google Cloud Next 23, platform tech lead Michael Fornaro revealed the active behind-the-scenes work on reshaping the tooling used by coders and engineers working on ANZ Plus.
Fornaro indicated there had been a rethink in the developer tooling since ANZ Plus had gone live.
Part of that was driven by a shift in the mindset around developer tooling, summarised by Google product manager Nick Eberts in the presentation.
“Internal developer platforms (IDPs) have to be treated as ‘products’,” Eberts said.
“It’s not a one-time thing [that] you just build and walk away [from]. It’s got a life.”
ANZ had come to the same conclusion, Fornaro said, and partnered “with Google engineers … to reimagine our platform and treat it like a product, rather than just a collection of tools that we throw at engineers and try and get them to figure out those complexities in how to use them.”
That “reimagination” of the IDP is happening right now.
“We’re actually still building it,” Fornaro said. “We are in-flight right now, so this isn’t like a perfect thing.”
Fornaro said an IDP was initially created as part of ANZx because every customer experience or “journey” in ANZ Plus runs using “tens, hundreds or even potentially thousands of different microservices”.
“So if we want to be able to scale and provide the best customer experiences and journeys rapidly, at a velocity rate that continues to grow, and meet that demand, then we need to be able to have way to ensure that engineers are focusing on the right things and not having to deal with low-level complexities.”
Fornaro indicated that the bank “definitely didn’t get [the IDP] right the first time.”
“We thought we knew what our engineers needed, and so we had regulatory requirements and we had security requirements and that led to our first instance of production which eventually led to us going live with our ANZ Plus offering in about 2022,” Fornaro said.
“Since then, [ANZ Plus] has been fantastic – we’ve had a rock solid production cluster, we haven’t really had any massive outages or anything like that.
“However, thinking of the platform offering as a ‘product’ to our internal engineers, the feedback was always consistent from the engineers: and that was that it was extremely hard to actually get their software all the way through to production, especially in a financial organisation that has so many gates and processes that they have to go through.”
Fornaro said the end goal is to have new teams get set up and be productive faster, and to give all engineers a more “intuitive” development and deployment experience.
He said the “day zero experience” would see an engineer use either a UI or GitOps CLI to create a “workspace” – and the resources and tooling they need to be able to get their work to production.
A workspace is “a higher level construct which effectively means they’re going to get a GCP [Google Cloud Platform] project, a tenancy, IAM, workload identity federation for keyless authentication,” he said.
“All they give us is a little bit of information, and this will spit out all the declarative resources in order to create all that and bootstrap them.”
Fornaro said this was previously a much longer process.
“Historically, [it] would take somewhere between three-to-six months for them to be onboarded and be able to eventually get their code to production, which is just crazy. It’s a very long time,” he said.
“With this approach we’re able to speed this up.
“Requesting a workspace and onboarding new teams has been reduced down to about 15 minutes.”
Fornaro said the “day two” experience would see engineers interfacing with their repository, and being provided specific guidance aimed at getting their code to production.
“We’re not just throwing things at them and saying, ‘Here you’ve got five different UIs to debug and troubleshoot your tool. They deploy to their repository, we have a GitOps workflow and at all of these points through the flow, we have feedback loops, and in those feedback loops we give them deep links to the relevant tools that they can look at to troubleshoot and debug their application,” Fornaro said.
“So rather than trailing through a CD pipeline wondering, ‘Why is my application not deployed?’, now it’s very intuitive.
“They can actually be directed to where to find their application is failing and why it’s failing. and so this is a much better experience for our engineers.”
About Author
