No more snowflakes - why enterprise application design needs to change in the age of cloud

Unique, fragile and impossible to reproduce, traditional enterprise applications will soon be left out in the cold, says Rory Barr, Barclays

Things are changing in the data centre and applications need to catch up with those changes.

That was the message imparted to the assembled audience at Computing's Data Centre & Infrastructure Summit by Rory Barr, who until very recently was global head of network tools and core services at Barclays, but who left last week to pursue his interests in software-defined networking (SDN) and network virtualisation.

It is developments like these, and more broadly the rise of public and private cloud, that Barr feels has left enterprise applications floundering. To illustrate this point he gave a hypothetical example of an application rollout at Barclays.

"Let's say Barclays wants a video-on-demand application that streams Premiership football out to all its customers," he said.

"We'd get our solutions architects on the case, and some end-to-end designers, and we'd need to build a separate DMZ infrastructure for compliance reasons.

"We'd buy some new firewalls, and load balancers, and some proxies and specialised middleware. We'd probably need to buy in some physical infrastructure to run it because of power-core licensing, and some new network infrastructure for high bandwidth..."

All of this, Barr concluded, would be very expensive and take a long time to bring to fruition. Contrast that, he said, with the Netflix video on-demand service.

"Netflix has no infrastructure. It's all delivered out of Amazon's cloud. And yet at peak times Netfilx accounts for 30 per cent of all US internet traffic. Their employees are developers or marketers, and yet they are making revenues of $1.7m per employee."

Netflix developers design for failure. In an extreme example of this practice the firm uses a program called the Chaos Monkey that attempts to disrupt the running of the live service by terminating virtual machines at random. Developers must ensure that the service can stay up and running despite the malign attentions of the Chaos Monkey.

"It was built like that from the start," Barr said. "It's this type of paradigm shift in thinking that's needed with enterprise applications."

Design for failure is a consequence of the move from specialised hardware to commodity infrastructure - from pets to cattle, as Barr puts it, quoting Microsoft engineer Bill Baker who came up with the analogy.

"Before you had lots of servers, or pets, with friendly names, all of them unique. When one gets sick you call in specialists to fix it; whereas if you're going to have applications that will scale out in a cloud-native way you want the servers to be much more like cattle. They're all pretty much the same and if they get sick, well just shoot them."

Moving the responsibility for availability and resilience from hardware to software has definite advantages, Barr said.

"Five-nine's availability in hardware is very expensive, but if you design for failure in the application it can be done a lot more cheaply."

In describing what the move to commodity scale-out architecture means for application design, Barr reached for another analogy - the snowflake.

"Snowflakes are unique, fragile and impossible to reproduce. This very much like how people build applications today.

"They are all made from exactly the same stuff and they all follow standard patterns," he said. "But we can avoid building snowflakes if we take advantage of cloud infrastructure."

It is this general drive towards standardisation and automation that is leading to changes at his former employer.

"At Barclays we've been rapidly moving down the private cloud route, deploying OpenStack. It's very easy to get up and running fast. On top of that you've got continuous integration. People who develop the applications are operating them as well, with the testing built into the development process."