NAB groups three-tier apps to automatically move them into Azure

NAB has identified groups of mainstream, three-tier applications that it intends to automatically move to Microsoft’s Azure cloud under a five-year deal unveiled earlier today.

Executive of enterprise technology Steve Day told iTnews the bank had spent the past six months using a “really detailed set of discovery tools” to map out “what application flows we have going from where to where, which has allowed us to group the applications and look at moving applications as groups.”

The need to move applications in groups is the result of tight coupling between parts of NAB’s app stack.

That means NAB’s approach to cloud migration work to date, which has largely involved rearchitecting and replatforming one application at a time, albeit at pace - is not fit-for-purpose.

“We’ll move apps across as groups, rather than as individual apps, and that's important because of the level of integration we have in the apps at the moment,” Day told iTnews.

“They're very tightly integrated and therefore to try and move them one at a time … is just too complex for us to do at this particular stage.”

The bank plans to move 1000 apps to Azure in 1000 days; 700 of those apps are NAB’s, and 300 are Bank of New Zealand’s (BNZ).

They are also all “mainstream” and “typically three-tier” - or web-based - applications, Day said.

These are applications NAB needed to move to cloud for reasons such as extra resiliency and to lower operating costs.

“This is [about moving] your typical three-tier architectures/off-the-shelf [applications], which work equally well in different clouds,” Day said.

“There's tiny variations here and there but generally they all support that lowest common denominator in the same way.”

Neither Azure or AWS is preferential

Though today’s deal was reported as a changing of the guard - a passing of the baton by NAB on the cloud it preferences for its cloud migration - Day said, in fact, the bank had no preference as to where it hosted its applications and workloads.

This was partially alluded to in NAB’s official statement, which said that apps migrated to Azure needed to be architected effectively to be cloud-agnostic - and therefore not tied specifically to Azure.

”Our preference is that we are multi-cloud and we've aligned to the guidance given to us by APRA [the Australian Prudential Regulation Authority] in that we should not link the success of NAB to any other company,” Day said.

“It’s really important that we don't do that. 

“This is really about having two really great partners that we work with in order to ensure that our apps are running in the most resilient way possible, while also keeping them relevant and allowing us to innovate at pace.”

How NAB works out where to place its apps now is determined by their relative importance, which is reflected by “seven different treatments”, called multi-cloud treatments or MCTs.

“Where, for instance, APRA have classed an application in their definition of extreme risk, then we typically build in both clouds simultaneously, whereas for lower risk applications that we could live without for an extended period of time, we typically just build [in] an environment that we know we're able to move [from] within weeks,” Day said.

“So from one end, which is you could rebuild it if you need to, right up to building an app in both clouds simultaneously and running it active-active, and then we've got a whole lot of stages in-between. 

“Each of those different treatments has a different design in the multi-cloud tools but it's a whole multi-cloud control plane that we're building right across those seven treatments.”

NAB's Multi-Cloud Treatment (MCT) options

MCT1: App doesn't require multi-cloud because if the app disappeared it wouldn't matter. Day provided the example of a meeting room booking tool, which could be easily substituted with another existing system.

MCT2 and MCT3: Applications NAB could live without for months without any impact to our customers. “It might be just something performing an annual function”. 

MCT4: These apps are backed up to a secondary cloud every evening. They are also configured to use the secondary cloud for production if needed, but this is not actually powered on. “If an event was to occur, we would power that secondary cloud up, rehydrate it with the backup, and we would then be able to repoint the data services with DNS and other mechanisms to be able to run that environment,” Day said.

MCT5: Unknown.

MCT6: Apps with active log shipping from one environment to another. Log shipping “is the process of automating the backup of transaction log files on a primary database server, and then restoring them onto a standby server,” according to Wikipedia. Says Day, “We still have the secondary environment powered down, but we are log shipping into a secondary database that's always turned up.” Recovery from backup could be hours, rather than days.

MCT7: App configured to run active-active, with both clouds processing in real time. “Transactions and the loss of one [cloud] would actually not stop services at all. That's our critical workloads like ledgers and other environments that we just couldn't afford to lose,” said Day.