Why you should care about serverless computing

We are looking to improve your experience on the Visual Studio Blog. It would be very helpful if you could share your feedback via this short survey that should take less than 2 minutes. Thanks!

You may have heard the industry buzzword “serverless computing.” Whether you are already a serverless ninja, or still on the fence about the bizarre name, read on! How does it work? Why should you care? Is it just a fad, or a real trend in computing?

Serverless computing defined

Serverless computing generally encompasses three things: 1) abstraction of servers, 2) event-driven scale and 3) micro-billing.

  1. Abstraction of servers. Serverless computing is fully managed. Users never explicitly reserve server instances; this is handled by the platform. Each function execution could run on a different compute instance, and this is completely transparent to your code.
  2. Event-driven scale. Serverless is an excellent fit for workloads that respond to incoming events. Events include timers (e.g., run this function everyday at 10 am), HTTP (API and WebHook scenarios), queues (e.g., order processing), and much more. Instead of writing an entire application, you author a “function,” which contains both code and metadata about its triggers and bindings. The platform automatically schedules your function to run and scales the number of compute instances based on the rate of incoming events. Triggers define how a function is invoked. Input and output bindings provide a declarative way to connect to services from within your code. For example, suppose you want to write a new file to Azure Blob Storage every five minutes. You would use a Timer trigger and a blob output binding:

    Azure Functions for DotNet Developers - Event Driven Scale

  3. Micro-billing. In traditional computing, there is a notion of per-second billing, but that’s often not as useful as it sounds. Even if you have a website that gets only 1 hit a day, you must still pay for a full day’s worth of availability. With serverless, you pay only when your code is executing. If there are no active function executions, you are not charged. For example, if your code runs once a day for 2 minutes, you are charged for 1 execution and 2 minutes of computing. For more details on billing, see Azure Functions pricing.

Together, these features enable you to focus on apps, not servers. That means you’ll have reduced DevOps and a more productive computing environment. Customers have found that they are able to deploy solutions much more quickly than before. Projects can now be completed in days or weeks, rather than months.

Azure Functions is Microsoft’s serverless computing platform. Serverless involves more than just computing; it includes databases, messaging, and workflows. To learn more about the entire Azure serverless platform, see azure.com/serverless.

Why serverless matters

More so than any other cloud computing paradigm, serverless frees you from managing infrastructure and enables you to focus on your business problem. Though serverless is still in its infancy, there are now many vendors who offer serverless platforms.

Serverless is not just a fad or buzzword. Rather, serverless represents a dramatic shift in how developers think about cloud computing. With serverless, you need only worry about your code and how it is triggered. The platform takes care of the rest.

Serverless and tooling

When most cloud vendors launched their serverless offerings, there were many barriers to developer productivity. There was no support for debugging, there was no local development experience, and monitoring functions was hard. Despite this, the new programming model was so productive that serverless become a popular trend.

As you might expect, Azure Functions included productivity features from the start. We have a tooling and local development experience that is unique among vendors. You can run the Azure Functions runtime on your local machine. Aside from the scale-out, it’s the same runtime as in the cloud. You can even trigger off events in Azure, enabling a hybrid debugging experience.

For monitoring, Azure Functions provides Azure Application Insights integration, an unparalleled monitoring experience. You can connect to a live event stream, see runtime metrics, and log your own custom metrics. Application Insights supports a rich query language, and you can create automated alerts.

.NET support on Azure Functions

Since its initial preview, Azure Functions has had first-class C# support. We now support C# and F# scripting as well as C# class libraries. The Function portal focuses on the scripting experience, while the Visual Studio tooling is based on class libraries.

The Visual Studio Functions project is a regular .NET class library that references the Functions NuGet package Microsoft.NET.Sdk.Functions. All standard Visual Studio features are supported, such as unit testing, debugging, and publishing to Azure.

Azure Functions also supports other languages, such as JavaScript, PowerShell, and Python.

Try it out

We’ve recently released the RTW version of the Azure Functions tools in Visual Studio 2017 Update 3. Azure Functions tooling is included in the Azure workload. Follow this tutorial to get started in 5 minutes: Create your first function using Visual Studio.

Learn more

Check out the following videos:

Connect with us:

  • For product news, follow @AzureFunctions.
  • For technical questions, post on the MSDN forums or StackOverflow. The entire Functions engineering team monitors these questions, so you’re sure to get an expert answer.
  • To report bugs or file feature requests, open an issue on the Azure-Functions GitHub repo. Include “Visual Studio” in the issue title.
Donna Malayeri, Program Manager, Azure Functions
@lindydonna

Donna Malayeri is a program manager on the Azure Functions team, where she is responsible for the developer experience and the Visual Studio tooling. She previously worked on products such as Azure Mobile Services, Reactive Extensions (Rx), Visual F#, and Scala. She holds a PhD in programming languages from Carnegie Mellon University.