Welcome back.

So today's video I want to talk about client server architecture in regard to client computing infrastructure.

So it is important to understand when I start talking about architectures where, whether I'm talking about client server architecture or service oriented architecture or server less architecture, these are methodologies for building out your infrastructure.

Don't get too hyper focused on the specific definitions of this thing, that thing or the other thing.

Basically, this is a way of looking and thinking about how to build your infrastructure and then from that concept, you will then go out and you will pick the technologies and you'll pick the specific products in order to build the infrastructure that you think will be good for your organization.

A lot of new people, whenever they first get into this, and they first started learning about architectures, they think it's they think it's, you know, 100% 1 thing or 100%.

Another thing that basically it's some kind of binary issue.

Either you have a service oriented architecture or you have a client server architecture or you have a server less architecture.

In reality, the fact of the matter is you're gonna have some client server stuff going on.

You're gonna have some service or into going on.

You want to maybe possibly have some several is going on, and then there's gonna be a couple of other architectures out there that will kind of get mission mash and all just kind of squeezed together into whatever infrastructure that you have built.

So whenever we're talking about these architectures, don't get hyper focused on any one thing.

Basically, this is a methodology.

It's a way of thinking about how you're going to be building your infrastructure so that once you have that idea, you're like Okay, yeah, this is how these things should work together.

Then you start figuring out the technologies that will actually allow that to happen, and then you figure out the products that will then implement those technologies to make all of that happened.

So we're talking about architectures.

This is just methodologies.

There's these air concepts about the ways that you're infrastructures should be designed.

Don't get too hyper focused on one specific thing.

So with this, when we're talking about client server architecture, we're talking about architecture style that's been around for a long time now.

And basically, this is the standard architecture style that you will have dealt with on your local area network.

So if you've been dealing with land environments, we've been dealing with active directory environments.

You've been dealing with old school e mail with extreme server environments.

That's the old client server architectures.

Basically, the idea with a client server architecture is that you have a server.

So you have a physical server.

That physical server has a server operating system on silent on it.

And then that operating system has specific service is installed on an operating system.

So think about active directory or extreme server FTP server.

Rounding a revote were crowding and remote access server, which is the VPN server.

The Microsoft World.

Right.

So think about that.

Basically, you have the sir, you have a physical server.

You have the operating system, a server operating system installed on the physical server and then on that operating system.

Then you have service is that will then be be provided to the clients on the network.

And then when you go out to the client computer, the client devices so compliant computer could be a laptop computer desktop computer.

Could be a laptop computer.

Could be a smartphone.

To this point, who knows?

Maybe a smart launching this point basically, have some computer that's a client computer that then has an application installed on that client computer that is able to communicate back to the server and be able to access the service is on the service.

That's why we call it a client server architecture.

You have clients.

You have client computers that have an application installed on them that are able to then get service is from the server computer.

And that's basically how networking has been built for a long time.

And so you're going to be dealing with this one way or another for a long time to come.

Now, one of the big things that's different about client server architecture versus some of the other architectures when you're thinking about designing this or when you have to maintain it, is that you have to deal with all of the equipment.

All the service is all the systems that allow communication happen between the client computers and the servers.

So when you're dealing with some of the other architectures out there Ah, a lot of times you really don't have to worry about the networking.

You don't have to worry about firewalls.

You don't have to worry about those types of things that has already been built into how the communication is supposed to happen.

Whereas when you're dealing with client server architecture, you're going to have to be dealing with everything.

So basically, you're going have a client computer, so that client computer is gonna have an operating system on it.

They're gonna have to make sure that's working properly.

Then it's going to have the app or the software on it that's gonna be communicating with server.

So you have to make sure that's working properly, and that's configured properly.

You have to have the server with a server operating system.

With the server, service is installed.

So again you have a physical server.

You have what's a server 2012 and then you have exchange servers.

You'd have to make sure extreme server and all of those things are configured.

Then you have to make sure things such as the firewalls, the ports and the firewalls are open of being able to to route traffic from the client computer to the server.

You have to make sure that can happen.

So if its internal to your local area network, you have to make sure the client computer on the servers are on the same sub net or that there was routing.

They're they're able to be communicated with through routers if your client computer is actually outside your land.

So let's say it's a remote work or something like that.

You have to set up the way that that remote worker is actually able to connect back to the server within your environment.

So whether that's through something like pork forwarding within a firewall or whether it's setting up VP and access right, all of those things have to be considered to make sure that your client server architecture works how it's supposed to work in the real world.

Back in the old days, 13 years ago or so, I was doing some work with a company on, they had a lot of remote workers, and one day they just got started getting inundated with help desk calls.

Basically, the VP and the service was no longer working, so they had a round in a remote access server within their environment and all their their their users, they're remote.

Users were able to connect to the internal environment using VPN to connect to that routing remote access server.

Well, where a weird thing happened, quirky thing happened.

As they say, Comcast, out of the blue blue decided to shut off the V p.

M port for residential clients.

Comcast just one day decided, Well, you know, residential clients, they don't need VP and access.

We're simply going to turn off the VP in port.

Um And so when they shut off the V P import over the Comcast network for the residential clients, all of our remote workers that used calm castes who no longer connect to the VP and service that they have a VP and client on their system, there's a VPN server that allows them access to the internal network and then they actually have to communicate over the I S.

P.

