Understand the Point of Servers

0:00[MUSIC PLAYING] Welcome to the CompTIA Server+ playlist that we have here at CBT Nuggets. Now, I can't tell you right now how excited I am to be recording this content because this right here is the stuff that I wished I had known when I started working with servers. You see, I really started out working with networks. I worked with networking switches, routers, firewalls. I was really good at subnetting, routing protocols, blah, blah, blah, blah.

0:32And then I jumped into servers, and I was completely overwhelmed by the tremendous number of things that they can do. Even physically working with servers, putting them into a rack and installing them, and understanding power requirements and things like that, just became overwhelming really, really fast. So whether I wanted to be an engineer, or just an administrator, or just someone in monitoring, whatever the case was, I figured out pretty quick that the server world is an entirely different beast or an entirely different animal in its own right.

1:07So what my plan to do here is, throughout this playlist, is to help you grow into the server role that you want to be in. That way, you'll understand how to physically work with servers-- what different sizes, and shapes, and forms, and options you have when it comes to picking out a server and deploying a server. What can the server really do at the end of the day? What's the point of a server? In fact, that's what we're going to start with first, is what is a server? What does it serve? And what are the different things that it can serve?

1:40That's what we talk about when we talk about the roles that servers play in our infrastructure. So I'm excited about this content, and I hope you are too. Because we're about to dive right into it and start talking about, what is a server, and what does it serve? Let's get going.

0:00[MUSIC PLAYING] When we talk about computers, in general, we just think of these machines that do-- you click, you point, you type, and it does all the stuff for us. But we've never really given a whole lot of consideration to what really happens when we turn our computer on. How does the computer know how to do things like get out to the internet? How does the computer know how to do things like access files that aren't on that computer?

0:30This is the magic of servers. And what we really need to do is we need to define where a server starts and stops with our infrastructure. And what are the other devices that are trying to connect to that server? What we're really saying here is we're going to break down the definition and the difference between a client and a server in this video. This is going to be important to understand so that we can start to see what the roles that servers play in our environment does for our clients. Let's get going. So we're going to begin our journey by demystifying what even is the point of a server?

1:04Why is it even called a server? What do servers do? I remember, when I first started getting into tech, you would hear the word server. And you would just think of this gigantic, abstract term-- server. You didn't realize that there were actually many different kinds of servers, no different from how there are many different kinds of IT employees or just like there's many different kinds of doctors or many different kinds of lawyers. There's all sorts of specializations, and servers are no different from that.

1:36And that's the entire point of this skill, really, is to talk about at a high level, what are these different types of specializations? But what does a server do at the end of the day? That's what we're talking about here. So I want you to think about this for a second. You walk into your office. You sit down in your chair. You press the power button on your computer. What happens next? Here's you, you're smiling. And this is going to be your computer. I'm just going to draw computers like little boxes here. You sit down.

2:07And you sit down, you press the power button on your computer. Your computer, of course, plugs into the wall. It's got power. But it's also got maybe an Ethernet jack that it plugs into the wall as well. And then, from there something happens, right? And everything else takes over. The computer boots up, and mysteriously, somehow, we now have access to the public internet. We can now browse the internet. We can now download files. We can now shop on Amazon. Or maybe we have access to all of these files that are within our network.

2:41We like to call them like the Z drive or the I drive or the J drive. What is really the deal with those drives? Or maybe there's an internal application that we access. Sometimes we call this the intranet. And that way, we access our internal application through a web browser, and we use that application to do our work. How does all of this really work? Well, that was just one fine example of you sitting down at your computer. But now think about what happens when the person who sits next to you comes into the office or the next person sits in-- and comes into the office and sits down at their computer?

3:15And the next person comes in and sits down at their computer, and they all turn it on. All of these things just mysteriously happen when everyone turns on their computer. But behind the scenes, what's really going on is these computers are each known as clients. Sometimes they're also known as workstations. Sometimes they're also known as computers or desktops. Sometimes they're known as endpoints. The point is, these are all devices that we use to be productive.

3:47And when we turn these computers on, what really happens behind the scenes is these devices are making all sorts of requests. They're begging. They're shouting into the network over the Ethernet cable asking for something. Somebody answer my questions, please because I have questions about how we're supposed to be accessing the internet. I have questions about how we're supposed to be accessing the intranet. I have questions about how we're supposed to be accessing all of these different files.

4:20Heck, even when you sit down at your computer, and you type in your username and password, something centrally is trying to determine if that username and password is even accurate, if you're even allowed to log into the computer. At the end of the day, all of these questions are being asked by these clients, and something has to respond to it. Guess what it is? It is a server. The server does exactly that. It exists to serve all of these requests that are coming in.

4:51Now, these requests are really broken down into different categories. And there's not just one overarching server that answers every single request that comes in. We can actually deploy a bunch of different servers that are specialized to answer these different types of requests. For instance, we may have a computer that plugs into the wall. We press power. And the very first thing it requests is, what is my IP address so that I can access the network?

5:21How do I find resources on the internet? These are very networking-specific requests. So that may be sent to our networking-style server. Here Knox's his head is in the way a little bit. This client right here may be asking, how do I access our main files that we use internally in our organization? And that request may be handled by the file server, which, its role in life, is to only serve the purpose of serving up files to everybody else.

5:52This device here might be trying to access the intranet through a web browser. So its requests may be sent over here to what's called a web server. Now, we're going to be digging into the details about what all of these different servers really mean and even, what does it look like to actually configure one of these servers? Do they all need to be completely separate servers? The answers lie within. And that's what really-- what really this entire playlist is all about is, how do these individual servers really work, and how do they act together?

