Moving to the cloud means more than not having to worry about hardware and system maintenance anymore; it’s a shift in the way you design applications and services. PaaS takes you further towards that than IaaS but serverless (sometimes called stateless) computing like AWS Lambda, IBM OpenWhisk, Google’s upcoming Cloud Functions and Microsoft’s new Azure Functions offers a different approach.
Unlike many PaaS options, you can write arbitrary code in the language of your choice and have it execute based on triggers and events; unlike IaaS, you don’t have to care about the VM or any other part of the infrastructure that code executes on.
That makes serverless a natural match for processing data from Internet of Things sensors, but it’s more widely applicable than that. IDC analyst Al Hilwa believes the model is “pretty broad — file processing, ETL, IoT data workloads or anything that requires back-end crunching. The flexibility, composability, productivity and cost efficiency of the cloud function model makes it compelling for developers.”
Nir Mashkowski from the Microsoft Azure Functions teams agrees the service is relevant for more than IoT, useful as it is for that. “It’s the whole idea of event-based computing, things like bots for Skype and so on, or doing DevOps using Functions to do management chores. We’re seeing some folks using Functions to implement search indexing for a WordPress site; that’s a canonical example of why Functions is so awesome in accelerating cloud development because you can use them for things that would have been a much bigger chore otherwise. You can do batches; you can do one-offs in protected environments.”
He sees this as a new tool to accelerate cloud development. “Serverless computing is another pillar; you get dynamic hosting plans and the ability to truly pay for what you use.”
Is Azure Functions Truly Serverless?
You can trace the service that’s now Functions back to Azure’s Web Sites service. “Even when we launched four years ago, we wanted to have the vision of PaaS implemented,” Mashkowski claimed; “the notion of shared hosting with horizontal scaling where you can purchase an instance that’s a promise of compute and memory power.”
With the addition of previously separate mobile app building, notification and workflow tools, the web Sites service evolved into the Azure App Service for building mobile, cloud and workflow apps and added the WebJobs SDK for running background tasks based on triggers and events. Even though the SDK is for .NET, you can do that in a variety of languages including PHP, Python, Node and Java because Microsoft uses JSON metadata to create bindings for multiple languages, and for WebJobs Extensions.
The functionality of WebJobs evolved well beyond the initial image processing, log handling and other tasks you need for a website, especially when Microsoft added WebHook support, and abstracted away the WebApp host WebJobs run on, into a serverless dynamic compute layer that does scaling, monitoring, diagnostics and telemetry. The combination of the flexibility of the WebJobs service and the experience the Azure team gained managing servers and allocating capacity proved ideal for building Functions.
“We manage a lot of servers,” Mashkowski pointed out. “What we do to manage all these promises of always having a warm instance for you means we became really good at understanding how much capacity is left to run to compute. We took the WebJobs SDK because they had an awesome experience with the bindings, and we took another project, called dynamic hosting plans, where we take all the free capacity that is that is used as buffers to guarantee reliability, and we are able to slot the atomic units of Functions in on those.”
Being based on the WebJobs infrastructure is also how Azure can make the economics of serverless work, rather like Google Drive slotting in your files on drives that would otherwise be left empty for performance reasons; Functions takes advantage of Microsoft’s expertise at managing images at scale to charge the fractional cost. “On the one hand, we had the innovation we needed to provide serverless; on the other, we figured out a model where essentially putting images on machines is something we do very fast and we don’t need to pass on the cost of getting images and lining them up to customers because we’re so good at it. And then we’re really good at measuring how much time your code really ran.”
So there is infrastructure under Functions, but you shouldn’t have to care about it. How true is that in practice?
“Given that Azure Functions are a specialization of a larger and more complex framework, with more features and options, it does mean that the model for using them is more complex than using AWS Lambda,” Hilwa noted. “On the other hand, the Azure team has done a great job with the user experience.”
So while there is a file system on the host you’re using, where you have a large amount of storage (currently 5TB), you only need to take account of that if you want to use it. There’s a very simple file layout for deployment, so you can use GitHub and CI tools, package managers like npm and NuGet, cloud storage, Visual Studio Team Services, the Functions portal or Azure Resource Manager templates, and there are templates for creating common actions like HTTPTrigger and QueueTrigger, plus a number of extensions, including DocumentDB.
“We have input bindings and output bindings,” explained Mashkowski; “Input bindings can be triggers like queue storage or file storage. We provide many formats, and we give you a strongly typed object you can play with. They’re all pluggable, and you can write your own binding extension for the WebJobs SDK.” Functions already has extensions for many other Microsoft services. “Functions is probably the easiest way to get a CRUD going in DocumentDB,” he suggested. “I can create an Azure Function to type into a DocumentDB connection, or put a file into Azure Storage or process an image with Bing Cognitive Services.” He promises easy ways to create bindings and triggers, both for developers and partners. “Instead of 40 or 50 lines of code to launch integration with Slack, all I do is visually say I want the Slack binding.”
In many of these areas, Functions is unusually advanced because it takes advantage of the maturity of the underlying PaaS platform, he suggested. “If I don’t like the web portal experience, I can develop in my IDE; I can download the WebJobs SDK and run it locally. It’s a bit more work than we want it to be but developers can run Functions locally and debug them — or use the features available for Web Sites like cloud debugging; you can debug Azure Functions in C# in real time already.”
I don’t want to know I’m running LAMP on RedHat; I just want to write my code — and for that, we’ll have the development model of Functions” — Nir Mashkowski, Microsoft.
Mashkowski promises more options for local development; real-time JavaScript debugging is possible already, but he notes that “it doesn’t meet our standard of smooth developer experience so you can expect it to keep improving.”
Currently, you need to use a release manager to do versioning, but Functions will get deployment features from App Services in future, like swapping between test and production environments. “You’ll be able to start managing versions and the more comprehensive things that real development projects need,” he promises.
The runtime is open source, and Mashkowski says that not only will there be a local runtime as well, but he expects Azure Functions to be available beyond Azure, and not just on Microsoft’s Azure Stack private cloud option. “I think will you see the development model available on other platforms, with a bias to Azure Stack. You may also see us detaching the serverless runtime model from Functions and making it available for other services.” He was careful to call that a strategy rather than a commitment but the strategy is that the potential savings of serverless computing aren’t tied only to Azure Functions.
Overlapping Azure Services
There’s some overlap with another Microsoft Service, Flow, which Mashkowski calls a sister product to Logic Apps in the Azure App service (and implemented on the same infrastructure); Flow lets you connect APIs and services into workflows. “The way we differentiate between Logic Apps and Flow and Functions is that Flow and Logic Apps are all about workflow; orchestrating steps together, making sure they’re transactional, making sure if the Flow stops it can be restarted. Functions creates a great way to implement some logic very quickly; we see it as complementary, they have a great natural affinity. You won’t see the Functions team focus on managing workflow between Functions; you can use Logic Apps or in some cases Flow for that.”
Rather than viewing serverless as competing with other cloud models like containers and microservices, Mashkowski suggests they’re part of a continuum of approaches. “I think containers are essentially a packaging format. If I use Docker Gateway to have a local development environment and then push it to the cloud, I know it’s going to behave the same way. If it’s not enough to use high-level services like Functions, you can package in a container.”
He predicts that containers will eventually end up running on serverless infrastructure too, which will mean not passing the cost of loading the container into memory onto customers who are looking value PaaS gives them. “I don’t want to know I’m running LAMP on RedHat; I just want to write my code — and for that, we’ll have the development model of Functions. I predict there will be a separation where we see serverless as the runtime and billing model, and then we see all these development paradigms adapting to serverless. The most natural one is PaaS, but we envision having other types of apps running on serverless. We think it’s the next big disruptive thing in the cloud.”
When Would You Pick Functions?
“The key value of Functions and similar capabilities like AWS Lambda, Google Cloud Functions and IBM Bluemix OpenWhisk is to run lightweight background processes. The capabilities vary from one to other in a variety of dimensions like the languages supported, the time-limits, the degree of concurrency, the ease of integration with other developer toolchains, and so on,” Hilwa points out. “I think the space is pretty fluid right now, and we should expect to see these solutions evolve rapidly and considerably over the next 12 months.”
Functions supports Node.js, C#, F#, Java, Python and PHP, as well as PowerShell, Bash and batch files; as RedMonk analyst Fintan Ryan notes, that gives Microsoft “the greatest depth so far” in languages.
You can have persistent environment variables. Functions doesn’t have an execution limit — or a billing cap. That combination is good for ETL and working with large files, and Mashkowski notes that he comes across as many developers complaining about billing caps as are concerned about accidentally running up bills with a bug in their code.
“We really want to end up allowing developers to have all the controls. If you don’t want to run for more than two minutes, we can say ‘here’s the knob to set max runtime.’ If you want to make sure a function runs only one time and is completely isolated, it will cost you a little bit more because you might have taken advantage of multithreading but that’s up to you.”
Functions is free to use in preview, and Microsoft hasn’t announced pricing yet, but the measurement units will match other serverless offerings although but Mashkowski says Microsoft will monitor how developers use the service to see if that’s the right billing model. Initially, the memory size will be the same as AWS Lambda, but he suggests, “it may make sense to have two sizes or dynamic memory for the combination of memory and runtime you consume. We’re starting with the notion that the most expensive resource is memory and time of compute and then we take it from there.”
In preview, you can only have ten concurrent executions per function. “All the limitations we have now come from being in preview and offering it for free, Mashkowski explains. “We want to strike a balance between letting people play with the service but not be able to DoS us. We decided what we feel comfortable with as far as creating an awesome experience for preview and learning more to get to GA as soon as possible.”
That let Microsoft open the preview immediately rather than having a private preview like Google Cloud Functions. “I’m proud that when we launched we could open the floodgates; we didn’t have a waiting list, we were able to let people play with it from day zero,” Mashkowski boasts, adding that “it may surprise everyone how fast we go GA because it’s critical for us to make sure enterprises trust us with their business.”
IBM is a sponsor of The New Stack.
The post Microsoft Prepares for Serverless Computing with Azure Functions Preview appeared first on The New Stack.