Forem: Mahmud Seidu Babatunde

Production-Ready Azure File Share Setup: Snapshots for Backup and Restricted Network Access

Mahmud Seidu Babatunde — Tue, 14 Apr 2026 18:09:35 +0000

At exactly 9:42 AM, I got a message I’ve seen too many times:

“Please… I think I just deleted the finance report.”

Three weeks of teamwork gone in seconds.

No recycle bin, no undo button, report is gone.

The finance team was already preparing for a review meeting. That file wasn’t optional; it was everything.

And in that moment, you realize something:

It’s not about storage.
It’s about what happens when things go wrong.

Luckily, this wasn’t luck.

This was design.

Let me show you exactly how I built a system where mistakes don’t become disasters and how you can do the same.

Before we go hands-on, let’s break down a few key terms (in plain English):

Storage Account → Your cloud “hard drive” where everything lives.
Azure Files → A shared folder in the cloud that multiple people can access.
File Share → The main folder everyone connects to.
Directory → Subfolders to keep things organized (like “Finance”).
Snapshots → Backup copies of your data at a specific moment in time.
Virtual Network (VNet) → Your private, secure space in Azure.
Subnet → A smaller section inside your network.
Zone-redundant storage (ZRS) → Keeps copies of your data in different locations so you don’t lose it.

Now that you understand the “why,” let’s build the “how.”

Step 1: Creating the Foundation (Storage Account)

We start by creating the backbone of everything: our storage account.

In the Azure portal:

Search for Storage accounts
Click + Create

We create one for the finance team:

Resource Group — Your Project Container

A Resource Group is simply a logical container for your resources.

Naming the Storage Account

This must be globally unique (Azure requirement).

Performance Matters

Set performance to Premium.

Why? Because finance workloads need:

Low latency
High reliability

Account Type

We choose file shares because we’re building a shared file system—not blob storage.

Data Protection (Redundancy)

Set to Zone-redundant storage (ZRS).

This ensures:

Your data exists in multiple physical locations
Even if one zone fails, your data survives

Deploy

Review and create.

Wait for deployment, then go to the resource.

Step 2: Creating a Shared Space for the Corporate Office

Now we create a File Share—this is where collaboration happens.

Inside the storage account:

Go to File shares
Click + File share

Provide a name and create:

Step 3: Organizing with Directories

Now we create a finance directory.

Why? Because structure matters.

Navigate into it:

You can keep nesting directories:

Upload a test file:

Step 4: The Mistake (Why Snapshots Matter)

Here’s where reality hits.

Someone deletes a file.

No backup. No recovery.

This is where Snapshots save the day.

Creating a Snapshot

Snapshots are point-in-time backups.

Add snapshot:

Verify contents:

Step 5: Simulating Disaster (File Deletion)

Let’s delete the file:

Step 6: Recovery (The Hero Moment)

Go back to snapshot:

Restore the file:

And just like that…

Crisis avoided. Finance team happy. Reputation intact.

Step 7: Locking Down Access (Security First)

Now we enforce controlled access using a Virtual Network.

Create Virtual Network

Deploy it:

Go to resource:

Configure Subnet

Select default subnet:

Enable Microsoft.Storage service endpoint:

Restrict Storage Access

Now we allow access only from our VNet.

Add the virtual network:

Now:

No public access
Only trusted network traffic
Finance data stays protected

Everything Was Working: The Hidden Cloud Mistake That Exposed My Database and Taught Me Why VNets Matter

Mahmud Seidu Babatunde — Mon, 13 Apr 2026 13:26:56 +0000

My app worked perfectly… until I discovered my database was open to the entire internet.

Everything was working. The application was live, users could sign up, and data was being stored without any issues. From the outside, it looked like success. But behind the scenes, it was a disaster waiting to happen.

The system itself was simple: a web application running on a Virtual Machine, a backend API handling requests, and a database storing user information. Everything deployed smoothly. There were no errors, no warnings—just a working system.

Like many beginners, I assumed that if it worked, then it was fine. That assumption turned out to be dangerously wrong.

