Deployment Models

Let's start laying the foundation for what those deployment models look like, and discuss deployment models from an overall perspective.

The client-server relationship

Before we get too in-depth into this, let's make sure we have an understanding of the client-server relationship. Here we have a client machine right here. It has software that's running on it, some sort of app. That app is going to connect into a server that has a service that's running.

So what really is going to happen? Let's say it's a browser, and the browser browses to a website. The browser is on the client; it's an application. What it's going to do is send a request that's going to come over here to this service. Maybe the service is running Apache, and Apache is going to then respond to that request with some sort of response and send it back to the client machine, and that browser will then display it. That's how things like websites work.

There's a lot of different services that could be running. It could be DHCP, DNS, SMB, SMTP — which is simple mail transfer protocol — SNMP, which is simple network management protocol. And the list goes on and on. So there's different services that could be running, and there's different apps that could be running to make that request and get the response to display it.

Too many services on one server

Here we have a server, and this server is providing services for this network right here. What services is it providing? Directory services, DHCP, DNS, and even some file services. Now, let's say this is a Windows server machine that's providing these. This is really common, to put all four of these on the same machine. We're probably not going to have much issues with it.

But we decide we want some web services, so we spin up Apache on here. We spin up a database on here. Now we're going to maybe start running into some issues — maybe some resource contention, maybe there's going to be something that is going to be problematic between these programs and these programs on here. And there are some security concerns, because we're opening up more ports. So now we're going to start running into problems.

Then maybe we install some other third-party system on here, some sort of third-party application, and it really opens up a lot of security holes for the rest of these different services. Now this is problematic. We are having resource contentions. Now we have this third-party application which is causing problems with the rest of these applications here. So now we have some real issues on this server. This is a common thing that happens: we start running into those resource issues.

Separating onto physical servers

So what would happen is we'd start buying servers to separate this out. We would have our directory services, DHCP, DNS and file services on one server. We'd have web services and the database on another server. Maybe we have some sort of third party running on a third server right here.

The advantage of this is it creates stability and security. However, the cons to this: it can be costly, because now we're buying all this physical equipment. It has problems with scalability, because every time we roll out a new service, we have to roll out another piece of hardware. There's manageability, because we've got all of this equipment we have to manage. And just from an agility standpoint, the time it takes to roll out a full physical server can be problematic.

Virtualization, containerization and serverless

That's where virtualization, containerization, and serverless came along to help save the day with this. These are different ways that we can split out these services into their own kind of sections while not buying different physical equipment. So this was a real lifesaver to all of this, where we were able to buy just one piece of equipment that was capable of doing quite a bit, and then we would install these in virtual environments, in containers, or go serverless with it. This really helped us to be able to scale much better and be able to implement better security, make sure that we are managing our resources better.

So what are the differences between all of these? We're not going to get into it all in this lesson, but this is just kind of a model that shows you visually how they can all look a little different. We've got the bare metal, just the physical servers that they're on right here. And then on this one we have the operating system — so this is what we'd call bare metal. We have the operating system, and then we have the services right here residing on top of that.

Then we have a hypervisor. A hypervisor is virtualization. We virtualize these different operating systems on here, and there's a couple of different types: there's a type 1 and a type 2. So this is one way we can deliver those services.

Then we have the container engine here. So if we want to do containerization, this is another way that we could do this. And then serverless just means that we're running scripts through some sort of application.

Each one of these has their pros to it and where they really shine. They have their negatives or drawbacks to this, and then they also have some sort of use case for them. So there are specific use cases, and they're much more wider than what I have listed down here, but it just gives you an idea of what some of those use cases are.

Microservices

All this virtualization has also allowed us to do some sort of microservices. This is instead of having one app that does everything to it; we create multiple applications that all then communicate with each other using APIs or some other method, in order to break apart this code into separate programs. And we can better scale it that way.