ANZ finds its feet to hit cloud migration milestones quicker

ANZ Banking Group has hit scale in its cloud migration, halving the time to re-platform applications and workloads compared to just 12 months earlier.

General manager of cloud, data and analytics Adrian Jansz told the AWS Summit Sydney earlier this year that the bank is “migrating at pace”.

Around this time last year, iTnews reported that ANZ had given itself a three-to-five year horizon to migrate or uplift “the majority” of its IT and application estate onto the cloud, predominantly AWS or GCP.

It hit 35 percent migration at the end of last year, which included “a number of material workloads” the bank received regulatory approval to move.

In a presentation to the summit, which has now been released, Jansz indicated that the bank had achieved a level of maturity in its migration processes, skills and cloud-based operations generally, and that is being reflected in progress across a range of strategic areas.

“We're rehosting multiple applications per week,” Jansz said.

“Our re-platforms have come down dramatically from 20 plus weeks to now 10-to-15 weeks, and at a fraction of the cost, all within the last 12 months. 

“We've targeted more complex workloads and our cost transparency and self-service is now assisting in lowering the bar for experimentation on cloud.”

Re-platformed pricing apps pave the way

Jansz said two of the first applications to be re-platformed were for home loan pricing and term deposit pricing.

“We selected these apps based on an app assessment in partnership with AWS, the application team and the core cloud and migration teams, and identified that these were the perfect candidates for ANZ's first re-platforms for AWS,” Jansz said.

“Both were made up of the same architecture and developed by the same team. Both were using GitHub, Bamboo CI/CD, and Artifactory for app development and pipelines, and OpenShift with Microsoft SQL server for on-prem. 

“Based on that assessment, the target state was Bamboo, along with AWS EKS [Elastic Kubernetes Service], ECR [Elastic Container Registry], and RDS [Relational Database Service].”

Now re-platformed, the immediate future for the two pricing apps “is to build out the app team's ‘day two’ operations, including building dashboards, optimising costs, and evolving what good looks like,” Jansz said.

But he noted the cloud migration is much bigger than these two apps - albeit that their migration contributed to the bank bedding down its migration processes and achieving maturity in aspects of app design and operational thinking.

One thing that worked for the bank - and, indeed, worked for other major Australian banks on similar journeys - is the use of “blueprinted AWS managed services” to “reduce… migration overhead”.

The use of managed services had enabled the “offload [of]... undifferentiated heavy lifting”, eliminated guesswork in provisioning infrastructure capacity, and had other benefits in areas such as availability, security, DR, cost optimisation and observability, Jansz noted.

He added: “We now have a roadmap to leverage from a catalogue of blueprinted AWS services.”

In shifting from on-premises infrastructure to the cloud, the bank has been keen to instil more of a cost-conscious mindset among teams, which can influence design decisions upfront and on an ongoing basis.

Jansz said existing apps - such as the two pricing ones - “were hosted on-premises on our OpenShift container environment, which had been running on extended support”.

“Moving to cloud has reduced the risk [associated with] that, and also reduced the cost for our application teams as they no longer need to maintain these asset life cycles going forward,” he said.

“When these [pricing] apps lived on-premises, there was limited visibility into the cost. Post-migration, teams have far greater transparency and can see on a daily basis how much infrastructure decisions, choices, and actions are costing. 

“As a result, we've seen a shift in our staff's behaviour and where they're now wanting to minimise more cost. 

“They're now looking real-time at the utilisation and making more informed decisions around what needs to be on and what can be shut down, what can be rightsized, and a number of other cost optimisation measures.”

In addition, “as automation is backed into application build, config and testing” over time, further cost savings are anticipated: “Typically, automation saves upwards of 50 percent in ongoing effort for build and test activities”, Jansz said.

Other cost savings are coming from switching off idle or non-prod workloads at night - again, a strategy seen across banks and enterprises more broadly when it comes to cloud resource utilisation and optimisation.

“At ANZ, we've commenced a cloud optimisation ambassador program targeted at identifying workloads and cost savings initiatives,” Jansz said.

“Application teams have started placing instances into a schedule, shutting down at 7:00PM, reducing idle resources.”

Jansz said application teams also now benefited from certain operational tasks being shifted to central teams.

“For example, many of the databases are now managed by our database-as-a-service team instead of our app teams, freeing them up to focus on building products and services for our customers,” he said.

The database-as-a-service team participates in cost optimisation, and shuts down all non-prod environments “for 12 hours over evenings”.