6:22For now, the big point that you need to take away is that we have servers. And their sole purpose in life is to answer the questions of desktops. Even right now, in your home, you're running servers, whether you realize it or not. Remember you've got this router. Maybe you're getting it from your service provider. You're leasing it from your service provider or you provided your own. At the end of the day, your phone, your cell phone wants to connect to the Wi-Fi. And guess what? It needs an IP address. So the router will double as a server and hand out IP addresses.

6:53This is all the interesting stuff that, when you dig into the actual roles that servers play, you're going to realize pretty quickly that you've been exposed to this this whole time and never even realized. Now, the last thing I want to walk away with is why are servers so big? Why are those so powerful? And why are they so expensive? Well, the idea is that you could potentially have dozens, hundreds, thousands of requests per second. And we need to have a big powerful machine that's able to handle and answer all of these requests.

7:24I mean, think about a three- or four-story building. That's not uncommon. That's a medium-sized business. Maybe it's got 300 or 400 employees, and each of those employees has, of course, their desktop. Maybe they have a laptop. Maybe they have a tablet. Maybe they have a cell phone. And all of that is connected. And all of a sudden, we could potentially have thousands of devices within our infrastructure of a 300-employee building. And all of a sudden, all of those devices are trying to do things constantly-- reach out to the internet and download files, maybe like software updates, or reach through internally to download files, or find the intranet, or things like that.

8:01The reason why we don't want to have to have-- we want to buy one gigantic server that can serve all of these requests. And that way, we have one single device that we can configure. But of course, we keep redundancy in mind along the way. There's principles about redundancy that we're going to be talking about, especially when we get into the physical installation of servers and start to understand that a little bit more. For now, the big takeaway in this video is that the point of a server is to serve the requests that are provided by clients, the many, many, many different clients that we have throughout our entire infrastructure.

8:32Now, through the upcoming videos, we're going to talk about the different kinds of servers that could really exist in your environment. And then we'll actually talk about, what does it mean to actually deploy one of these kinds of servers? We'll take a look at it from the perspective of Windows. I hope this has been informative for you. And I'd like to thank you for viewing.

0:06I guess in the intro, I did say that I started out more as a networking guy than a server guy. But throughout my career, I became quite a bit of both. And I would argue that if the network doesn't work, absolutely nothing works. How many times have we seen, or at least thought about, that person standing over your shoulder going, hey, the network doesn't work. And then they stand there until you fix it, right? That's kind of what we're talking about here. So what we need to first focus on is, what kinds of servers manage our networks? How do servers help our network come to life?

0:39This is going to be a very important role that a server can play within our infrastructure. So let's take a look at the networking roles that servers can play. I'll see you there. In the previous video, we setup the concept that there were two types of servers. And one of those types of servers was networking servers. They serve a role within our infrastructure to help facilitate how our clients will get around the network. One of the very first things that we're going to talk about is, when we turn a computer on, we press the power button, one of the absolute very first things that these computers do is they start reaching out.

1:14They start shouting-- broadcasting is the key term-- out to this Ethernet cable, hey, I'm alive. But what I need is I need someone to give me an IP address. That way, I can identify myself on the network and now I can be routed throughout the topology or out to the internet. This process is using a protocol called DHCP. We're not going to get too much into DHCP right now in this video. There is a whole lot of dedicated content in DHCP.

1:45The thing that I want to point out right now is that when this thing starts shouting out into the network, it's sending a message called discover. I'm trying to discover where I configure out my IP address. And someone needs to discover me and hand me an IP address back. Guess what? In this case, we have what is called, very cleverly, a DHCP server. And this DHCP server is configured to respond to discover requests. When it receives a packet in on its Ethernet cable that's sent out to absolutely everybody-- because it's shouting.

2:21It's shouting out to the entire network, hey, somebody give me an IP address. The DHCP server is going to receive that and say, wait a minute. I'm configured to respond to these types of requests. And guess what? I have this gigantic pool of IP addresses that I can hand back to you. So I'll pick one out of that pool and send it back to you. The cool thing about this is this DHCP server keeps track of exactly which clients have received which IP address, and it rotates them in such a way that they're not permanently reserved for each one of these clients.

2:54If the computer shuts down, if the client shuts its computer down, it could more or less release the IP address back into the pool so that others can come along and get it later. So this is one of the very first networking servers and networking roles that exist, is the moment you turn a computer on, it's going to use the DHCP protocol to try and discover a DHCP server and find an IP address. The DHCP server will already be plugged in, and running, and listening for these discover messages so that it can pick an IP address out of the pool and send it back towards the clients, and say, hey, here you go.

3:31Here's your IP address and here's your default gateway so you can get out. And then there's one more thing about this DHCP request that it provides back. And that is the option to provide DNS options, or really, DNS servers. What's DNS all about? Domain Name Service, in networking terms. This is probably a website you've typed a few times in your life, google.com. You type in that domain name, google.com, and guess what? google.com is not what's used throughout the actual network itself.

4:04When this client here goes to google.com, what it really has to find out is, what is google.com's IP address? That way, we can send our packet directly to the google.com server. So what we have to do is we, humans, are really good at remembering these names. We're not so good at remembering IP addresses. So we have a server called a DNS server-- Domain Name Service server-- and its sole purpose is to take what we type in and translate that into the correct IP address.

