Let’s say you need to add some scheduling to your existing application. Perhaps you need to bring together an existing code written in different languages? Maybe you need a functionality that, although it’s quite important, won’t be used so often – thus you don’t want to pay for the whole infrastructure just for this little piece. Or maybe you just need to prototype and release a feature as quickest and cheapest as possible?
Here come Azure Functions to save the day!
What are Azure Functions?
Azure Functions are serverless computing solutions created by Microsoft, meaning that all the resources are managed by the cloud and a user only provides the logic that the application will execute. Such applications work in a pay per use pricing model which means the user is only charged for the actual usage of the application.
To operate, the function needs to be triggered by some event. It can be a schedule, HTTP request, or event from Azure Event Grid. Azure Function can also react to updates in storages, such as Blob or Cosmos DB. Access to the function can be anonymous as well as authorized, both by simple token and more sophisticated solutions like Azure AD, Facebook, Google, or Twitter authentication.
Azure Functions support many languages. At the moment of writing of this article – C#, Java, JavaScript, Python, F#, Typescript, and PowerShell. These are very popular languages and chances are high that you have a specialist in your team knowing one of them.
This diversity also comes in handy when you need to add some part of the system using another language. No one will probably want to write their system in multiple languages (I hope). But having a choice is always a nice option and maybe useful – especially in cases when you have some legacy code and need to integrate it into the project that’s written in another language. Instead of rewriting the whole thing, you can use Azure Function!
Can Azure Function really reduce costs? Yes, it can! And notably, in certain cases. The user is only billed for the actual usage of the application. Also, you get a million (!) executions a month, for free. In many cases, this limit won’t even be exceeded. (User still needs to pay for the CPU and Memory usage, but only as much as actually have been used).
By combining many Azure Functions that react to different types of events, it is possible to create a whole serverless system consisting of many small parts and helping develop a project in the microservice approach. In more complicated cases, there might be a need for more advanced flow control. Azure Logic Apps can be used to achieve that, but it is a story for a whole different article.
Rise and shine… Not that I wish to imply that you have been sleeping on the job…
Now, wait a second! I knew I’ve heard it before! Amazon AWS has it for ages! It’s called Lambda, and it can do the same! Why do we need another one?
You’ve heard it right! AWS Lambda is also a serverless solution. Both Lambda and Azure Function share a similar purpose, yet there are some subtle differences you might want to consider before choosing one side for your next project:
- They both support the majority of popular programming languages, but Lambda additionally allows you to write in Go and Ruby.
- Azure Functions support F# and Typescript instead. Lambda functions need to be invoked via an HTTP request, while Microsoft solution, as already discussed, has a wide variety of possible triggers.
- Azure Functions are more flexible when it comes to pricing plans. You can choose a Consumption Plan, which is “pay for what you use”, but there is also a Premium plan which can give more performance, get rid of a cold start problem, and also increase the timeout of the function.
- Lambdas always run on Amazon Linux, whether in Azure Functions you can choose between Windows and Linux runtime.
- Both solutions allow scalability and concurrent executions.
How do we use it?
In our projects, we have used Azure Functions to accomplish many tasks. Let’s share the most interesting ones!
Integrating with legacy code
Our whole application had been written in .NET Core but it was part of a bigger and older system. At one point, we had to use an already written and well-tested library, applied in other parts of the system. The problem was, it has been written in Python (not that we have something against Python, don’t get us wrong). We could have, of course, rewrite it from scratch but it would require time, both for developing and testing the solution. Instead, we used the Azure Function that let us execute that code without needing to worry about deployment and infrastructure and easily integrate it with our application using HTTP request just like we would integrate with regular REST API.
It is also worth mentioning that Azure Function in version 1 supports full .NET Framework, and versions 2 and newer .NET Core. This helped us solve a very similar case with legacy code which was written in an older version of .NET Framework. Azure Function worked as a proxy, solving all compatibility issues.
Scheduled actions
This is a pretty common scenario. Action that needs to be executed according to some schedule. It requires initial configuration and orchestration. With Azure Functions all these problems are taken care of. All that’s needed is setting a schedule which is as simple as modifying the configuration in the panel.
The history of each run can be viewed in the panel with a result, errors, and duration.
Generating thumbnails
Users can upload photos that later can be viewed as a list. We wanted to generate thumbnails for each uploaded photo, but we didn’t want users to wait for them to be generated. It was a very simple system, with no true asynchronous operations, service bus, and so on. Doing that only for the sake of these operations would be too much.
We used Blob storage triggered Azure Function which was looking for newly uploaded photos, and generated a thumbnail for each.
Downsides
Seeing all those amazing advantages offered byAzure Functions, it might be tempting to use it to deliver every part of the project. And it doesn’t necessarily need to be a good idea.
There are a few things that need to be taken into consideration.
Usually, for serverless functions, it takes more time to start up. It’s called “cold start” and means that the first run of the application within some imposed time takes longer than normal since the application is getting its resources ready. However, it can be eliminated for example by using a higher service plan.
Functions run in the cloud, which in reality is just someone else’s computer. There are certain cases when you may not want to store your code and data on other computers or servers than yours. Example – some business agreements or licenses. Running an app in the cloud is supposed to be easier, since you don’t need to worry about infrastructure, but that also means you don’t control it. There can be some cases when that fact can become a problem – just like a need for using different runtime or some external libraries.
Azure Functions are meant to run relatively short tasks up to about 10 minutes. With an HTTP trigger, the timeout is set to 230 seconds (who would want to wait any longer for an HTTP request to complete anyway, let’s be honest…).
But there are cases where an operation will take longer than that. A solution to this problem might be Azure Durable Function which has been designed as an orchestration solution. Such a function can run virtually forever. Durable functions deserve a separate article, so we’ll leave it for now.
Conclusion
We hope you’ve enjoyed our journey into the world of serverless. We encourage you to use Azure Functions in your next project, whether you’ll need scheduled tasks, integrations with other languages, quick prototyping, or maybe a way to cut the costs.
We have delivered many projects using that technology and are more than happy to help you! Feel free to contact us – together we can deliver another great project with serverless technology.
