.NET architecture components

A tale of three platforms----UWP, WPF and Windows Forms

A tale of three platforms

Over the years, different technologies and requirements have led to the development of many ways of writing applications that run on Windows. The goal has always been the same: help developers create a user interface and generate essential boilerplate code, leaving them to add the unique functionality that makes their apps useful. No one wants to write code that displays text pixel by pixel or draws the shapes that make up a menu or window. Developers want to have consistent, proven, reliable code that handles all these features (and a lot more!) already available.

To that end, Microsoft has created many tools and libraries. The three we're going to look at in this learning path are UWP, WPF, and Windows Forms. You'll see how all three provide similar approaches for building basic applications.

Universal Windows Platform

Windows 10 introduces the Universal Windows Platform (UWP), which provides a common app platform on every device that runs Windows 10. The UWP core APIs are the same on all Windows devices. If your app uses only the core APIs, it will run on any Windows 10 device, whether it's a desktop PC, Xbox, a mixed-reality headset, or something else.

UWP is best if you're targeting Windows 10 and you want unencumbered access to the latest Windows 10 APIs and features. UWP also provides the other benefits of a modern application platform. These benefits include a XAML-based UI model with built-in support for adapting to DPI and screen size changes, a security model in which users explicitly grant apps access to device capabilities, and a packaging model that supports clean installations and the ability to publish directly to the Microsoft Store.

Windows Presentation Foundation

Windows Presentation Foundation (WPF) is a UI framework for creating desktop client applications. The WPF development platform supports a broad set of application development features, including an application model, resources, controls, graphics, layout, data binding, documents, and security. It's a subset of the .NET Framework, so if you've already built applications with the .NET Framework by using ASP.NET or Windows Forms, the programming experience should be familiar. WPF uses the Extensible Application Markup Language (XAML) to provide a declarative model for application programming.

WPF and Windows Forms are best if you need to target OS versions earlier than Windows 10 and you want to have a higher level of coding productivity than C++ and Win32. You can also share some .NET Framework code and libraries with other Microsoft platforms by using portable class libraries.

Windows Forms

Windows Forms is a smart-client technology for the .NET Framework, a set of managed libraries that simplify common application tasks like reading and writing to the file system. When you use a development environment like Visual Studio, you can create Windows Forms smart-client applications that display information, request input from users, and communicate with remote computers over a network. Windows Forms is an older development platform and lacks some of the features provided by WPF and UWP.

We can't talk about writing Windows apps without mentioning one more option: Win32.

Win32 (Windows API) and C++

The Win32 API (more accurately called the Windows API) enables applications to use the features of Windows. By using this API, you can develop applications that run successfully on all versions of Windows while still taking advantage of the features and capabilities unique to each version. Win32 is a good choice if you need to achieve the highest levels of performance or efficiency, access native OS features, or target DirectX technologies.

This approach lets you achieve the best performance for your app by taking direct control over memory allocation and performance-oriented CPU features like SSE or AVX instructions. It's the best way to target DirectX technologies for low-level, high-performance graphics access. You can share C++ code between all types of Windows applications and with non-Windows platforms. The tradeoff is that, compared to C# and UWP for example, it can take a fair amount of work to implement even basic features.

How to choose?

All of these application platforms let you create desktop apps like Word, Excel, and Photoshop that run in the classic Windows desktop and take full advantage of that environment's specific features. However, some of these platforms share some traits and are better suited for certain types of applications:

• UWP, WPF, and Windows Forms. These platforms provide managed runtime environments (the Windows Runtime for UWP, and .NET for Windows Forms and WPF) with many benefits, especially in the areas of developer productivity, sophisticated and customizable UI, and application security. Because these frameworks support visual designers and UI markup for rapidly creating UI, they are particularly well-suited for line-of-business applications.
• Win32 API. The Win32 API (also called the Windows API) is the original platform for native C/C++ Windows applications that require direct access to Windows and hardware. It provides a first-class development experience without depending on a managed runtime environment like .NET and WinRT. This makes the Win32 API the platform of choice for applications that need the highest level of performance and direct access to system hardware.

UWP