What I didn’t realize at the time was that my database was exposed to the internet. There were no restrictions, no isolation, and no protection. It was simply sitting there, reachable by anyone who knew where to look.

It didn’t take long before something did.

An automated bot scanning the internet found the open port. There was no sophisticated attack involved—just a simple scan. It connected without resistance.

At that moment, everything was already compromised. User data, emails, and passwords were all accessible. There were no alarms, no warnings, and nothing visibly broke. The application kept running as if nothing had happened, but the damage was already done.

That’s when it hit me—the problem wasn’t my code or my deployment. It was my network.

I had focused on building the application, but I completely overlooked the environment it lived in. Everything was public and exposed. In the real world, that’s not just a mistake, it’s an invitation to attackers.

The system should have been structured differently. The web app could remain public, but the API should have had controlled access, and the database should have been completely private. Only the application should communicate with the database, not the internet.

This is exactly where Virtual Networks (VNets) come in. A VNet creates a private space in the cloud where you control what is exposed and what remains hidden. It allows you to define who can access your resources and how they interact. Without it, you’re essentially leaving your infrastructure open.

The truth is, systems don’t get compromised because they are complex. They get compromised because something was left open.

DevOps is not just about making things work; it’s about making sure they are secure and resilient. Virtual Machines run your applications, but Virtual Networks protect them. Without proper network isolation, you’re not building systems—you’re exposing them.

If I Already Have a Laptop, Why Do I Need a Virtual Machine? (The Question That Changed My Understanding of Cloud)

Mahmud Seidu Babatunde — Sat, 11 Apr 2026 20:40:45 +0000

I remember sitting in front of my screen, staring at Azure, trying to make sense of it all.

Virtual Machines?
Servers?
Cloud infrastructure?

At the time, I only knew that a Virtual Machine was basically a computer running in the cloud, something I could create, start, and connect to, just like a real computer.

And then a question hit me, one that didn’t feel “technical” at all:

If a Virtual Machine is just another computer built virtually…
why do I even need it?

Because think about it.

Every single person accessing a Virtual Machine is doing so from a physical laptop.
A real device.
Something that already works.

So why introduce another “computer” on top of that?

Why not just use the laptop we already have?

And more importantly…

Why would I start paying for something that looks like what I already own?

That question bothered me for a while.

Not because I couldn’t create a VM, but because I didn’t understand why it truly mattered.

Then it clicked.

My laptop was never designed to serve others.

It was designed to serve me.

The moment I build something that needs to be accessed by someone else, a website, an API (An API is a way for applications to communicate), even a simple app, my laptop becomes a limitation.

It can go off.
It can disconnect.
It can fail.

And the moment it does, everything I’ve built disappears with it.

That’s when the idea of a server started to make sense.

Not just as a concept, but as a necessity.

A server, in simple terms, is just a computer designed to respond to requests from other people’s devices over the internet.

A machine that is always on.
Always reachable.
Not tied to my physical presence.

And that’s exactly what a Virtual Machine gives me.

Not just “another computer”
But a computer that exists beyond me.

One that anyone can reach, at any time, from anywhere.

Think about watching a movie on Netflix or a video on YouTube.

You press play, and within seconds, the video starts.

Now imagine if that video was being streamed from someone’s personal laptop.

Halfway through the movie, their laptop battery dies.
Or they close the lid.
Or their internet disconnects.

Your movie stops immediately.

That would be frustrating.

But that’s exactly what would happen if real-world applications depended on personal machines.

Instead, these platforms run on servers that are always on, always connected, and designed to handle thousands, even millions of users at the same time.

And in today’s world, those servers are often Virtual Machines running in the cloud.

That’s when I stopped seeing VMs as an extra cost.

And started seeing them as the foundation of anything that needs to live on the internet.

Because the real question was never:

“Why do I need a Virtual Machine if I already have a laptop?”

The real question was:

“Can my laptop truly support what I’m trying to build for the world?”

And for the first time, the answer was clear.

No, it can’t.

A Practical Guide to Azure Architectural Components in Real-World System Design