4:36So when our DHCP server sends IP addresses back, it's going to, first of all, send an IP address. But it's also going to send the default gateway, like we've already said, as well as what DNS servers are. Now maybe the DHCP server is also a DNS server, or maybe a completely separate server is going to be a DNS server. The point is when our computer types in google.com, it's going to have to go look up, where does google.com really live? And it'll send a request directly to a DNS server, who will reply with-- make something up-- like 12.49.31.15.

5:13Sorry if that's your IP address. I just made that up on the fly. And now this computer knows, OK, when it's time for me to go to google.com, here's the IP address that I can send out into the internet. I can send my packet to this IP address right here, out into the internet, and google.com will now be able to handle my request. There's a lot more networking server roles out there in the wild-- I mean a whole lot more. But these are really the two big whoppers. Whenever you're deploying infrastructure, these are probably going to be the very first two things you deploy, because without IP addresses and without network connectivity, we really don't have much going on for us.

5:51So the DHCP server and the DNS server are absolutely critical roles to fill, so that way, all of our clients in our other servers can get connectivity into the network. I want to show you this. Here on the screen, I have a Windows Server pulled up. It looks kind of like Windows 10. At the time that we're recording this, Windows 10 is out. Windows 11 is going to be rolling out later this year. This looks like Windows 10, doesn't it? That's because, basically, Microsoft architects their clients and their servers on the same underlying operating system.

6:24The thing that differs is that the server has a couple little abilities where you can actually tell it what role it serves. So what I'm going to do is I'm going to unlock this. Don't worry about what you're actually seeing on the screen here. All of the stuff that's going on around it, this is a special type of operating system called ESXi. We're going to talk a lot more about virtualization and ESXi in upcoming content. So just for now, focus in on this box right here, where it looks like Windows is pulled up. I'm going to get signed in. Oop, wrong password.

6:54And yeah, take a look at what we got here. If I click the Start button, it looks exactly like Windows 10. The difference is that this Windows Server operating system comes with a piece of software called Server Manager. And the very cool thing about this is on our servers, we install the Windows Server operating system just as it is, just Windows Server as the operating system. There's not Windows Server networking. There's not Windows Server files. There's not Windows Server web server. There's just Windows Server.

7:24And then once we've got the operating system installed, we can actually come to Manage, and Add Roles and Features, and then walk through the little wizard and tell it exactly what role, or what purpose, or what kind of server it will be running in our infrastructure. So I know that the font's a little small here. But if you look right there where those checkboxes are checked, look. I've already installed the DHCP Server role and the DNS Server role on this operating system. All I had to do was click the checkbox, and click Next, and Install, and guess what?

7:57We've now turned this Windows Server operating system into a DHCP server and into a DNS server. And now it can respond to these types of requests, after a little bit of extra configuration, once we actually setup the DHCP server. I want to show you what that looks like real quick. This is going to be a very high level. Of course, this is a vendor-agnostic playlist. This is just to show you the examples. For instance, this little icon here is the DHCP server. So if I expand it out, under IPv4, we can see over here on this side, I've got some different IPv4 scopes setup-- basically, pools of IP addresses.

8:34I've got a scope setup for IOT devices. I've got a scope set up for HR devices. I've got a scope setup for my wireless access points. So when all of these devices plugin to the correct interfaces and the correct subnets, or VLANs, within our environment, this DHCP server can respond to each one of them and hand out the correct IP addresses, as well as DNS information. As far as DNS goes, I'll show you this real quick, too. When I expand this, real quick, I've set up a internal domain called nuggetlab.local.

9:05And when somebody types in that they want to access dc-nug, an A record tells it, well, dc-nug is exactly on this IP address. And in the event that somebody requests a URL or a domain that we don't support, like google.com, this device is configured to do DNS forwarding. So it has an upstream DNS server going out towards the internet, where it can look up further domains if it doesn't have the answer. Then-- very cool of it-- it caches that answer so that when the next client comes along and requests google.com, it already knows the answer and it doesn't have to do a forward lookup after that.

9:44So this is just to give you a feel for what does it really look like to turn a server into a specific kind of server? And how do we actually go about configuring these, at least on the Windows Server side of things? I want to stress this right now. You don't have to use Windows. Windows isn't the only kind of device that can run a DHCP server or a DNS server. All of your networking devices can do it and Linux can do it, too. So it's just nice to know that you have all of this flexibility. These are open, standard protocols that basically every vendor out there implements.

10:14It's just for familiarity purposes. We're all pretty familiar with Windows at this point, so this is what it looks like from the Windows Server side of things. So this has been understanding the network server role. I hope this has been informative for you, and I'd like to thank you for viewing.

0:00[MUSIC PLAYING] Probably the most well known role that a server can play in an entire infrastructure is the file server. And why is it the most well-known role? It's because every single employee in the infrastructure will use it at some point. This is a centralized place where we can store all of our files that the users want to use and access all the time. So what's the point of the file server?

0:31Why do we even need it in the first place? That's what this video is all about. Let's get to know what file shares and file servers really do. I'll see you there. Now this is an interesting one, because it seems really, really simple at first. But then when you dig into it, you realize pretty quickly that it's very complicated. Systems administrators spend a tremendous amount of time getting the file server set up. What is a file server? Well at the end of the day, you log into your computer. But you only have so much disk space, right?

