The trend of making applications serverless is on fire! And it’s not just hype…going serverless makes the administration, monitoring and debugging of code so much easier that developers all around are flocking to use it in one way or the other.

If you don’t know what serverless means, I would suggest you start here. In a nutshell, it basically abstracts the underlying platform and allows the developers just to run a piece of code without worrying about servers and their maintenance. Also, it gets the usual benefits of the cloud like auto-scale, pay-per-use, etc.

The Background

At AIS IDC, we have a separate timesheet system to keep track of records internally. This system comprises of various features like Leave Requests, Time Logs, Work-From-Home Requests, etc. We deployed the system a couple of years ago, and it’s comprised of an Azure SQL instance, Azure Web App on Windows, and an Azure Classic Cloud Service. The Azure Classic Cloud Service was deployed with a separate application written in C# to keep track of overtime hours, update leaves, figure out timesheet defaulters, send out email notifications, etc. Since this was a classic Cloud Service, we had little visibility into what was going on while it was running.

Furthermore, just to do these basic tasks every five minutes, the classic cloud service was costing us $60 per month on an average.

The Copy-Paste

Changing the application from Classic Cloud Service (which used the WorkerRole class) to Azure Functions was 95% copy-paste from the previous solution. The additional 5% included the following…

1. Merging the Run() method (Inside RoleEntryPoint class. Used when building applications for Cloud Services) into a method which is recognized by Azure Functions (Here’s a basic template for writing Azure Functions)
2. Rewriting/Upgrading the code to store log messages in Azure Storage Tables (they are awesome!) using the latest SDK.
3. Using CloudConfigurationManager to get environment settings. I also added a few more as nice-to-have additions.

It took me around one to two hours of work to add the nice-to-have features and make the code changes.

Any issues?

Yep. I spent around three to four hours looking for NuGet package conflicts. There is a known conflict between the packages – Microsoft.Azure.CosmosDB.Table (1.1.2), Microsoft.NET.Sdk.Functions (1.0.13), Newtonsoft.Json (10.0.2).

The first two packages have strict dependencies on different versions of Newtonsoft.Json. The Microsoft.NET.Sdk.Functions (1.0.13) has a strict dependency on Newtonsoft.Json (9.0.1) but Microsoft.Azure.CosmosDB.Table (1.1.2) requires Newtonsoft.Json (>10.0.1).

Finally, the following packages worked together in this case:

1. Azure.CosmosDB.Table (1.1.2)
2. Azure.DocumentDB (1.20.1)
3. NET.Sdk.Functions (1.0.13)
4. Json (10.0.2)

Note: NuGet will still complain about version mismatch, and VS will complain during building the project, but the end result will be successful.

The Result

So after spending around five to six hours on this small but important functionality, we enjoyed the following benefits:

1. Save ~$700 per year in Azure costs. Right now, the code is running free of cost because of the generous free quota of Azure Functions.
2. More visibility into what is happening and the result after each execution.

1. No more maintenance of the Cloud Service!
2. Future developers can focus on writing code and features instead of figuring out how to deploy or envision how their code will run on Cloud Service or even figure out auto-scaling.

As you can see, it takes very little time to start utilizing and realizing the benefits of Azure Functions. Migrating even small applications can result in huge savings. If you would like to migrate functionalities to a Serverless Compute Model, contact AIS today!