Network architecture usually refers to the different topologies, hardware, software and protocols
that we're using in our environment, where topology is literally how the network is laid out, the
different hardware that we're using, the different software that we may be using in unison with that
hardware.
And of course, the protocols in which we're using to communicate and the different ports associated
with those protocols.
Network architecture is usually defined in the three distinct and separate formats.
We have a client server architecture, a cloud architecture, and a peer to peer network architecture.
A client server architecture is exactly like it sounds.
I have a client talking to a server, and if I want to talk to another client, I'm going through that
server in order to get to that specific client.
This is closely related to most video games.
You may see this with things like World of Warcraft, where everybody's jumping on a server in order
to communicate with one another.
You may also see this in something like a community forum or something of that nature where everybody
is connecting to the server, and then interoperability comes from the server itself.
In a peer to peer network, we're talking from client to client.
There is no server that's in the middle of that communication strand.
So if I have a client and I want to talk to my wife's computer, I have a direct connection to her.
And we are literally talking 1 to 1 over that same line of communication.
If I have more than two clients, then I need more than two cables.
I need one cable going from me to my wife, and maybe another cable going from myself to my son, and
then again myself to my daughter, maybe myself to whomever.
So I need to have different connections for every person that I'm talking to, to have that 1 to 1 connection.
It's not a very efficient manner for peer to peer network, but sometimes it does provide us a little
bit more reliability and security.
And then finally we have a cloud architecture.
A cloud architecture sounds exactly like it is.
We hook up into a cloud atmosphere and I use atmosphere.
Kind of a joke.
I hope you got the pun.
But we hold up to that cloud atmosphere where we are literally talking over the internet.
We're connecting to a centralized server, and then within that server we have different colored lines
or different elements within our network.
So unlike a client server architecture where I may have a client talking to a specific server, I'm
going through switches, I'm going through endpoints.
I have different IPS IDs involved in that.
Within a cloud environment, I'm looking up into the cloud and the cloud provides that entire architecture
available to me.
So a little bit of difference in response.
A lot of times in a cloud network architecture we're seeing different virtualized servers.
We're seeing containerization, which we talked about.
We really see that endpoint where the network itself is all virtual, as in we can't physically touch
it and maintain it.
This is what an stipulates a cloud infrastructure within an on premise network.
This is something that you can physically touch.
This provides additional security, meaning that I'm usually behind a locked door.
We've got security guards in place.
A lot of times this on premise would be much like what you may see in your house.
You've got the network architecture going from your at home router or your at home switch connected
to your modem or your cable modem, and then that provides us a gateway into the internet.
We have more security.
If somebody breaks into your house, you're going to know about it.
However, if we took that same functionality and put it into a virtual environment, you really have
no idea what's going on.
You just know that you logged into it with an on premise network architecture.
We literally have more control over what's going on within our within our enterprise network.
We can dictate, hey, this port is open on this switch.
This, uh, this firewall is looking for these specific items, and I'm going to turn off this port
or I'm going to physically maintain it.
I can physically translate it or transfer that firewall into a different make or a different model.
I'm responsible for all the physical devices that are part of my network.
It provides us a little bit more customization.
If I want to do some weird things with my network architecture, maybe provide some access to the legacy
systems, I can do that.
I can arrange my network architecture any way I feel fit just by changing the cables around.
I can also configure those devices in such a way that makes it more or less secure, depending on how
I see fit.
However, there's also an in-house maintenance requirement to it.
Unlike a virtual system where they're taking care of all the maintenance and they're doing everything
for you, you physically have to have technicians on staff that not only have the expertise, but the
know how and how to interface with all those different devices.
This often leads to somebody having a wide array of knowledge, because if you think about it, you've
got firewall, you've got IPS, IDs, servers, client.
There's just a wide range of different equipment that's inside of an enterprise environment.
And you have to provide the expertise to work on all those different devices.
However, Magus is usually faster as well.
If I have an employee that is doing something and working for me, then 8 a.m. in the morning I can
say, hey, listen, I want you to go do X on the firewall and they will go do it because they work
for me.
This also leads to more costly obviously by having the equipment in house, I'm not renting it.
I'm not buying space on a virtual format.
I have to have the actual physical device, which could run into the tens to hundreds of thousands of
dollars.
It's also the manpower aspect of it, hiring somebody that actually has the expertise and the knowledge
and the know how to interact with these physical devices can be costly when it comes to actually fixing,
repairing, installing and maintaining those different devices on my on prem network.
There's also the matter of maintaining the on premises, uh, capability, meaning the building has
rent, I pay for electricity, I pay for internet access.
There's a lot of different on cost benefits to having an on premise.
Uh, but it's definitely going to be costlier in the long run with all the different added, uh, costs
associated with it.
Unlike a cloud architecture where we go in and we have remote access to it, a lot of those different
aspects of our network are actually virtualized or containerized, meaning that I log into the system
and if I need to spin up a new switch, I literally tell the cloud architecture, hey, I'd like a new
switch with an on prem network.
If I need a new switch, I have to physically purchase it.
That's an added cost.
But the virtualized switch, it's maybe, you know, a little bit of an additional cost, but not near
what I'm going to pay for a physical device, which could go in again to the tens of hundreds of thousands
of dollars, depending on what type of switch you want This all makes it highly scalable if I want to
go through a cloud architecture and I need to add an additional 50,000 users, I can easily spin up
those access to 50,000 users.
It's very quickly scalable.
I can very quickly go through the process and say, hey, I need access to these additional users or
I need to go forward in this perspective.
If I was on prem, I'd have to order the devices for that.
I have to wait for it to actually come in.
I had to pay for it.
Then I had to pay somebody to actually hook it up into my existing network architecture.
I had to pay somebody to configure it, and I had to bring it online, test it and make sure it works.
You get the point.
There's that added cost to associated with the new equipment that I'm bringing into my on prem network,
making it incredibly cost effective in a virtual cloud environment.
There's different cloud service models that you need to be aware of software as a service or SaaS platform
as a service or PaaS and infrastructure as a service or IaaS.
Now, I know there's a lot more service models that have recently come out, but Cisa only requires
us to identify these three and the differences between them The first one is software as a service.
Now, software as a service is all about providing you, the user, with the data that you need.
We're going to provide the applications, whether it's Microsoft Word or Adobe Enterprise or whatever
you need that application, that software is going to be preloaded for you.
All you have to do is go in and actually write the data.
The data is the only thing that you're managing.
This could be different aspects of it, but I want you to think of an Excel spreadsheet where you don't
actually own the Microsoft program, but you own the data on that Microsoft program.
This is software as a service with platform as a service.
You own not only the data, but you also own the application.
So they provide you maybe a windows box that has no software embedded upon it.
You want to provide Excel to yourself on this platform as a service.
So you download Microsoft Office 365, which then gives you Excel, and then you put the data on the
Excel format.
You own not only the application and you are responsible for the application.
You also own the data.
If you go to the platform, the cloud provider and say, hey, my Microsoft Office isn't working, they're
not going to care.
That's not their problem.
They provided you the core operating system.
You're responsible for the application that you put on it.
Now, this is great if you are developing a new program or you're developing a new application that
you want to showcase on a personal system, then it's fantastic.
However, if you're just going to use it for something like Microsoft Office, I would recommend, uh,
the software as a service model as opposed to the platform as a service model.
Finally, there's infrastructure as a service.
This infrastructure as a service provides us not only the operating system, the databases, the runtime,
the application, the user data.
You're responsible for all of that, which means they provide you a bare metal machine.
This means that you need to download Microsoft, uh, Windows 11 or the Microsoft Server, or if you
want to do a Linux box, whatever you want to do, that's fine.
But I want you to imagine that you get a laptop and that laptop has no operating system on it whatsoever.
That's infrastructure as a service.
Now, this is great if you're developing new programs or if you're developing a specific software for
a specific device.
For instance, let's say you're developing a firewall software that you want to test on a firewall system
infrastructure as a service would be the way to go, because you're overriding and getting this bare
metal firewall that has no software on it, just the Bios.
You can go on there and then input your new software that you develop and test it out in this order.
This is great for different aspects like that.
Again, I wouldn't use this if I was going to develop a new windows architect, right?
Unless I'm actually going through and modifying windows to the point that I need access to those operating
system files.
Finally, we come to a hybrid architecture.
Now we talked about the on prem.
We talked about the cloud.
And we literally talked about the hybrid architecture in the last lecture.
But let's kind of go through this process again.
Hybrid architectures are highly flexible meaning I can spin up different servers, I can expand my network,
I can increase my network all within the cost confines that I want to do.
Let's say that you operate a retail store online and Black Friday is coming up.
You know that your average traffic is only 10,000 users, but you're building on this massive sale for
Black Friday.
You need to quickly expand your capabilities within that architecture.
So you want to be able to handle that increased customer base that you were seeing.
So let's say that you're going up to 30,000 new customers is what you predict for Black Friday and for
Christmas holiday season.
So you expand out your hybrid, uh, infrastructure to increase that 30,000 user base.
However, as soon as the first of the year comes around, you no longer need that additional capacity
because your user ability goes back down to that 10,000 users.
So you scale back.
This is where hybrid architecture really has a cost effectiveness to it.
I can quickly scale up or scale back needed on my individual needs as an enterprise environment.
We can see improved security in the cloud infrastructure as well as in the on prem network.
What do I mean by that?
Is within the cloud infrastructure, if I'm just spinning up different web servers to handle my clients
and I improved performance, then those clients are seeing improved security because they're having
to go through what the virtualized system or the cloud environment already takes for granted with its
uh, with its, uh, Configurations for security.
On the on prem side, we're seeing improved security because my HR department or my finances need aspects
of security to ensure that only our employees, only our direct people in that operational environment,
i.e., that department are capable of seeing those financial outputs.
And so we have improved security on both sides.
We also see an improved performance for much the same.
Our improved performance within the cloud environment, meaning our customers are able to see increased
or decreased latency as they're interacting with our website to buy different items that we're selling,
but we also see improved performance on the on the on prem side, because my HR department is literally
in the same building, meaning they can interact with the different financials or the different capabilities
they need access to.
This interoperability between the cloud and the on prem environment is very cost effective, because
we're able to scale up very quickly in the virtual environment while keeping our on prem environment
very secure and only needed.
What we needed for this Harvard architecture is where we're seeing a lot of movement, especially in
modern technology.