Newcomers to cloud computing might be a bit put off by the sheer number of acronyms in use, as there are a fair amount. In addition, just about everything is sold as a service (aaS) these days, even transportation. To try to clarify some of the available offerings, let’s have a look at some of these aaS acronyms, namely infrastructure as a service (IaaS), platform as a service (PaaS), containers as a service (Caas), and serverless, which is also known as function as a service (FaaS).

When trying to decide which of these offerings is most suited to you, one (not incredibly helpful) way to look at it is: how much money do you have to spend?

decision-tree

Plenty of cash

Let’s start with the most expensive solution and work our way down. If you have an unlimited budget, you might not need any of these offerings. You could buy your own building, fill it full of racks of servers and networking gear, and hire your own staff to install, run, and maintain it. You’ll probably need a fair share of air conditioning units as well.

But that isn’t likely the case. Even government entities with unfathomable budgets hire outside companies to run data centers for them. Why? Because realistically, doing all that yourself is quite a pain, and probably what brought about cloud computing in the first place. Which brings us to the first offering up for discussion: infrastructure as a service (IaaS).

The opposite of crumbling infrastructure

IaaS most closely resembles having your own data center. You get to control how many of whatever kind of machines you need, the network that connects (or separates) them, and the forms in which your data is stored. You can rent actual hardware or get virtual machines that behave just like them. This is the most expensive offering, but offers the most control.

That ends the usefulness of cost as an indicator of which offering is most helpful to you. It isn’t often that cost is your sole limitation, but it is probably a very important concern. A better decision could be made based on how complex your endeavor is. We can also look at this question in regards to your required level of control.

Function over form

Can what you are trying to accomplish be broken down into short pieces of code? If so, a function as a service (FaaS) implementation might be a good fit. Here is an example of a project I recently worked on. When a GitHub issue was given a particular label, I wanted a new repository to be created:

cloud-function-action

In this example, an action is run when a webhook from GitHub is generated. The action checks to see if the label it is looking for has been applied and, if so, makes an API call back to GitHub to create the intended repo. This works great as a cloud function, which is a short bit of code that is triggered by an easily defined event. This is where some serious money can be saved. You’re only charged for the time it takes to execute your small bit of code. If your code is only executed a few times a day, that amount could be as little as a few seconds.

Now arriving on platform one

While FaaS can be very useful for splitting up small tasks, it isn’t a good fit if you want to deploy a larger or more complex application. Platform as a service (PaaS) may be more to your liking. A platform such as IBM Cloud Foundry lets you publish, update, and scale your application without worrying about the kind of hardware it is running on. You gain a bit more control with a PaaS offering, like being able to specify the number of instances you run of your application and how much memory each of those instances are allowed to consume. With PaaS, your application is always running, as opposed to FaaS, where your code is only executed when needed. As such, more resources are used so the price goes up.

faas-decision-tree

A good candidate for deployment using PaaS is what is commonly referred to as a front-end. This is the user-facing part of a web application that connects to and uses other back-end services that a user does not have direct access to, such as a data store.

The most popular sample application in the Cloud Foundry repository on GitHub is spring-music, a Java app that allows a user to browse and edit a music collection. This works well for deployment in PaaS, as the app can be scaled as needed, while the data store can be managed (backed up, made more resilient) separately.

sample-deployment-of-spring-music

Another important consideration when choosing a service offering is whether or not your deployment needs to save state. Stateful applications keep track of interactions and their progress, while stateless ones do not, relying instead on information accompanying any given request. It is certainly easier to push stateless code and leverage a platform’s managed services for handling request histories. If your desired deployment requires keeping state yourself, containers may be of use.

Contain your excitement

Between the PaaS and IaaS offerings comes containers as a service (CaaS), where you get to specify a bit more about the environment in which your application is running, such as the operating system. As the name CaaS implies, you deploy one or more containers, as opposed to just an application with PaaS. It isn’t a full virtual machine, however, as it is sharing a kernel with other containers, which has its own security ramifications. A major benefit of CaaS is the ability to deploy multiple containers at the same time that work in conjunction with each other. In a larger deployment, you can have separate containers for the front-end of your application, its underlying database, search capability, log storage and processing, etc. All of which can be managed as one group, which is called a cluster.

The following diagram represents one of the simpler examples of a containerized application, namely Guestbook.

guestbook-flow

When working your way through Kubernetes documentation, deploying a Guestbook application is your first exercise. It consists of a single-instance Redis master to store Guestbook entries, multiple replicated Redis instances to serve reads, and multiple web frontend instances. If you want to manage both a front- and a back-end, and also have control over how those two talk to each other, a CaaS offering aligns much closer to your needs.

One size does not fit all

Displaying the decision making process in a straight line, as I have done, is quite the misnomer. Especially because none of the above mentioned offerings are mutually exclusive. In the age of microservices, mixing any or all of these offerings together is a feasible reality for you to most effectively reach your desired deployment. It’s even possible to host a container as a cloud function. The resulting function isn’t always running so it wouldn’t be stateful, but it is a possibility. And the possibilities are almost as numerous as the amount of acronyms used to deploy them.

Hopefully you now have a better idea of where to start in your journey to the cloud!