UWP is the leading-edge platform for Windows 10 applications and games. It's a highly customizable platform that uses XAML markup to separate UX (presentation) from code (business logic). UWP is suitable for desktop applications that that require a sophisticated UI, styles customization, and graphics-intensive scenarios. UWP also has built-in support for the Fluent Design System for the default UX experience and provides access to the Windows Runtime (WinRT) APIs. By adopting Fluent, UWP automatically supports common input methods such as ink, touch, gamepad, keyboard, and mouse.

Not only can you use UWP to create desktop applications for Windows PCs, but UWP is also the only supported platform for Xbox, HoloLens, and Surface Hub applications. UWP is our newest, leading-edge application platform.

For more information about UWP, see Get started with Windows 10 apps.

WPF

WPF is the established platform for managed Windows applications with access to the full .NET Framework, and it also uses XAML markup to separate UX from code. This platform is designed for desktop applications that require a sophisticated UI, styles customization, and graphics-intensive scenarios. WPF development skills are similar to UWP development skills, so migration from WPF to UWP apps is easier than migration from Windows Forms.

For more information about WPF, see Getting started (WPF).

Windows Forms

Windows Forms is the original platform for managed Windows applications with a lightweight UI model and access to the full .NET Framework. It excels at enabling developers to quickly get started building applications, even for developers new to the platform. This is a forms-based, rapid application development platform with a large built-in collection of visual and non-visual drag-and-drop controls. Windows Forms does not use XAML, so deciding later to extend your application to UWP entails a complete re-write of your UI.

For more information about Windows Forms, see Getting started with Windows Forms.

Platform comparison: UWP, WPF, and Windows Forms

Choose your app platform

When you want to create a new desktop application for Windows PCs, the first decision you make is which application platform to use. Windows provides four main application platforms, each with different strengths:

• Universal Windows Platform (UWP)
• WPF (.NET)
• Windows Forms (.NET)
• Win32

All of these application platforms let you create desktop apps like Word, Excel, and Photoshop that run in the classic Windows desktop and take full advantage of that environment's specific features. However, some of these platforms share some traits and are better suited for certain types of applications:

• UWP, WPF, and Windows Forms. These platforms provide managed runtime environments (the Windows Runtime for UWP, and .NET for Windows Forms and WPF) with many benefits, especially in the areas of developer productivity, sophisticated and customizable UI, and application security. Because these frameworks support visual designers and UI markup for rapidly creating UI, they are particularly well-suited for line-of-business applications.
• Win32 API. The Win32 API (also called the Windows API) is the original platform for native C/C++ Windows applications that require direct access to Windows and hardware. It provides a first-class development experience without depending on a managed runtime environment like .NET and WinRT. This makes the Win32 API the platform of choice for applications that need the highest level of performance and direct access to system hardware.

This article describes these platforms in more detail and helps you determine the best one for your application.

Note

No matter which app platform you choose, you can use many features of the Universal Windows Platform (UWP) to deliver a modern experience in your app on Windows 10. For example, even if your desktop app is built using WPF, Windows Forms, or the Win32 API, you can still use many features first introduced with UWP, such as MSIX package deployment and UWP XAML controls. For more information, see Modernize your desktop apps.

UWP

UWP is the leading-edge platform for Windows 10 applications and games. It's a highly customizable platform that uses XAML markup to separate UX (presentation) from code (business logic). UWP is suitable for desktop applications that that require a sophisticated UI, styles customization, and graphics-intensive scenarios. UWP also has built-in support for the Fluent Design System for the default UX experience and provides access to the Windows Runtime (WinRT) APIs. By adopting Fluent, UWP automatically supports common input methods such as ink, touch, gamepad, keyboard, and mouse.
Not only can you use UWP to create desktop applications for Windows PCs, but UWP is also the only supported platform for Xbox, HoloLens, and Surface Hub applications. UWP is our newest, leading-edge application platform.
For more information about UWP, see Get started with Windows 10 apps.

WPF

WPF is the established platform for managed Windows applications with access to the full .NET Framework, and it also uses XAML markup to separate UX from code. This platform is designed for desktop applications that require a sophisticated UI, styles customization, and graphics-intensive scenarios. WPF development skills are similar to UWP development skills, so migration from WPF to UWP apps is easier than migration from Windows Forms.
For more information about WPF, see Getting started (WPF).

Windows Forms

