The definition of a function in the FaaS or the serverless platform is that it should focus on only one objective. Due to the nature of the function, it should not be too complex. As we described in Chapter 1, Serverless and Docker, serverless FaaS is actually a subset of the event-driven programming model. All cloud functions on GCF behave that way. Every single component of our application pipeline is connected by sending events to another. Also, events can be monitored. When we receive an event from the source, a cloud function associated with that mechanism will be triggered to run.
The function supported by GCF must be written in JavaScript, or languages that are able to transpile to JavaScript. At the time of writing, the environment for executing functions is a Node.js v6.11.5. Basically, developers would use any Node.js runtime that matches the same version. Using JavaScript and Node.js yields good portability and it allows developers to test the function locally. In addition, using Node.js allows access to the vast numbers of Node.js libraries, including APIs offered by the platform (https://cloud.google.com/nodejs/apis), that help simplify development and integration.
GCF is designed to be a connection or a glue layer that links services together. In some use cases, we use functions to extend the existing cloud services.
With the event-driven model, functions can listen and wait until the file uploading event is triggered, when some files are put into cloud storage. We can also listen to log changing in a remote blockchain environment. Or maybe we subscribe to a Pub/Sub topics and get a notification to trigger the functions.
We usually put some complex business logic inside a function. Cloud functions owned by Google have the ability to access the credential system of the GCP, therefore, it could authenticate with the large set of GCP services. This feature usually makes the cloud functions very useful on their own platform.
All infrastructure and the system software layers are fully managed by Google's platform, so we need to care only for our codes. Autoscaling is also the normal feature of this kind of platform. Provisioning additional computing resources just works automatically when the number of triggers becomes large. Deployed functions will autoscale to serve millions of requests without any further configuration from us.
The fine-grained concept of an FaaS function makes this kind of computing fit nicely to implement self-contained APIs and WebHooks (we will demonstrate this in later chapters). Google Cloud Functions supports many aspects of workloads, for example, data processing/ELT, WebHooks, implementing APIs, acting as a backend for mobile applications, and accepting streaming data from IoT devices.
GCF supports many aspects of serverless computing. An obvious limitation at the moment is that it supports only Node.js as a programming language. GCF uses containers internally to wrap around the Node.js codes and deploy onto its internal orchestration FaaS system. A part of this engineering has been open sourced as a project called distroless. We can accomplish similar things with the concept of declarative containers, proposed in the final chapter. Using this concept allows us to deploy a workload containing only the application in the same way GCF does.
All of these use cases allowed by GCF will be demonstrated with different approaches using Docker and FaaS platforms in a later chapter.