1:01Maybe, super generous employer, and you get 1 terabyte of disk space on your computer. However, you have a need to collaborate with your other peers, with the people that you work with. So you're working on a file here. And then somebody else comes along they log in to their computer. And they need to access that file. So yeah, you could email it to them. But then they would have to edit it and then email the latest copy back to you. Meanwhile, you could be editing in at the same time. So you got an email the updates back to them.

1:33You see, this gets out of hand quickly. And we're only talking about a scenario, where two people are working on the same file. So you know, then there's somebody else who comes into the mix. And they need to work on that file too. And then guess what, your 1 terabyte hard drive craps out on you. And all of a sudden, you've lost that file and you have no way of backing it up. This is all a big, big problem when we have files sprawled out all over the place, located on only one disk drive that could fail at any given moment.

2:04So what we end up doing as server administrators and systems engineers is that we centralize file storage over the network. So all of these clients can now access files and folders over the network as if they're attached to their local computer. Oftentimes, you see this show up as something like an I drive or J drive or a Z drive. Or something like that. Of course, we know our local computers are going to have something like a C drive. That's what we always install to. And of course, the old school A and B drives were reserved for 3 and 1/2 inch floppy drives.

2:38And D drives were reserved for disk drives. But what happened after that? All of these other letters of the alphabet are left over. And that's what we can purpose for our file server. So our file server may have a tremendous amount of disk space. This could be something like-- make up something like 10 terabytes or 20 terabytes. In very large infrastructures, you have petabytes or exabytes that are available to you. And beyond that, they live on redundant storage drives. So if one of the drives gives out, that's OK, because we didn't lose anything.

3:13But beyond that, we also run backup software. So that we regularly take backups of all of the files. So if the entire server goes down or gets washed away in a flood, that's OK because we have backups of everybody's files throughout the entire organization, throughout the entire operating system. Now the other cool things about it is we can assign-- we can create folders here on the drive. And we can set these folders to either be visible by multiple people as part of a group.

3:44Or we can set folders to only be visible for individual users. So we could say, let's say, this is Karen here. We could set this folder to be Karen's private folder. And this is Bob here. We could set this folder here to be Bob's private folder. But then let's say Karen and Bob are part of an HR group. So in this folder we could create the HR folder that they can share with each other. And this is where it starts to get complicated. It's not so much about creating folders and then enabling the sharing.

4:16It becomes all about structuring the folders in such a way that they're hierarchical. We start off with large groups of people that can access the folders. And then we get into smaller groups and smaller groups and smaller groups, until we drill down to the individuals themselves. Then we have to control what their permissions are. Are they allowed to read, write, and delete in this folder? Are they allowed to read only in this folder? And this is what a sysadmin spends a tremendous amount of time doing, which in the Windows world is controlling NTFS permission.

4:49NTFS is where we associate what a user's file permissions are given their user name and when they log in to the network in the first place. When someone logs in, like Bob here, when they log in to the network they type in their username and password. Immediately, the network knows where Bob lives, what its IP address is, and what computer Bob is coming from, and what permissions does Bob have to access specific files and folders on the file server. That's the big thing that sysadmins spend a lot of time doing.

5:21And again, this is a vendor neutral certification playlist. So we're not going to talk about how to do that. That's what the Windows Server playlists are all about. Just wanted you to know that the file servers play a very big role. And that's not just necessarily having a place to store files. But it's also a place to keep files on redundant storage as well as backup the files that we have. That way in the event of a disaster, we can still get to all of our files that are being backed up regularly. Again, I want you to think big picture here.

5:52We could potentially have hundreds or thousands of employees who all need file storage. And they need to secure their file storage. And they need to backup their file storage. And that's again, why file servers, big, big servers, we pay a lot for them. We pay a lot for that storage. So this has been understanding the role of a file server in a network. I hope this has been informative for you. And I would like to thank you for viewing.

0:00[AUDIO LOGO] If the file server is the most well known and accepted server type that there is an environment, then I would argue that a close number 2 is the web server. The web server, is a device that, well, serves web pages. That way when you open up your web browser and you browse to a website, a server is the one that is actually serving the content that you interact with. Now, I'll say this right now, this sets up a bigger conversation about how the internet and web applications really work.

0:34But we're going to start off simple by talking about what they call the front-end application, which is going to be our website. So let's talk about what web servers do in an infrastructure. I'll see you there. Now, this one is pretty interesting because many people don't realize how browsing the internet really works. I mean, you're probably watching this in a web browser right now, aren't you? Have you ever given thought about what is actually, happening behind the scenes when you type in a website, a URL, and you press Enter? Well first of all, we know that DNS takes place, where the requests like google.com resolves to an IP address.

1:08But what is that IP address that we're trying to get to at the end of the day? That IP address, is the front facing IP address of a web server. And what is our browser really, doing at the end of the day when we try and go to that IP address? We use the HTTP protocol to actually, transmit information that we're trying to request from a web server. Let's pretend for a second that we're trying to get to google.com, and we're going over the public. And I like to pick on Google, because everybody knows that. We open up a web browser, we type google.com, DNS takes place and it says, OK, if you want to get to google.com, here's the IP address of that web server.

1:47So the HTTP protocol builds a packet that's destined for google.com, and it goes over the internet towards google.com, but then what really happens under the hood? Under the hood, the web server receives our request, and it replies with the information that we need to turn it into a website. What is that information? Typically, it's just an HTML document, like a text document, or any other document that you've ever downloaded before. All that's really, taking place in our browser, is we're using the HTTP protocol to request an HTML document, and the HTTP protocol from the web server replies with the HTML document.

