ServerlessDays Amsterdam 29 March 2019

ServerlessDays is a small conference that is part of a series of community events. As the name implies, it’s about serverless architecture, which is about building applications where you only concern yourself with the application, and not with the server that it runs on. They are typically low cost, pay-per-invocation and highly scalable.

The two main providers are Amazon AWS Lambda and Microsoft Azure Functions. Google also has Cloud Functions, but this was barely mentioned.

Serverless-as-a-bank

Talk about Moneyou’s journey to serverless. Moneyou started 12 years ago as a mortgage product of ABN Amro with outsourced development. In 2016 it started as a retail banking app with in-house development, and they started with serverless because it’s easier to be secure and compliant than in their own data centre. The idea of serverless is that they don’t touch the OS and don’t do capacity planning. They use serverless.com infrastructure-as-code. They continually scan for compliance, eg if they find an S3 bucket without encryption then they notify the the team responsible so that it can be fixed.

Testing serverless applications

The testing pyramid for serverless applications can be thicker in the middle because it’s cheap to test a function.

Serverless machine learning

ML looks for patterns in existing data and predicts results for new data. Because ML tends to be server-intensive, there’s limited possibilities for serverless, but it can be used as the glue for binding together other services. Azure Functions has bindings for i/o to many data sources. Durable Functions can be used to coordinate jobs.

A couple of ML terms:

Where serverless falls short

Azure Functions can use smart scaling for pull events, eg for a function with a queue trigger, it can scale quickly when it sees that there’s a long queue. This is not possible for push events, eg HTTP trigger, because the function is reactive.

Coming soon: premium functions: A shortfall of functions is that they have a coldstart warmup time when the function scales to a new instance. With reserved instances there will always be one reserved instance, so that the scale is already ahead of current load, in order to avoid the coldstart. This is still within the consumption plan, but using one more instance than would otherwise be used.

It’s a common pattern to chain functions together, eg with queues. A fallback of this design is that it’s hard to handle errors. Logic Apps and Durable Functions coordinate the child functions.

Durable Functions invoke other functions in a way that looks similar to calling an async method. It may look like a long, sequential, top-level method, but it’s reliable. The Durable Function stores state and wakes up when needed.

Serverless security

With serverless, more of the security responsibility moves from the application developer to the cloud provider, but there are still many security considerations:

A couple of interesting points are:

Orchestrating functions

This talk was comparing the three main cloud providers, specifically in the area of orchestrating functions.

Azure Durable functions:

AWS:

GCP:

Safe deployments

Options for deploying:

Use a post-traffic function after deployment, eg to check NFA’s such as encryption being enabled.