One of the roles I see more and more in recent years is the Cloud Architect. This role is used by architects who deal mainly with cloud-based systems, as opposed to on-prem ones.
Since I myself work on a lot of cloud systems, I was trying to define for myself what is the real difference between Software Architect and Cloud Architect.
And I think I found it.
The Classic Architect
I’ve already covered the basic definition of a classic architect, what she should know and what she should to.
To add a little bit to that post – architect should be able to design a system that is fast, secure, reliable and easy to maintain based on functional and non-functional requirements.
This definition is timeless – it stood the test of time, and I’ve been using it for many years.
But what about cloud architect? Is it any different?
The Cloud Architect
I believe the answer is “Well, sort of…”.
The basic premise of the Cloud Architect is the same as Software Architect – design a system based on the requirements.
But there are two main differences:
- Puzzle Pieces
- Cost Analysis
Let me explain:
The cloud, any cloud, offers a huge amount of services. So much so that even a simple task like hosting a small web app can be performed using at least 3 alternatives (IaaS, PaaS, FaaS).
Now, when designing app for an on-prem environment, a decision about using an off-the-shelf product is influenced by the local IT support. For example, if the app requires a queue mechanism, but the IT cannot support it, then more often than not the queue will be implemented using the DB or distributed cache mechanisms such as Redis.
However, with the cloud this limitation does not apply. We’re not looking for IT support when exploring the tools and services the cloud offers us, and we’re free to use whatever we want.
And this makes the architect’s job a little bit harder, because it’s now her job to be familiar with all the cloud’s offerings. Suddenly, she cannot say that “We’re not going to use this and that tools because the IT can’t support it” and then base the architecture on one, maybe two, data store technologies. No, that won’t work in the cloud. Suddenly she has to be able to explain (to her and to the customer) which data store platform to use (and I’ll use Azure for examples in this post) – Azure SQL, Postgres, MySQL, Cosmos (with five models to choose from), Blob Storage, Redis and more.
And messaging – should we use Event Grid? Event Hub? Service Bus? Queue Storage?
Suddenly the spectrum of possible solution to a single challenge becomes extremely crowded, and it’s up to the architect to make an informed decision about it.
Or, on other words – the Cloud Architect must be familiar with all the puzzle’s pieces, and be able to put them all together.
In on-prem systems, the architect usually works in a given IT environment, consisting of X number of servers, specific DBs, network bandwidth and so on, and she should be able to work with it.
There is usually not a specific cost related to the architecture itself – the client already has the licenses and hardware (Or, in more formal wording – the CapEx is already done).
In the cloud, however, things are completely different.
Every decision, every feature, almost every configuration, will affect the budget.
Do you want the database to be replicated across continents? That’s fine, pay for it.
Do you need the disks to be SSD? Sure, but first show me the money.
Everything you do in the cloud will cost you.
And this must be factored into the architecture.
The way I deal with it – when I design a cloud-based architecture, I always include a “Projected Monthly Cost” section to the architecture document.
This is an extremely important section, and it prevents the “bill shock” so common in cloud’s first timers.
Including this section in your document will add real value to your clients, and will definitely make you a better, more valuable architect.