Mahmud Seidu Babatunde — Fri, 10 Apr 2026 03:14:31 +0000

I used to think Azure was just cloud storage until I tried to build something real

A few weeks ago, I decided to deploy a simple application on Azure.

Nothing fancy. Just something small.

But the moment I opened the Azure portal, I froze.

I kept seeing terms like Region, Resource Group, Subscription, and Availability Zone.

And I asked myself

Why is this so complicated for just deploying an app?

Then it clicked.

Azure is not complicated. I was just looking at it the wrong way.

I started thinking of Azure like building a city

If you want to build a house, you do not just drop it anywhere randomly.

You think about where the city is located, how reliable the infrastructure is, how everything is organized, and who has access to what.

That is exactly what Azure architectural components are.

First, where is your app living? Region

This is the geographical location of your application.

Choosing a region close to your users improves performance and reduces latency.

Then, what if one datacenter fails? Availability Zones

Azure provides multiple isolated datacenters within a region.

If one fails, your application continues running in another.

What if the entire region fails? Region Pairs

Azure pairs regions together for disaster recovery.

This ensures your system can recover from large scale outages.

How do you organize everything? Resource Groups

Instead of scattering resources everywhere, you group them logically.

Your virtual machines, databases, and storage can all live inside one resource group.

Who is responsible for billing and control? Subscription

Every resource you create lives inside a subscription.

It defines billing, access, and usage limits.

Who can access your system? RBAC

Not everyone should have full control.

Azure allows you to define who can view, deploy, or manage resources.

How do you deploy consistently? Azure Resource Manager

Instead of manually clicking through the portal, you define your infrastructure as code.

This allows you to deploy reliably and repeatedly.

How do you enforce rules? Azure Policies

You can enforce standards such as restricting regions or requiring proper tagging.

This helps maintain governance across your environment.

What I learned

The biggest mistake I made was thinking Azure is just where my application runs.

In reality, Azure is a structured system designed to make applications scalable, secure, and resilient.

Now when I build, I do not just deploy an application.

I think about availability, organization, security, and scalability.

If you are just starting with Azure and feeling overwhelmed, you are not alone.

You simply have not seen the full picture yet.

When “Private” Files Leak: How I Fixed a Silent Azure Storage Misconfiguration

Mahmud Seidu Babatunde — Wed, 18 Mar 2026 02:31:27 +0000

Most storage failures aren’t caused by hackers, they’re caused by small configuration decisions engineers overlook.

A few years ago, a company accidentally exposed internal documents to the public.

Not because of a breach.
Not because of an attack.

But because of a simple misconfiguration.

Files that were meant to be private became publicly accessible through a URL.

No authentication. No restriction.

Just access.

That’s the reality of cloud systems.

Security failures are rarely loud, they are quiet, and often invisible until it’s too late.

This isn’t just a lab exercise, this is the same type of design decision engineers make in real systems where data must remain secure, available, and controlled.

In this article, I’ll walk through how I built a secure, highly available Azure Storage system for private company documents, and more importantly:

why each configuration matters.

The Problem Engineers Actually Solve

When dealing with internal company data, engineers are not just thinking:

“Where do I store files?”

They are thinking:

What happens if a region fails?
How do I prevent public exposure?
How do I share files securely and temporarily?
How do I reduce storage costs over time?
How do I ensure backups exist automatically?

This is what turns storage into architecture.

Key Concepts You Must Understand First

Storage Account

A storage account is the foundation of Azure storage. All files (blobs) live inside it.

High Availability

Systems must continue running even when failures occur. In cloud systems, failure is expected.

Geo-Redundant Storage (GRS)

GRS replicates your data to another region. If one region fails, your data still exists elsewhere.

Private Access

Private access ensures:

no anonymous access
no public exposure
only authorized users can access data

Thinking Like a Cloud Architect

Before building anything, I asked:

How do I survive regional failure?
How do I enforce strict privacy?
How do I allow temporary access securely?
How do I automate cost and backup?

Everything below answers those questions.

Step 1 — Create the Storage Account