2:26So our browser downloads the HTML document, it reads it, and it turns it into a human usable website that we actually-- it just interprets that code, and turns it into a website. That's it. That's fundamentally, it at the end of the day. Now, there is more to it, and that's what the next videos are talking about when we talk about web applications, but a static generic website at the end of the day, that's all there is to it. Is we're just downloading documents, and we use the HTTP protocol to do that. DNS, is what gets us to the web server and then, of course, routers and networks themselves get us to the web server, but the web server itself at the end of the day, is nothing more than a publicly facing file server that serves up HTML documents and other supporting documents that are used to render a website.

3:13Our browser, like Chrome, or Edge, or Firefox, or Brave, whichever one you're using right now, it's doing nothing more, than building the HTTP requests, receiving the documents back, and downloading them. Check this out. So I browsed in my Brave web browser here to opensea.io. This is a website, it's a open marketplace for purchasing and selling NFTs, Non-fungible Tokens, basically, for trading artwork on a blockchain. And I've got this cool little dog here that I've got up for sale.

3:45It's like little robo cyber dog it's really, really cool. If I press F12 on my web browser, brings up the developer tools, which I think is pretty neat. But when I go to the actual network section here, and I refresh the page with an F5, look at this. Well, you see all of these? These are the actual network transactions that went back and forth, that were used to render this document, this website. And what are they really here? These are just JavaScript files. If you see where I'm hovering-- I know it's kind of small font again-- but these are little .JS files.

4:15All of these JavaScript files are downloaded by my web browser, and then immediately used to render this website. So when I go to this website first of all, opensea.io, DNS translates that into an IP address. Look, I can do nslookup opensea.io, and there's the IP addresses right there that come back. From my command line, I can now resolve both IPv6 and IPv4 addresses, and I can try any one of these to reach out over the internet to get to this website.

4:47From there when I find the exact files that I want to access and view, it downloads all of these different JavaScript and HTML files here what we've seen in the network activity, and the web browser very quickly interprets each one of them to build the visual website that we see here and interact with. So this is what a web server does at the end of the day. When web developers generate their website, what are they doing? They're really just coding HTML and JavaScript documents. Then, they put them on the web server, who's then enabled to serve out all of this content.

5:18Now, I want to stress the different kinds of web servers. In the Windows world, there is the IIS role. Just like we saw before when we were installing DHCP and DNS roles, we go through that same wizard, and we can install the web server role, which installs the IIS application. Windows Server runs IIS to serve web content. In the Linux world, this is honestly, the more common web servers that you will see in the world today. Probably the most common web server that exists on the internet is Apache.

5:51This is, again, an application that you can install on Linux. But an alternative to Apache that is, again, very popular, is NGinx, that is N-G-I-N-X, and it's pronounced engine X. That is another important thing to understand because I see a lot of people stumble with that, but that's how this is pronounced. So whether you're running Windows on IIS web servers, or you're running Linux, you may be running Apache or NGinx servers, this is what you're going to run into in the world whenever you administer web server. So I hope this has been informative for you, and I'd like to thank you for viewing.

0:06Now, this stuff right here. This content that you're about to watch, this is where I break away from a structured playlist format that's going to follow exactly what the exam does, and start to talk about things in the real world. One of the things that I really wrestled with when I was a consultant and I was working with servers was actually understanding why specific types of servers exist, and why they're called an app server, or a database server, or a web server in the first place. And in order to really understand that, you need to understand the architecture of a modern application.

0:42Now, yes, this is a software development topic. But you, as a systems administrator or a systems engineer, you should really take just a couple minutes to learn why we're rolling out the servers that we're rolling, and how do they all interact with each other. That's what this video is all about. And that is going to be focused in on what does today's modern application really look like. I'll see you there. So this video is a little bit of a pause, a break momentarily to talk for a second about how applications work, how web apps specifically work and how developers, well, develop these applications.

1:17And you may be thinking to yourself, "Wait a minute. I don't want to be a developer. I don't want to learn code." That's fine. You don't have to. But the thing that I've encountered in my own personal experience that I think needs to be addressed is the fact that most systems administrators or systems engineers don't actually understand the applications that are running on their infrastructure. They don't really understand why they have to deploy these servers in the first place. And that's because they don't fundamentally understand how modern applications work.

1:50In order to know how to support applications by deploying software, you need to have a fundamental understanding of how apps work. Now, what am I talking about when I talk about web apps in the first place? I want you to think about any time that you've interacted with a website. Maybe you searched for a product. You added it into your shopping cart. You purchased it by charging a credit card, and then it was delivered to your address. That's actually an application that was just built into a website. And the real kicker here is that we talked about the web server in the last video.

2:25That's how you access the website and download the code. But it's not how you actually interact with the website. It's not where you actually charge your credit card. There are actually a bunch of servers that all work together to make that one application seem like a seamless experience. So let's kind of talk it out for a second. Here you are. You're on your computer. Right here, here's that little box that's your computer. And you're going to reach out across the internet. Let's pick on Amazon this time. So we make our way over here to Amazon's web server.

2:57I'm just going to write AMZN. And now we're interacting with Amazon's website. But there are utilities on that website. First of all, at the very top of that website, there's going to be a search bar. And you can dynamically type your own text into that search bar, and when you click a button, you're triggering the application to go get information. So for instance, let's say we're going to search for CAT 5E patch cables, right? We want to buy some patch cables, just like you've seen me browse on Amazon already throughout this series of courses.

