WEBVTT 00:06.650 --> 00:11.900 Network architecture usually refers to the different topologies, hardware, software and protocols 00:11.900 --> 00:17.120 that we're using in our environment, where topology is literally how the network is laid out, the 00:17.120 --> 00:21.590 different hardware that we're using, the different software that we may be using in unison with that 00:21.590 --> 00:22.040 hardware. 00:22.040 --> 00:26.690 And of course, the protocols in which we're using to communicate and the different ports associated 00:26.690 --> 00:28.070 with those protocols. 00:28.790 --> 00:33.140 Network architecture is usually defined in the three distinct and separate formats. 00:33.170 --> 00:38.720 We have a client server architecture, a cloud architecture, and a peer to peer network architecture. 00:38.750 --> 00:41.570 A client server architecture is exactly like it sounds. 00:41.570 --> 00:46.310 I have a client talking to a server, and if I want to talk to another client, I'm going through that 00:46.310 --> 00:48.740 server in order to get to that specific client. 00:48.770 --> 00:50.990 This is closely related to most video games. 00:50.990 --> 00:54.770 You may see this with things like World of Warcraft, where everybody's jumping on a server in order 00:54.770 --> 00:56.090 to communicate with one another. 00:56.120 --> 01:01.670 You may also see this in something like a community forum or something of that nature where everybody 01:01.700 --> 01:06.140 is connecting to the server, and then interoperability comes from the server itself. 01:06.170 --> 01:09.410 In a peer to peer network, we're talking from client to client. 01:09.410 --> 01:13.070 There is no server that's in the middle of that communication strand. 01:13.100 --> 01:17.570 So if I have a client and I want to talk to my wife's computer, I have a direct connection to her. 01:17.570 --> 01:21.680 And we are literally talking 1 to 1 over that same line of communication. 01:21.680 --> 01:24.950 If I have more than two clients, then I need more than two cables. 01:24.950 --> 01:30.260 I need one cable going from me to my wife, and maybe another cable going from myself to my son, and 01:30.260 --> 01:33.440 then again myself to my daughter, maybe myself to whomever. 01:33.440 --> 01:38.060 So I need to have different connections for every person that I'm talking to, to have that 1 to 1 connection. 01:38.060 --> 01:42.320 It's not a very efficient manner for peer to peer network, but sometimes it does provide us a little 01:42.350 --> 01:44.150 bit more reliability and security. 01:44.150 --> 01:46.130 And then finally we have a cloud architecture. 01:46.160 --> 01:48.440 A cloud architecture sounds exactly like it is. 01:48.440 --> 01:52.010 We hook up into a cloud atmosphere and I use atmosphere. 01:52.040 --> 01:52.640 Kind of a joke. 01:52.640 --> 01:53.570 I hope you got the pun. 01:53.570 --> 01:58.130 But we hold up to that cloud atmosphere where we are literally talking over the internet. 01:58.130 --> 02:02.450 We're connecting to a centralized server, and then within that server we have different colored lines 02:02.450 --> 02:04.250 or different elements within our network. 02:04.250 --> 02:11.420 So unlike a client server architecture where I may have a client talking to a specific server, I'm 02:11.420 --> 02:13.820 going through switches, I'm going through endpoints. 02:13.820 --> 02:17.480 I have different IPS IDs involved in that. 02:17.510 --> 02:22.610 Within a cloud environment, I'm looking up into the cloud and the cloud provides that entire architecture 02:22.610 --> 02:23.510 available to me. 02:23.540 --> 02:25.130 So a little bit of difference in response. 02:25.160 --> 02:29.840 A lot of times in a cloud network architecture we're seeing different virtualized servers. 02:29.840 --> 02:32.360 We're seeing containerization, which we talked about. 02:32.540 --> 02:38.900 We really see that endpoint where the network itself is all virtual, as in we can't physically touch 02:38.900 --> 02:39.890 it and maintain it. 02:39.890 --> 02:45.770 This is what an stipulates a cloud infrastructure within an on premise network. 02:45.770 --> 02:47.870 This is something that you can physically touch. 02:47.870 --> 02:52.220 This provides additional security, meaning that I'm usually behind a locked door. 02:52.220 --> 02:53.990 We've got security guards in place. 02:53.990 --> 02:58.100 A lot of times this on premise would be much like what you may see in your house. 02:58.100 --> 03:02.780 You've got the network architecture going from your at home router or your at home switch connected 03:02.780 --> 03:08.130 to your modem or your cable modem, and then that provides us a gateway into the internet. 03:08.160 --> 03:09.510 We have more security. 03:09.510 --> 03:11.970 If somebody breaks into your house, you're going to know about it. 03:12.000 --> 03:16.380 However, if we took that same functionality and put it into a virtual environment, you really have 03:16.380 --> 03:17.520 no idea what's going on. 03:17.550 --> 03:21.480 You just know that you logged into it with an on premise network architecture. 03:21.480 --> 03:26.160 We literally have more control over what's going on within our within our enterprise network. 03:26.160 --> 03:29.640 We can dictate, hey, this port is open on this switch. 03:29.640 --> 03:34.650 This, uh, this firewall is looking for these specific items, and I'm going to turn off this port 03:34.680 --> 03:36.270 or I'm going to physically maintain it. 03:36.270 --> 03:42.030 I can physically translate it or transfer that firewall into a different make or a different model. 03:42.030 --> 03:46.140 I'm responsible for all the physical devices that are part of my network. 03:46.170 --> 03:48.060 It provides us a little bit more customization. 03:48.060 --> 03:52.830 If I want to do some weird things with my network architecture, maybe provide some access to the legacy 03:52.830 --> 03:54.510 systems, I can do that. 03:54.510 --> 03:59.700 I can arrange my network architecture any way I feel fit just by changing the cables around. 03:59.730 --> 04:04.770 I can also configure those devices in such a way that makes it more or less secure, depending on how 04:04.770 --> 04:05.490 I see fit. 04:05.520 --> 04:08.120 However, there's also an in-house maintenance requirement to it. 04:08.150 --> 04:12.650 Unlike a virtual system where they're taking care of all the maintenance and they're doing everything 04:12.650 --> 04:17.210 for you, you physically have to have technicians on staff that not only have the expertise, but the 04:17.240 --> 04:20.390 know how and how to interface with all those different devices. 04:20.420 --> 04:25.400 This often leads to somebody having a wide array of knowledge, because if you think about it, you've 04:25.400 --> 04:28.280 got firewall, you've got IPS, IDs, servers, client. 04:28.310 --> 04:31.850 There's just a wide range of different equipment that's inside of an enterprise environment. 04:31.850 --> 04:35.180 And you have to provide the expertise to work on all those different devices. 04:35.180 --> 04:37.760 However, Magus is usually faster as well. 04:37.760 --> 04:42.500 If I have an employee that is doing something and working for me, then 8 a.m. in the morning I can 04:42.500 --> 04:46.970 say, hey, listen, I want you to go do X on the firewall and they will go do it because they work 04:46.970 --> 04:47.570 for me. 04:47.600 --> 04:52.280 This also leads to more costly obviously by having the equipment in house, I'm not renting it. 04:52.280 --> 04:54.890 I'm not buying space on a virtual format. 04:54.890 --> 05:00.140 I have to have the actual physical device, which could run into the tens to hundreds of thousands of 05:00.140 --> 05:00.740 dollars. 05:00.770 --> 05:05.450 It's also the manpower aspect of it, hiring somebody that actually has the expertise and the knowledge 05:05.450 --> 05:10.460 and the know how to interact with these physical devices can be costly when it comes to actually fixing, 05:10.460 --> 05:14.660 repairing, installing and maintaining those different devices on my on prem network. 05:14.690 --> 05:20.180 There's also the matter of maintaining the on premises, uh, capability, meaning the building has 05:20.180 --> 05:23.870 rent, I pay for electricity, I pay for internet access. 05:23.870 --> 05:28.280 There's a lot of different on cost benefits to having an on premise. 05:28.310 --> 05:33.890 Uh, but it's definitely going to be costlier in the long run with all the different added, uh, costs 05:33.920 --> 05:34.970 associated with it. 05:36.380 --> 05:42.650 Unlike a cloud architecture where we go in and we have remote access to it, a lot of those different 05:42.650 --> 05:47.660 aspects of our network are actually virtualized or containerized, meaning that I log into the system 05:47.660 --> 05:51.590 and if I need to spin up a new switch, I literally tell the cloud architecture, hey, I'd like a new 05:51.590 --> 05:53.570 switch with an on prem network. 05:53.570 --> 05:55.970 If I need a new switch, I have to physically purchase it. 05:55.970 --> 05:57.260 That's an added cost. 05:57.260 --> 06:01.550 But the virtualized switch, it's maybe, you know, a little bit of an additional cost, but not near 06:01.550 --> 06:06.230 what I'm going to pay for a physical device, which could go in again to the tens of hundreds of thousands 06:06.230 --> 06:11.330 of dollars, depending on what type of switch you want This all makes it highly scalable if I want to 06:11.330 --> 06:16.970 go through a cloud architecture and I need to add an additional 50,000 users, I can easily spin up 06:16.970 --> 06:18.980 those access to 50,000 users. 06:18.980 --> 06:20.570 It's very quickly scalable. 06:20.570 --> 06:25.430 I can very quickly go through the process and say, hey, I need access to these additional users or 06:25.430 --> 06:27.350 I need to go forward in this perspective. 06:27.350 --> 06:30.050 If I was on prem, I'd have to order the devices for that. 06:30.050 --> 06:31.850 I have to wait for it to actually come in. 06:31.880 --> 06:32.960 I had to pay for it. 06:32.960 --> 06:36.740 Then I had to pay somebody to actually hook it up into my existing network architecture. 06:36.740 --> 06:40.730 I had to pay somebody to configure it, and I had to bring it online, test it and make sure it works. 06:40.730 --> 06:41.600 You get the point. 06:41.600 --> 06:46.190 There's that added cost to associated with the new equipment that I'm bringing into my on prem network, 06:46.190 --> 06:50.030 making it incredibly cost effective in a virtual cloud environment. 06:51.410 --> 06:56.840 There's different cloud service models that you need to be aware of software as a service or SaaS platform 06:56.840 --> 07:01.310 as a service or PaaS and infrastructure as a service or IaaS. 07:01.340 --> 07:06.380 Now, I know there's a lot more service models that have recently come out, but Cisa only requires 07:06.380 --> 07:12.350 us to identify these three and the differences between them The first one is software as a service. 07:12.350 --> 07:16.830 Now, software as a service is all about providing you, the user, with the data that you need. 07:16.860 --> 07:23.100 We're going to provide the applications, whether it's Microsoft Word or Adobe Enterprise or whatever 07:23.100 --> 07:26.670 you need that application, that software is going to be preloaded for you. 07:26.700 --> 07:29.310 All you have to do is go in and actually write the data. 07:29.340 --> 07:31.470 The data is the only thing that you're managing. 07:31.470 --> 07:35.550 This could be different aspects of it, but I want you to think of an Excel spreadsheet where you don't 07:35.580 --> 07:40.020 actually own the Microsoft program, but you own the data on that Microsoft program. 07:40.020 --> 07:44.070 This is software as a service with platform as a service. 07:44.100 --> 07:47.370 You own not only the data, but you also own the application. 07:47.370 --> 07:51.720 So they provide you maybe a windows box that has no software embedded upon it. 07:51.720 --> 07:55.230 You want to provide Excel to yourself on this platform as a service. 07:55.230 --> 08:01.590 So you download Microsoft Office 365, which then gives you Excel, and then you put the data on the 08:01.590 --> 08:02.490 Excel format. 08:02.520 --> 08:06.300 You own not only the application and you are responsible for the application. 08:06.300 --> 08:07.530 You also own the data. 08:07.530 --> 08:12.600 If you go to the platform, the cloud provider and say, hey, my Microsoft Office isn't working, they're 08:12.600 --> 08:13.350 not going to care. 08:13.350 --> 08:14.370 That's not their problem. 08:14.370 --> 08:16.470 They provided you the core operating system. 08:16.470 --> 08:19.080 You're responsible for the application that you put on it. 08:19.110 --> 08:23.970 Now, this is great if you are developing a new program or you're developing a new application that 08:23.970 --> 08:27.510 you want to showcase on a personal system, then it's fantastic. 08:27.540 --> 08:31.980 However, if you're just going to use it for something like Microsoft Office, I would recommend, uh, 08:31.980 --> 08:36.420 the software as a service model as opposed to the platform as a service model. 08:37.290 --> 08:39.270 Finally, there's infrastructure as a service. 08:39.270 --> 08:45.150 This infrastructure as a service provides us not only the operating system, the databases, the runtime, 08:45.150 --> 08:46.290 the application, the user data. 08:46.320 --> 08:49.890 You're responsible for all of that, which means they provide you a bare metal machine. 08:49.890 --> 08:56.550 This means that you need to download Microsoft, uh, Windows 11 or the Microsoft Server, or if you 08:56.550 --> 08:59.460 want to do a Linux box, whatever you want to do, that's fine. 08:59.460 --> 09:04.200 But I want you to imagine that you get a laptop and that laptop has no operating system on it whatsoever. 09:04.200 --> 09:06.090 That's infrastructure as a service. 09:06.120 --> 09:11.610 Now, this is great if you're developing new programs or if you're developing a specific software for 09:11.640 --> 09:12.600 a specific device. 09:12.600 --> 09:17.580 For instance, let's say you're developing a firewall software that you want to test on a firewall system 09:17.610 --> 09:21.900 infrastructure as a service would be the way to go, because you're overriding and getting this bare 09:21.900 --> 09:25.080 metal firewall that has no software on it, just the Bios. 09:25.080 --> 09:31.110 You can go on there and then input your new software that you develop and test it out in this order. 09:31.140 --> 09:33.120 This is great for different aspects like that. 09:33.120 --> 09:37.530 Again, I wouldn't use this if I was going to develop a new windows architect, right? 09:37.560 --> 09:42.900 Unless I'm actually going through and modifying windows to the point that I need access to those operating 09:42.900 --> 09:43.980 system files. 09:45.480 --> 09:47.370 Finally, we come to a hybrid architecture. 09:47.400 --> 09:49.440 Now we talked about the on prem. 09:49.440 --> 09:50.940 We talked about the cloud. 09:50.940 --> 09:54.630 And we literally talked about the hybrid architecture in the last lecture. 09:54.630 --> 09:56.940 But let's kind of go through this process again. 09:56.970 --> 10:02.700 Hybrid architectures are highly flexible meaning I can spin up different servers, I can expand my network, 10:02.700 --> 10:06.990 I can increase my network all within the cost confines that I want to do. 10:07.020 --> 10:12.600 Let's say that you operate a retail store online and Black Friday is coming up. 10:12.630 --> 10:17.340 You know that your average traffic is only 10,000 users, but you're building on this massive sale for 10:17.340 --> 10:18.120 Black Friday. 10:18.150 --> 10:22.050 You need to quickly expand your capabilities within that architecture. 10:22.050 --> 10:25.530 So you want to be able to handle that increased customer base that you were seeing. 10:25.530 --> 10:30.390 So let's say that you're going up to 30,000 new customers is what you predict for Black Friday and for 10:30.390 --> 10:31.800 Christmas holiday season. 10:31.800 --> 10:37.920 So you expand out your hybrid, uh, infrastructure to increase that 30,000 user base. 10:37.920 --> 10:42.690 However, as soon as the first of the year comes around, you no longer need that additional capacity 10:42.690 --> 10:45.900 because your user ability goes back down to that 10,000 users. 10:45.900 --> 10:47.220 So you scale back. 10:47.250 --> 10:51.000 This is where hybrid architecture really has a cost effectiveness to it. 10:51.030 --> 10:57.480 I can quickly scale up or scale back needed on my individual needs as an enterprise environment. 10:57.630 --> 11:02.760 We can see improved security in the cloud infrastructure as well as in the on prem network. 11:02.790 --> 11:03.840 What do I mean by that? 11:03.840 --> 11:09.300 Is within the cloud infrastructure, if I'm just spinning up different web servers to handle my clients 11:09.300 --> 11:13.380 and I improved performance, then those clients are seeing improved security because they're having 11:13.380 --> 11:18.090 to go through what the virtualized system or the cloud environment already takes for granted with its 11:18.090 --> 11:21.450 uh, with its, uh, Configurations for security. 11:21.480 --> 11:27.660 On the on prem side, we're seeing improved security because my HR department or my finances need aspects 11:27.660 --> 11:34.410 of security to ensure that only our employees, only our direct people in that operational environment, 11:34.410 --> 11:38.370 i.e., that department are capable of seeing those financial outputs. 11:38.400 --> 11:40.620 And so we have improved security on both sides. 11:40.620 --> 11:43.110 We also see an improved performance for much the same. 11:43.140 --> 11:47.550 Our improved performance within the cloud environment, meaning our customers are able to see increased 11:47.820 --> 11:52.380 or decreased latency as they're interacting with our website to buy different items that we're selling, 11:52.380 --> 11:58.440 but we also see improved performance on the on the on prem side, because my HR department is literally 11:58.440 --> 12:02.730 in the same building, meaning they can interact with the different financials or the different capabilities 12:02.730 --> 12:04.260 they need access to. 12:04.290 --> 12:09.510 This interoperability between the cloud and the on prem environment is very cost effective, because 12:09.510 --> 12:14.370 we're able to scale up very quickly in the virtual environment while keeping our on prem environment 12:14.370 --> 12:16.110 very secure and only needed. 12:16.110 --> 12:21.150 What we needed for this Harvard architecture is where we're seeing a lot of movement, especially in 12:21.150 --> 12:22.320 modern technology.