This episode of Azure Functions Monthly Update comes to us directly from #MSIgnite. It is one of those episodes with grand style studio room having three people from the Azure Functions team – Jeff Hollan (Senior Program Manager, Azure Functions), Eduardo Laureano (Principal PM Manager, Azure Functions), and Fabio Cavalcante (Senior Engineer, Azure Functions). Almost the entire Azure Functions were at #MSIgnite that happened between September 23-28, 2018 in Orlando, FL. I’ll try to give you a very crisp recap of the proceedings and the important announcements from this month webinar.
Azure Functions 2.0
The moment everyone has been waiting for is here… #AzureFunctions V2 is now generally available!! This is a comprehensive update that brings valuable changes to the UX, platform and the functions runtime (of course) – Bring on your production workloads!https://t.co/08l9sLiQbP pic.twitter.com/OzBxub4mhb— Azure Functions (@AzureFunctions) September 24, 2018
.NET Core 2.1
You can now author functions using .NET Core 2.1, this results in performance improvements and you can develop and run .NET functions in more places.
Assembly Resolution Issue
The most discussed issue 992 (assembly resolution issue) the team has made major changes to how assembly resolution works, giving functions their own load contexts. This will ensure no more running into assembly conflicts, but if you do, it’s easier than ever to mitigate.
Functions 2.0 is not only about runtime changes, but there is also more like the Quick Start that helps you for easier development. Azure Functions has powerful native tooling for Visual Studio, VS Code, VS for Mac, and CLI that can be run alongside any code editing experience. You can start these toolings easily using the Quick Start, this feature will have an immediate impact on your productivity.
All bindings are brought in as extensions, except for the core HTTP and timer support. These bindings are just simple packages that you can install with Functions tooling. Azure SignalR Service, is now part of the bindings. It is a fully managed service that enables to focus on building real-time web experiences without worrying about setting up, hosting, scaling, or load balancing the SignalR server. More details on the SignalR Service bindings for Azure Functions can be read from this documentation.
Azure Functions Premium plan – Private Preview
Azure Functions runs in two different modes say, the Consumption plan and the Azure App Service plan.
The App Service plan is no longer powered by the scale controller rather it relies on the auto scale service. This method is reactive, and you can scale only within the size of your plan. For example, if you have a standard App Service plan with 10000 events, the most you could scale even after the auto scale is 10 instances. Whereas in consumption plan you can do cross tab scaling to scale your events.
In a Consumption plan, the instances are hosted dynamically, like adding and removing instance are based on the number of incoming events. In this plan, scaling is automatic, and you’re charged only for the compute resources when your functions are running.
Azure Functions Premium plan is about the same functions, same tooling but instead, you can choose the number of cores that you want to reserve to avoid cold start. With this plan, you can scale in and out extremely rapidly but with better hardware. In this plan, you get VNET connectivity, always on cores and many other benefits. You can sign up for the Premium plan here http://aka.ms/functionspremium
Azure Functions Dependency Injection Demo
Azure Functions triggers are static in nature and it is not easy to manage dependencies. Azure Functions not only have a user interface unlike just drag and drop in Logic Apps, but there is also always a need for Dependency Injection in Functions. Here is a scenario that Fabio showed as a demo on handling Dependency Injection in Azure Functions. The screenshot below shows a standard function project with an HTTP trigger.
If you look at it closely, you can notice a few differences like the Run Method is not static but an instance method. There is a constructor defined to take dependency for IMyService.
IMyService is an interface and the implementation of the interface just exposes the property Id. There is also an instance id created whenever the constructor is called (_istanceId). So, whenever an instance of the function class is created, the local variable _myService will be assigned with the instance of IMyService and a new Id is assigned for _istanceId.
The above screenshot has the piece of code which injects the IMyService during startup of the Function. It works similar to the dependency injection in .Net Core. Here, A Singleton service is registered with the interface as IMyService and MyService as the class. So, if anyone calls for IMyService, the implementation that needs to be returned is MyService.
While running this project, the _instanceId gets changed whenever the HTTP request is made. Where the Id from MyService is not getting changed for each trigger. The scope of the instance is maintained until the function is restarted or redeployed.
Azure Functions team is excited to give some visibility into their short-term roadmap including expanding hosting options for Azure Functions – serverless Linux hosting (powered by Service Fabric Mesh), Python 3.6 support on Azure Functions 2.0 runtime, and support PowerShell Language Worker for Functions.
If you are working on Azure Functions and have something interesting, feel free to share them with the Azure Functions team via Twitter at @AzureFunctions.
You can watch the recorded video of this session here.
In case you missed the earlier updates from the Azure Functions team, take a look at our recap blogs here –