Aubrey Stearn, CTO of Digital Accelerator Platform at Nationwide Building Society, talks cloud-native benefits, risks and avoiding vendor lock-in ahead of her talk at The Cloud Migration Summit 2019 in London on May 14th 2019.
Cloud-native is a hot topic in the software development world. Some call it a fad, others call it the future of software development. Whatever side you are on, there is no doubt that cloud-native is currently one of the biggest trends, changing the way we think about developing, deploying and ultimately operate software products.
But what exactly is “cloud native”? We spoke with Aubrey Stearn, CTO of Digital Accelerator Platform at Nationwide Building Society, about cloud-native and the DevOps movement – which she believes redefines what we need to nurture and grow in our current and future engineers.
How did you get into Cloud Computing and DevOps? What keeps you in the field?
I started my career as a Network Engineer, but I’ve been writing code since the Commodore 64. I’ve switched between Ops and Dev a few times, though it’s always been a fluid movement for me. I love a challenge and solving new problems, but I’m not a huge fan of “the maintenance cycle” things traditionally have, a persistent engine of change is way more interesting.
How would you define ‘Cloud Native’?
‘Cloud Native’ is something a lot of people would describe as being ‘container centric’, however there is a risk of forgetting technology such as ‘serverless’, also known as ‘functions as a service’. Personally, I think Cloud Native Engineering focuses on scale and resilience over anything else, inherently when you focus on those two elements you end up with things like microservice architectures and a shift to observability from monitoring.
Why is designing Cloud Native Apps and Architectures tricky? What are the risks associated with transforming and reengineering legacy systems to Cloud Native?
I think the biggest challenge you have with going Cloud Native is ‘people vs technology’ - when you’re moving from on-premises, you’ve maybe got a run organisation and the build organisation, where build will handover to run and generally let something fester away until it’s transformation time again.
People are used to owning silos of things and control is generally very important to them. Whereas in a Cloud Native world, we focus heavily on the federation of trust by leveraging controls and guard rails. For example, in the old world, group security may run through a security checklist and look for publicly exposed S3 buckets with someone before going live, in the new world we would just ensure that something like AWS Config has a rule denying any publicly exposed S3 buckets etc.
I’ve seen some pretty tell-tale designs in my time, one of them I mentioned my feature in the book ‘Epic Failures in DevSecOps’ where something that was obviously an on-premises design, with elements of fail-overs, just popped into a cloud. Clearly, you’re not going to get much benefit out of the cloud by doing a lift and shift.
It’s a significant change in engineering capability, we use the phrase as-code quite frequently, but to a developer that also means testing your code like you would with an application. S3 has so many .9’s of availability, it’s considered durable enough to be your backup rather than something you need to back up.
How can these risks you mention be avoided?
On legacy risks, re-engineering legacy applications for cloud can be a significant challenge without the right people or the right support. If something is monolithic, and doesn’t already lend itself to a microservice architecture, you will need to apply something like the strangler pattern and maybe take a hybrid approach to breaking out to the cloud. Fortunately, even for a bank like Nationwide, things like AWS Direct Connect and Azure Express Route make things like that much easier in terms of connective. The trick again is to not do too much, think about how to eat the elephant and don’t go too fast, break functionality or journeys off the old thing and shim traffic to the new thing.
What are 3 major advantages of cloud native?
Speed from dev to release, quality behaviour driven from the left to the right and cost efficiency.
When would you ‘lift & shift’ apps to the cloud vs rewrite cloud native apps?
I think usually it’s a financial call, if something is going to stick around for a while and you must keep it on life support, that’s different to sticking around and having to write new features, that’s where you need to eat the elephant and start rewriting things to be more cloud native. Of course, some things are so old they can’t be containerised, you have to plan for either EoL, custom support agreements or rewriting.
What are the risks associated with writing cloud native apps and vendor lock-in? Is this something developers should be worried about?
If you want full advantage of the cloud, you will need to go all in. There is a fantasy of multi-cloud that is frequently peddled which reminds me of the emperor’s new clothes, of course you could balance or schedule workloads between Azure and AWS, no worries, but what have you achieved with distributed compute if your services are all in on a specific cloud. There is such a small number of things that would be suitable to multi-cloud, you’re better of defining an exit strategy rather than trying to abstract functionality and getting little benefit and high maintain costs from your shim.
Meet Aubrey at the inaugural Strategic Cloud Migration Summit on May 14th 2019 in London. She will be on a panel discussing ‘Cloud Native: Advantages, Challenges & Learning Points From The Front Line’ with Tom Clark, Head of Common Platform at ITV, and Leo Mindel, Founder & Owner of Sotic Ltd. Don’t miss out on your ticket - register online now.