If your application does not have internal state – and sometimes it is handling peak loads of requests while at other times it is not doing any work at all, why then should there be one or even more instances of the application (plus container and/or server) continuously and dedicatedly up and running for the application? For peak loads – a single instance is nowhere near enough. For times without any traffic, even a single instance is too much – and yet you pay for it.

Serverless computing – brought to prominence with AWS Lambda – is an answer to this. It is defined on Wikipedia as a “cloud execution model” in which “the cloud provider dynamically manages the allocation of machine resources”. The subscriber to the cloud service provides the code to execute and specifies the events that should trigger execution. The cloud provider takes care of running that code whenever the event occurs. Pricing is based on the combination of the resources used (memory, possibly CPU) and the time it takes to execute the function. No compute node is permanently associated with the function and any function [execution] instance can run on a different virtual server. (so it is not really serverless in a strict sense – a server is used for running the function; but it can be a different server with each execution). Of course, function instances can still have and share state by using a cache or backend data store of some kind.

The Serverless Function model can be used for processing events (a very common use case) but also for handling HTTP requests and therefore for implementing REST APIs or even stateless web applications. Implementation languages for serverless functions differ a little across cloud providers. Common runtimes are Node, Python, Java and C#. Several cloud vendors provide a form of Serverless Computing – AWS with Lamba, Microsoft with Azure Functions, Google with Google Cloud Functions and IBM with BlueMix FaaS (Function as a Service). Oracle announced Oracle [Cloud] Functions at Oracle OpenWorld 2016 (Oracle Functions – Serverless architecture on the Oracle PaaS Cloud) and is expected to actually the service (including support for orchestration for distributed serverless functions) around Oracle OpenWorld 2017 (October 2017) – see for example the list of session at OOW2017 on Serverless.

Note: monitoring the execution of the functions, collecting run time metrics and doing debugging on issues can be a little challenging. Special care should be taken when writing the functions – as for example there is no log file written on the server on which the code executes.

In this article, I briefly show an example of working with Serverless Computing using Azure Functions.

Steps for implementing a Function:

arrange Azure cloud account
create Function App as context for Functions
create Function
trigger Function – cause the events that trigger the Function.
inspect the result from the function
monitor the function execution

Taking an existing Azure Cloud Account, the first step is to create a Function App in your Azure subscription – as a context to create individual functions in (“You must have a function app to host the execution of your functions. A function app lets you group functions as a logic unit for easier management, deployment, and sharing of resources.”).

I will not discuss the details for this step – they are fairly trivial (see for example this instruction: https://docs.microsoft.com/en-us/azure/azure-functions/functions-create-first-azure-function#create-a-function-app)

Quick Overview of Steps

Navigate into the function app:

Click on plus icon to create a new Function:

Click on goto quickstart for the easiest way in

Select scenario WebHook + API; select JavaScript as the language. Note: the JavaScript runtime environment is Node 6.5 at the time of writing (August 2017).

Click on Create this function.

The function is created – with a name I cannot influence

When the function was created, two files were created: index.js and function.json. We can inspect these files by clicking on the View Files tab:

The function.json file is a configuration file where we specify generic meta-data about the function.

The integration tab shows the triggering event (s) for this function – configured for HTTP requests.

The manage tab allows us to define environment variable to pass into the function runtime execution environment:

The Monitor tab allows us to monitor executions of the Function and the logging they produce:

Return to the main tab with the function definition. Make a small change in the template code – to make it my own function; then click on Save & Run to store the modified definition and make a test call to the Function:

The result of the test call is shown on the right as well in the logging tab at the bottom of the page:

To invoke the function outside the Azure Cloud environment, click on Get Function URL.

Click on the icon to copy the URL to the clipboard.

Open a browser, paste the URL and add the name query parameter:

In Postman we can also make a test call:

Both these calls are from my laptop without any special connection to the Azure Cloud. You can make that same call from your environment. The function is triggerable – and when an HTTP request is received to hand to the function, Azure will assign it a run time environment in which to execute the JavaScript code. Pretty cool.

The logging shows the additional instances of the function:

From within the function, we can write output to the logging. All function execution instances write to the same pile of logging, from within their own execution environments:

Now Save & Run again – and see the log line written during the function execution:

Functions lets you define the threshold trace level for writing to the console, which makes it easy to control the way traces are written to the console from your functions. You can set the trace-level threshold for logging in the host.json file, or turn it off.

The Monitor tab provides an overview of all executions of the function, including the not so happy ones (I made a few coding mistakes that I did not share). For each instance, the specific logging and execution details are available:

Debug Console and Package Management

At the URL https://<function_app_name>.scm.azurewebsites.net we can access a management/development console where we can perform advanced operations regarding application deployment and configuration:

The CMD console looks like this:

NPM packages en Node Modules can be added to a JavaScript Function. See for details : https://docs.microsoft.com/en-us/azure/azure-functions/functions-reference-node#node-version-and-package-management

An not obvious feature of the CMD Console is the ability to drag files from my local Windows operating system into the browser – such as the package.json shown in this figure:

Note: You should define a package.json file at the root of your function app. Defining the file lets all functions in the app share the same cached packages, which gives the best performance. If a version conflict arises, you can resolve it by adding a package.json file in the folder of a specific function.

Conclusion

Creating a JavaScript (Node) Function in Azure Functions is pretty straightforward. The steps are logical, the environment reacts intuitively and smoothly. Good fun working with this.

I am looking forward to Oracle’s Cloud service for serverless computing – to see if it provides a similar good experience,and perhaps even more. More on that next month I hope.

Next steps for me: trigger Azure Functions from other events than HTTP Requests and leveraging NPM packages from my Function. Perhaps also trying out Visual Studio as the development and local testing environment for Azure Functions.