"The cloud isn't magic. It's networking happening at an incredible scale."
In the first article of this series, Why Every Cloud Engineer Needs to Understand Computer Networks, we explored why networking is one of the most important skills for anyone pursuing a career in cloud engineering.
Now it's time to answer another important question.
What actually happens when you press Enter after typing a website into your browser?
Let's use a simple example.
You open your browser and type:
You press Enter.
Within a fraction of a second, Google's homepage appears.
Simple, right?
Not quite.
Behind the scenes, your request travels through multiple processes before it ever reaches Google's servers. That request is prepared, secured, routed across networks, delivered to the correct server, and then the response makes the exact same journey back to your browser.
Understanding that journey is where the OSI Model comes in.
For cloud engineers, this isn't just networking theory. It's the foundation for understanding Azure Virtual Networks, AWS VPCs, DNS, Load Balancers, VPNs, Firewalls, Network Security Groups, and almost every networking service you'll work with in the cloud.
Why Do We Need the OSI Model?
Imagine you want to send a parcel to a friend in another country.
You carefully package it, write the address, and hand it to the courier.
From that point on, different people take over.
Someone sorts the package.
Someone loads it onto a truck.
Someone flies it across the ocean.
Someone else delivers it to your friend's doorstep.
Each person has one responsibility. Nobody tries to do everyone else's job.
Computer networks work exactly the same way.
Instead of handling communication as one giant process, networking breaks it into smaller tasks. Each task is assigned to a different layer, and together they move data from one device to another.
That's exactly what the OSI Model is.
It divides network communication into seven layers, each with a specific responsibility.
Meet the Seven Layers
The easiest way to understand the OSI Model isn't by memorizing all seven layers.
Instead, think of each layer as answering one important question.
Layer 7 – Application
Where does communication begin?
This is the layer closest to you.
Every time you browse a website, send an email, or connect to a server using SSH, you're interacting with the Application Layer.
This layer provides the protocols applications use to communicate across a network.
Some examples include HTTP, HTTPS, DNS, SMTP, and SSH.
When you typed https://www.google.com, your browser created an HTTPS request at this layer before passing it down to the next one.
Layer 6 – Presentation
Can the receiving computer understand the data?
Different systems don't always represent data in exactly the same way.
The Presentation Layer acts as the translator.
Its responsibilities include:
- Translating data into a common format
- Encrypting and decrypting information
- Compressing data before transmission
Whenever you access an HTTPS website, this layer helps encrypt your data so your passwords and personal information remain protected while travelling across the internet.
Layer 5 – Session
How do two devices keep a conversation going?
Imagine making a phone call.
Someone dials.
Someone answers.
The conversation continues.
Eventually someone hangs up.
That's exactly what the Session Layer does.
It establishes communication, keeps it active while data is exchanged, and closes the connection cleanly when everything is complete.
Layer 4 – Transport
How does data reach the correct application?
This is one of the most important layers for cloud engineers.
The Transport Layer breaks large amounts of data into smaller pieces, ensures everything arrives in the correct order, and retransmits anything that gets lost along the way.
It's also where port numbers come into play.
Think of an IP address as the address of an apartment building.
A port number is the apartment number inside the building.
The IP address gets your data to the correct computer.
The port number delivers it to the correct application.
For example:
- HTTPS uses Port 443
- HTTP uses Port 80
- SSH uses Port 22
- DNS commonly uses Port 53
If you've ever configured an Azure Network Security Group or opened a firewall port, you've already worked with Layer 4.
Layer 3 – Network
How does data find another network?
This layer is responsible for logical addressing and routing.
Every device connected to a network has an IP address.
Routers examine these addresses and determine the best path to the destination.
Whether data travels across your home network or halfway around the world, Layer 3 is responsible for finding the route.
As cloud engineers, we encounter Layer 3 everywhere.
Azure Virtual Networks.
AWS VPCs.
Route Tables.
VPN Gateways.
ExpressRoute.
Everything begins with Layer 3 networking.
Layer 2 – Data Link
How do devices communicate on the same local network?
While Layer 3 uses IP addresses, Layer 2 relies on MAC addresses.
Switches use these hardware addresses to deliver data efficiently between devices connected to the same local network.
A common protocol here is ARP (Address Resolution Protocol).
Suppose your computer knows another device's IP address but doesn't know its MAC address.
It simply asks:
"Who has this IP address?"
The correct device replies with its MAC address, allowing communication to continue.
Layer 1 – Physical
How does data physically travel?
At the bottom of the OSI Model, data is nothing more than a stream of binary bits.
The Physical Layer converts those bits into signals that can travel across a medium.
Those signals might be:
- Electrical signals through Ethernet cables
- Pulses of light through fibre optic cables
- Radio waves over Wi-Fi
Without this layer, nothing would ever leave your device.
The Journey Down... and Back Up
As your request travels down the seven layers, each layer adds its own information before passing it to the next.
This process is called encapsulation.
Once Google's server receives the request, the reverse happens.
Each layer removes the information that was added until the original request reaches the web application.
This reverse process is called decapsulation.
Think of it like shipping a gift.
You place the gift inside a box.
The courier adds labels.
Shipping companies attach tracking information.
When the recipient receives the package, they remove each layer until they finally reach the gift inside.
Networking works exactly the same way.
Why Cloud Engineers Should Care
One of the biggest misconceptions about the OSI Model is that it's only useful for passing certification exams.
Nothing could be further from the truth.
The OSI Model gives you a structured way to troubleshoot problems.
Imagine you've deployed a web application to Azure.
Users suddenly report they can't access it.
Instead of guessing, you can troubleshoot layer by layer.
- Is the network connection working?
- Does the server have the correct IP address?
- Is Port 443 open?
- Is HTTPS configured correctly?
- Is the web application actually running?
Good engineers don't troubleshoot randomly.
They troubleshoot systematically.
That's exactly what the OSI Model helps you do.
Key Takeaway
If there's one thing I want you to remember from this article, it's this:
Every cloud service ultimately depends on networking.
When you configure a Virtual Network in Azure, you're working with Layer 3.
When you create firewall rules or Network Security Groups, you're working with Layers 3 and 4.
When users securely access your web application over HTTPS, Layers 4, 6, and 7 are all involved.
Cloud platforms don't replace networking.
They build on top of it.
The stronger your networking foundation becomes, the easier cloud engineering will be.
Final Thoughts
The OSI Model isn't something to memorize and forget after passing an exam.
It's a mental framework that helps you understand how computers communicate, why networks behave the way they do, and how to troubleshoot problems logically.
As you continue your cloud journey, you'll discover that almost every networking concept in Azure, AWS, and Google Cloud traces back to these seven layers.
Understanding them now will make everything you learn later feel much more connected.
In the subsequent articles, we'll explore IP Addressing, Subnetting, and CIDR Notation. These are the concepts that determine how cloud networks are designed, secured, and scaled.
If you found this article helpful, consider following the series. We're building the networking foundation every cloud engineer needs, one concept at a time.
Top comments (0)