3:33What really happens then? How does it really work? The web server that's running the website has just enough code deployed on it to where it can grab the text that you type in, and then send it to the next tier of the application. This is called the app server. Typically, it's called the app server, or it's sometimes called a middle tier server, or a middleware server. And basically, what the web server's job is to do is just to grab your request and hand it off to the app server that actually processes and handles your requests.

4:07So this text that you've got here, this CAT 5E patch cable, is going to be sent to the app server, which is running code behind the scenes. It's code that you don't physically see with your own eyes. There's not like a website that's running. There's just code that's running and listening for a command, or an instruction. In this case, the web server says, hey, the user has requested CAT 5E patch cables, so it's on you, app server, to go retrieve all the data that they asked for, and send it back towards the web server in such a way that it can present it to you.

4:41So the app server takes our CAT 5E patch cable request and translates that into a database query, because somewhere on Amazon's infrastructure they have a tremendous database that's just full of data about their products, prices, SKU numbers, availability, shipping information, blah, blah, blah, blah, blah, blah, blah. So the app server creates a programmatic query to pull the exact data out of the database and sends it back to the app server. The app server then takes those query results, those structured results, and translates them into a format that the web server can understand, which then sends the information back to you in the form of an HTML or a JavaScript document.

5:25Did you realize that all of this was going on under the hood? Maybe you did, or maybe you didn't. But immediately, what I see here is at a minimum three servers that were going to have to run just to support the search functionality on the Amazon website. Now, in reality Amazon's going to have like hundreds of servers doing just the search functionality, because it's Amazon. It's globally known. It's got gajillions of transactions per second, and that's what's going on. But immediately, I see I'm going to have my Amazon web server, which just is the front end.

5:55I'm going to have an app tier that's responsible for search only, and then I'm going to have a database that it searches through. But then what happens when I want to add a product to my cart? I'm going to click Add to Cart on the web tier, which is going to trigger a new app tier, maybe for the cart section. And then a new database maintains what is in my cart. So that way if I leave the website and come back later, all of my information is stored in the database, and it can be pulled out of the database and sent back to the website to show you what all is in my cart.

6:30Then it's time for me to purchase my product. So guess what. I click the Buy Now button. Let's hide Knox for a second. So you click the Buy button, and then what happens? Now, it's time to actually process the payment and schedule this item, these patch cables that I want for delivery. So we're going to have a big application tier, which is going to collect some payment information. But very critical to understand, it's not going to store that information anywhere. Why is that? We're going to talk about that when we get to data security, and we start talking about regulations.

7:02It's a big thing. But this is going to be the purchasing app. It takes the credit card information, then immediately punts it to an outside application, a different application. This is going to be something like PayPal or Stripe. That's another big payment processor. And these organizations are specifically built to do nothing but handle the actual charging of credit cards and debit cards, or the drafting of bank accounts, or handling payment processes. Once that card has been successfully charged, it communicates back to the application.

7:36And this application then says, "Cool. I've got a successful payment, and now I need to send this information over towards another application," which is going to be my logistics, my supply chain. So this is going to handle finding out where this device lives among all of the warehouses, all of these patch cables. Where do we have them actually stored as inventory, and which location is closest to me for shipping. And then it goes through the process of actually scheduling that application, or that-- my actual patch cables here out for delivery.

8:10See how I could probably go on, and on, and on, and on, and on, and on about all of the different moving parts to just one website, amazon.com? Now, extrapolate that towards all of your favorite websites. Google is going to work the exact same way. Gmail, your Gmail web app is going to work the same way. Newegg, where we all buy our computer parts from, is going to work the same way. Apple, every time we want to purchase a laptop, or put a laptop within our shopping cart, it's going to work the exact same way, right? You know, or our air buds, or all of the cool things that we like to purchase from Apple, because, I mean, I'm an Apple fan, of course.

8:45So the idea here is it's all the exact same thing that we've got here. This is a major application that we're talking about at the end of the day. And our infrastructure, us as a systems administrator and a systems engineer, it's more than just supporting a web server these days. Now we're going to have all of these additional tiers of application, all of these pieces communicate together through the usage of something called APIs. Now, very simply, what is an API? When we as a user want to interact with Amazon's website, we use the HTTP protocol.

9:21The HTTP protocol can specifically say, hey, this is coming from a web browser, and we are requesting some HTML, or JavaScript documents, or CSS documents, or whatever else it is to support it. And that's what gets sent back to my web browser, which then renders a website. However, on these applications over here, the app tier servers can also run HTTP endpoints. But when they communicate to each other, they're not requesting HTML documents. Instead, what they're doing is they're using the HTTP protocol to transmit raw data.

9:55Using the HTTP protocol, we can send data, or we can receive data. And this is all using APIs. So we may end up in installing web servers on all of these tiers, but never actually running a website. Instead, we'll enable an endpoint of our HTTP server so that internally all of these applications can speak to each other using our HTTP endpoints. But again, instead of transmitting HTML documents back and forth, we just transmit data back and forth.

10:27Now, if you're a real go-getter, you may be wondering, what does that data really look like? And I encourage you to look up something called JSON. This is the actual structure of the data. And it's based off of JavaScript objects. JSON stands for JavaScript Object Notation. So when the Amazon web front end is going to communicate down to the app tiers, it's actually sending JSON-structured payloads to the HTTP endpoints. And those applications know how to receive that data. And it knows exactly what action it should take with that data. So this is how modern web applications really work today.