In the portal, search for and select Storage accounts.

Select + Create.

Select the resource group created in the previous lab.

Set the storage account name to private and ensure it is unique.

Select Review, then Create.

Wait for deployment and select Go to resource.

Step 2 — Configure High Availability

This storage requires high availability if there’s a regional outage.

In the storage account, in the Data management section, select the Redundancy blade.

Ensure Geo-redundant storage (GRS) is selected.

Refresh the page.

Review the primary and secondary location information.

Save your changes.

Trade-off: Why GRS Instead of RA-GRS?

RA-GRS allows read access from the secondary region.

However:

this is internal storage
read failover is not required
cost optimization matters

GRS provides redundancy without unnecessary cost.

Good engineering is about choosing the right tool — not the biggest one.

Step 3 — Create a Private Container

In the storage account, in the Data storage section, select the Containers blade.

Select + Container.

Ensure the name is private.

Ensure access level is Private (no anonymous access)
Select OK and Create.

Step 4 — Upload and Verify Access Restriction

Upload a file and test access.

Expected result:

❌ File should NOT open
❌ Browser should return an error

The above confirms your storage is secure.

Step 5 — Configure Secure Temporary Access (SAS)

Select your uploaded file and navigate to Generate SAS.

Set permissions to Read only.

Set expiry to 24 hours.

Generate SAS URL.

Test access.

SAS allows:

temporary access
controlled permissions
secure sharing

Step 6 — Configure Lifecycle Management (Cost Optimization)

Return to storage account.

Notice default tier is Hot.

Navigate to Lifecycle management.

Select Add rule.

Set rule name to movetocool.

Apply to all blobs and select Next.

Set condition: 30 days → Move to Cool tier.

Step 7 — Configure Backup with Object Replication

Create backup container.

Navigate to Object replication and create rule.

Set destination storage.

Map containers.

Lessons From This Implementation

• Security must be intentional
• Private access should always be default
• Temporary access must be controlled
• Cost optimization should be automated
• Backup should never be manual

Final Thoughts

Cloud systems rarely fail because of missing features.

They fail because of poor configuration decisions.

A storage system can either:

expose sensitive data
lose critical files
or fail silently

Or it can be:

secure
resilient
intentional

The difference is not the tool.

It is the engineer!

Why Website Images Sometimes Fail to Load — And How I Built a Highly Available Azure Storage Backend to Fix It

Mahmud Seidu Babatunde — Sat, 14 Mar 2026 11:19:22 +0000

A few months ago, I opened an online store to check the specifications of a device I wanted to buy.

The page loaded.

The navigation bar appeared.
The product description was visible.
But the product image never showed up.

Instead, there was a small broken-image icon sitting where the picture should have been.

If you’ve ever experienced that moment, you know exactly what happens next.

You refresh the page.

Nothing changes.

And suddenly you begin to wonder:

Is the website broken?
Is the product unavailable?
Is the platform unreliable?

What most users never realize is that a broken image on a website usually isn’t about the website itself.

It’s almost always about where the file is stored and how the storage system is designed.

Behind every image, downloadable document, and product asset is a storage system responsible for delivering those files instantly.

If that storage system is poorly configured, small things begin to fail:

images disappear
downloads stop working
documentation links break
websites feel unreliable

Modern cloud platforms solve this using distributed storage infrastructure.

In Microsoft Azure, one of the core services used for this purpose is Azure Blob Storage.

But simply creating a storage account isn’t enough.

Engineers must think about deeper questions:

What happens if an entire Azure region fails?
How can users access files without authentication?
What if someone accidentally deletes important files?
How do we keep track of document updates?

To explore these questions, I built a high-availability storage architecture for a public website using Azure Storage.

The goal was simple:

Create a system that can:

survive regional outages
serve public website assets
allow anonymous file access
recover deleted files
maintain file version history

Let’s walk through how that system was designed.

The Problem Engineers Face

Imagine running an e-commerce website where thousands of customers view product images every day.

Everything works perfectly until one day an Azure region experiences an outage.

Suddenly:

product images stop loading
downloadable files fail
customer experience breaks

The website itself may still be online.

But the storage system serving those files is unavailable.

This is why cloud engineers design storage systems not just to store files, but to ensure they remain available, recoverable, and resilient.

Azure Storage provides several mechanisms to solve these challenges.

Before implementing the solution, I will helps to understand a few important concepts.

Key Concepts Behind Azure Storage

Azure Storage Account

An Azure Storage Account is the top-level container that holds all storage services.

Inside a storage account you can store:

blobs (files, images, documents)
file shares
tables
queues

For public websites, Blob Storage is typically used to store static assets like images and downloadable files.

High Availability

High availability means designing systems that continue operating even when failures occur.

Failures in cloud infrastructure are expected.

Servers fail.
Networks fail.
Entire regions can fail.

High availability ensures systems remain accessible despite those failures.

Geo-Redundant Storage

Azure provides multiple redundancy options.

One of the most resilient is Read-Access Geo-Redundant Storage (RA-GRS).

This configuration:

replicates data to another Azure region
stores multiple copies of data
allows read access from the secondary region

If the primary region fails, the secondary region can still serve requests.

Thinking Like a Cloud Architect

When designing storage for a public website, engineers typically ask four important questions:

What happens if an entire region fails?
Can users access files without authentication?
What if someone accidentally deletes files?
How can we track document updates over time?

Azure Storage provides solutions for each of these challenges:

Geo-redundancy protects against regional outages
Anonymous blob access allows public content delivery
Soft delete enables file recovery
Blob versioning keeps historical file versions

The following implementation combines these capabilities to build a resilient storage backend.

Create a Storage Account With High Availability

Create a storage account to support the public website

In the Azure portal, search for and select Storage accounts.

Select + Create.

For resource group select New, give your resource group a name, and select OK.

Set the storage account name to publicwebsite and add a unique identifier.

Take the default settings for the remaining configuration.

Select Review + Create, then Create.

Wait for deployment and select Go to resource.

Configure High Availability

This storage must remain accessible if a regional outage occurs.

Navigate to Data management → Redundancy.

Select Read-access Geo-redundant storage (RA-GRS).

Review the primary and secondary region information.

This ensures your website assets remain accessible even if the primary region experiences downtime.

Allow Anonymous Access for Public Files

Public website content should be accessible without requiring users to log in.

Navigate to Settings → Configuration.

Enable Allow blob anonymous access.

Save the configuration.

Create a Container for Website Files

Navigate to Data storage → Containers.

Select + Container.

Name the container public and Create.

Configure Anonymous Read Access

Select your container.

Change the access level to:

Blob (anonymous read access for blobs only).

Select OK.

Upload and Test Files

Select Upload.

Choose a file.

Upload the file.

Refresh the container to confirm the file appears.

Copy the file URL and test it in a browser.

Example URL:

https://publicwebsiteproject.blob.core.windows.net/publicc/image.png

Configure Blob Soft Delete

Navigate to the Overview page.

Locate the Blob service section.

Select Blob soft delete.

Enable soft delete.

Set retention to 21 days.

Save the changes.

Restore Deleted Files

Delete a file.

Confirm deletion.

Enable Show deleted blobs.

Restore using Undelete.

Enable Blob Versioning

Navigate to Blob service → Versioning.

Enable versioning.

Save the configuration.

Lessons From This Implementation

Several key lessons stood out while building this storage architecture.

• High availability must be intentional.
• Public access should be carefully controlled.
• Data protection features like soft delete and versioning are essential.
• Testing configurations ensures your infrastructure behaves as expected.

These small architectural decisions are what transform basic cloud setups into production-ready systems.

Final Thoughts

Creating cloud resources is easy.

Designing them responsibly is what defines engineering maturity.

In this implementation we built a storage architecture capable of:

serving public website assets
remaining available during regional outages
allowing secure anonymous access
protecting files from accidental deletion
maintaining historical file versions

Behind every reliable digital experience is infrastructure configured with intention.

And mastering these fundamentals is how engineers move from using cloud tools to designing resilient cloud systems.

