Azure Functions are an event-driven, compute-on-demand experience that extends the existing Azure application platform with capabilities to implement code triggered by events occurring in other Azure services, SaaS products, and on-premises systems.
As companies are trying to innovate and deliver faster, modern software architecture is evolving at the speed of light. We’ve quickly evolved from managing physical servers to virtual machines, and now we’re evolving from running on containers and microservices to running “serverless”.
What is “serverless”?
This new computing model is almost everywhere defined as a model which “allows you to build and run applications and services without thinking about servers.” If this definition makes you wonder why this is different from PaaS, you’ve got a point. But there is a difference.
With PaaS, you might write a Node app, check it into Git, deploy it to a Web Site/Application, and then you’ve got an endpoint. You might scale it up (get more CPU/Memory/Disk) or out (have 1, 2, n instances of the Web App), but it’s not seamless. It’s great, but you’re always aware of the servers.
Enter Azure Functions
Azure Functions is Microsoft’s answer to the serverless question. Written on top of the WebJobs SDK, Azure Functions is the logical successor to WebJobs.
As the serverless compute service of the Azure application platform, Azure Functions lets developers run code on-demand, without having to explicitly provision or manage infrastructure. It provides an intuitive, browser-based user interface, allowing users to implement their code in a variety of programming languages including C#, F#, or Java. This code can be triggered by events occurring in Azure, third-party services, as well as on-premises systems.
But there’s more to it: With Functions bindings, developers can interact with other data sources and services through their Function, without worrying about how the data flows to and from a Function, thus making it easy to react to events. With this capability, developers don’t have to know too much about the underlying services they’re interacting with, making it simple to swap out later for different services. A detailed list of triggers and bindings supported by Azure Functions you can find here.
Because Azure Functions is scale-based and on-demand, you pay only for the resources you consume. Apart from the consumption model, in Azure you also have the App Service plan, where, just like in the case of every app service, you pay for the run time of x instances.
We can create for you a solution with .NET Core and C# and the Azure Functions you need, adding the source or the destination you want to use.