These are my thoughts and key take aways from working with Azure Functions for a while now.
Creating a Function in the Azure Portal is easy as Pie
Creating your first Function in the Azure Portal is a simple process and you can use pretty much any language you want. I prefer PowerShell for prototyping and management stuff – like reacting to events where I have to fire some PowerShell command to handle something in Azure – and I use JavaScript/TypeScript for the more heavy programmatic tasks like creating “real” solutions.
As Microsoft adds support for more languages the possibilities of using serverless Functions will extend to other areas. Recently Python was GA’ed (see below) and as soon as PowerShell for Functions is GA’ed “DevOps”-people can become Azure Function Developers too. Functions is not only for web services and databases but for all things serverless! Think Flow/Logic Apps -> Functions written in PowerShell which do IT management operations.
Great Developer Experience
The developer experience for creating, running and testing Functions locally is just perfect. You can do everything completely locally and even offline – just like any other local development stack/platform/toolchain.
Then push changes to a central repo like Azure DevOps where CI/CD pipelines can build and deploy the Function to Azure completely automated.
If you don’t have Azure DevOps then Functions can pull in code from pretty much any cloud reachable Git repo – it’s completely cross platform.
There is complete support for Visual Studio and Visual Studio Code and lots of other editors for creating Functions so that writing, editing, testing, debugging and so on is a first class experience.
Triggers & Bindings
Functions can be triggered or react to a range of builtin sources like Azure Event Grid, Service Bus, Cosmos DB and so on – and of course HTTP requests. So calling and activating Functions is really easy.
Bindings are a way of declaratively receiving the input from a trigger or other resources and passing the output of the Function to a receiver – like Azure Cosmos DB, storage or Service Bus. This makes it very easy to react to events – get and process data and output the result with very little friction. Moving data in and out of Cosmos is almost like magic (Please note that more complicated usage of Cosmos requires the use of the SDK!).
For me it has completely replaced the necessity to create Web APIs in .NET or Node and deploy to Azure Web App. If you’re doing web services today using the regular technology platforms and you want to move to Azure I would recommend looking into Functions rather than Web Apps for hosting web services.
Proxies & API Management Gateway
Function Proxies is like a miniature API Manangement Gateway (APIM) which can route URL based requests to methods in your Function or even other Functions if you’re scaling out at the implementation level.
For instance a proxy could route requests to /api/shipments to the actual implementation in the “GetShipments” method.
I also really like the actual APIM and the integration with Functions but updating the API specification in the APIM when a Function is updated is a bit of a pain. I would never expose a Function to the internet just through the URL or even Proxies I would always use APIM as the front door.
Automated Scaling
You can deploy using either App Plan or Consumption Plan and unless you have very specific requirements (or extremely high load) I can’t think of a reason not to choose Consumption Plan and just let Azure handle everything.
Some of our APIs are hammered in the morning and Azure just scales the number of “servers” up in seconds and scales back down again when things settle. We haven’t missed a single call yet with Consumption Plan and we did that on App Plan because we ran out of horse power during that single it will never happen freak influx of data moment.