11:00What you should now think about is, again, all about redundancy. Wherever you see one server here written on the screen, realistically, there's going to be at least two servers deployed in production. So that way, if one goes down, the other one can step in and fulfill the duties. So this has been understanding how modern apps work. I hope this has been informative for you, and I'd like to thank you for viewing.

0:00[MUSIC PLAYING] So in the previous video, we started to introduce the concepts about how modern application works. And we talked about how there would be a middleware tier, a tier that sits in between the data and the front end that handles all of the processing, all of the actions that the application does. Many people would argue that the front end is the most important, or the database here is the most important. I would actually argue that the middleware tier is the most important because it's the glue that ties everything together.

0:34This is where the actual application itself lives. And that's why it's called the app server. So in this video, we're going to do is talk a little bit more about what the app server really brings to the table and why we end up deploying them all over the place in today's infrastructures. I'll see you there. Now, one of the servers that feels the most fuzzy of all as systems administrators or systems engineers dive into supporting servers is the application tier server. And the real reason for that is there's not something that we can really touch and administer in this case.

1:05This is really just a landing zone for a developer's code. So let's talk about how this is going to work first of all. For the most part, we deploy this server. This is going to be our application-tier server. And the application-tier server is to sit in between other layers of our application. We talked about this in the last video, how on one side, there could be a database. And on the other side, there could be a web server. So the web server is what people are going to interact with.

1:37And somehow or other, people are going to generate or interact with data. That's what the database is all about. So maybe they're typing in their name, their first name, their last name, their address, and then they click Save. And the idea is the web server now has to take that data and get it into the database. Or maybe they click purchase, and now that purchase needs to go through, and records of their purchases need to be saved. The application tier is what handles all of that. But the really funny thing about the application tier is that we as a systems administrator are very hands off with the application tier.

2:13However, this is one of the devices that gets clobbered the most because, guess what, it's sitting in the middle of the application. Both of these servers here, server one and database server, are both trying to interact with the app server at the same time. So the app server's typically going to have a bigger load. Now, for the most part, how does the app server really, really work at the end of the day if we're not really running a website on it? Well, we are going to install web service roles. So, again, this may be something like Apache or Nginx in the Linux world.

2:49Or maybe if we're running Python, we may use something like Flask or Django. Or maybe if we're using a Windows environment, which is built on top of a framework called .NET, we may use something like IIS. The point is is that we, as the administrator, are going to be responsible for, first of all, deploying the server and then installing these roles or these applications into it. And then from there, we walk away. It's up to the software developer at that point to deploy their code to Apache or Nginx or Flask.

3:24And we just got to make sure that we have enabled the right ports in the firewall or the right network connectivity at the same time. So the application tier is kind of a funny one because it's not one that we really interact with very often. Now, when devs are creating the code that's going to run on the application tier, again, it really depends on what framework or what languages they want to write on. One of the most common languages that can be written for an application tier is Java. And as a systems administrator, when somebody says, hey, I want to run a new app server.

3:58It's going to run some Java code. That means we need to make sure we're installing the OpenJDK, which is the Java Developer Kits. We've got to make sure we have that installed for the developers so that when they deploy their code, it can actually run the Java code. Python is another very popular programming language that can run web servers very easily. This includes things like Flask and, again, Django. So we, as a systems administrator or a systems engineer, may have to install Python on the operating system.

4:31Windows does not ship with Python installed in it by default. Linux devices and macOS devices do however install with Python installed by default, but you may want to check which version is installed. So if you're running a Windows-based environment, you'll have to install Python before you can install Flask or Django. Or, alternatively, if you're running a Linux-based environment, which is very popular, you may just install Flask or Django directly. Then, lastly, of course, we talked about this .NET. When we have a Windows-based environment, and we're running Windows Server, .NET comes installed by default. However, versions are very, very important in all software programming languages.

5:11If .NET 3 ships on Windows servers, but my developers are trying to develop in .NET 3.2, guess what. 3.2 supports more features and programming words and things like that. That's a very high-level term there. Don't say that around developers. But it supports different code features in 3.2 than 3 can support. So they may write code and try to deploy it, and that will all fail because it doesn't have the latest version of .NET installed. So our role as a systems administrator, when we're interacting with an application tier, is we do have to know what kind of application is going to run on it.

5:49Is it going to be a web server, even though we're not deploying websites, but we still need to enable the ability to digest data as it comes in? Then, beyond that, what programming language are these developers wanting to use so that we can prep their development environment and get all of the applications installed? The big deal here is we tend to want to avoid delegating too much power to developers. The idea here is we don't want the developers to be able to install whatever software they want into all of our applications, because then there can be security risks or the actual programming code or installations themselves can be sprawled and differ from one app server to the next.

6:29And it becomes very messy when we do that. So this is understanding the role of app servers and what we as systems engineers or administrators have to do to support them. I hope this has been informative for you, and I'd like to thank you for viewing.

0:00[MUSIC PLAYING] Now, I actually began my technical career working with data as a data interpreter, a data analyst, where I visualize data that oftentimes came from a database. That spawned me into working with even more and more database technologies, like SQL servers, until I actually became a SQL developer, which spawned me into getting into networking and server roles after that. So databases in general kind of hit home for me.

0:33I feel like that's my cozy spot, since that's where I really began my career. So what we're going to do in this video is talk a little bit more about the roles and what a database server really brings to the table. We're also going to talk about job roles and who would be working with you when we talk about administering a database server. I'll see you there. Now, the last one that really throws systems administrators and engineers for a loop is the database server. And the reason why is because, quite frankly, they are big beasts in their own right to deploy and especially maintain and optimize.

