DIY Serverless at Home – Going open-source

One of the drawbacks of using Functions-as-a-service (FaaS) with the likes of Amazon is vendor lock-in.  All of your APIs and extensibility are specific to that vendor. Project riff, an open source platform from Pivotal Software, aims to change that. Riff was shown at the recent SpringOne Platform in December and runs Java microservices using the popular Spring framework.  Riff achieves this by packaging up your code snippet into a Kubernetes container. When your function is called, the container orchestration spins up a new container, runs your code and then kills it off afterward. There’s language specific function invoker which supports Python, Javascript, shell scripts and of course Java. It relies on a ‘sidecar’ component which marshals communications between the event trigger and your code, ensuring your code is called in response to your chosen event, signal or notification. These events are largely focussed around HTTP calls at present. One of the nice things is that Riff supports (or plans to support) event streaming, basically meaning that your container (code) will stay alive for more than a single call, keeping the function ‘warm’ to avoid the common pitfall of cold-start wait times, and allowing the system to scale better. Riff isn’t alone, there are other efforts to create open-source Serverless alternatives, such as OpenFaaS, Kubeless, OpenLambda, Apache OpenWhisk and the Serverless framework. As the market is young we’re still waiting for the community to settle on a few ‘leaders’, so you don’t end up coding against the next BetaMax. Over the long term these frameworks will find their… Read More

Securing Serverless with Puresec

As we’re all aware by now, Serverless doesn’t mean there are no servers. It also doesn’t mean we can completely forget they’re there. Because our code still runs on computers, and those computers are normally in the cloud, we still have to think about security. Our code will be vulnerable to attack just like any other code. Old favourites such as SQL injection, privilege escalation, etc will still work if we’re not diligent. As the industry grows, companies will spring up to fill in the gaps. One of those companies announced their presence at the recent AWS summit in California. Normally you would protect your application not just with good coding practices, but with a firewall device with packet inspection and intrusion prevention capabilities. Now that architecture is abstracted away from you, and not something you can control. Puresec promises a “Serverless Security Runtime Environment”, and it’s now available in Beta form for AWS Lambda. There’s a series of blog posts on their site to learn more, which I’ll now be doing. You can include the SSRE library in your code as an import, and it can be trained to detect abnormal access patterns. It can then log that information into logfiles or onto a dashboard. When a malicious execution is detected, the SSRE intercepts it and stops your code from executing. It’s also capable of detecting potential misconfigurations such as a database or blob with write-access where your code only requires read-access. As is common in the serverless world, Puresec is offering billing based on per-execution.

A Look at the Serverless Framework

The Serverless framework gave Serverless its name, so I wanted to take a closer look at what it provides, and how it contributed to where we are today. The framework is downloadable from and provides a command line interface (CLI) for creating and manipulating serverless functions. It works with: Amazon AWS Microsoft Azure IBM OpenWhisk Google Cloud Platform Kubeless SpotInst Auth0 Webtasks It ships as an NPM package and relies on NodeJS v6.5.o or greater.  The basic framework is installed via  npm install -g serverless and then you add the vendor-specific extension packages (such as  npm install -g serverless-azure-functions for Azure). At the time of writing the latest version is 1.26.1, and like a lot of NPM packages, it pulls in quite a screenful of dependencies. The interface runs under Node so should work where-ever Node runs, so you’re covered on Windows, Mac, and Linux. Creating Functions can be created by the CLI using templates.  If you look at the help you get a complete list of available out-of-the-box templates: Available templates: “aws-nodejs”, “aws-nodejs-typescript”, “aws-nodejs-ecma-script”, “aws-python”, “aws-python3”, “aws-groovy-gradle”, “aws-java-maven”, “aws-java-gradle”, “aws-kotlin-jvm-maven”, “aws-kotlin-jvm-gradle”, “aws-kotlin-nodejs-gradle”, “aws-scala-sbt”, “aws-csharp”, “aws-fsharp”, “aws-go”, “aws-go-dep”, “azure-nodejs”, “google-nodejs”, “kubeless-python”, “kubeless-nodejs”, “openwhisk-nodejs”, “openwhisk-php”, “openwhisk-python”, “openwhisk-swift”, “spotinst-nodejs”, “spotinst-python”, “spotinst-ruby”, “spotinst-java8”, “webtasks-nodejs”, “plugin” and “hello-world” So most options are covered out of the box, including Javascript, Python, Java and .NET. I’m not going to cover everything here so you can follow along with the tutorials on their site. You can also pull existing services straight from Github and modify those instead of creating them from scratch. Authenticating When running serverless deployfor… Read More

Serverless on Azure – Azure Functions Review

I’ve been learning and using Azure Functions for the past couple of months, so this is my experience so far. Developing and deploying to Azure Functions is very simple if you’re running an up to date version of Visual Studio.  In the Visual Studio installer, be sure to tick “Azure Development” under the Web and Cloud workflow options.  At the time of writing the latest VS 2017 version is 15.6.4.  The free community edition works fine for this. Once that’s installed, you’ll have an option under File -> New Project to start an Azure Functions project: When you start a new project, you’ll get an option to select which API version you want to code against (v1 or v2), and a choice of triggers.  These can all be changed afterward they’re just useful scaffolding: Recently Microsoft released version 2 of the Azure Functions Runtime, which allows you to use .NET Core or .NET standard rather than the full-fat .NET framework.  There are some limitations however.  I’ve used both v1 and v2, but I’m only using Http and Queue triggers so I haven’t run into any issues (yet). The great thing about Azure Functions is you can write them in more-or-less any language, with bindings provided for C#, F#, Python, PHP, Javascript/Node and Powershell/Bash.  The function.json file is the heart of the function, and it describes how to trigger your job and its inputs and outputs. If you’re developing in a language with first-class support such as C#, then the functions.json file is automatically generated for you when… Read More