Serverless Computing with Azure Functions

 

In the past few years, there’s been a big shift towards serverless computing and it’s a shift brought on by the microservices architecture that’s been gaining popularity. For a new greenfield project, should you stick to the traditional web server + database server, or structure your application as a series of microservices using serverless computing?

 

Serverless computing brings with it a lot of benefits. The way I see it, with serverless, you take away a lot of responsibility for provisioning, managing and updating servers so that you can spend more of your resources focused on the application rather than the infrastructure. This inherently saves you time and money on the project as you won’t need to involve a sysadmin as well as pay for server hosting costs as most serverless platforms only bill you for the executions of your code.

One such example of serverless computing is Azure Functions (or AWS Lambda). The functions are discrete pieces of code that are typically stateless and perform a discrete piece of work. As an example, I setup an Azure Function service to automate the deployment of one of our projects every morning through Octopus Deploy. The code itself was probably 20 lines, but if I didn’t deploy it as an Azure Function then I would have needed to:

  • Run the code on a server somewhere
  • Think about how to schedule/trigger the code at a certain time of day (windows task scheduler? Cron job?)
  • Think about how to deploy new versions of the code if I update it

Instead, with serverless computing, I just deploy the function to Azure, setup the schedule in the UI, and setup auto deployment from Git. I also get a UI where I can view logs and executions of my functions so I don’t need to remote to a server to view any logs.

Cost wise, this little function costs me nothing as it falls within the free tier (1 million executions a month).

What I like about this approach is:

  • Promotes good architecture and design patterns
    • Single responsibility
    • Decoupling
    • Micro services
  • Promotes the use of message buses or queues
  • Promotes fast efficient code (as it’s going to cost you $$ if it’s slow)
  • Allows me to scale just that one function if it’s going to be heavily used instead of having to scale up/out the whole application

Eric Phan – CTO SMEx Digital