Service, Please!

As an individual/business using "The Cloud", it's likely that what you want or need might be slightly different to another in terms of how much you want to be in control of, and therefore responsible for. Luckily, there is a solution for this - users will generally fit into 3 groups: 1) those who want to have maximum control but just don't want to have the hardware on premises 2) those who want to have control over everything they develop but don't want to deal with everything else and 3) those who have most things managed for them.

Let's start with the principle that allows for this flexible approach...

Shared Responsibility Model

This sort of does what it says really: the user and the cloud take ownership of different things, i.e. you "share" the "responsibilities" of your ecosystem with the cloud. How much responsibility you keep comes down to what you pay to be done for you, but you're generally limited to the three groups mentioned above. These service levels mean that you can (hopefully) make your life easier and also evolve your business/skills in a way that suits you.

Always remember though, you will *always* be responsible for what you develop, your data and the accounts that are allowed access to these things. As an example, you can check out the offerings for Microsoft Azure to see how responsibilities may be distributed.

So, let's get stuck into the different service models...

Infrastructure as a Service (IaaS)

This service gives you the most control. Infrastructure means the servers. It's a great model to have if you want to scale fast and easily but don't want to own your won hardware. In IaaS, the service you're paying for is the perk of not having to manage your own on premises servers. That means that virtual machines, networks etc. - everything your software runs on - is provided for you. But that's it. Everything software is your responsibility as the user and that includes install, cost, configuration etc.

Platform as a Service (PaaS)

This option was designed to support an entire lifecycle of a web app: build, test, deploy, manage, update. It provides you with everything that IaaS does and then some. Not only will you have your foundational infrastructure provided but also the middle ware. This includes your tools, business intelligence services, database systems etc. You're still responsible for what you develop, but you can avoid software licence complications and costs that you might encounter with an on premises system as you can often use one license for the multiple VMs.

Software as a Service (SaaS)

This is the most comprehensive offering, it includes everything that IaaS and PaaS have to offer but also the applications that you'll use. This is a fully managed service that usually involves buying a software managed service to use. For instance, G-Suite or Microsoft 365 for business collaboration, or Shopify for managing payments or even Spotify to listen to your music and good ol' Netflix! There are so many examples here that we use in business and our home lives.

Note though, you probably don't own the software, but essentially rent it for use, whether that's a one of fee or a subscription you pay for regularly. You get the latest features and no maintenance hassle!

BONUS: Serverless

Weirdly a bit of a misnomer, as of course there are servers but the term comes from the fact that as a user you don't have to worry about that AT ALL. This is not your problem, because you're using someone else's servers.

Serverless provision takes SaaS to an extreme and extracts the server from the provision so it's not your problem. Serverless allows for a single function of code to be hosted, run and managed without you needing to manage an entire application. These pieces of code are "single function" because they just do one thing. The great thing about this is that you can run that single function over and over again, and if it fails it won't affect the next run. For instance, it might be useful if you own a repository where people can upload their photos. Every photo is uploaded using the same function, that pulls the image from local and passes it to the repository. It can be used once or 1000s of times.

There is no one size fits all approach to Cloud, and thankfully the creators of Cloud platforms understand that. This is just a very brief introduction to these concepts, but hopefully enough to start you off and help you to understand the terms in case you're ever stuck in a meeting where these are talked about/someone is asking you!