Intro into the Clouds — Part 4 — FaaS Compute

If you have got to this page without reading Part 1, I recommend to start with Part 1 first to know more about what is it about, why I decided to write it etc. (or Part 2 or Part 3).

If you ready, let’s continue…

—

There is another very important term that was created by Clouds — “serverless”.

“Serverless” means that you, as a developer, don’t need to worry about servers, CPU/RAM and infrastructure in general at all. You just build your code, deploy it to the cloud and let it run (and Cloud will take care of scalability and availability).

According to the Google Cloud Platform documentation, App Engine — is a serverless platform. And it is true, as you don’t need to provision any servers to run your application; however, you can still have control over instance classes if you want.

However, most people would put App Engine into the PaaS (Platform-as-a-Service) category, and say that the true meaning of serverless is FaaS (Function-as-a-Service).

So, what is FaaS?

According to Wikipedia: Function as a service (FaaS) is a category of cloud computing services that provides a platform allowing customers to develop, run, and manage application functionalities without the complexity of building and maintaining the infrastructure typically associated with developing and launching an app.

But wait! I promised that we would always start with a problem…

Interestingly enough, FaaS and PaaS were designed to address the same problem — let developers focus more (or even fully) on writing their code and less on servers (infrastructure).

However, the issue is that each problem solved by developers may require a little bit different approach. That is why there is no one single-and-best software language, framework, etc.

So, when you try to design a “perfect system” for developers without knowing what problems they may want to solve using it, you have to solve one important question: how much control do you want to give to the developer? Do you want to allow for selecting a language or you want to force everyone to use one language for simplicity? Do you want to allow users to load additional libraries or you want to make that impossible for better security and performance? Do you want to show your users how much CPU/RAM they are consuming?

And there is no right or wrong answer to those questions, because it may depend on the type of problems to be solved using your platform.

So, when it comes to control, PaaS solutions like Google App Engine are on the “give more control” side of the spectrum, but still trying not to cross the line and stay within the “serverless” area. FaaS, in their turn, are on the completely opposite side of that spectrum. FaaS services try to take full control of the infrastructure and just let you upload your code (set of supported languages is fixed and was very limited in the beginning, but is much better) and then run it (as well as scale, of course).

In case of Google Cloud Functions (the FaaS service within GCP), you may even write your code directly using the online editor (and even build your application using just your phone if you want…).

One area where FaaS are very popular is when you need to connect different cloud services together. For example, when a file is uploaded to a folder, a notification is sent or another service is called to process that.

There is no specific limit to the type of application you can build using FaaS. Some people build rather big and complex systems using just FaaS (as a compute option); however, this is more of an exception than some common practise…

As you have probably already guessed, there is no distinct border between FaaS and PaaS (especially because different cloud providers would give a little different definitions to those terms).

But, for example, in case of GCP, here is probably the main difference between Cloud Functions (FaaS) and App Engine (PaaS): when GCP runs your App Engine application, it actually creates dedicated VM instances that are used to run your application (you can even have control over the type of those instances if you want). In case of Cloud Functions, your code is running in a shared environment that you have no control over.

In reality, your choice between those services may actually be driven by the choice of supported languages, the need to install an IDE, the way you want to manage your source code etc.

• Cloud Functions: Qwik Start — Command Line
• Cloud Functions: Qwik Start — Console
• HTTP Google Cloud Functions in Go

—

So, now we have learnt that we have the following options in Cloud:

• Working directly with VMs, called IaaS (Infrastructure-as-a-Service)
• Using Kubernetes, called CaaS (Container-as-a-Service)
• Trying to abstract from infrastructure a little more and just deploy your code to App Engine, called PaaS (Platform-as-a-Service)
• Giving up almost any control and 100% focusing on your code with Cloud Functions, called FaaS (Function-as-a-Service)

Note: Some people know a very popular term, SaaS (Software-as-a-Service), Modern clouds provide lots of those. But we will talk about them later.

Are those all the available options? Well, it depends on what you mean…

If we are talking about names, then yes — IaaS, CaaS, PaaS, and FaaS are all the options that exist at this moment.

But, as you have noticed, borders are blended, especially on the CaaS-PaaS-FaaS side of things. And there are more services (and probably more still to be added) that occupy the place in between, e.g.:

• App Engine comes in 2 “flavors” — App Engine Standard (which was the initial one and is closer to FaaS with more restriction, but better security and performance because of the latter) and App Engine Flexible (which is closer to CaaS, as it allows running Docker containers without much worry about a managing K8S cluster).
• Cloud Run, which is another option to run your Docker containers without worrying about K8S clusters, but use Knative, open-source component build on top of K8S instead of some proprietary technology used in App Engine Flexible. You can find a comparison between those services, but differences would be minor and very technical (and are constantly changing). (If I had to guess, I would say that Cloud Run would eventually replace App Engine…).

The good part is that, with the end of Cloud Orchestration Wars and wide adoption of Docker Containers and Kubernetes, I hope that at some point we actually won’t see any separation between those options, and it will just be a simple selection during deployment (one will just need to select what to control and what not to…)

For example, if you wanted to develop an application for App Engine Standard (that was introduced in 2008 and still exists), you would have to write your application in a specific way (and use specific SDKs). However, you can write your application once, and then run it on App Engine Flexible, Cloud Run, Kubernetes Engine and even a VM… Let’s see what the future holds…

Another interesting set of labs you may want to check: Serverless Cloud Run Development

—

If you read to this point, it means you have completed first 4 lectures on Introduction to Clouds series.

I would really appreciate if you take a moment and leave your comment. I want to know if you like the format, style, detail coverage etc. And most importantly — if I should continue or do something else :)