1:07And what we as systems administrators and systems engineers end up doing is we rely heavily on the database administrator to deploy and maintain the server for us. They're the ones who are really trained to know how to install and configure and secure a database. Now, what is a database at the end of the day? It's just a gigantic collection of data. If you were to actually explore a database, what it would look like to you is just a set of Excel files.

1:40It looks like just like an Excel file, where you've got columns at the top and then rows of data going down. That's exactly what is contained in a database. So it's just dozens and dozens and dozens of all of these different Excel files. But there's one thing that makes them different. Pretend that I have an Excel file here. I'm just going to put X here. And I have a separate Excel file here. Now, I want you to consider all of the data about you as a person. You've got a name, you've got an address, you've got an age, you've got an eye color, you've got a hair color or maybe you don't have hair at all.

2:14Maybe you have a beard or maybe you don't have a beard. You're so tall. You've got X amount of education under your belt. You drive a car or maybe you don't drive a car. Maybe you ride a bike. There's just so much information about you as a person that would not be physically possible to store it in one Excel file. So what we do is we end up giving you an ID number like Knox. And we identify, in one of these quote-unquote "Excel files," the names of all of the people and the ID numbers within that Excel file.

2:51Then in a separate Excel file, we'll write the same ID number again, but instead of identifying the name, maybe we'll identify the address. I'm in Louisiana. And then, maybe in a separate Excel file, we'll identify the eye color, which in my case is kind of like bluish gray. Do you see what we're doing here? We use what's called an ID-- or really, in database terms, they call this a primary key-- that we can use to link all of the data that's spread out together.

3:22That way we can collect a tremendous amount of data, but we never actually lose our ability to keep track of who it is that we're really talking about at the end of the day because they have one identifier that's in common. Now, that's what a database does. And spreading all of this data out optimizes, first of all, how the data is stored on disk, and second of all, how quickly we can retrieve it because we can now specify, I want this exact subset of data from this one file.

3:52I've been calling this Excel files, in database terms these are actually called tables, tables of data. So we can specify what tables we want to pull data out of, we can get very specific to where we only pull out the data that we actually need. So this is all going to live on our server. Now, begs the question-- you may have heard about these different kinds of databases, but we'll go ahead and list them out now. Probably the most widely deployed, paid-for database server is the Oracle SQL servers. That stands for Structured Query Language.

4:24That is the language that we use to interact with databases. Oracle landed some big government contracts early on. Now Oracle's pretty much everywhere and they're a dominant force when it comes to databases. But right on their heels is Microsoft SQL Server. And that's also a paid solution. Then there's also free solutions like MySQL or PostgreSQL is what this was called. So I'll just group these together and say free, and I'll group these together and say paid.

4:54You won't need to know these for the exam, but you will need to know these for the real world. And it kind of begs the question-- like you look at these and it feels intimidating like, am I deploying a server with the SQL server operating systems on it? No, it's just an app. It's just an app that you install on your basic Windows server or your Linux machine. That's it. So when I install, when I deploy a new server here, I may install Windows Server 2019 on it or I may install Ubuntu Linux server-- just the basic operating system that I've always installed.

5:26But instead of adding a new role to it, I'll actually have to provide an installer for Microsoft SQL Server. Now, I'll also go ahead and say this now. There are free versions of Microsoft SQL Server. They call it SQL Server Express. You could download it, install it right now in your desktop. It will consume a lot of RAM and CPU cycles if that's what you want to do, but this is a great way to learn about how databases really work. Again, the database administrator's job is to be the one who deploys, configures, and secures the actual database software itself.

6:00And I'm going to tell you right now, they're going to be very skilled and talented and speak your language. The DBA, even though they know SQL and can write a whole bunch of code, they're really more in line with systems administrators and systems engineering. Because their role, primarily, is to add users and security permissions into the database that align very closely to our active directory servers, how we log into our networks. And beyond that, they're very focused on optimizing the database software itself by employing the hardware.

6:34They know how to do disk subsystems. They know how to optimize read and writes to the disks. They know how to optimize how RAM is allocated for the SQL server process. So this has been understanding what database servers are and where they fit in to our overall role about what servers do, what are the different roles that different servers can facilitate in our environment. Now, we've seen some of the core server roles, and now we have an idea of all of the different kinds of servers that can be deployed. I want to stress this right now though. There are literally hundreds of different kinds of servers out there that all do something unique and fascinating.

7:11We've only just covered a few of the basic categories of servers, but they're the really big ones that you're going to encounter in the real world. So this has been understanding what the servers are, what the foundations are, and what servers really do. I hope this has been informative for you, and I'd like to thank you for viewing.

0:06So now we've wrapped our head around what a server is. It is something that serves our clients. And we've seen that a server can wear many different hats. It can install many different roles and serve many different purposes in an environment. Lots of times, we will deploy a server to fill just one role, and then we'll deploy a separate server to serve a completely separate role. This is what today's modern infrastructure really looks like as we have lots of servers deployed all over the place that serve many different specialized roles.

0:40We've lowered our footprint a little bit when we introduce something like virtualization into the mix, which we're not there yet. We're not talking about virtualization just yet. Just know, for right now, that it's a very common practice to have a server fill one specific role and then a separate server serve the completely separate roles, and now we understand why so many different servers exist. I hope this has been informative for you, and I'd like to thank you for viewing.