Microsoft Azure recently created its Azure Functions to hop on the useful trend of serverless computing. How does it fit into your architecture and what are the most important Azure Functions features?
While, of course, serverless computing can’t actually be “serverless,” this relatively new technology allows developers and users to bypass concerns about infrastructure or server issues, allowing them to worry only about the code they are building.
Azure began releasing its Functions about a year ago, in May 2016, lagging behind AWS Lambda’s 2014 release but trailing closely after Google Cloud Functions from February 2016.
This architecture has been very successful not only by helping developers simplify their process but also by helping people and companies save money. These services charge in different ways, but effectively you are charged for the events that are triggered in your code rather than simply by time, including the time the application spends just waiting.
Azure allows this different type of billing through a few different things, including server abstraction and development based on events.
Azure Functions features
Here, we’ll go a little bit more in depth about the features of Azure Functions and what they mean to you.
As explained before, it is serverless, meaning you won’t have to concern yourself with infrastructure and provisioning servers. This is particularly useful when you need to scale up your application.
Another useful feature is the ability to immediately execute your code after writing it in the Functions Editor. This helps spot bugs, see development, and run tests as you go, speeding up the development process.
You are also able to “click and add bindings to Azure services and external services (Box, Dropbox, Microsoft OneDrive, SendGrid, and more) to get input into or output from Functions.”
Azure Functions is also useful for businesses because it delivers results from events in internal APIs or business systems to your on-premises databases if you choose this option.
Authentication is also simple when using this tool, easily protecting cloud function endpoints with third-party authentication, including sites such as Facebook and Twitter.
As mentioned, you only have to pay for the actual time your code is running. According to Microsoft’s site, “Functions are billed based on the total number of requested executions each month for all Functions. Executions are counted each time a function is executed in response to an event, triggered by a binding.”
Even more, the first million executions are included each month for free. You’re charged for the exact amount of time your code takes to execute, as well as the number of Azure Functions that you need.
Function costs are calculated based on “observed resource consumption measured in Gigabyte Seconds (GB-s).” The way Microsoft determines the observed resource consumption is by “multiplying average memory size in Gigabytes by the time in seconds it takes to execute the function.” For more information, check out Microsoft’s pricing page.
This greatly helps with costs when considering other, nonserverless architectures. Additionally, there’s no upfront cost or termination fees.
It seems that users are able to have Function Apps with a maximum number of 10 instances, while the execution is limited to 5 minutes per invocation. Many believe that this is a limitation and dislike it, particularly when long execution tasks are necessary.
Luckily, there have been infrastructure changes to allow for a higher maximum timeout of 20 minutes, although this change has not been deployed yet.
Make sure you and your team don’t set the timeout time too high, however, or else you might be a bit shocked by the billing costs. While a higher execution time limit can be necessary, it isn’t recommended to make this your default because of the higher potential expenses. Though, of course, this varies based on your needs.
Users are also free to use Visual Studio Team Services, GitHub, or BitBucket to quickly iterate on Azure Functions with continuous deployment in order to integrate their DevOps more simply.
However, it’s important to note that if you implement your code from these various sources, the code becomes read-only and you cannot edit the functions from the portal. Azure Functions themselves implement deployment through the App Services infrastructure.
Another thing to note about Azure Functions is that deployments do not simply deploy single functions, but the entire app, meaning that each deployment affects all of your functions. However, the same app can have functions implemented in different languages.
If you’re deciding between Azure Functions or Lambdas, you need to know that Lambdas can be versioned, but it seems that Azure Functions still cannot. Instead, you would have to rely on a source code repository such as Git or a different version control system that is supported in Azure Functions.
Understanding events and invocations in Azure Functions
Microsoft Azure Functions often work to process data or build microservices or APIs because it is an event-driven service. There are many events and services that can trigger functions, such as streaming data for IoT, HTTP requests (from both a REST API or a WebHook), or scheduling an activity via a timer.
You are also able to integrate with certain third-party services, such as GitHub via webhooks or Azure Event Hubs to trigger events.
It’s not necessary to have a manual configuration because the environment helps you with mapping, giving each function binding parameters to easily “configure their name, trigger type direction, and configuration of the sourcing parameter.”
In fact, each function will automatically be mapped to an HTTP endpoint if you choose to enable this feature.
Azure Functions is a great product that has been on the market for about a year now. Its runtime is open source and Microsoft seems to regularly provide updates, making this a solid choice if the pricing and features fit what you and your team need.