Microsoft’s Azure cloud service has had a rocky journey to where it is today. Its initial focus on delivering PaaS was clearly too early for the rest of the industry, and it was only a pivot to hosting IaaS that gave it the users it needed to be successful. Still, Azure’s PaaS features aren’t going away. In fact, Microsoft continues to develop Azure as a platform for developers.
Earlier this week, Scott Guthrie, executive vice president of Microsoft’s Cloud and Enterprise group, explained how developers could take advantage of Azure’s latest PaaS features, with a focus on using existing .Net skills in the cloud. One key element of his talk was a look at building apps on Azure Functions, Microsoft’s main serverless compute offering.
Azure Functions leverages the serverless future
Serverless computing is a cloud buzzword, with similar offerings from Amazon Web Services, Google, and Microsoft. Of course, they’re not actually serverless; the term is more an abstraction away from the idea of the physical server as a host for your code. Instead of building to an operating system, you build to a set of APIs, expecting compute resources to be available when you need them.
That’s a tribute to how services like Azure have learned to deploy virtual servers, with Azure Functions’ underlying servers deployed on demand and torn down as soon as they’re no longer needed. Microsoft automatically scales the compute resources used by Azure Functions, and you’re billed for only the resources you work with.
That serverless approach makes Functions ideal for event-driven computing, a model that’s closely related to the microservice architectures that are increasingly popular for born-in-the cloud code. Closely related to Azure’s existing WebJobs, Azure Functions have a simple programming model that works across various programming languages—including C#, Node.js JavaScript, and even Windows’s own batch-processing tools. The underlying WebJobs SDK lets Microsoft have a single runtime for all the language options, simplifying engineering requirements while letting developers use the tools and technologies they know best.
Building functions in Azure Functions
When you build a function in Azure Functions, you’re creating an API endpoint that takes JSON data over HTTP, processes it, and either triggers an action or sends the data on to other services. Triggers allow your function to respond to events in other Azure services, as well as to external events.
One note about functions: They must be stateless. There’s no guarantee you’ll get the same compute resources the next time an event triggers a function, so you’re going to need to manage state elsewhere. That means working with other Azure services like DocumentDB or building your own applications on a virtual server.
Instead of worrying about the complexity of data connections to different types of storage (and even to streams and message queues), functions have declarative bindings that describe the connection and the data. It’s easy enough to swap one binding for another, so while you may start working with Azure SQL, you can swap your binding to one that works with DocumentDB, without changing the code at the heart of your application. It’s an approach that gives you some element of future-proofing and means you can choose services based on performance or budget.
While most of Azure Functions’ use cases involve functions with Azure services, there’s also scope for working outside of Azure, via WebHooks to handle callbacks from web applications and from apps utilizing HTTP and HTTPS connections.
Microsoft has done a lot to deliver Azure Functions’ developer experience. Once you’ve defined a function, it automatically becomes a Git endpoint, so you can build it into a continuous integration process. Similarly, the local development client means you can test functions before deploying them, though any local code shouldn’t be used in production.
Much of your development will be in the Azure Functions portal, with a simple editor that lets you build, test, and monitor your code without leaving the Azure Portal. To further simplify matters, there are a set of templates for common Azure Functions patterns and languages. You can choose a template that’s close to your scenario and in your usual language, install it, then customize the template code in the Azure Functions editor.
Changing cloud architectures
Azure Functions’ serverless model means you don’t need to know anything about the underlying infrastructure; all you need to know are whether a function has triggered and how many times it’s triggered. You’re billed only for code that executes, making Azure Functions ideal not only for regularly triggered operations but also for tools that monitor for rare situations. For example, you can have a function monitoring a log-file storage blob for an IoT application that triggers log-file rotation when logs get to a certain size, without having to provision a server or configure an application on another part of your infrastructure.
One difference between Azure Functions and its competition on the other public clouds is that it’s an open source project. Microsoft aims to make Azure Functions portable, so it will run on your own infrastructure, whether on premises or on other public clouds. However, with tight integration to Microsoft’s own Azure services, you’re likely to get the most out of it on Microsoft’s own cloud. Still, knowing there's the possibility of portability should make it easier to justify building simple microservices around Azure Functions.
Another advantage to being an open source project: You can see the project backlog on its GitHub page and get a feel for what new features will be delivered when.
Using Azure Functions like this helps keep cloud infrastructure simpler, and it gets you ready for further PaaS development using tools such as Azure Service Fabric.
There’s a lot to be said for simply dispensing with virtual infrastructure and letting your cloud handle servers and networking invisibly under your code. Tools like Azure Functions may not be suitable for much of what you do in the cloud, but they point to a cloud future that’s very different from – yet valuable to – what we have today.