A Practical Guide to Securing Azure Storage Accounts in Dev/Test (With Real-World Context)

Mahmud Seidu Babatunde — Tue, 03 Mar 2026 06:33:39 +0000

Behind Every Streamed Movie and Processed Payment Is Secure Cloud Storage.

When you stream a movie on Netflix, process a payment with Flutterwave, or order a product on Jumia, you rarely think about storage.

You just expect it to work.

Your payment confirmation appears instantly.
Your playlist loads without delay.
Your order history is always available.

But behind that simplicity is something quietly powering every interaction:

Cloud storage — carefully designed, configured, and secured.

Companies like Netflix, Shopify, Spotify, Flutterwave, Paystack, Jumia, and digital banking platforms across Africa rely heavily on distributed cloud storage systems to:

Store application data
Maintain financial transaction records
Preserve logs and audit trails
Scale across regions
Enforce encryption and compliance standards

And here’s what matters:

Their storage systems are not secure by accident.

They are configured intentionally.

A single misconfigured storage account can expose sensitive data.
A legacy TLS setting can weaken encrypted communication.
An overly permissive network rule can expand an attack surface.

Security in cloud environments lives in the configuration details.

As part of my Azure storage implementation practice, I provisioned and hardened a storage account designed for a non-production workload.

The objective was simple:

Maintain cost efficiency while enforcing real-world security discipline.

This walkthrough documents not just the steps I took, but the reasoning behind each configuration decision and how those decisions translate into real systems.

Objective

In this implementation, I aimed to:

Provision a secure Azure Storage account
Apply cost-efficient redundancy
Enforce modern encryption standards
Reduce authentication risk
Configure network exposure intentionally

The workload in this case was non-business critical. High availability across regions was not required. Cost optimization was important but not at the expense of security fundamentals.

1️⃣ Creating the Resource Group

I began by creating a dedicated resource group to logically isolate the storage resources.

In the Azure portal, search for and select Resource groups

Select + Create.

Give your resource group a name. For example, storagerg.

Select a region. Use this region throughout the project.

Select Review and create to validate the resource group.

Select Create to deploy the resource group.

2️⃣ Deploying the Storage Account

Next, I created the storage account.

In the Azure portal, search for and select Storage accounts.

Select + Create.

On the Basics tab, select your Resource group.

Provide a Storage account name. The storage account name must be unique in Azure.

Set the Performance to Standard.

Why Standard?

For non-production workloads, Standard performance provides cost efficiency while maintaining reliability.

Large-scale platforms like Netflix or Shopify may require Premium storage for specific high-throughput workloads. But dev/test environments rarely demand that level of performance.

Choosing the right tier is about aligning cost with workload sensitivity.

Select Review,

and then Create.

Wait for the storage account to deploy and then Go to resource.

3️⃣ Configure simple settings in the storage account.

The data in this storage account doesn’t require high availability or durability. A lowest cost storage solution is desired.

In your storage account, in the Data management section, select the Redundancy blade.

Select Locally-redundant storage (LRS) in the Redundancy drop-down.

Locally-redundant storage (LRS)

Why LRS?

Replicates data three times within a single datacenter
Lowest-cost redundancy model
Suitable for development and testing environments

In fintech platforms or e-commerce systems operating across regions, geo-redundancy is critical for disaster recovery.

However, resilience must match workload importance.

I saved the changes to apply the configuration.

Refresh the page and notice the content only exists in the primary location.

The storage account should only accept requests from secure connections.

In the Settings section, select the Configuration blade.

4️⃣ Ensure Secure transfer required is Enabled (HTTPS Only).

Financial platforms like Flutterwave and Paystack process sensitive transaction data daily. HTTPS-only communication prevents insecure requests and protects data from interception.

Security discipline should not depend on environment type.

5️⃣ Enforcing Minimum TLS Version 1.2

In the Settings section, select the Configuration blade.

Ensure the Minimal TLS version is set to Version 1.2.

Allowing outdated TLS versions increases exposure to protocol-based vulnerabilities.

