The team behind the product are confident that Microsoft’s approach towards serverless trumps Amazon’s

At the recent Microsoft Build developer conference, I took part in a session with a small group of analysts speaking with Mark Russinovich, Microsoft’s CTO of all things Azure. The same day, I spent some one-on-one time with Nir Mashkowski, Partner Director Program Management for Azure App Service and Azure Functions. While these were two different conversations, the subject was the same – Microsoft’s perspective on serverless computing.

The timing was good since Microsoft had some serverless-focused announcements at the event including a preview of a new Visual Studio extension which allows developers to integrate Azure Functions development by leveraging third-party extensions, testing frameworks, and continuous integration systems. Alongside the development aspects, Microsoft announced support for serverless within Azure Application Insights, meaning that developers can measure performance, detect issues, and diagnose the source of the problem with serverless apps. Finally, with Azure Functions Runtime, a preview product, this functionality is extended outside of Azure’s cloud.

Russinovich is personally bullish on serverless, stating that it is an approach which is the “future of computing.” That’s a strong statement for someone so deep in the developer world. Given the importance of serverless and the fact that all the big three public cloud vendors are feverishly working on serverless offerings, it was good to question Russinovich about how Azure Functions compares to other players – specifically Amazon Web Services’ Lambda serverless offering and Google’s Cloud Functions.

Lambda has been in-market for around three years, whereas Azure Functions was only introduced last year. Russinovich was quick, however, to explain that Azure Functions is the culmination of work that Microsoft has been doing for many years. It also complements an adjacent technology offering from Microsoft, Azure Logic Apps.

Differences between Azure Functions and Lambda

Russinovich led the differentiation conversation by stating his perspective that Lambda has some serious economic issues at scale. With Lambda, developers pay for the invocations of a function – every time a function is triggered, a charge is made. And while these charges are tiny, they can, said Russinovich, end up extremely expensive. In many cases, it is better to simply pay for fully provisioned resources and fill those resources with the processing of functions. Either way, Microsoft offers developers the choice – they can either use Azure Functions on a consumption basis (like Lambda) or they can run Azure Functions in fully provisioned resources. The Azure AppService plan is simply infrastructure – developers can use it within a virtual machine (VM) construct, or a function-based one.

Russinovich was also willing to differentiate Azure Functions based on the way Azure Functions works. Whereas Lambda developers need to state both the input and output location, as well as the actual transformation which is to occur to the data, Microsoft offers a range of different bindings – with these bindings, developers have the ability to take input from a variety of different sources and therefore only have to code the actual transformation logic itself – a saving in time and complexity. As he explained it:

“With Lambda, developers need to go read an S3 object, actually execute the mutation and then drop it off. What if we could simplify – that’s where our bindings came into play. The developer doesn’t write code – they specify in Visual Studio how the object will be transformed. Developers register once and Microsoft maintains authorization. Developers can focus just on the function code rather that the peripheral aspects.”

Finally, Russinovich spoke of the fact that, given Microsoft’s pedigree of providing the tools that developers actually use to code, and the fact that their serverless offering is a first-party integration into these tools, that the developer experience is a key differentiator also. The fact that Logic Apps

Finally, he differentiated Microsoft’s Logic App paradigm with AWS’ closest analog, Step Functions. As he put it:

“The differentiation are the integration aspects. step functions orchestrate Lambda together. Whereas Logic Apps build pieces of discrete operation no matter where. As an example – it would be simple for a developer to leverage Logic Apps to create a complex chain of events writing just logic rules, not code. Russinovich gave a real example where an organization might create a function to read its Twitter account, assess a particular tweet, derive sentiment analysis, get the email of an unhappy customer and trigger an action all a CRM.

MyPOV

Serverless technologies are certainly a big part of how technology will look into the future. I suspect that individual developers feelings about AWS versus Microsoft versus Google will have more to do with personal preference and their particular context than any huge technological differences. I’d also suggest that all three vendors will work hard and fast to build out their serverless offerings and that we’ll see new and exciting tools introduced in the near future.

Ben Kepes

Ben Kepes is a technology evangelist, an investor, a commentator and a business adviser. Ben covers the convergence of technology, mobile, ubiquity and agility, all enabled by the Cloud. His areas of interest extend to enterprise software, software integration, financial/accounting software, platforms and infrastructure as well as articulating technology simply for everyday users.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.