Serverless for the Enterprise

Published: October 16, 2018

Tags:

This blog is extracted from the MSIgnite session on “Serverless for the Enterprise” presented by Jeff Hollan (Sr. Program Manager, Azure Functions) and Matthew Henderson (Program Manager, Azure Functions).

Why Serverless

Today, every one of us wants to get things done fast. The fact of the matter is Serverless is a fantastic platform for doing things fast. Because, with Serverless, you really don’t have time to waste in terms of delivering your business value. Business of all sizes from enterprises to SMB is going through a digital transformation. Serverless is a technology where you don’t worry about the server underneath. Whereas, you can fully focus on your application and get your products to market a whole lot faster. In a nutshell, you don’t spend time and money thinking about infrastructure management, patching, scaling that’s all on the Azure platform.

One of the key things that are driving a lot of business to functions as a service model is the fact that it is so productive.

Sample scenarios for Functions

Service Platform in Azure has 3 key services like Event Grid, Functions and Logic Apps. This session will focus on explaining Functions. Here are some scenarios where you can use Functions as building blocks:

Web/Mobile App Workloads

IOT connected backends

Real time processing

Automation of infrastructure

Relativity – Relativity wanted to improve the customer experience of cloud-based e-discovery platform. The company decided to create a monitoring solution based on a serverless architecture powered by Azure Functions that proactively identifies and resolves performance issues. It really worked for them and they reduced 85% of time consumption in their projects.

FujiFilm – FujiFilm software started using Azure Functions to develop its file management solutions called Image Works. This along with implementing Microservices with Functions boosted the solutions stability and cut the development time by 75%.

Azure Functions 2.0

The big news for Azure Functions from MSIgnite is Azure functions 2.0 is GA. So what does it mean? Well, the core of this is your functions can now run pretty much anywhere.

Functions Everywhere

Azure Functions is an open source project platform, with host runtime. The host is basically the code that ends up running the code. Now, this is being rebuilt and it gets delivered in different ways.

You can run the exact same runtime on your local machine with Functions 2.0 that doesn’t have to be Windows. This means it can run on all platforms supported by .NET Core, including macOS and Linux. This enables cross-platform development and hosting scenarios. Visual Studio code has built-in support for Functions and if you’re using any other editor, you can use core tool CLI to run, locally set breakpoints, and debug etc.

Azure Functions runs in two different modes:
The Consumption plan automatically allocates compute power when your code is running. You don’t have to pay for idle VMs or reserve capacity in advance. The App Service plan is more traditional. Dedicated VMs are allocated to your function app, which means the functions host can be always running.

Furthermore, Functions can run on IOT devices like Raspberry Pi, AKS Service Fabric Mesh and more which makes it more interesting to play with.

Language Options

Azure Functions runtime 2.0 uses a new language extensibility model to improve tooling and performance. This version support C#, F#, JavaScript and Java. Language from Azure Functions 1.x are not updated to, so they are not supported in 2.0. The table indicates the programming languages that are supported in each runtime version.

Language

1.x

2.x

C#

GA (.NET Framework 4.7)

GA (.NET Core 2)

JavaScript

GA (Node 6)

GA (Node 8 & 10)

F#

GA (.NET Framework 4.7)

GA (.NET Core 2)

Java

N/A

Preview (Java 8)

Python

Experimental

N/A

TypeScript

Experimental

Supported through transpiling to JavaScript

PHP

Experimental

N/A

Batch (.cmd, .bat)

Experimental

N/A

Bash

Experimental

N/A

PowerShell

Experimental

N/A

Bindings and Integrations

When working with Functions, you are often working with different data source bindings and integration. The main goal is to make sure you’re actually more concerned with the data than the data source itself. While most of the trigger and binding properties and configurations remain the same between versions, in 2.0 you will need to install any trigger or binding to the app. The only exception for this is HTTP and Timer triggers.

Previously, all the bindings were bundled as part of the core runtime. In Functions 2.0, the approach is slightly different. The HTTP and timer triggers are baked into the platform, everything else comes in extension because they can be version independent. This brings a lot more control over what dependencies are added. You exactly know what assemblies are used and how they’re interacting with your platform.

These extensions give you access to new programming models like the Microsoft graph extensions which is currently in preview and the Durable Functions.

Creating a Function in Azure Functions 2.0

The first step is to add the function app, here you have 2 different options – Windows and Linux preview.

Next, you select the hosting plan, where you have the choice to select between the Consumption and App Service plan. Select the region for hosting.

The next big change is to pick the runtime stack. So now you can pick the language that your app is going to be using. Going forward, you also have a lot more control over the language stack. Javascript support for node 8 and 10.

Select the storage account – use the existing account or create a new account.

Once the app is created, you can add your code in different development environments like the Visual Studio, VS Code etc and you can publish it directly or use deployment center.

When you publish a project, there are few changes like publishing is moved to a package-based model. Here basically the code gets zipped irrespective of the language. This leads to a significant performance gain in Functions 2.0 runtime.