Windows Forms is the original platform for managed Windows applications with a lightweight UI model and access to the full .NET Framework. It excels at enabling developers to quickly get started building applications, even for developers new to the platform. This is a forms-based, rapid application development platform with a large built-in collection of visual and non-visual drag-and-drop controls. Windows Forms does not use XAML, so deciding later to extend your application to UWP entails a complete re-write of your UI.
For more information about Windows Forms, see Getting started with Windows Forms.

Platform comparison: UWP, WPF, and Windows Forms

The following table compares various characteristics of Windows Forms, WPF, and UWP in detail.

Feature or scenario	UWP	WPF	Windows Forms
Supported versions	Windows 10	Windows 7 and later	Windows 7 and later
Languages	C#, C++/WinRT, C++/CX, VB, JavaScript	C#, C++/CLI (Managed Extensions for C++), F#, VB	C#, C++/CLI (Managed Extensions for C++), F#, VB
UI runtime	Native (C++/WinRT and C++/CX) and managed (.NET Native)	Managed (.NET Framework) Support for .NET Core 3 is coming soon	Managed (.NET Framework) Support for .NET Core 3 is coming soon
Open source	Yes (Windows UI Library only)	Yes (.NET Core only)	Yes (.NET Core only)
Supports XAML	Yes	Yes	No
Strengths	XAML markup for UI Rich and customizable UX Your existing code bases are .NET Standard compliant High DPI support Support for multiple input types across Windows devices (including touch, pen, gamepad, mouse, and keyboard) Support for Xbox, HoloLens, IoT or Surface Hub Support for native C++ Optimized battery life Modern accessibility support (such as screen readers) Rich text data capabilities (such as built-in spell check) Inking support Secure execution via application containers (for example, untrusted content is sandboxed)	XAML markup for UI Rich and customizable UX Large collection of controls from Microsoft and partners Dense UI Support for Windows 7 Platform support for input validation	Rapid application development WYSIWYG editor for building UI Large collection of controls from Microsoft and partners Dense UI Support for Windows 7 Keyboard and mouse input
Scenarios that have limited support	Dense UI (creating a dense UI requires custom styles)1 Multiple window support1 Platform support for input validation1 Windows 7 is not supported Some UWP APIs require specific minimum versions of Windows 10 Full platform support and shell integration (for example, UWP currently doesn't support System Tray integration or full access to all devices) Direct access to all files on disk ADO.NET Existing code-base class libraries that use non-.NET Standard or non-Windows App Certification Kit compliant APIs Local network loopback support (that is, if your app needs to communicate with localhost without creating a loopback exemption on the target device) Intensive file I/O	High DPI support2 Touch input2	High DPI support2 Touch input2 Customizable UI Rich graphics and user experiences (such as touch and animations) Rich abstraction of views and data models

¹ We have publicly announced features that will address this scenario in a future release of Windows 10.

² Although the platform lacks first-class API support for this scenario, developers can support this scenario with workarounds.

Win32

Using the Win32 API with C++ makes it possible to achieve the highest levels of performance and efficiency by taking more control of the target platform with unmanaged code than is possible on a managed runtime environment like WinRT and .NET. However, exercising such a level of control over your application's execution requires greater care and attention to get right, and trades development productivity for runtime performance.
Here are a few highlights of what the Win32 API and C++ offers to enable you to build high-performance applications.

• Hardware-level optimizations, including tight control over resource allocation, object lifetimes, data layout, alignment, byte packing, and more.
• Access to performance-oriented instruction sets like SSE and AVX through intrinsic functions.
• Efficient, type-safe generic programming by using templates.
• Efficient and safe containers and algorithms.
• DirectX, in particular Direct3D and DirectCompute (note that UWP also offers DirectX interop).
• C++ AMP.

For more information, see Get started with desktop Windows apps that use the Win32 API and Desktop app technologies.

Win32 and C++ for traditional desktop applications

When writing a desktop application in C++, you can choose Win32 or MFC for the UI, or a host of third-party application frameworks that also support non-Windows platforms.

• Win32: This is the handle-based, C-language API of the Windows platform, including but not limited to UI functionality such as windowing, drawing, and UI controls. Because it is a low-level, C-language API based on handles, it's an infrequent choice for creating modern, UI-intensive apps. However, it supplies the basic APIs necessary to interact with the Windows platform, and is a suitable choice for apps that have simple UI requirements or that just want the Windows UI to stay out of the way as much as possible for example, games.
• MFC (Microsoft Foundation Class Library): This is the venerable application framework and UI library that has served Windows developers since 1992. It's a thin C++ wrapper over the handle-based, C-language Win32 API and provides object-oriented interfaces for many of the predefined windows, common controls, and other Windows objects. Although many modern UI frameworks in the .NET ecosystem surpass MFC in convenience, it is still the native UI framework of choice for many C++ developers creating applications for the Windows desktop.
• Third-party application frameworks: Because C++ can run on a wide variety of platforms and isn't tied to Windows or the .NET runtime, third-parties have developed new application and UI frameworks for C++ to ease development of cross-platform applications with rich user interfaces. Some of these frameworks provide their own look & feel, while others such as wxWidgets or Qt use or emulate the native control set of the platform. Using these libraries, it's possible to share nearly all of an application's source code between versions of the application that run on Windows or other platforms, such as OSX or Linux.

Other app platforms

Progressive Web Apps (PWAs)

PWAs let developers package their website code so it can be installed and run like an application on Windows 10 PCs. For more information, see Progressive Web Apps.

Xamarin

Use Xamarin to build cross-platform applications for Windows 10 that can also run on iOS and Android. For more information, see Xamarin.

C#: delegates

A delegate type represents references to methods with a particular parameter list and return type. Delegates make it possible to treat methods as entities that can be assigned to variables and passed as parameters. Delegates are similar to the concept of function pointers found in some other languages, but unlike function pointers, delegates are object-oriented and type-safe.

using System;
delegate double Function(double x);
class Multiplier
{
    double factor;
    public Multiplier(double factor) 
    {
        this.factor = factor;
    }
    public double Multiply(double x) 
    {
        return x * factor;
    }
}
class DelegateExample
{
    static double Square(double x) 
    {
        return x * x;
    }
    static double[] Apply(double[] a, Function f) 
    {
        double[] result = new double[a.Length];
        for (int i = 0; i < a.Length; i++) result[i] = f(a[i]);
        return result;
    }
    static void Main() 
    {
        double[] a = {0.0, 0.5, 1.0};
        double[] squares = Apply(a, Square);
        double[] sines = Apply(a, Math.Sin);
        Multiplier m = new Multiplier(2.0);
        double[] doubles =  Apply(a, m.Multiply);
    }
}
 

An instance of the Function delegate type can reference any method that takes a doubleargument and returns a double value. The Apply method applies a given Function to the elements of a double[], returning a double[] with the results. In the Main method, Apply is used to apply three different functions to a double[].

A delegate can reference either a static method (such as Square or Math.Sin in the previous example) or an instance method (such as m.Multiply in the previous example). A delegate that references an instance method also references a particular object, and when the instance method is invoked through the delegate, that object becomes this in the invocation.

Delegates can also be created using anonymous functions, which are "inline methods" that are created on the fly. Anonymous functions can see the local variables of the surrounding methods. Thus, the multiplier example above can be written more easily without using a Multiplier class:

double[] doubles = Apply(a, (double x) => x * 2.0);

An interesting and useful property of a delegate is that it does not know or care about the class of the method it references; all that matters is that the referenced method has the same parameters and return type as the delegate.

Learn C#

C# is an important Microsoft-supported language which is widely used in .NET applications.

using System;
class Hello
{
    static void Main()
    {
        Console.WriteLine("Hello, World");
    }
}
 

C# is an object-oriented language, but C# further includes support for component-orientedprogramming. Contemporary software design increasingly relies on software components in the form of self-contained and self-describing packages of functionality. Key to such components is that they present a programming model with properties, methods, and events; they have attributes that provide declarative information about the component; and they incorporate their own documentation. C# provides language constructs to support directly these concepts, making C# a very natural language in which to create and use software components.

Several C# features aid in the construction of robust and durable applications: Garbage collection automatically reclaims memory occupied by unreachable unused objects; exception handling provides a structured and extensible approach to error detection and recovery; and the type-safe design of the language makes it impossible to read from uninitialized variables, to index arrays beyond their bounds, or to perform unchecked type casts.

C# has a unified type system. All C# types, including primitive types such as int and double, inherit from a single root object type. Thus, all types share a set of common operations, and values of any type can be stored, transported, and operated upon in a consistent manner. Furthermore, C# supports both user-defined reference types and value types, allowing dynamic allocation of objects as well as in-line storage of lightweight structures.

To ensure that C# programs and libraries can evolve over time in a compatible manner, much emphasis has been placed on versioning in C#’s design. Many programming languages pay little attention to this issue, and, as a result, programs written in those languages break more often than necessary when newer versions of dependent libraries are introduced. Aspects of C#’s design that were directly influenced by versioning considerations include the separate virtual and override modifiers, the rules for method overload resolution, and support for explicit interface member declarations.

Windows 10 development?

Windows development tools and platforms

Most developers who write software for Windows use Visual Studio, the development environment that supports code editing, designing, building and debugging. Visual Studio is your toolbox, and where you'll spend your time honing your apps. But you can't create anything with Visual Studio alone, so you'll need to make use of software development kits (SDKs) and platforms such as .NET to make a working app.

As needs and technologies change over the years, a variety of platforms and frameworks have been created to help developers write apps. Different types of application use different tools, and different developers prefer some tools over others. There is no "one size fits all" rule. In this module, we explain your choices and then walk you through building an app by using some popular options.

Advice on selecting a platform

Which development platform should you use? Well, that's really up to you. You may already have written an app by using Windows Presentation Foundation (WPF), in which case you'll probably want to continue using it. You can now add to WPF new features that are available from the Universal Windows Platform (UWP). If you're starting a new project from scratch, using UWP is an attractive option. With UWP you get immediate access to the latest Fluent Design System components for making modern user interfaces.

This module discusses UWP, WPF, and Windows Forms examples, but other platforms, such as Progressive Web Apps(PWAs), are available as well.

Common terms you will see

C#

C# is a programming language, perhaps the most popular for developing Windows apps. C# is a modern language with sophisticated features, but it's still easy enough for a beginner to pick up quickly. You can also use other languages, such as Visual Basic, C++ (and WinRT/C++), F#, and JavaScript.

If you are completely new to C#, here's a C# Guide you will find useful.

XAML

XAML is a markup language that's used to define user interfaces. Several Windows development platforms use XAML, and so there are variations in exact syntax and capabilities. XAML can be generated automatically by tools such as the Visual Studio designer or the Blend editor, or even entered manually. You'll see a lot of XAML if you develop with UWP or WPF. XAML looks like a typical XML-based markup language. 

.NET

.NET is a free, cross-platform, open source developer platform for building many different types of applications. With .NET, you can use multiple languages, editors, and libraries to build for web, mobile, desktop, gaming, and the Internet of Things (IoT). .NET Standard is a base set of application programming interfaces (APIs) that are common to all .NET implementations. Bottom line: .NET is a collection of very useful, proven, high-quality features that make your code easier to write and more reliable.

When you write a Windows Forms or WPF app, you're using .NET. UWP has its own similar features but doesn't use .NET by default.

GitHub

GitHub is a website and service that can act as a storage place for source code, individual and shared projects, and other forms of content. In practical terms, you can save your projects to GitHub and share them with other developers (a very common scenario with open source projects), or search it for code and tools that will help you. It uses the tool Git to manage submissions and deal with changes from multiple developers.

Windows Template Studio

Windows Template Studio is a Visual Studio extension that accelerates the creation of new UWP apps by using a wizard-based experience. The resulting UWP project is well-formed, readable code that incorporates the latest Windows 10 features while implementing proven patterns and best practices. WTS is an open source project on GitHub.

Windows Community Toolkit

The Windows Community Toolkit is a collection of helper functions, custom controls, and app services. It simplifies and demonstrates common developer tasks that build UWP apps for Windows 10 and ships through NuGet for easy consumption by developers.

Build, configure, and execute a Azure function

Triggers

Functions are event driven, which means they run in response to an event.

The type of event that starts the function is called a trigger. You must configure a function with exactly one trigger.

Azure supports triggers for the following services.

Service	Trigger description
Blob storage	Start a function when a new or updated blob is detected.
Azure Cosmos DB	Start a function when inserts and updates are detected.
Event Grid	Start a function when an event is received from Event Grid.
HTTP	Start a function with an HTTP request.
Microsoft Graph Events	Start a function in response to an incoming webhook from the Microsoft Graph. Each instance of this trigger can react to one Microsoft Graph resource type.
Queue storage	Start a function when a new item is received on a queue. The queue message is provided as input to the function.
Service Bus	Start a function in response to messages from a Service Bus queue.
Timer	Start a function on a schedule.

Bindings

Bindings are a declarative way to connect data and services to your function. Bindings know how to talk to different services, which means you don't have to write code in your function to connect to data sources and manage connections. The platform takes care of that complexity for you as part of the binding code. Each binding has a direction - your code reads data from input bindings and writes data to output bindings. Each function can have zero or more bindings to manage the input and output data processed by the function.

A trigger is a special type of input binding that has the additional capability of initiating execution.

Azure provides a large number of bindings to connect to different storage and messaging services.

A sample binding definition

Let's look at an example of configuring a function with an input binding (trigger) and an output binding. Let's say we want to write a new row to Azure Table storage whenever a new message appears in Azure Queue storage. This scenario can be implemented using an Azure Queue storage trigger and an Azure Table storage output binding.

The following snippet is the function.json file for this scenario.

{
  "bindings": [
    {
      "name": "order",
      "type": "queueTrigger",
      "direction": "in",
      "queueName": "myqueue-items",
      "connection": "MY_STORAGE_ACCT_APP_SETTING"
    },
    {
      "name": "$return",
      "type": "table",
      "direction": "out",
      "tableName": "outTable",
      "connection": "MY_TABLE_STORAGE_ACCT_APP_SETTING"
    }
  ]
}

Our JSON configuration specifies that our function will be triggered when a message is added to a queue named myqueue-items. The return value of our function is then written to the outTable table in Azure Table storage.

This example is a simple illustration of how we configure bindings for a function. We could change the output to be an email using a SendGrid binding, or put an event onto a Service Bus to notify some other component in our architecture, or even have multiple output bindings to push data to various services.

Creating a function in the Azure portal

Azure provides several pre-made function templates for common scenarios.

Quickstart templates

When adding your first function, you are presented with the Quickstart screen. This screen allows you to choose a trigger type (HTTP, Timer, or Data) and programming language (C#, JavaScript, F# or Java). Then, based on your selections, Azure will generate the function code and configuration for you with some sample code provided to display out the input data received in the log.

Custom function templates

The selection of Quickstart templates provides easy access to the most common scenarios. However, Azure provides over 30 additional templates you can start with. These can be selected from the template list screen when creating subsequent functions or be selected by using the Custom function option on the Quickstart screen.

• HTTP trigger w/ C#, F#, or JavaScript
• Timer trigger w/ C#, F#, or JavaScript
• Queue trigger w/ C#, F#, or JavaScript
• Service Bus Queue trigger w/ C#, F#, or JavaScript
• Azure Cosmos DB trigger w/ C# or JavaScript
• IoT Hub (Event Hub) w/ C#, F#, or JavaScript
• ... and many more

Navigating to your function and files

When you create a function from a template, several files are created. For example, if you opted to use the Webhook + API Quickstart using JavaScript, the files generated would be a configuration file, function.json, and a source code file, index.js. The functions you create in a function app appear under the Functions menu item in the function app portal.

When you select a function in your function app, a code editor opens and displays the code for your function, as illustrated in the following screenshot.

As you can see in the preceding screenshot, there's a flyout menu on the right that includes a tab to View files. Selecting this tab shows the file structure that makes up your function.

Testing your Azure function

Once you've created a function, you'll want to test it. There are a couple of approaches: manual execution and testing from within the Azure portal itself.

Manual execution

You can start a function by manually triggering the configured trigger. For instance, if you are using an HTTP trigger - you can use a tool such as Postman or cURL to initiate an HTTP request to your function endpoint URL, which is available from the HTTP trigger definition (Get function URL).

Testing in the Azure portal

The portal also provides a convenient way to test your functions. On the right side of the code window, there is a flyout tabbed navigation menu. This menu contains a Test item. Expanding the menu and selecting this tab gives you another way to execute your function and view the result. When you click Run in this test window, the results are displayed in the output window, along with a status code.

Monitoring dashboard

The ability to monitor your functions is critical during development and in production. The Azure portal provides a monitoring dashboard available if you turn on the Application Insights integration. In the function app navigation menu, once you expand the function node you'll see a Monitor menu item. This monitor dashboard provides a quick way to view the history of function executions and displays the timestamp, result code, duration, and operation ID populated by Application Insights.

Streaming log window

You're also able to add logging statements to your function for debugging in the Azure portal. The called methods for each language are passed a "logging" object, which may be used to log information to the log window located in a tabbed flyout menu located at the bottom of the code window.

The following JavaScript code snippet shows how to log a message using the context.log method (the context object is passed to the handler).

context.log('Enter your logging statement here');

We could do the same thing in C# using the log.Info method. In this case, the log object is passed to the C# method processing the function.

log.Info("Enter your logging statement here");

Introduce serverless

What is serverless compute?

Serverless compute can be thought of as a function as a service (FaaS), or a microservice that is hosted on a cloud platform. Your business logic runs as functions and you don't have to manually provision or scale infrastructure. The cloud provider manages infrastructure. Your app is automatically scaled out or down depending on load. Azure has several ways to build this sort of architecture. The two most common approaches are Azure Logic Apps and Azure Functions, which we focus on in this module.

What is Azure Functions?

Azure Functions is a serverless application platform. It allows developers to host business logic that can be executed without provisioning infrastructure. Functions provides intrinsic scalability and you are charged only for the resources used. You can write your function code in the language of your choice, including C#, F#, and JavaScript. Support for NuGet and NPM is also included, so you can use popular libraries in your business logic.

Benefits of a serverless compute solution

Serverless compute is a great option for hosting business logic code in the cloud. With serverless offerings such as Azure Functions, you can write your business logic in the language of your choice. You get automatic scaling, you have no servers to manage, and you are charged based on what is used — not on reserved time. Here are some additional characteristics of a serverless solution for you to consider.

Avoids over-allocation of infrastructure

Suppose you've provisioned VM servers and configured them with enough resources to handle your peak load times. When the load is light, you are potentially paying for infrastructure you're not using. Serverless computing helps solve the allocation problem by scaling up or down automatically, and you're only billed when your function is processing work.

Stateless logic

Stateless functions are great candidates for serverless compute; function instances are created and destroyed on demand. If state is required, it can be stored in an associated storage service.

Event driven

Functions are event driven. This means they run only in response to an event (called a "trigger"), such as receiving an HTTP request, or a message being added to a queue. You configure a trigger as part of the function definition. This approach simplifies your code by allowing you to declare where the data comes from (trigger/input binding) and where it goes (output binding). You don't need to write code to watch queues, blobs, hubs, etc. You can focus purely on the business logic.

Functions can be used in traditional compute environments

Functions are a key component of serverless computing, but they are also a general compute platform for executing any type of code. Should the needs of your app change, you can take your project and deploy it in a non-serverless environment, which gives you the flexibility to manage scaling, run on virtual networks, and even completely isolate your functions.

Drawbacks of a serverless compute solution

Serverless compute will not always be the appropriate solution to hosting your business logic. Here are a few characteristics of functions that may affect your decision to host your services in serverless compute.

Execution time

By default, functions have a timeout of 5 minutes. This timeout is configurable to a maximum of 10 minutes. If your function requires more than 10 minutes to execute, you can host it on a VM. Additionally, if your service is initiated through an HTTP request and you expect that value as an HTTP response, the timeout is further restricted to 2.5 minutes. Finally, there's also an option called Durable Functions that allows you to orchestrate the executions of multiple functions without any timeout.

Execution frequency

The second characteristic is execution frequency. If you expect your function to be executed continuously by multiple clients, it would be prudent to estimate the usage and calculate the cost of using functions accordingly. It might be cheaper to host your service on a VM.

While scaling, only one function app instance can be created every 10 seconds, for up to 200 total instances. Keep in mind, each instance can service multiple concurrent executions, so there is no set limit on how much traffic a single instance can handle. Different types of triggers have different scaling requirements, so research your choice of trigger and investigate its limits.

Ref:

1. Decide if serverless computing is right for your business needs, Azure Learning