[00:01] the evolution of networking in modern infrastructure from physical servers to virtual machines to containers to container orchestration tools and all container orchestration tools and all the core networking concepts underneath.
[00:15] And knowing these networking concepts is important whether you are a software engineer, DevOps engineer, or cloud engineer. So, let's dive into a practical scenario to see how networking has evolved and what you need to know
[00:29] today. And we created a full breakdown of these in a beginner-friendly handout to accompany this specific video. So, grab it from below and let's dive in. grab it from below and let's dive in. Imagine we have built ShopEasy, an
[00:44] e-commerce platform that has grown dramatically over the years or decades. Now, let's trace its networking journey from the early days to today's modern
[00:57] architecture. When ShopEasy first launched, everything ran on a single physical server. One powerful machine in a data center running our web application, database, and all the services using a single
[01:12] public IP address. So, customers needed to access our ShopEasy website. So, our physical server that runs the website needed to be identified on the network
[01:24] somehow. And that's where IP addresses come in. Think of an IP address like a physical street address. Just as your home has a street address. Just as your home has a unique address for mail delivery to
[01:38] uniquely identify that specific house, our server also needs a unique address where clients can send it requests. So, IP address is like a street address for
[01:50] your server on the network. It's a special number that looks like this that tells other computers exactly where to send data or requests so that it can
[02:03] reach your server. And every device on a network, including your Shop Easy network, including your Shop Easy server, needs to have its own unique IP address for the communication, just like every house on a street needs its own
[02:17] address to get mail. But wait, what even is a network? Think of a network as a group of devices that can talk directly to each other, like all houses in the same neighborhood. And going back to the IP
[02:31] addresses, if we have an IP address like 203.0.113.10, the IP address looks this way because it's based on the IPv4 standard, which
[02:45] uses four sets of numbers. So, each section between the dots, ranging from 0 to 255, separated by dots. So, the first three
[02:57] parts of the device's IP address identify the specific network or the neighborhood. And the last part, the fourth section, points to a particular
[03:09] device in that network. Or, to use our analogy, a specific house in the neighborhood. But then, how does one device in one network talk to another device on another network? That's the role of
[03:24] special devices called routers. When a computer wants to send data to When a computer wants to send data to another device outside its own network, it sends the data to its network's router, also called a default gateway.
[03:39] The router then forwards the data toward the destination network, passing it through other routers on the way if needed, until it reaches the right device. Routers use the network part of the IP
[03:53] Routers use the network part of the IP address to decide where this data needs to be sent. Much like sending mail from one neighborhood to another through sorting post offices. So, the network part of the IP address is like saying
[04:07] "All houses on Maple Street." While the host part is the exact house number on that street. This way, any device on any network can reach any device on any
[04:20] other as long as there are routers linking these networks together. But wait, customers would not type in 203.0.113.10
[04:35] Right? Instead, they would type something like shopeasy.com when visiting our site. So, that's where the main name system or DNS comes in. So, DNS is like the internet's address book. It translates easy-to-remember website
[04:52] names or human-readable website names like shopeasy.com into the IP address that uniquely identifies the server that is hosting that website. Because we humans definitely don't want to remember or type server's IP address, but we can
[05:08] remember simple names like shopeasy.com or google.com. So, when a user types a website name into the browser, the browser asks a DNS server for the browser asks a DNS server for the matching IP address or an actual address
[05:23] of the server for the website, and DNS will automatically translate the website name into the server's street address or IP. So, the browser knows where to fetch the web page from. And in addition to that, even if the IP address changes in
[05:40] the background, the shopeasy.com will bring users to the right server with a new IP address. And this process happens in milliseconds. And as I said at the beginning, all this will be neatly organized with practical visuals in the
[05:57] handout, so you can review it and easily follow along. It will be in the link below, so go grab it. Now, let's say we delivered mail to the Now, let's say we delivered mail to the right house, but how do recipients in
[06:11] that house actually get it? Meaning, once the request from client reaches the server machine, how does it get to the actual web application running on that server or on that virtual machine? If we imagine a server like a house on a
[06:26] street, every house has an entrance for visitors and mail, like the main entrance. And for computers and servers, the network interface acts as this main entrance. It's a special doorway where all network traffic comes in and goes
[06:41] out. One common network interface is called Ethernet zero. Think of Eth zero as the front door of the house. All data packets trying to reach the server must
[06:54] enter through this door. There can be other doors, like Eth one, another other doors, like Eth one, another Ethernet cable, WLAN zero, a Wi-Fi door, or LO, which is a small door for local self-communication, for localhost, but
[07:10] let's focus on Ethernet zero, which is the main way for outside traffic to arrive into the server. Inside the house, there are different rooms, each for different purpose. And these are ports on a server. A web
[07:24] And these are ports on a server. A web application room on port 80 or 443 is application room on port 80 or 443 is where website visitors go. The database room, let's say port 3306 or 5432, handles data queries. And other
[07:39] rooms exist for other services and programs. When the server gets a delivery, the package comes in through ETH0, as we said. But, how does the ETH0, as we said. But, how does the right room get the delivery? Well, the
[07:53] operating system on the server is like the house manager. It looks at each package and checks the room number or the port written on it. So, which port is this request addressing? The OS manager, the house manager so
[08:09] say, then takes the package to the correct room, the program inside the house. So, any request that is addressing the web app port gets to the web application. The database gets the queries addressed to the database on its
[08:25] port and so on. So, in summary, the network interface connects your house or server to the road or network. ETH0 is the main front door for deliveries, where all the network traffic to your server comes in.
[08:39] Ports are the rooms inside the house where different programs live. The OS is the manager that figures out what goes where, making sure every delivery reaches the right room. Now, we have been running our website on this simple
[08:52] web server. However, this simple setup had major problems. First of all, if something happens to this house, like a fire or a broken lock, someone broke into the house, there is nowhere else for customers or
[09:06] mail to go. All your deliveries, web requests will stop and your shop is instantly offline. In real terms, if your server crashes, the whole business is down until it's fixed. There is no backup house or server to handle
[09:20] visitors or orders. Now, suppose it's a holiday season and crowds line up at With only one house, you can't add more rooms or doors to serve more customers.
[09:32] Everyone must squeeze inside one entrance, so people have to wait outside, you have slower performance or outages. You can't expand quickly to keep up with busy times. But, what if the opposite happens and nobody comes
[09:46] for a week or month? You still have to pay for rent and heating and upkeep on the house even when it's empty. So, one physical server is expensive whether it's serving one customer, 100 customers, or none. And most of the time
[10:02] customers, or none. And most of the time your resources sit unused wasting money. let's say you want to upgrade the kitchen or add new rooms to the house. You've got to close down the whole house and stop visitors from coming
[10:16] while you work on that remodel or renovation, meaning downtime every time you change or update things on your server. When the only server is being updated or fixed, the entire application must pause. So, customers notice gaps in
[10:30] must pause. So, customers notice gaps in service. virtualization. Running multiple virtual machines on one physical server. So, virtualization is like splitting that big house into many
[10:44] separate apartments. So, from a single house, we're moving to apartment buildings, which means a virtual machine is like having many fully equipped apartments, self-sufficient,
[10:57] isolated apartments inside one large building or a physical server. Each apartment has its own entrance, unique address for mail delivery, has its rooms, kitchen, bathroom, mailbox, and so on.
[11:11] And they can run independently as if each were its own house with private tenants or applications. A virtual machine, or VM, is an independent, fully functional computer created by software inside a real physical server. Here's
[11:28] inside a real physical server. Here's how VMs work. Each VM gets its own slice of system resources of the underlying physical server. So, they get a virtual physical server. So, they get a virtual CPU, virtual memory, disk, and network.
[11:41] CPU, virtual memory, disk, and network. Every VM runs its own guest operating system, like Windows, Linux, and can install apps, set configurations, and host network connections exactly as if running on real hardware. So, VMs are
[11:57] fully isolated. So, something running in one VM cannot interfere with another VM on the same hardware. And these VMs communicate over a virtual network created by the hypervisor, which is a special program that sits between the
[12:12] physical server and the virtual machines. This virtual network is like having invisible network cables connecting virtual computers inside our physical server. So, hypervisor lets the physical server share its actual
[12:26] physical CPU, memory, storage, and network among several virtual machines, but keeps them completely separated so that each VM acts like a real private computer. So, with this setup, there are several benefits that we gained for our
[12:41] application. This setup gives us isolation between services. A crash in one VM does not affect others. Better resource utilization, so we can run multiple VMs on one more powerful server. But, the biggest difference
[12:55] between physical servers and VMs is that VMs are portable and easier to back up because their entire state, including the operating system, data, configuration, can be saved as a snapshot file, which can be quickly
[13:11] restored or copied to another physical server. Unlike physical servers that require reinstalling hardware, OS, and applications if they fail or need to be moved. And this means easier backups of our services because we can snapshot the
[13:26] entire VMs. So, even if the underlying server machine crashes, the physical server basically burns or is not functional anymore, we can easily restore all our programs on another server using the backups because we can
[13:41] back it up in a snapshot file. But, let's see how this works technically and what are the main networking components of VMs. So, when you run multiple virtual machines inside one physical server, the building at 203.0.113.10,
[14:01] a unique apartment number in the building's private hallway, like internal network, often something like 10.0.0.5, 10.0.0.6, 7, and so on. These internal IPs are
[14:16] only used inside the building. They aren't visible from outside on the wider internet, on the public internet. For example, VM1 web server has an internal example, VM1 web server has an internal IP of 10.0.0.5, VM2, which is database
[14:30] server, has internal IP of 10.0.0.6. Let's say we have a cache server with Let's say we have a cache server with internal IP of 10.0.0.7, and so on. These VMs themselves can talk to each other using their private addresses,
[14:44] like neighbors passing notes in the hallway in an apartment building, without sending their messages onto the public street or internet or leaving the building. Each virtual network interface has a firewall that acts like a team of
[15:00] careful security guards who check every incoming or outgoing delivery based on incoming or outgoing delivery based on strict rules. So, verifying the sender's identity, what room or port they're trying to reach, and whether their
[15:14] message is allowed, so only trusted visitors and safe packages make it past the entrance, keeping the apartment's data secure from intruders, and so on. And all traffic is routed and managed by the hypervisor, which now acts like the
[15:29] building's supervisor manager, making sure everyone's mail and messages reach the right apartment and keeping outsiders out unless invited. If a VM needs to communicate with the outside world, its messages pass from its
[15:43] internal apartment number, the internal IP, out through the main entrance, the physical server's public IP, and the process uses network address translation
[15:55] to convert the private internal addresses to public ones. And every bit of traffic is filtered by software firewalls, which check the data, enforce security policies, and only allow safe, permitted requests and responses to go
[16:12] through, which keeps the entire communication secure. Now, you just saw how even a simple VM setup requires managing firewall rules, IP addresses, net gateways, and security groups. Now, multiply that across cloud VMs,
[16:28] containers, and Kubernetes clusters, this becomes a lot to manage. And this is where Tailscale comes in, which is a sponsor of this video. So, shout out to Tailscale for supporting us. So, Tailscale is basically a modern, secure,
[16:44] zero trust connectivity platform. And it provides a very easy and fast way to securely connect from and to any device or service anywhere. And unlike a legacy
[16:56] VPN, where all traffic flows through one central server that becomes a bottleneck, Tailscale actually builds an encrypted mesh network where each device directly connects to the other devices that it needs to reach. This means no
[17:10] detour, no single point of failure, and it also adds massive improvements in latency and scalability because of that type of setup. And it also figures out how to make those direct connections automatically, even when devices are
[17:25] automatically, even when devices are buried behind nets and firewalls. So, there is no need to open ports or manually touch any firewall rules, etc. And that means with Tailscale, you can actually replace legacy VPN
[17:38] infrastructure in minutes and build simple networks across multiple multi-cloud environments. Also, SSH into any device without managing keys and much, much more. You can get started for free at tailscale.com.
[17:53] To test it out, the personal plan is always free. And if you want to bring always free. And if you want to bring Tailscale to work, use code Nana for three free month on any paid plan. All the links and information is going to be
[18:06] in the description. Now, back to the video. maintaining our own giant apartment building or physical server became
[18:20] overwhelming and costly. Because we needed to have dedicated engineer or multiple engineers, network and server administrators, who actually managed those physical machines. So, we moved to
[18:33] the cloud, which is like renting apartments in a huge, expertly managed skyscraper built by professional landlords, cloud providers, who have already set up thousands of buildings, data centers in different parts of the
[18:48] data centers in different parts of the city or the world. So, now ShopEasy can quickly and affordably rent just the right amount of secure, modern living space or modern space or computing resources that it needs, scaling up or
[19:03] down instantly with all the building maintenance, networking, security, and upgrades handled by the provider's team, leaving us free to focus on running our business, not managing the property. Think of it like that. Companies went
[19:19] and bought a whole bunch of computers, server machines, wired up the whole thing, connected all the network cables, configured the networking, built the data centers with all those machines in different locations, and then built a
[19:32] simple interface, a web browser-based interface, to offer slices of these server resources to other companies as a rent. That's how cloud platforms like
[19:44] AWS, Google Cloud, and so on emerged. So, technically, cloud is easy access to vast amounts of servers that someone else is managing at scale. So, let's see
[19:56] under the hood of most important cloud networking concepts. Moving to AWS is like ShopEasy renting the whole private wing in a giant modern skyscraper that's filled with many companies. So, this private wing is called virtual private
[20:12] cloud, or VPC, and it's isolated from the rest of the building, so only ShopEasy staff and customers have access to it. And all our VMs, or rooms, are within our own VPC. And inside our own section, office wing, VPC, we set up
[20:30] different purposes, which are called subnets. Subnets are like separate zones within our wing. A public subnet is windows facing the street, or the internet, perfect for web servers that
[20:46] public must access. So, the VMs in public subnets are accessible to internet or public traffic. A private subnet is secure office space hidden subnet is secure office space hidden deeper inside, used for databases or
[21:00] applications that only our internal staff should reach. No public or strangers should be allowed in those sections of the VPC. All the VMs in private subnet are not directly exposed to internet, so are only accessible from
[21:14] within, which keeps them secure. Security groups are like security guards stationed at every door, checking who goes in and out of each room based on goes in and out of each room based on strict guest lists or firewall rules.
[21:28] Route tables are the building's directory and navigation system, showing exactly where deliveries, visitors, or messages should be sent to reach the right office, server, or storage room. If staff in a private office or private
[21:43] subnet need to grab something from outside, like software updates, they use a net gateway. Think of it like a trusted concierge that allows them to fetch what they need from the street, but keeps their office address hidden,
[21:58] so uninvited visitors cannot get in. So, as technical summary, AWS VPC lets businesses segment their cloud space into these isolated, secure areas, which
[22:10] is only dedicated to them, further divided with subnets for different exposure levels and security needs, with security groups as fine-grained firewall policies, route tables to guide traffic flow, and gateways to tightly control
[22:25] internet access or to act as the middleman as an interface to the public middleman as an interface to the public internet.
[22:37] story. And let's switch contexts and imagine that ShopEasy ran all its operations in one giant factory. Every team, payments, shipping, catalog, and so on, worked under the same roof and shared the same machinery. So, basically
[22:54] a monolithic application in a VM. Any update meant pausing the entire factory, making changes slow and risky, affecting all the parts of the factory. As we grew, we realized that it was much smarter to break the factory into small,
[23:10] smarter to break the factory into small, independent workshops or workstations, each focused on a single task, like shipping, packaging, payment, or managing inventory. And this is a shift to microservices. Instead of one huge
[23:25] system for everything, we now had teams specialized for each job. But if each workstation relied on the building to provide exact tools and supplies, we'd
[23:37] still face a problem. Like moving or replicating the workshop elsewhere would be hassle, and updates could break if the new building didn't match the old setup. And that's where containers come in. A container is like a portable,
[23:50] fully stocked toolbox for each workstation. All the specific tools, supplies, dependencies, blueprints a team needs are packed inside. And with this, we can set up a new workstation on any factory floor, in other words,
[24:04] server or VM, simply by unpacking the container. We don't care what equipment comes ready to work. So, with packaged together with all its
[24:18] dependencies, libraries, configuration, the operating system, environment configuration in a single unit. And this means we can deploy and run a service on any compatible server or cloud without worrying about what's installed and
[24:34] configured on underlying infrastructure. Now, let's again look at how container networking works on top of VMs. Containers are like lightweight VMs that share the host's operating system. So, we have multiple VMs on the physical
[24:49] server, and we then install multiple containers inside a single VM. The reason why containers are so lightweight is because they share the hosts or VMs,
[25:02] virtual hosts, operating system kernel and only provide the isolated application layer on top of it. This means they don't need to boot the entire operating system like virtual machines. When they start, they just load the
[25:17] application layer on top of the existing kernel, which is much faster and lightweight. So, container images are measured in megabytes while VMs are measured in gigabytes. And Docker is the most popular container
[25:31] technology. But, how do these containers communicate both with each other and with the outside world? That's where Docker networking comes in. By default, bridge.
[25:44] Think of this as a private company hallway where all the toolboxes, or containers, on the same VM can talk to each other using their own unique desk each other using their own unique desk phones, or internal IPs. They can easily
[25:57] call each other directly and Docker's built-in phone book, or DNS, lets them connect by container name, like dialing API or Redis instead of memorizing the numbers, the phone numbers, or IP addresses. When Shop Easy expands to use
[26:14] several adjacent company buildings, like multiple VMs or servers, Docker creates what's called overlay networks, special encrypted passages that seamlessly connect the rooms, or
[26:28] containers, from different buildings. So, even if the containers are running in different VMs or servers, they can still talk to each other through the Docker overlay network. So, in our analogy again, teams working different
[26:43] buildings of the same company can still communicate with each other even if they're in different places. So, this enables reliable microservice communication and scaling beyond a single virtual or physical machine.
[26:56] Now, of course, for containers that host web application or client-facing front-end application, we need the outside world to access that container or the application that's running inside. And that's where container port
[27:09] mapping comes in. Containers are like own isolated machines with their own ports, right? So, when a request comes to the VM that hosts the container, how does that request actually end up inside the container? Well, we map the host
[27:24] port, host being the VM where containers are running, to the container port, saying, "If a request comes to VM on port 80, then forward this request to port 80, then forward this request to container called web app on port 8080."
[27:38] It's like setting up a main receptionist at the building lobby, which is the VM entrance, who answers incoming calls on the building's main phone number, so public IP address, port 80, let's say, and then transfers them to the right
[27:54] internal extensions. In this case, port 80 to containers port 8080. For example, if we execute Docker run with port mapping 80 to 8080, this tells Docker to
[28:06] forward any calls coming to the port 80 to the containers port 8080, connecting outside traffic to the exact microservice they need. Now, as Shop Easy's digital operations grew, our Agile teams found themselves
[28:22] launching tens, even hundreds of container toolboxes for all the shops, departments, and specialized tasks we created. And managing each of these toolboxes manually, figuring out where
[28:36] to put them, tracking which ones were running, and restarting any failed ones became like trying to supervise a bustling city block entirely by hand. It simply wasn't possible as we scaled up. That's when we hit the next phase and
[28:51] turned to container orchestration tool like Kubernetes. Just as a city brings in a master planner to coordinate where new buildings go, how traffic flows, and which shops open or close in response to
[29:05] real demand, Kubernetes acts as Shop Easy's automated orchestrator. It knows every container's status, places new ones in the best available slots or automatically restarts or replaces any failed ones, and dynamically scales up
[29:22] failed ones, and dynamically scales up or down as business needs shift, which frees up our teams from manual container management and allows us to scale and grow continuously and reliably. So, how does Kubernetes networking work
[29:38] under the hood? A pod in Kubernetes is the smallest unit for running applications. It can have one or more containers that work closely together inside a pod. And every pod needs to communicate both with other pods and the
[29:54] rest of the infrastructure. To make this happen, Kubernetes gives each pod its own IP address, just like an office gives each room its own unique phone number or door. All pods in the cluster are part of the same internal network.
[30:10] are part of the same internal network. So, one pod can connect directly to any other by using its IP, even if they are on different machines. But setting up and managing all these network connections
[30:22] automatically is a big challenge. And this is where the container network interface comes in, also called CNI. So, Kubernetes uses a standard called CNI to automatically create a tiny virtual network cable, that's how you
[30:37] can imagine it, or virtual ethernet interface for each pod. And this gives each pod its own unique IP address, so we can talk to any other pod in the cluster, no matter which server it's on, without needing a
[30:53] router to translate addresses or extra setup by the user. So, CNI is like the contractor that installs and plugs in the network cables for each new pod that
[31:06] gets created in the cluster. So, when a new pod is scheduled, Kubernetes calls the CNI plugin, which plugs in this network cable for the pod, giving it a virtual network cable or virtual ethernet interface,
[31:20] assigns it a unique IP address, and sets up the routes so that pod is directly reachable from anywhere in the cluster. So, since every pod has its own network interface and IP address, even if pods are on different nodes, any
[31:34] pod can talk to any other pod inside the cluster as if they were on one flat cluster as if they were on one flat company-wide network or LAN, local area network. There's no need for port mapping or address translation and so
[31:49] on. However, even though each pod gets its own unique IP address, these IPs change whenever pods are restarted, moved, or replaced. And pods are ephemeral, so that happens often. If another service tried to keep track
[32:05] of these changing addresses, it would be a mess. So, to make things simple, Kubernetes gives us a service, which is like a permanent company hotline. No matter how many employees or pods are working behind that hotline, or if they
[32:22] change desks, like IP addresses, the phone number stays the same. When someone calls the hotline, the service IP, Kubernetes distributes the calls to any available employee in that department, which means any healthy pod
[32:36] behind that service. So, no one needs to know which desk they're at. And this load balancing is handled automatically by a piece called kube-proxy using special routing rules to forward the call to whoever's available.
[32:50] So, how do different teams in the company know how to call the right department? Well, Kubernetes has an internal phone book or DNS where every service registers its name, for example, backend service. If the front end wants
[33:05] to reach the backend, it just calls backend service and Kubernetes takes care of connecting to the currently healthy pods behind that service. Even healthy pods behind that service. Even if the pods keep swapping in and out.
[33:20] worry about pod IPs changing. They just use simple, never-changing, static names and connections that always work. Now again, we have all these services and pods inside cluster, but at some point we need to give outside clients
[33:35] access to the applications running within pods in the cluster, right? And in. Ingress in Kubernetes is like a smart main entrance to your cluster. A single front door with a helpful
[33:49] receptionist. Instead of giving visitors a tricky map to every room or service inside to navigate, the receptionist looks at each guest's request, checks
[34:01] clear instructions, which are routing rules, and sends them directly to the right department, like the web front end, API, or another internal app. Ingress can check the visitor's name or which door they knocked on, like host
[34:15] name or path, provide secure connection, meaning it can make sure that the visitor is actually authorized to enter and talk to that specific service they're trying to connect to, and make sure only right people get access
[34:30] without showing off all internal rooms to the public. In this way, you have just one clearly managed entry point for outside users, and the Ingress controller inside Kubernetes takes care of the rest, which is efficiently
[34:44] directing traffic to the correct services and keeping your cluster both accessible and secure. By default, all the rooms or pods in Kubernetes can freely talk to each other, like having a building where every door is always
[34:59] unlocked. While this makes it easy for apps to communicate, it's not 100% secure, especially as your company grows and you want to keep sensitive areas private. And that's where network policies come
[35:13] in. These are services in Kubernetes that act like security guards and door locks in front of each pod or service. So, you can write clear, detailed rules
[35:25] for who can come in or out of each room inside the office. For example, you may inside the office. For example, you may say, "Only pods labeled as API server can enter the database room on port 5432. Everyone else gets blocked." You
[35:40] can set rules for incoming traffic. So, it's like digital badge that based on your role gives you access to specific rooms in your office. You can set rules for incoming traffic, like who's allowed in, as well as
[35:55] outgoing traffic or who's allowed out, and these policies use things like pod and these policies use things like pod names, labels, even namespaces to match the right rooms or sections of the rooms, and they work for both internal
[36:08] and sometimes external addresses. Once you apply a network policy, only the connections you allow are possible. Anything else is locked down. In the background, Kubernetes uses built-in network features like IP tables or
[36:23] special plugins to enforce these rules. So, in short, network policies in Kubernetes help you secure your cluster by letting you control exactly who can connect to what specific service, locking the doors that should stay
[36:37] closed, and opening just the ones your apps and teams really need, but also giving all these specific people with specific authorization to walk into those doors. So, to wrap up, Kubernetes networking starts with virtual network
[36:50] interfaces in every pod, managed through CNI, it allows seamless pod-to-pod communication using services as unchanged endpoints, DNS for service discovery, ingress for controlled
[37:05] external access, and enforcing strict network policies for security. computer into the internet all the way to designing modern systems like
[37:19] Kubernetes, the basics of networking have stayed the same, even as the tools have become much more powerful and complex. So, here are the fundamentals. Everything needs an address, like an IP address. Rules control what traffic is
[37:34] allowed. These are firewalls, security groups, network policies. Names need to resolve to addresses, DNS, service discovery. Traffic needs routes to follow, like routing tables. And if you get these basics, like addresses,
[37:49] security rules, names, and phone books, as well as routing, then you'll feel comfortable troubleshooting any issues or designing new systems, no matter if you're plugging in a physical server, setting up a VM, or building a modern
[38:03] cloud application like our ShopEasy on Kubernetes cluster. And as we saw in our simulated application example, each layer of abstraction actually adds
[38:15] powerful capabilities, but also added complexity. And having a solid grasp of networking basics, the underlying fundamental knowledge of those building
[38:27] actually helps you navigate that complexity with much more confidence. So, I hope this helped you a lot to build that foundation knowledge. Thank you for watching, and I'll see you in the next video.