DevOps Best Practices

DevOps automates your development process making your products more reliable. The development process is often seen in 2 loops – the Inner loop and the outer loop. The inner loop is the iterative process that a developer performs when they write, build and debug code. The outer loop has steps like source control, build and test, deploy, run, and finally monitoring. It is just as important to keep the outer loop healthy as the inner loop.

Tools for Azure Functions DevOps

Local Tools – The local tools are the home for building the Function Apps, whether it is Visual Studio or VS Code or IntelliJ. These tools are good for writing the functions and quickly validate the code before publishing. Here you have to be cautious, it is not recommended to “Right click and Publish” the code to the production.

Deployment Center – The Deployment center is powered by the KUDU engine. The deployment center is fully integrated with App Services and Functions and it gives quick CI/CD. It is best suited for one-click deployment from GitHub or Source Controller. The only drawback of this tool is it is not as customizable as Azure DevOps and you don’t have options to customize deploying to multiple stages.

Azure DevOps – This tool was previously called Visual Studio Team Services. DevOps is a fully managed CI/CD platform. This tool requires more configurations, it is not a one-click setting tool. Historically Azure DevOps or other CI/CD tools rely on the technology called Web Deploy. So to take advantage of ‘Run from Package’ feature, build Function as a zip file and run from the zip in the VSTS or Azure DevOps.

Other CI/CD tools – You can also use tools like Travis or Jenkins or Octopus Deploy. Azure Functions team will work on getting extensive documentation for these tools.

Note: Generally, from DevOps perspective, if it works for Azure App Services then it will also work for Azure Functions. So, if you’re struggling with Azure Functions DevOps, it would work just the same with App Services.

Inner Loop Best Practices

Write unit tests for your Functions

How should this behave on success?

How should this behave on failure?

Mock external systems and side-effects

Environment variables

settings.json when local

Application Settings when published

Outer Loop Best Practices

Every function should be checked into source control

Feature / Bug branches should be tested before merge into master

Code compilation

Unit test pass

Deploy to stages

Development, Productions and Pre-production

Use release gates and approval (auto and manual) between stages

Use slots where appropriate

Optimized for HTTP scenarios

Be aware of scaling impacts to consumption functions

Enable App Insights

Serverless Security

Security is often discussed in shared responsibility model unless you are in On-prem. When using the Iaas, PaaS, SaaS and Serverless model the vendor is responsible for some of the components and the customers have some responsibility as well. Comparing PaaS and Serverless there is whole a lot of change in the Logical Application server, making a really strong security posture for your organization.

Azure Key Vault

Azure Key Vault is a tool for securely storing and accessing secrets. A secret is anything that you want to tightly control access to, such as API keys, passwords, or certificates. A Vault is a logical group of secrets. Azure Key Vault helps solve the following problems

Secrets Management – Azure Key Vault can be used to Securely store and tightly control access to tokens, passwords, certificates, API keys, and other secrets

Key Management – Azure Key Vault can also be used as a Key Management solution. Azure Key Vault makes it easy to create and control the encryption keys used to encrypt your data.

Certificate Management – Azure Key Vault is also a service that lets you easily provision, manage, and deploy public and private Secure Sockets Layer/Transport Layer Security (SSL/TLS) certificates for use with Azure and your internal connected resources.

Store secrets backed by Hardware Security Modules – The secrets and keys can be protected either by software or FIPS 140-2 Level 2 validates HSMs.

Update: Key Vault References – Coming Soon

Managed Identities for Azure Functions

Managed Service Identity (MSI) lets you securely connect to Azure AD-protected resources without needing to manage or rotate any secrets. If you need to work with a service that doesn’t support AAD, MSI makes it easy to work with Azure Key Vault for secure secret management. With Managed Identities, you can keep credentials out of code. The only way your code interacts with Azure AD is through a token service. This token is used to call other services like Key Vault and Azure Resource manager.

Serverless Security Best Practices

Standard PaaS/web app security is still a must have

New security tooling options needed

When you have more secret keys, managing it becomes more important

Permissions and grouping – remember the least privilege

Mind both inputs and outputs – the app is only as secure as its weakest endpoint

Hosting and Connectivity

Azure Functions runs in two different modes: Consumption plan and Azure App Service plan. Here is the difference between the hosting models. There is a new hosting model introduced in MSIgnite – Functions Premium Plan (Private Preview).

Related Posts

Author: Mohan Nagaraj

Mohan as a Product Marketing Executive is responsible for Product messaging and positioning, Sales Enablement, Market, customer, and competitive analysis. He combines his passion for business, technology, and writing to spread the word about Serverless360. Mohan is responsible to work with cross-functional teams to visualize and create product documentation and marketing content. He feels writing is so much fun and it is satisfying to capture the company’s soul & passion and make it live through documentation.
View all posts by Mohan Nagaraj