Auto-provisioning and auto-scalability are the killer features of Function-as-a-Service cloud offerings, and Azure Functions in particular.
One drawback of such dynamic provisioning is a phenomenon called “Cold Start”.
Azure Functions are designed for stateless, fast-to-execute, simple actions. Typically, they are triggered by an HTTP call or a queue message, then they read something from the storage or database and return the result to the caller or send it to another queue.
Back in August this year, I’ve posted Azure Functions: Are They Really Infinitely Scalable and Elastic? with two experiments about Azure Function App auto scaling. I ran a simple CPU-bound function based on Bcrypt hashing, and measured how well Azure was running my Function under load.
Update: I missed the elephant in the room. There actually exists a specialized trigger for Event Grid binding. In the portal, just select Experimental in Scenario drop down while creating the function.
Updated results are available at Azure Functions Get More Scalable and Elastic.
Automatic elastic scaling is a built-in feature of Serverless computing paradigm. One doesn’t have to provision servers anymore, they just need to write code that will be provisioned on as many servers as needed based on the actual load.
Azure Functions are the Function-as-a-Service offering from Microsoft Azure cloud. Basically, an Azure Function is a piece of code which gets executed by Azure every time an event of some kind happens.
Azure Application Insights is an analytics service to monitor live web applications, diagnose performance issues, and understand what users actually do with the app. Aurelia is a modern and slick single-page application framework.
At the recent Webscale Architecture meetup we discussed two implementations of the Actor model in the .NET ecosystem: Akka.NET and Azure Service Fabric Actors. One important discussion was around Ask vs Tell call model.