Microsoft Pushes Serverless Beyond Events and Functions
Microsoft continues to add new features to its serverless offering, Azure Functions, but at its recent Build conference, the company shows that it’s also developing a range of tools and services that use the same idea of not having to care about infrastructure for everything from workload orchestration to machine learning with Python.
It’s a sign how fast serverless technologies are maturing that some of those new features are less about development but monitoring and diagnostics for maintaining apps in production. Application Insights is now the default monitoring experience for Azure Functions, with an Application Insights instance created by default for every new Functions app (and available for existing functions) that uses correlation IDs, making execution counters both faster and more accurate.
Event Grid is one of the first public cloud services to support the new CloudEvents standard from the Cloud Native Computing Foundation.
Functions also now uses Azure App Service Diagnostics, with an interactive bot, Genie, that suggests diagnostic tools and possible reasons for errors and performance issues. That includes a Functions Health Checkup that analyses CPU and memory usage.
Going beyond Functions, Azure Event Grid takes the idea of serverless operations beyond Functions to an increasing number of services on Azure. At Build, Microsoft announced multiple new event sources (Azure Media Services and Azure Container Registry) and targets (Azure Storage Queues and Azure Relay Hybrid Connections) as well as input mappings that let developers map fields in their own schema to Event Grid events. To support external sources like IFTTT that don’t allow modification of the HTTP response POST for security validation, validation events will now include a validation event for webhooks, where making a GET request to the URL validates the endpoint too.
A Cloud of Events
Microsoft plans to expose events from all Azure services that can be managed by Event Grid using a serverless composition model, and Hybrid Connections allows WebSockets and server applications running on your own hardware to consume events. That means a WebSocket connection can relay events to an application that can’t expose a public HTTP endpoint because it’s behind a firewall or even on a desktop PC, so it can still get real-time notifications. The new Java management and client SDKs for Event Grid (and stable versions of the .NET, Node, Python, Go, and Ruby SDKs) simplify that kind of enterprise integration.
But event-driven programming is available on multiple public clouds and frameworks, and Event Grid now also goes beyond Azure as one of the first public cloud services to support the new CloudEvents standard from the Cloud Native Computing Foundation. The initial Cloud Events specification is very similar to an Event Grid message and Event Grid can send Azure Storage events to other serverless platforms, or consume events from other CloudEvents services and process them in Azure Functions or Logic Apps that are connected to Event Grid. CloudEvents means that the same trigger, like a photo being taken, can create an event that’s consumed by Azure Functions and AWS Lambda and other services.
As the scope of what can be built with Azure Functions increases, CloudEvent support will start to extend as well, Jeff Hollan, senior program manager for Azure Functions told The New Stack. Take the way Durable Functions simplifies handling state. This is now out of preview, giving Azure Functions a way to orchestrate long-running, stateful workloads so developers can chain together complex scenarios, use fan-in and fan-out patterns for scale or handle long callbacks without leaving a function running.
That means Functions supports design patterns like Map-Reduce, async HTTP APIs and orchestrating input from humans as well as other systems, which is nearly always asynchronous. Writing orchestrator functions in JavaScript is now supported via node.js, although it’s in preview because it requires the Azure Functions v2 runtime.
State is something serverless developers will need to cope with beyond Azure Functions, and the question becomes how much abstraction services can offer to simplify the task, because even CloudEvents doesn’t help here. “The way CloudEvents is scoped right now, it’s only about the shape of the message being sent and it’s very unopinionated about things like how the message gets there,” Hollan noted.
“CloudEvents is just the signal that says something has changed in your state; it doesn’t contain the state. We’re just at the beginning here. The developer dream is always that I don’t care where or how my state is stored, I just want to write code in a super decoupled way,” Hollan said. “We’re thinking about a world where I build apps and I want something to respond to events and maybe a lot of decisions are made for you because don’t care about it. If the state is in an S3 bucket or an Azure blob, or Cosmos DB or MongoDB, maybe we need an abstraction layer for when I don’t care where the state is and the serverless function should just know I have a new document and go use whatever service the state is stored in.”
At the moment, Azure Functions has an option where developers can choose whether a new function runs on Linux or Windows Server. That might seem odd for a serverless service, but it’s there because the Linux support is in preview and Windows support isn’t. In the longer term, that configuration will move to the Azure DevOps Project. Initially, that offered a very simple way to take applications running on either VMs or Azure App Service and give them a CI/CD pipeline using Visual Studio Team Services. As of Build, it also includes Azure Kubernetes Service for .NET, Java, and Node.js web app pipelines, and Azure Service Fabric support for .NET.
The idea is to guide developers to the recommended path for running the language and type of application a developer is working on, with intelligent defaults, and Hollan suggested that CloudEvents would help enable this. “We want it simple enough that a brand-new developer who is terrified of the cloud but knows what node.js and a website is can pick up serverless. Don’t make me choose between so many new concepts that they have thrown in their face that I’m just going to stick with on-premises because the distributed computing world scares me. If I want to host this in a way where I’m not managing any infrastructure, maybe I don’t have to know whether changing a setting means that something is going to live as a function or a pod in a Kubernetes cluster because the event will be the same.”
If CloudEvents takes off and gets support across the industry, Hollan hopes to see more innovation in how we manage and monitor these decoupled processes. “You might get excited building your first function or even your tenth, but when you get to thirty or forty functions, now you have all these tiny little pieces running independently. How do you make sure you have an eye on them all so you can manage the solution and deploy updates to that solution? I know have events coming from, say, Salesforce but how many functions are spinning up every time I add a customer? If I change something in my Salesforce database do I know how many functions that’s going to pin up?”
Taking More of Azure Serverless
Serverless models are showing up in other Azure services. The new Azure Machine Learning SDK for Python works with all the Python-compatible machine learning frameworks like TensorFlow and CNTK, covers key machine learning workflows from model training to deployment to scoring — and dispatches and manages the stages of those workflows on a serverless fabric with a mix of CPU and GPU configurations to suit different jobs.
The new Azure Service Fabric Mesh preview means you no longer have to set up the Service Fabric orchestrator, provision virtual machines, add them to a cluster and step through a series of management tasks to run a containerized app. Create a Service Mesh application project in Visual Studio and the service now handles creating the Azure resource group, setting up the containers and creating automatic placement rules to honor placement constraints specified for the application, using the full programming model for Windows, Linux, Java and .NET, including stateful services and reliable collections.
This turns Service Fabric into a fully managed, scalable, “pay for what you use,” serverless microservices platform which can orchestrate workloads in Azure or locally, which could be for local debugging with a simulated Service Fabric cluster or on a standalone cluster on your own servers, in another public cloud or even on an IoT device, all managed through the Azure portal.
“Azure Functions is a programming model, but serverless is a billing model more than anything else,” Hollan points out. “We have serverless containers with ACI, we have serverless mesh with Service Fabric. They’re different programming models. Functions is saying ‘associate me with an event.’ With ACI it’s ‘give me an entire container image and compute on demand but I’m not very opinionated about what that compute is’ and you can still have the economics of serverless. If you have a machine learning job that’s going to take eight hours to process, you would never do that as an Azure Function but you could spin up ACI to process the video, compress and caption the video. It’s a heavyweight process but it can still be serverless.”
That suggests that many more Azure services will offer serverless approaches as well as connecting to Event Grid and out through CloudEvents.
“The notion of on-demand compute that I only pay for when I’m using it will permeate far and wide,” says Hollan. “It’s much bigger than individual functions. We’re going into a world where all necessary compute should be available on demand.”