Modern systems enforce current encryption standards by default.

6️⃣ Until the storage is needed again, disable requests to the storage account.

In the Settings section, select the Configuration blade.

Ensure Allow storage account key access is Disabled.

Why Disable Shared Keys?

Shared keys:

Are long-lived
Harder to audit
Increase risk if exposed

Modern cloud environments prefer identity-based access control using RBAC and managed identities.

In fintech and enterprise systems, auditability and least-privilege access are critical.

Be sure to save your changes.

7️⃣ Ensure the storage account allows public access from all networks.

In the Security + networking section, select the Networking blade.

Ensure Public network access is set to Enabled from all networks.

In production systems — such as banking platforms or telecom environments — public exposure would typically be restricted using private endpoints and firewall rules.

Network access decisions must always reflect workload sensitivity.

Be sure to Save your changes.

Real-World Perspective

Cloud infrastructure powers platforms used daily across Nigeria, Africa, and globally.

Behind every processed payment, streamed video, or online transaction is storage configured with intention.

This implementation focused on a non-production workload, but the principles applied here mirror the same foundational decisions made in production environments.

Security is not dramatic.

It is deliberate.

Final Thoughts

Creating a storage account is easy.

Configuring it responsibly is what defines engineering maturity.

Even in dev/test environments:

Encryption should be enforced
Legacy authentication should be minimized
Redundancy should be intentional
Network exposure should be deliberate

Behind every reliable digital experience is infrastructure configured carefully.

Mastering these fundamentals is how a strong cloud engineering discipline is built.

Cloud Computing: What It Is, Why It Matters, and How It Really Works

Mahmud Seidu Babatunde — Sun, 22 Feb 2026 14:17:39 +0000

A few years ago, if your laptop crashed, you panicked.

Your files? Gone.
Your photos? Gone.
Your work documents? Gone.

Today, if your laptop crashes, you log into Google Drive from another device and continue working like nothing happened.

That quiet shift represents something bigger than convenience.

It represents a fundamental change in how computing infrastructure is built, delivered, and consumed.

That change is cloud computing.

But cloud computing is not just “online storage.”
It is the architectural foundation powering Netflix, online banking, AI systems, e-commerce platforms, and modern Software as a Service (SaaS) products.

Why Cloud Computing Changed Everything

Before cloud computing:

Companies bought and maintained physical servers.
Infrastructure setup could take weeks or months.
Scaling required purchasing and installing new hardware.
Downtime often meant serious business loss.

Cloud computing changed the model from ownership to on-demand consumption.

Instead of owning infrastructure, businesses rent computing resources and scale as needed.

That shift unlocked speed, flexibility, global expansion, and continuous innovation.

What Is Cloud Computing?

Cloud computing is the delivery of computing services such as storage, servers, databases, networking, and software over the internet.

Instead of owning:

Physical servers
Storage infrastructure
Networking equipment
Power and cooling systems
Entire data centers

You rent computing power from providers like:

Amazon Web Services (AWS)
Microsoft Azure
Google Cloud Platform (GCP)

And you pay only for what you consume.

The simplest analogy is electricity.

You don’t build a power plant at home.
You connect to the grid and scale usage based on demand.

The shift from ownership to on-demand consumption is what makes the cloud transformative.

It reduces capital expenditure, increases flexibility, and accelerates innovation.

Cloud Service Models

A cloud service model explains the division of responsibility between the cloud provider and the customer.

In cloud computing, there are mainly three service models:

Infrastructure as a Service (IaaS)
Platform as a Service (PaaS)
Software as a Service (SaaS)

Infrastructure as a Service (IaaS)

IaaS provides basic computing infrastructure over the internet.

The provider gives you:

Virtual machines
Storage
Networking
Load balancers

You manage:

Operating system
Applications
Data
Security configurations

Think of IaaS like renting an empty apartment.
The building exists, but you furnish and manage everything inside.

Platform as a Service (PaaS)

PaaS provides a platform where you can build, run, and deploy applications without managing the underlying infrastructure.

The provider manages:

Servers
Networking
Operating systems
Runtime environment