Since the Iast he decided to show off that particular port this service all just stop working in the blink of an eye, and that was just that was about it.

An amusing week.

And so that's something you have to be thinking about with clients.

Service architecture is you're not simply responsible for configuring the service.

You're not simply responsible for configuring the client.

You're responsible for everything that is required for the clients to be able to communicate with the server and make sure all that happens.

And so that's one of problems you can run into is if your eyes P just decides that we're gonna close a port, then you can run into a lot of major issues.

So that's one of things to really be thinking about what we're talking about, the client service client server architecture and why this is a little bit different than some of the other architectures.

So you may be sitting there thinking, Well, you know, if client server architecture is old and I'm young, so I don't want to deal with old stuff, why would I?

Why would I even bother with client server architecture anymore?

And the reality is there, and it is as you will bother with clients over architecture for the reason all of us deal with incredibly old crap that should been thrown in the trash years ago.

It's called legacy infrastructure.

So what legacy infrastructure means is all the crap that was built before you that basically the executives don't want to replace.

Remember, when you're dealing with executives, when you're dealing with managers in your company, they will be willing to spend money and possibly a lot of money.

To get better service is to get better performance to get something.

Maur.

They're not going to spend very much money to basically replace exactly what you already have with something else that provides the exact same thing on Lee.

The architecture is different, right?

So basically that that's one of the big problems is let's say you coded something way back when and PHP So you have a lot of code running and PHP you realize, Oh, you know, this would be so much better if it wasn't node.js.

So you think Hey, I'm gonna migrate all the code from PHP to node.js.

You go the executives and you say, Hey, I want to spend this much money migrating the code and they say, Well, why?

What additional thing are we going to get by having this written and node.js versus PHP, you go well.

It will be a little bit easier for the coders to know.

And it's a modern language Allah and basically, executives are going to say, So you want to spend all this money to essentially get exactly what we already have?

No, we will spend money on something else.

And so that's why you're going to be dealing with client server our protection for a long time to come simply because it is.

It is a legacy if you're dealing with large corporations or even medium sized organizations and companies, The fact of the matter is, they already have a client server architecture.

They already have their client computers communicating back, most likely with their their Microsoft servers.

And you're going to keep that going because it is easier to maintain and build off of what has already been built versus trying to start again from Square One is that's one of reasons why you're going to be dealing with the client server architectures now.

From that point, though, one of things you can start doing is you can start thinking about how you can start bringing the cloud into your client server architecture how you can start migrating so Miss Service's off onto the cloud and that type of thing.

Eso, let's say with with email service, is so you may have outlook, so outlook is installed on your Microsoft client computers, and then you have exchange server on one of your Microsoft servers.

And so again, that's a client server architecture.

That right there so one of things you might start thinking about is like, Well, you know, there's a lot of vulnerability with having one or two exchange servers.

This is big problem.

There's a lot of costs for maintenance and all that.

What about if we migrated that up to office?

3 65 So Office 3 65 is Maur.

I would argue more like a service oriented architecture type thing is a service that's being provided for you.

It's a software as a service model on DSO.

That's one thing.

You may look at a go, you know, instead of instead of upgrading to the next exchange server, which may cost us $50,000 servers plus all the labor to migrate up to the next version Exchange server.

Why not at that time.

Wine only mark my great office over the office 3 65 or the female premium Siri's or something like that to basically get rid of this vulnerability of this server that we have in our environment.

So that's something one of the things that you could be thinking about beyond that again, we start thinking about the whole client server architecture.

You start thinking about things about like, Well, where would be the best place to really put a server right?

Having a physical server with in your local area network is that Is that really the wisest way to be?

Providing service is to your to your clients, possibly simply doing something such as turning your physical server into a virtual machine, turning into a virtual server on, then running that within a hyper visor within your system or possibly up on the cloud.

That may be a better way to provide service is for your users than what you're currently using or even go with.

The whole medal is a service where you started thinking about, you know, like, well, do I really want to spend all this time and money having our own server room in our environment.

Or would it be better to migrate the servers that we have up onto the clouds basically purchased a dedicated server, migrate the service's and the data up to a dedicated server and then figure out how the architecture should be built that way?

So these are some of the things to be thinking about the whole client server architecture.

And then, as you start going into the future, not just simply again because his legacy, I mean, you don't have to upgrade everything.

So something's got me thinking about as well.

Maybe we should migrate to office 3 65 Maybe we should migrate to something else.

Then you could be thinking about Should you should you turn some servers and virtual servers instead of having his physical servers?

Should you move some of the physical servers from your environment up into maybe a co location facility or rent a dedicated server somewhere, that type of thing.

So these are some of the things to be thinking about if you're dealing with a client server architecture and think about going into the future with it.

So with what I have said, let's go over the white board for a second.

I just want to draw out a couple of examples of ways to be thinking about your client server architecture and how you might want to think about building this going into the future for the modern world.

So in the old days, client server architecture worked very well, cause more or less everybody was in the same building again.

For a lot of younger folks out there, you may not realize this, but D S L broadband connection really did not start coming into its own until 2000 or 2001.

Eso most people simply did not have the ability to do things like VPN access into somebody else's land.

Mobile phones, mobile devices.

They really have only come into their own within the last 10 years.

And so, basically, if you go back and you look at the architecture's and the infrastructure is that we were building not that long ago, uh, the idea was everything was in the same building.