From Design Conflict to Design Harmony on Cloud

The dome of St Paul’s is an iconic part of the London skyline: it’s instantly recognisable, and can be seen from far away.

What’s harder to see, though, is that the famous building is also a famous architectural compromise. Sir Christopher Wren’s original plan was for a floorplan shaped like a symmetrical cross, in line with the classical inspiration for his design. The clergy disagreed, though, and insisted on the more traditional layout for an English church, with an extended nave. As a result, we have a classical dome on top of a medieval floorplan.

Most design involves compromises like this: we have design goals (build a beautiful structure following classical ideals; demonstrate visual continuity with church tradition) which cannot be satisfied simultaneously, and we have to figure out which goals we will give priority to.

One of the things that attracts me to Cloud, though, is that design goals which have traditionally conflicted can be brought into harmony.

Let me illustrate with a few examples:

Cost vs Flexibility

We have had to choose between cost and capacity since the first time we deployed infrastructure, but this choice has become harder since systems have been exposed to the Internet and usage patterns have become more variable. When buying infrastructure, we always have to choose whether to optimise for peak capacity (in which case we probably spend money on idle equipment) or to optimise for cost (in which case we risk being unable to accommodate peak capacity).

On Cloud, these design goals are no longer in competition: when capacity is available on demand and you pay for what you use, your cost tracks your capacity. We still have plenty of choices to make about how to optimise cost, but we don’t have to make choices which limit capacity ahead of time.

Security vs Innovation

We want to bring valuable new technology innovation into our organisations at speed, but we also want to make sure that our systems and services are secure. Every time we deploy new technology into our data centres, especially when that technology is very new, we increase our potential exposure to vulnerabilities. We often respond to that exposure by conducting additional security reviews, which slow things down or result in a flat ‘No’.

Cloud helps with this too, but differently to the way it helps with capacity. Increasingly, the companies that want to bring us innovative new solutions aren’t asking us to install new software in my data centre: they are asking us to access Cloud hosted solutions through APIs. We still need to determine whether those APIs are secure, and understand how any data which goes to the company is managed, but we are putting less new stuff into our data centres.

Resilience vs Speed

I’d love to say that the design goals of resilience (providing reliable services which rarely fail and recover quickly if they do) and speed (releasing new features and functions frequently) can be fully reconciled in my on-premise architecture: we have been following DevOps approaches for some time, and believe that small, frequent releases are safer than big, infrequent releases. However, releasing frequently with low risk and an easy back out path is often dependent on infrastructure flexibility which we don’t always have on-premise for our older applications: naturally, in these cases, we optimise for resilience rather than speed.

On Cloud, we can use the inherent flexibility of on-demand infrastructure to introduce new instances of infrastructure running new versions of my application, to withdraw them if the change doesn’t work, and to replace existing instances if it does.

Thought Still Needed

Cloud does not solve all of our problems: thoughtful design is still needed, and we still work to find smart ways to meet design goals on-premise. But Cloud does bring design goals which have traditionally conflicted into greater harmony, and as a design person, that makes me happy.