On cloud, cloud architecture, serverless and cloud native
Chapter XII. Where our protagonist looks at the world with a terrified amusement.
Slow but steady. Today’s best Band Ever is Blockhead. Instrumental hip hop, as paradoxical as it sounds, but storytelling is quite brilliant.
Difficulty: Hey, not too rough.
Anything in the news? Not much. Elon is musing about dangers from Artificial Intelligence, while completely missing that it will be the greed of the super rich that will be the end of the humanity, not the robots.
And it’s too quiet in Ukraine. Fewer dead defenders is good, but waiting is hard.
As Nintendo said: “Don’t forget to breathe”.
What is Cloud Architecture?
Last time I mentioned that, in my opinion, The Cloud is mostly stabilised and at least we know what it is. So I suspect, to answer what is cloud architecture, it’s better to start with:
What is Cloud?
Well, compute, storage and networking, one might say. But that describes two Raspberry PIs, sharing an SD card over a Wi-Fi connection.
For something to be a cloud it needs those obvious three, plus
You don’t manage it, just use.
You request resources ad-hoc, when they’re needed.
You don’t pay, when you don’t use.
In other words, a minimal cloud is Infrastructure as a Service (IaaS).
Those three points look simple, but require quite some work to implement. For instance, to allow the ad-hoc resource creation and destruction, the platform has to have complete CRUD API. It sounds obvious, but without the API, it’s not IaaS, but an old school VM hosting.
Add to that an IAM model and billing, and you can call yourself a cloud provider.
A mature cloud, of course, would have more features — availability zones and different regions, managed databases and other goodies, etc. PaaS and SaaS.
They’re nice but technically not required.
Conversely, if somebody offers PaaS or SaaS, but not IaaS, they’re not a cloud.
Let me sum up.
Cloud is IaaS, IAM and billing. Mature one adds locations, PaaS and SaaS on top of those.
Ok, so what is Cloud Architecture?
Cloud architecture is software architecture that utilises cloud capabilities.
No.
Cloud architecture is software architecture that correctly utilises cloud capabilities.
Mandatory XKCD
Just by doing something in the cloud doesn’t automatically make it a cloud solution. After all load balancing and pretty much anything else we do in the cloud, predate cloud.
It’s about how things are done to use the cloud effectively.
The ShapeUp framework from 37signals introduces an interesting concept of an Appetite. In short, it’s a measure or even a feeling of how much effort do you want to invest into a particular feature. People often talk about the minimal viable product and the Appetite is a way to measure whether something is an MVP and if it’s worth implementing.
Not every problem requires a hot multi-regional replica, and it’s the job of the cloud architect to identify what is the right level of complexity that solves a particular part of the architecture.
Interestingly, it’s not the Well Architected Framework that guides those decisions.
It all starts at the choice between IaaS, PaaS and Saas. Going low, is more work but offers more control and potential savings, going high is easier but more rigid and costlier.
Then one can dust off the WAF and use it as a checklist for what there’s an appetite for.
And this is very important. When one chooses an architectural block that is too high level and prevents use of lower levels of the cloud, it’s a potentially missed opportunity for cost saving and refactoring in the future.
Let’s have a look at Kubernetes’ little sibling, Docker Swarm (same argument will apply to a more complex K8s).
To run a swarm, one needs to run a control plane. A redundant cluster that uses Raft algorithm to elect a manager node. The job of the manager node is to create nodes and keep track of them in the cluster.
Redundant in this situation means at least three.
So there are at least 3 servers that are running for the duration of the cluster’s lifetime and even though they can also run tasks and services, their purpose is to occasionally run some management code and to maintain a consensus over a list of nodes.
If that sounds like a lambda function and a dynamo DB table, it’s exactly that. But both Swarm and K8s were designed with the idea that all one has is the naked data centre, and by using either of them, one automatically loses a bit of the flexibility a mature cloud can offer.
Don’t get me wrong, K8s is an excellent tool if you’re Google and have frequent planetwide deployments. Or you have to run everywhere (even if I think there’s a better way).
The higher one goes in [I P S]aaS stack, the faster they can deliver, but it comes at the higher cost of running and refactoring the solution.
It’s a wild guess, but I’m quite sure that refactoring K8s to use lambdas for control plane, would be a significant effort. Still, I’d love to see it happen.
Somewhat ironically, refactoring and continuos improvement is part of Well Architected Framework, but to be able to afford such refactoring, one has to invest in the upfront flexible architecture.
In a way, it’s kind of like the CAP theorem, in that you have to choose two out of the speed and cost of development, and refactorability.
So cloud architecture is all about finding the right balance of development and operational cost, as well as flexibility in future improvements. In other words
Cloud architecture is about the most efficient use of the cloud both today and tomorrow.
Serverless and cloud native
Serverless started with a clear definition:
Pay per use
High level management only (you don’t manage neither VM nor OS).
These days it’s lost and anything can be called serverless, which is quite a shame.
Equally, virtually everything is now cloud native, but if it’s not utilising cloud to the maximum, I’d rather not call it that.
In a way, cloud architecture is all about efficiency, cost optimisation and continuous improvement.
Take care and stop aggressors.
PS. This post is still stubbornly 100% GPT-free.
Good article.... again :-)
You wrote ".......... you have to run everywhere (even if I think there’s a better way)."
I'd love to hear what your better way is.
All the best
Patrice