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


SUSE Linux Enterprise Server (SLES) is now available for Raspberry Pi

Ok, so it’s not serverless, but the Raspberry Pi 3B is available for just £32, which is pretty low cost. SUSE Linux have just announced that they’ll be supporting their Enterprise Server v12 SP3 on the tiny computer. The Pi has become very popular not only as a home hacker board, but as a media streaming box, and in lots of factories and warehouses where its lack of moving parts makes it ideal for use in dusty environments. If you’re happier with a supported version of  Linux which is guaranteed to stay the same for 3-4 years, rather than regularly doing “apt-get and hope”, this might be for you. At the moment this is only for the Pi 3B, additional builds/support for other models like the new 3B+ and the compute module should follow soon. If you’re stuck with what to do with your Raspberry Pi, there’s a ton of good suggestions here on weekend projects with a raspberry pi

You’re doing HttpClient wrong

Today I learned something that shocked me to my core. The following piece of c# code is wrong: using (var client = new HttpClient()) { // client.GetAsync(…); } Why is this wrong? Superficially, HttpClient implements IDisposable, and if you’re like me (and I suspect 90% of all .Net developers) you’ve been taught to diligently call Dispose() on anything that implements IDisposable. Except that HttpClient is a bit different, it’s actually designed to be a shared object, and thread-safe.  If you come up against problems with TCP socket exhaustion, you’ve probably got loads of connections in TIME_WAIT state, and it could be due to this simple issue.  The use of HttpClient in a using block is so common across the internet, and in Microsoft’s documentation that it was a real shock that this was wrong. What should I do instead? You can instead just instantiate HttpClient once, either as a class-level static, or pass it around in your IoC container.  You could come up against some issues with setting properties such as Timeout after instantiation, and it may not respect changes to DNS but if you’re having problems with using too many sockets this is the only solution. References:


So what exactly is serverless computing?

What does serverless mean? Wikipedia defines Serverless as “a cloud computing execution model in which the cloud provider dynamically manages the allocation of machine resources“.  It’s sometimes referred to as Functions-as-a-service (FaaS). The term comes from the Serverless Framework. So how does it work if there’s no server? Ok, all is not quite as it seems. There is still a server or in fact lots of servers. There is no magic, but the beauty is that you don’t need to worry about them.  You don’t pay for them or have to maintain them.  All that pain is shifted to the cloud service provider.  It’s similar to shared web hosting – you don’t have a server to yourself but instead, you share one with several other people.  It’s up to the provider to decide how many clients they can support on each server.  On the flip-side, you don’t get to decide what software should be installed on the servers, you’re stuck with the functionality provided.  The provider has gone out of their way to ensure you can’t even see the server. What’s the point? Why should I use it? Well, it means that you won’t have to worry about operating systems, patching, rebooting and most of your day-to-day maintenance. Serverless architectures work well as a set of microservices, or as a glue between layers of an application.  They tie in well with messaging frameworks and can often be triggered by multiple means such as queues, files, HTTP calls, and database triggers. Serverless normally support multiple languages such as .NET, Javascript,… Read More