I still remember how lost I felt during the first few months of starting my Cloud FinOps journey. I was learning about AWS and their plethora of services (which, by the way, it continues to expand). Understanding the basic pricing models - in most cases - was fine, but I quickly realised that that won’t cut it for me. There is only so much you can achieve by knowing that you can buy reservations and change storage tiers. To me, the real power of FinOps would derive from decisions that would directly affect how systems are built.
But to get to that point, first I needed to understand what those components are and how they work together. And that’s what I will try to cover in this two-part post. First I will try to give a general overview of the basic components of a software (also known as the services that cloud providers offer), and from then build up to discussing Software Architecture (or how those components interact with each other). I don’t expect this to be a fully comprehensive guide, not even a fully accurate one to be honest. Instead, it’s just a way to ease our way into the depths of IT and add some context to those ‘free’ courses that cloud service providers offer (and that you will likely be consuming when trying to get certified).
Let’s get started with what - I will guess - are the three main expenditures in your cloud bill; Compute, Database and Storage. And, just for fun, I’ll try to explain these with an analogy to what we are more comfortable with: Excel. I know it sounds weird, but bear with me and picture the following scenario: suppose that you work in a company where the only business application you use is Excel (the web-browser version of it). You come in every day, launch that piece of software and work on it until it’s time to go home. Dreamy. One day, someone comes in and says ‘hey, running Excel costs us too much money, go find a way to make it cheaper’ because, after all, you are the cost accountant, aren’t you?.
Compute
So, now you are on a mission and committed to understand what are the different elements to make ‘running Excel’ possible. In the old days, that was easy. Excel would have been installed in your computer and everything Excel needed to run would have been contained within that tall - and noisy - cabinet under your desk. (keep that in mind, we will come back to it). But now things have changed. You probably just have a laptop in which you open your web browser, login and fire up Excel from there. There is - you have heard - an IT department responsible for this app so you decide to go have a chat with them.
While chatting to IT you begin to understand a few things. Excel is still running on some computer in ‘the cloud’, and, by the way, it’s not called computer, it’s just compute or virtual machine. This is our first cloud service. Compute is not other than a virtual machine located in a datacentre administered by a big company like AWS, Google, Microsoft, etc. Being a Virtual Machine means that they use software to carve out a small piece of the big hardware and ‘make it look’ like a smaller server that you have access to (which you can even do with your own laptop by the way, just download VMware). So, differently to what your old computer would have done, where it served multiple purposes, it’s likely that that compute has only one purpose: in this case, run the code for the ‘Excel’ app.
Same as you would choose a laptop for yourself, developers will get these compute units by defining the CPU, RAM (memory) and Storage (disk size) they need. Further down the line, you can have a conversation about whether or not they have chosen the right ‘size’ of compute and whether or not you can save some money by rightsizing (meaning trying to better match your compute power with your technical needs).
That virtualisation that I was describing before can happen at two levels. Virtual machines are a virtualisation at a hardware level where you can do with the virtual hardware whatever you want. Containers are a virtualisation at an Operative System (OS) level, meaning that you now are limited to a specific OS kernel.
Functions are also a type of virtualized compute which is, technically, at a hardware level, but the only thing you care for is the code that needs to run (your cloud provider will define the compute requirements they need to run it). However, in this case it gets a bit more complex -or abstract- than that. In this service, everything is not only virtual but also ephemeral. Meaning that your provider will be creating and destroying the (virtual) compute resources every time the code runs.
But, what does virtualisation mean exactly? In its most basic form, virtualisation means that you divide a big piece of hardware or software into smaller chunks to be consumed independently. It would be something like grabbing your laptop that has 4 cores processor, 8GB of RAM and 1TB of disk space and split it in half so you and your friend can use it independently at the same time without affecting each other's performance. And you can do that at a hardware level, if you are a Windows fan and your friend is a Linux fan, or at an OS level, in which case you will both have the same OS. If you were using computers in the 90's, you may have done some virtualisation yourself, for example, to create multiple partitions of your hard disk in your ‘My PC’.
Storage
The second most commonly used cloud service, I dare say, is storage. Continuing with the Excel analogy, back in the day you probably used various types of storage for different purposes. Your hard disk stored your daily data. You had a memory stick to carry files around. If you were organized, you might have used an external drive for backups — just in case — and sometimes you even burned CDs to preserve files or share them. And yes, data could also be stored on tapes — still considered by some the most secure, durable, and cost-effective option for long-term archival.
In the same way, Cloud Providers will bombard you with loads of Storage services and tiers to meet your needs. As mentioned before, virtual machines have a storage disk attached — mimicking your hard disk — and technically, that disk is its own cloud service. That’s a good thing. It will allow you for great flexibility were you can - virtually - detach a disk from one Virtual Machine and attach it to a different one, or you can simply leave it unattached if you want to keep it for whatever reason (don´t do that as a backup tho, there are more efficient ways).
You can back up these disks using snapshots, which you can later use to restore data. Just remember to configure lifecycle policies. Unlike your old external drive, where you reuse the same device, each snapshot in the cloud counts as a new storage item — and you’ll be charged for it unless you define how long to retain them. Lifecycle policies automate the creation, retention, and deletion of snapshots to control costs.
💡If your organization is new to FinOps, you might be surprised by how many quick wins are out there. Checking for lifecycle configurations is an easy one. Many teams forget to create these rules, leading to unnecessary storage costs.
Another storage option is file systems. That term may remind you of your personal computer’s file system — My Documents, Images, etc. — and you’d be partially right. A file system is how the operating system organizes and stores data. Sometimes this is personal, but often it’s shared across users. If you’ve worked in an office, you’ve likely seen a “central” file system everyone could access. Similarly, virtual machines and the apps they run often need shared file storage — that’s why this service exists. What's the underlying technology, you wonder. To be honest, it’s a bit hard to get your head around but in simple terms, File Systems run on Solid State Drives (SSD) - think of a super fast hard disk -, but these hardware is optimized for network usage and sharing with a Protocol called Network File System (NFS).
If you are looking for a more loose kind of storage, somewhere where you can just drop files in to be kept, so something like your old memory stick let’s say, then you would probably resource to what is now called an ‘object storage'. These are more cost efficient than the virtual hard disks, and are meant to be used for unstructured data (so, basically random files of any kind, including backups). Cost wise, it would be good for you to understand how frequently you are going to need and access these files as this kind of storage charges you (at a high level) based on size (how much you store) and request (a charge for every time you open a file). Files (or objects as they may be referred to) that you are meant to be kept for long time but hardly ever access them are good candidates for “cold” storage were the price per GB will be low but the access request charge will be high (it will also take longer to retrieve by the way, performance is part of the equation too). Alternatively, “hot” objects will pay more per GB, but the access request would be immediate and less expensive.
Lifecycle policies are also a thing here, and also highly advised to have them configured. But along with that, you can also configure certain guardrails for the objects kept in this service. Things like versioning, encryption, immutability and external access are all options that you want to learn, understand and implement to match your use cases and avoid regrets further down the line.
Databases
The last basic component that you need to understand going into the world of IT & Cloud are Databases. And, let me be honest, it took me a long time to get the gist of it. Back when I was in school I learnt about Ms. Access as a database service and that probably confused me going into IT many years later. Up until that point, I thought that databases were just a piece of software to make very sophisticated and hard to use spreadsheets. It turns out there is more nuance to it. Databases are their own system, optimised to store structured data. Further above I referred to “unstructured data” as a combination of random files or things that don't have a specific order or structure. Structured data, on the other hand, will follow a schema of data (table) that will not change. Think of your spreadsheet where you keep a record of all customers you have. For each of them you will have the same information (name, phone number, address, etc). That is your schema.
For small volumes of data, a manual, single spreadsheet will do the trick. But if you are a large organization, with thousands of transactions per second and multiple integrations with other systems, you are not going to pay a team of analysts to add records manually to your spreadsheet (and copy them to other systems). Instead, you will have a dedicated system to keep these records that also has a programmatic way to access the data for integrations, enter Databases. That, at least to me, was the easy part to understand. What took me an embarrassing long time to figure out was that, in the end, databases are complex systems that run on VMs and manage storage, memory, and queries efficiently — almost like a mini operating system for data.
At this point, hopefully, you are starting to think: if databases run on virtual machines, then what's the difference with Compute? Great question. The answer is: none. You can -and many companies do- get a virtual machine and install your own database engine on it for you and your services to use. So what we see -and pay for- here is just a service, rather than a piece of technology. Both compute and databases will run on the same underlying technology, but it will depend on how much you want to outsource the maintenance of the database to choose the right service for you. If you just want to -or have capacity to- only look after the data and integrations of your database, then maybe a (managed) Database Service is more suitable to you than a Virtual Machine with a Database engine installation.
Closing Thoughts
If you have made it to this section of the post then first and foremost: thank you!, but also, what does all of the above mean for us?. What we see here is the distinction between hardware and software. You see, there is only so much hardware you need for computers to run. At risk of over-simplifying this, besides a storage unit, a CPU, and a Network card, what else is there? Not much, I believe. So where do all those thousands of Cloud Services come from? Well, software of course.
Most of the things we run on the cloud will be some Compute with a specialized software (which in many cases is Open Source that you can use for free) that serves a specific purpose. Load balancers? a compute with software that distributes loads to other machines running applications. Firewalls? another compute with software that analyzes and blocks certain network traffic based on IP tables. Cold storage? a disk somewhere keeping data. And the list goes on and on.
Why is this distinction important? It depends on the stage and maturity of your business and what trade-offs you are willing to make. If you are a startup, with a handful of highly motivated and resourceful employees, you may not have the capacity to manage every single system yourself. You may then decide to leverage as many managed services as possible. As you grow you may decide that it is more cost efficient, secure or compliant to dedicate internal personnel to run and maintain your own databases, search clusters, etc.
Or, it may also be a question of speed and time-to-market. We are at a time where innovation is a competitive advantage and if you are not leading that race then the next best thing you can do is catch up with it as soon as you can. Think of it this way: in 2025, if you are not OpenAI, then your next best option is to be using AWS Bedrock, GCP Vertex, etc to be able to offer GPT services to your clients.
Comments
Post a Comment