You manage:

Your code
Application logic
Your data

Think of it like renting a fully equipped kitchen.
You just cook.

Software as a Service (SaaS)

SaaS delivers fully functional software applications over the internet.

The provider manages everything.

You simply use the application.

Think of it like ordering food at a restaurant.
You just eat.

Core Cloud Concepts

To truly understand cloud computing, you must understand the principles that power it.

What Is Virtualization?

Virtualization is the backbone of cloud computing.

It allows one physical server to run multiple isolated virtual machines (VMs).

A hypervisor allocates hardware resources efficiently across these VMs.

Why virtualization matters:

Efficient resource utilization
Reduced hardware costs
Workload isolation
Multi-tenant architecture

Without virtualization, scalable public cloud infrastructure would not exist.

What Is Scalability?

Scalability means a system can grow when demand increases.

For example:

Today your website has 100 visitors.
Tomorrow it has 10,000 visitors.

If your system can increase its capacity to handle that growth without performance degradation, it is scalable.

There are two main approaches:

Vertical scaling: Increase the power of an existing server.
Horizontal scaling: Add more servers to distribute the workload.

Scalability ensures your system remains stable as demand grows.

What Is Elasticity?

Elasticity is similar to scalability but more dynamic.

Scalability means the system can grow.
Elasticity means the system automatically grows and shrinks based on real-time demand.

Example:

When traffic increases → more resources are automatically provisioned.
When traffic drops → extra resources are automatically removed.

Elasticity optimizes performance while controlling cost.

What Is Agility?

Agility refers to speed and flexibility.

Before cloud computing:

Provisioning a new server could take weeks.

With cloud computing:

You can deploy infrastructure in minutes.

Agility allows businesses to:

Move faster
Test ideas quickly
Launch products rapidly
Adapt to market changes

Cloud makes IT flexible and responsive.

What Is High Availability?

High availability means a system remains operational with minimal downtime.

If one server fails, another automatically takes over.

This is achieved by:

Using multiple servers
Deploying across different locations
Implementing load balancing
Replicating data

High availability reduces service disruption and improves reliability.

What Is Fault Tolerance?

Fault tolerance goes further than high availability.

It means the system continues operating even when components fail.

In cloud environments, failure is expected:

Servers can fail
Networks can fail
Entire data centers can fail

Fault-tolerant systems are designed to survive those failures without interrupting service.

What Is Global Reach?

Cloud providers operate data centers around the world.

This means:

You can deploy applications closer to your users
Reduce latency
Improve performance
Serve global markets

If your users are in Africa, you deploy closer to Africa.
If they are in Europe, you deploy in Europe.

Cloud infrastructure removes geographical limitations.

Cloud Deployment Models

There are mainly three primary cloud deployment models:

Public Cloud

Infrastructure is owned and operated by a third-party provider (such as AWS, Azure, or Google Cloud) and shared among multiple customers over the internet.

It is cost-effective, scalable, and widely used by startups and modern applications.

Private Cloud

Infrastructure is dedicated to a single organization.

It offers greater control, customization, and security but usually at a higher cost.

Common in industries with strict compliance requirements such as banking and healthcare.

Hybrid Cloud

A combination of public and private cloud environments.

Organizations may run sensitive workloads in a private cloud while using the public cloud for scalable or customer-facing applications.

Hybrid cloud provides flexibility and balance.

Major Cloud Providers

The industry is led by:

Amazon Web Services (AWS)
Microsoft Azure
Google Cloud Platform (GCP)

While each provider has its strengths, the core principles of cloud computing remain consistent across platforms.

Final Thoughts

Cloud computing represents more than infrastructure.

It represents a shift toward scalable, resilient, and globally accessible systems.

By understanding service models, deployment strategies, and core principles like virtualization, scalability, and high availability, we move from simply using cloud tools to designing cloud architectures.

For me, mastering these fundamentals is the first step toward building production-ready systems and contributing meaningfully to modern infrastructure teams.

This is the foundation I am intentionally strengthening as I continue my journey into cloud engineering.