Service Models

Now that we're putting a lot more services in the cloud, there's still a lot of options on how we put it up in the cloud. There are different service models.

A while ago, one of our main options for installing services was to go out and buy a physical server, install an operating system on it, and then install your services on top of that. That created some scalability problems. It was not very agile — that is, you couldn't roll out your services very fast — and so it really caused some problems.

Virtualization has been around for a long time, but the adoption of virtualization and putting things like a hypervisor in here really allowed us to scale faster with this. We could spin up new machines much faster without all of that delay.

Then came containerization. Once again, it's been around for a long time, but what happened is it became very popular. It's very similar to virtualization with a hypervisor, except we're not duplicating the operating system. And then we went serverless, where we didn't even have to have a server altogether. We would just create our scripts and we would run our scripts.

There's a use case and a benefit to each one of these, so we use them in different areas. But essentially what this all developed was our ability to go to the cloud, to move things to the cloud and not have it local. There are a lot of different ways that we can utilize the cloud.

On premise

First of all, I'm just going to compare things to on premise. Let's say we have our on-premise equipment. What that means is that I'm going to have to have a physical location to put the server. Let's say I have a server closet. It's not a very big one, but it's got a couple of racks in it and I can put a server on there and at least do something.

But of course I need to cool that room, so I'm going to have to cool it. I'm going to have to have an internet service provider come in and make a connection into my equipment, because I want it connected. I'm going to have to have the networking to it. I'm going to have to have power to it. I'm going to have to provide everything a data center would provide. So essentially I'm creating a little mini data center.

From there I need to interconnect my equipment, so I set up networking. I'm going to have to have storage. I'm going to set up a server. Maybe I have some sort of virtualization going on. I install the operating system on top of that hypervisor. Then I install some middleware, and I have this runtime environment and data where I have to manage everything running. I have to go in there and make sure it's running correctly, I have to monitor. And then I have my application, which is up and running, which is what my users are then connecting to. So this is what I have on premise, and when it's on premise I manage it all.

Colocation

There are different services out there, colocation services, where they will manage the data center and I can go and hire that data center. Then I set up my networking, storage and servers in there, all my physical equipment. I set it up with my hypervisor, my operating system and so on and so forth. So now I am managing less, because I don't have to go out and buy the AC, buy the power, buy the internet service provider connection. I don't have to provide that side of it. But that's still a lot.

Infrastructure as a service

So maybe I'm going to find some way that they provide infrastructure as a service — the whole infrastructure side of things. So they're providing the data center, the networking, the storage, the server, the virtualization, the whole bottom stack there. All I need to do is jump on their system and turn up a new machine. Maybe they have some pre-installed operating systems, or maybe I need to install the operating system, and then I manage on top of that.

So that's infrastructure as a service: the whole infrastructure is being provided. It's a service that's being provided, and I'm essentially renting that infrastructure part of it.

Platform as a service

Then there is platform as a service. Platform as a service is in between software as a service and infrastructure as a service. If I wanted to set up my own server, I'm going to set up an infrastructure as a service, where I don't have to manage the infrastructure but I manage the rest of it. But let's say I don't want to even manage the operating system. I don't even want to manage the middleware or the runtime. I don't need to do that. So platform as a service really just allows me to manage my application and have my application up and running on there, and it can be deployed.

A good example for infrastructure as a service — there are many examples, but one of the ones that I think is one of the best out there — is Amazon Web Services. For platform as a service, one of the best ones that I feel like is out there is Azure, Microsoft Azure.

Software as a service

And then there is software as a service. There's a whole bunch of examples of software as a service, but essentially you don't have to go in there and even manage the application. All you're doing is logging into it. It's a web application: you log into it and you're using it. An example of this might be like Gmail. With Gmail, I don't manage the hardware, I don't manage the email on the back end. I just manage the front end. I manage my inbox. That's software as a service.

The shared responsibility model

This is called a shared responsibility model. It's a shared responsibility because the responsibility of security and uptime and availability and all that fun stuff is shared amongst you and whatever service provider you have. The red line right here is like the delineation between what they are providing and what you are providing. I'm responsible for everything on this side of the red area, and the cloud service provider is responsible for all the red area down here. So it's a shared responsibility for maintaining these services and keeping them up and running.