Extending Azure Functions with custom handlers

Another benefit of the hyperscale clouds is their operational expertise and their infrastructure design. They can spin up a new server instance in seconds, providing compute on demand. And with container technologies, they’re able to quickly switch in new isolated environments and scale them up as necessary.

[ Also on InfoWorld: The best programming language to learn now ]

That’s where serverless technologies come in, building on those skills and the processes to rapidly launch small, stateless processes as necessary. Like much cloud-native development, these serverless processes are event driven, responding to messages, processing their contents, and passing the results on to the next element of a distributed application. As they’re launched on demand, they can scale rapidly, and as they’re billed per second of CPU time, they’re also relatively cheap when compared to a full-time virtual infrastructure.

The evolution of Azure Functions

Azure’s serverless elements are its Functions, easy-to-construct blocks of code that can be assembled into more complex platforms. They’re designed to work in conjunction with Azure’s messaging infrastructure, from its IoT (Internet of Things) services to its scalable publish-and-subscribe Grid. There are direct bindings to key Azure services, simplifying building a Functions-based PaaS application or using a Function to control and trigger other Azure-hosted applications.

Microsoft has continued to evolve Functions, and it’s now on the third release of its runtime. With that comes support for C# and F# based on .NET Core 3.1; JavaScript running on node.js 10, 12, and 14 (along with a TypeScript transpiler for more complex applications); Java 8 and 11; PowerShell 7 and Core 6; and Python 3.6, 3.7, 3.8, and 3.9. It’s a long list of languages, covering much of the enterprise development space, but it’s not everything out there. You can use earlier versions, but Version 3 is the default for new Functions.

Limited language support isn’t surprising; even with its size, Microsoft doesn’t have the scale to produce Functions runtimes for every language. However, there is an option that lets you continue to use your choice of languages. For example, you can work in Rust or Go while still looking like a Functions end point to the rest of your application.

Adding additional language support with custom handlers

Under the hood, a Function has a very simple architecture. Inputs come in through a trigger, which extracts the input payload and passes it to a language-specific functions host. This runs your code, sending its output payload to a predefined target. Microsoft now gives you the ability to build custom handlers around a generic function host that calls out over an HTTP connection to an external Web server that’s running your own code. The function host makes a request of the Web server, receiving a response that it then formats and forwards to the function target.

Copyright © 2021 IDG Communications, Inc.

Source link