WTF is Cloud Native? Even the experts don't completely agree. To help us unpack this sprawling topic, WTF is launching a series in which we ask some of the industry's thought leaders three key questions:
- What the f*#k is Cloud Native?
- What is Cloud Native's biggest problem?
- What is Cloud Native's secret superpower?
First up: tech ethicist Anne Currie, microservices guru Sam Newman, and the Financial Times' s Cloud Native pioneer Sarah Wells. Here's what they had to say.
Anne Currie
Hard science fiction author,
Tech Ethicist, Container Solutions
Sam Newman
Consultant, author of Monolith to Microservices
Sarah Wells,
Tech Director for Operations and Reliability, Financial Times
WTF is Cloud Native?
It's about building systems that benefit from the cloud rather than just running on it.
You can move to the cloud by just taking your monolith and running on EC2, and you get some benefit—AWS now does a lot of the work for you around provisioning, configuring, patching, etc., of the infrastructure. And you can scale up or down very easily to meet demand.
But once you are in the cloud, you can change the way you architect your systems—so you can use microservices, deploy in containers, adopt Continuous Delivery and DevOps, and change from 12 releases a year to thousands (I know, because the Financial Times has done that).
Or you can use serverless tech like Lambda to abstract away even more of the underlying infrastructure.
And you can use the queues and data stores that your cloud provider offers, rather than maintaining your own database clusters.
Generally what you want to be doing is concentrating your efforts on business value, and passing on as much as possible of the legwork of building and supporting your platform to other people.
What’s the biggest problem with Cloud Native?
The big change for me when we moved to the cloud and started building microservices etc. is that, suddenly, writing code was taking up less than 50% of my time as a developer, The rest was spent on building and running our systems. That's largely because we no longer had a separate infrastructure team doing that. But it's also because, as early adopters, you are dealing with things that are still a bit rough 'round the edges.
For example, we started using containers before there was much good tooling around them. We built our own cluster orchestration!
It's tough to expect developers to know the full breadth of stuff they may have to tackle. At the moment, the best options seem to be having a core platform team that builds the layer between your cloud provider and your developers, or opting for a PaaS, something like Heroku (used quite heavily at the FT).
I'm hoping that, over time, things will get tidied up and abstracted away, to the point where as a developer, you don't have to spend much time thinking about the underlying deployment platform.
What’s Cloud Native’s underrated superpower?
I feel like it's much easier to attribute costs, and to work out the total cost of building and running a system—to help identify whether it is worth continuing to invest in it, for example. We're starting to look at that at the FT, but we still have lots of things where the cost is held centrally rather than allocated across systems. But the way things get built in Cloud Native, this stuff is a lot easier to track.
Previous article
