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”.
I’m writing this post in the train to London Stensted, on my way back from F# Exchange 2018 conference.
F# Exchange is a yearly conference taking place in London, and 2018 edition was the first one for me personally.
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.