Forem: Maxime Rouiller

1-Click Deployment of Cognitive Services with ARM Templates

Maxime Rouiller — Sat, 04 Apr 2020 15:30:00 +0000

I've been using Cognitive Services for a while now. I'm creating AI services for hackathons, personal projects, or actual work.

One of the scenarios I'm always facing is to create the service initially. It requires you first to find the right service, then chooses a region, then a pricing tier. Could all of this be made simpler? I think so!

If, like me, you are only using the free tier and are trying to publish into an EastUS/WestUS region, then I'm ready to show you how to do this!

There is a feature in Azure that allows us to create templates for resources. They are called Azure Resource Manager Templates. They are also known as ARM Templates. At a bare minimum, those templates are a combination of a template file and a parameter file.

The template file defines the resources that we need to create while the parameters allow you to set variables at deployment time. You can use the template directly with the Azure Portal and fill the parameters there. Alternatively, you can create a set of parameters in a file and deploy those resources with a Command-Line. Isn't that powerful?

The best use for us at the moment, however, is to reduce the number of choices. We're going to build a single-click deployment option for us to use later on.

Let me show you the repository I created for One-Click Cognitive Services deployment.

Let's take a look at our templates to identify how we are deploying them.

{
    "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
    "contentVersion": "1.0.0.0",
    "parameters": {
        "baseName": {
            "type": "string",
            "defaultValue": "computervision"
        },
        "location": {
            "type": "string",
            "defaultValue": "eastus",
            "allowedValues": ["eastus", "westus"]
        },
        "apiType": {
            "type": "string",
            "defaultValue": "ComputerVision",
            "allowedValues":["ComputerVision"]
        },
        "sku": {
            "type": "string",
            "defaultValue": "F0"
        }
    },
    "resources": [
        {
            "apiVersion": "2017-04-18",
            "name": "[concat(parameters('baseName'), uniqueString(resourceGroup().id))]",
            "location": "[parameters('location')]",
            "type": "Microsoft.CognitiveServices/accounts",
            "kind": "[parameters('apiType')]",
            "sku": {
                "name": "[parameters('sku')]"
            },
            "properties": {
                "customSubDomainName": "[concat(parameters('baseName'), uniqueString(resourceGroup().id))]"
            }
        }
    ]
}

There's a lot to unpack here. There are 3 sections in that file: parameters, variables, and resources. We're not going to use the variables, and parameters is self-describing. Let's look at resources.

First, it's an array, which means that we are can create multiple resources at the same time. For the resource we selected, Computer Vision, let's look at the resource structure.

Excluding whitespaces and sub-properties, there are only around seven meaningful lines in there. Let's go through them.

apiVersion is representing the version of the resource provider we use internally. It affects the available properties and schema.

name is representing your resource name. Here, we are building a unique name using the uniqueString function to ensure we're not creating duplicates within a same Resource Group.

location is representing the deployed region of the service. From the default values, we are only letting EastUS and WestUS as options. For a complete list of locations, here's the reference page.

type is representing the actual service we are deploying. For Cognitive Services, it's all the same type. The attribute kind specify which service we want.

kind is representing what kind of cognitive services we want to deploy. There are many available and is listed by running the Azure CLI command az cognitiveservices account list-kinds -o table

sku is representing the amount we want to pay. We are selecting F0 here by default since we want the free option.

customSubDomainName represents the domain name we can enable for token authentication.

With that, we can deploy cognitive services with the click of a button within any subscription on Azure.

If you are interested in a follow-up article, please let me know in the comments or on Twitter.

September 2019 .NET/ASP.NET Documentation Update

Maxime Rouiller — Fri, 04 Oct 2019 14:01:31 +0000

TLDR; This is a status update on the .NET documentation. If you want me to do more of those (once a month), please let me know in the comments!

Comment: If you have suggestions, please let me know in the comments. Any product feedback will be forwarded to the proper product team.

Hi everyone!

This is the fourth month where I post a summary of all .NET-related documentation that was significantly updated. This month covers all changes from September 1st to September 27th.

My name is Maxime Rouiller and I’m a Cloud Advocate with Microsoft. For this month, I’m covering three major products:

.NET, which had ~474 commits, and 3,492 changed files on their docs repository and ~96 PRs on their API docs repository
ASP.NET, which had ~282 commits, and 1,102 changed files on their docs repository
NuGet, which had ~109 commits, and 45 changed files on their docs repository

For this month, I’ll be trying something new. I will not be leaving a comment beside each article and will instead use a Legend with emojis (I know, it’s Reddit. What am I doing!?). Thing is, it’s easier to show you what’s what than explain it. Where relevant, I will leave notes.

Legend

📢: Major/Main article that everyone will want to read
💥: Important/Must read.
✨: Brand new page

Note: It’s not because a page doesn’t have an icon that it is not important. Everything here is either brand new or significantly modified.

Themes this month

.NET Core 3.0

What’s new for Preview 9 and GA release
JSON serialization
CLI updates

Managed Languages

C# 8.0 Updates
C# 8.0 Spec updates
✨101 LINQ samples in your browser. Through the magic of try.net, Blazor, and Roslyn, you can explore LINQ using a dotnet global tool. See the try-samples home page for installation instructions and more samples.

.NET Core

E-book - Blazor for Web Forms Developers (Preview) ✨

Are you a Web Forms developer? This book is brand new and will help you bridge your knowledge between Web Forms and Blazor.

More content should be coming in the next few months.

❗ Don’t forget that you can download all e-books with the Download PDF button in the bottom left of your screen (desktop) or through the Content menu if you are on mobile. ❗

Blazor for ASP.NET Web Forms Developers

E-book - Architecting Cloud Native .NET Applications for Azure (Preview)

Are you a developer, a lead or even an architect? Do you want to know how to build an application that is made for the cloud?

This is the book for you.

❗ Don’t forget that you can download all e-books with the Download PDF button in the bottom left of your screen (desktop) or through the Content menu if you are on mobile. ❗

Architecting Cloud Native .NET Applications for Azure

E-book - ASP.NET Core gRPC for WCF Developers (Preview) 💥✨

Lots of you have asked me last month about how to handle gRPC coming from a WCF point of view. Well, this month is your time to shine. There’s a literal book being currently written about it. The whole thing is brand new and is aimed at developers that were, surprise surprise, using WCF before.

This book takes you from migration, load balancing, Kubernetes, error handling, security, and to why even use it. It’s a must-read.

❗ Don’t forget that you can download all e-books with the Download PDF button in the bottom left of your screen (desktop) or through the Content menu if you are on mobile. ❗

ASP.NET Core gRPC for WCF Developers

Compatibility 💥

When you’re upgrading your app from one version of .NET Core to another, you might be interested to know if there were any compatibility changes introduced that could impact your app. The list is not final yet so there will be more breaking changes added in the next few months. You have the option to look at them by version or feature area:

Desktop Guide for Windows Presentation Foundation (WPF) 💥✨

We’re revamping the WPF content and giving it a new home called “Desktop Guide”. This guide will cover WPF for both .NET Core and .NET Framework, with an emphasis on .NET Core. This guide will continue to grow over time as the team modernizes and bring more relevant content into it.

Whether you like XAML or not, it’s a good thing to remember as there are tons of WPF applications in the wild and your chances of encountering one is mostly guaranteed.

This guide may save you some time in the future.

.NET Framework

Updates to the actual .NET Framework content. Not Core related.

.NET Guide - Assemblies in .NET

Everything you ever wanted or didn’t want to know about assemblies in .NET. To sign or not to sign isn’t the question. Did you know? That is the question.

The assemblies content used to be in the .NET Framework guide and was now moved to where our .NET Fundamentals content live. It’s now applicable to both .NET Framework and .NET Core.

Tooling, tutorial, serialization, exceptions, and others

Machine learning tutorial? Yes. We haven’t gotten enough of them that’s for sure. Machine learning is becoming omnipresent and starting with a tutorial sure is a good way to learn.

The JSON serializer is brand new. Have you tried it? Those articles are your perfect start to understanding how it works. Including the most fun data type to serialize, DateTime and DateTimeOffset.

With the new tooling and .NET being used on the daily, you’re bound to run into issues. The first article handles the possible issues you might run into. The second shows you how to make localized exception messages. Neat 🤖📷.

ASP.NET Core

📢 What’s new in ASP.NET Core 3.0
💥 Migrate from ASP.NET Core 2.2 to 3.0

Blazor

If you are now reading this, it’s because you are a fan of WebAssembly(aka WASM). Enjoy this small update.

Server-side Blazor has hit GA while the client-side is still in Preview.

Fundamentals

Lots of fundamental articles have been updated to the 3.0 release.

You will find here updated articles, samples, and general tidying of articles (typos, more snippets, clarifications).

gRPC

So you’re not the book kind of developer. You’d rather jump in the code and try right away. I get that. After you get up to date as to what is gRPC on .NET Core, we’re getting right into how to integrate with gRPC services. Straight to the code.

MVC

Updated article about testing controller logic. Finally, there were some docs missing about Tag Helpers. This is now a solved problem. See below.

SignalR

We were missing a page about what feature each of our client supports. Check out the brand new page below. Then, since SignalR has dropped UseSignalR() everywhere and you now need to use UseEndpoints(...), all of our docs now accurately represent how to set this up.

WebAPI

After releasing the Microsoft.dotnet-openapi global tool, it is important to have documentation for it. That’s in the first article. A new article on customizing your error handling with ASP.NET Core Web API is definitely a must-read as well.

For the rest, you will find here updated samples, and general tidying of articles (typos, more snippets, clarifications).

Host and Deploy

Tons of updates on hosting with the new release of 3.0 in GA. With the release of Blazor Server-Side, this documentation also needed major updates. If you are using Blazor today, make sure to read this to avoid problems in the future. Health checks now get wrapped under UseEndpoints which required its documentation to be changed as well.

Performance

Updated package names and new snippets.

Distributed caching in ASP.NET Core

Razor Pages

The introduction has been completely rewritten with new code snippets for 3.0. Worth taking the time to refresh your knowledge on Razor Pages.

Security

Updated for UseEndpoints() as well as including new API updates for 3.0. Updated documentation troubleshoot certification update.

Tests

Integration tests in ASP.NET Core

NuGet

📢 NuGet 5.3 Release Notes
💥 Deprecating packages on nuget.org

Reference

.nuspec File Reference for NuGet
- deprecating iconUrl, adding icon to replace it.
NuGet pack and restore as MSBuild targets
- adding instruction on how to pack an icon within your package

Using EasyAuth (AppService Authentication) with ASP.NET Core

Maxime Rouiller — Tue, 09 Jul 2019 17:15:00 +0000

There's this cool feature in Azure AppService that I love. It's called EasyAuth although it may not use that name anymore.

When you are creating a project and want to throw in some quick authentication Single-Sign-On (SSO for short) is a great way to throw the authentication problem at someone else while you keep on working on delivering value.

Of course, you can get a clear understanding of how it works, but I think I can summarize quite quickly.

EasyAuth works by intercepting the authentication requests (/.auth/*) or when authenticated, fills in the user context within your application. That's the 5-second pitch.

Now, the .NET Framework application lifecycle allowed tons of stuff to happen when you added an HttpModule in your application. You had access to everything and the kitchen sink.

.NET Core, on the other hand, removed the concept of all-powerful modules and instead introduced Middlewares. Instead of relying on a fixed set of events happening in a pipeline, we could expand the pipeline as our application needed it.

I'm not going to go into details on how to port HttpModules and Handlers but let's assume that they are widely different.

One of the many differences is that HttpModules could be set within a web.config file and that config file could be defined at the machine level. That is not possible with Middlewares. At least, not yet.

Why does it matter?

So with all those changes, why did it matter for EasyAuth? Well, the application programming model changed quite a lot, and the things that worked with the .NET Framework stopped working with .NET Core.

I'm sure there's a solution on the way from Microsoft but a client I met encountered the problem, and I wanted to solve the problem.

Solving the issue

So, after understanding how EasyAuth worked, I've set on to create a repository as well as a NuGet package.

What I was fixed to do was relay the captured identity and claims into the .NET Core authentication pipeline. I'm not doing anything else.

Installing the solution

The first step is to install the NuGet package using your method of choice. Then, adding an [Authorize(AuthenticationSchemes = "EasyAuth")] to your controller.

Finally, adding the following lines of code to your Startup.cs file.

using MaximeRouiller.Azure.AppService.EasyAuth
// ...
public void ConfigureServices(IServiceCollection services)
{
    //... rest of the file
    services.AddAuthentication().AddEasyAuthAuthentication((o) => { });
}

That's it. If your controller has an [Authorize] attribute, the credentials are going to automatically start populating the User.Identity of your MVC controller.

Question

Should I go farther? Would you like to see this integrated within a supported Microsoft package? Reach out to me directly on Twitter or the many other ways available.

Solving Cold-Start disturbs serverless' definition and it's okay

Maxime Rouiller — Wed, 19 Jun 2019 14:50:00 +0000

When you look at Azure Functions, you see it as a great way to achieve elastic scaling of your application. You only pay for what you use, you have a free quota, and they allow you to build entire applications on this model.

The whole reason why Azure Functions is free is due to its linked plan. It’s called Consumption Plan. While Azure Functions is an application model, the consumption plan is where the serverless kicks in. You give us your application, and you care less about the servers.

One of the main selling points of serverless is the ability to scale to 0. It allows you to pay only for what you use and it’s a win-win for everyone involved.

That would look a little bit like the image below.

About Cold Starts

Cold start happens when an application loads for the first time on a server. What happens behind the scene look as follows.

The cloud receives a request for your application and starts allocating a server for it
The server downloads your application
The cloud forwards the request received initially to your application
The application stacks load up and initialize what it needs to run the code successfully
Your application loads up and starts handling the request.

This workflow happens every time your application either goes from 0 to 1 or when the cloud scales you out.

This whole process is essential as Azure can’t keep the servers running all the time without blocking other applications from running on the same servers.

That time between when the request initially arrives and is handled by a server can be longer than 500ms. What if it takes a few seconds? What do you do to solve that problem?

Premium Functions

Azure Premium Functions is the best way to resolve that problem. It breaks the definition of Serverless by the fact that you can’t scale to 0. It does, however, offer the elastic scale-out that is required to handle a massive amount of load.

This minimum of one instance is what makes a night and day difference in terms of improving performance. This single instance already has your application on it; the Azure Functions runtime is ready to handle your application.

Having a permanent instance removes most of the longer steps needed to handle a request. It effectively removes cold-start issues as seen below.

When would you use Premium Functions? When your application can’t have cold-starts. Not every application require the need for this feature, and I wholeheartedly agree. Keep on using the Consumption Plan if it fits your needs, and the cold-start isn’t a problem.

If you are among the clients that can’t afford to have cold-start time in your application while still needing the bursting of servers, Premium Function is for you.

Resources

I’ve gone very quickly over the essential feature that I think fixes one of the more significant problems with serverless. More features come with Premium Functions. I’ve left a link to the docs in case you want to read it all by yourself.

Azure Premium Functions

Getting rid of Time Zone issues within Azure Functions

Maxime Rouiller — Fri, 14 Jun 2019 15:25:00 +0000

Your client wants to run a database clean up task every day at 2 am. Why? Mostly because it's when there's no traffic on the site and it reduces the amount of risk of someone encountering problems due to maintenance tasks.

Sounds good! So as an engineer, you know that task is periodic and you don't need to create a Virtual Machine to handle this task. Not even an AppService is required. You can go serverless and benefit from those free million monthly executions that they offer! Wow. Free maintenance tasks!

You create a new Function app, write some code that looks something like this.

[FunctionName("DatabaseCleanUpFunction")]
public static void Run([TimerTrigger("0 0 2 * * *")]TimerInfo myTimer, ILogger log)
{
    // todo: clean up the database
}

Wow! That was easy! You publish this application to the cloud, test it out manually a few times maybe then publish it to production and head back home.

When you get back to the office the next day, you realize that the job has run yes... but at 10 pm. Not 2 am. What happened!?

You've been struck by Time Zones. Oh, that smooth criminal of time.

Default time zone

The default timezone for Azure Functions is UTC. Since I'm in the Eastern Time Zone, this previous function now runs at 10 pm instead of 2 am. If there were users that were using my application at that time, I could have severely impacted them.

That is not good.

The Fix

There are two ways to go around this. One, we change our trigger's CRON Expression to represent the time in UTC and keep our documentation updated.

The second way is to tell Azure Functions in which timezone they should interpret the CRON Expression.

For me, a man of the best Coast, it involves setting the WEBSITE_TIME_ZONE environment variable to Eastern Standard Time. If you are on the lesser Coast, you may need to set yours to Pacific Standard Time.

However, let's be honest. We're in a global world. You need The List™.

Find your region on that list, set it in the WEBSITE_TIME_ZONE, and Azure Function automatically set the correct Time Zone for your CRON expression.

Fixing Azure Functions and Azure Storage Emulator 5.8 issue

Maxime Rouiller — Tue, 19 Mar 2019 13:05:00 +0000

So you've updated Azure Functions to the latest version (2.X at the time of writing this), and nothing starts anymore.

Now, when you boot the Functions host, you get this weird error.

[TIMESTAMP] A host error has occurred
[TIMESTAMP] Microsoft.WindowsAzure.Storage: Server encountered an internal error. Please try again after some time.

There happen to be an issue opened on GitHub that relates to Durable Functions and Azure Storage Emulator.

The thing is, it's not directly related to Azure Durable Functions. It's related, in my opinion, in a breaking change that happened in Azure Storage Emulator 5.8 ways of responding from its API.

If you want to fix that issue, merge the following setting in your local.settings.json file.

{
  "Values": {
    "AzureWebJobsSecretStorageType": "files"
  }
}

This only applies when "AzureWebJobsStorage": "UseDevelopmentStorage=true".

So why should we set that? There was a change that was introduced back in September 2018 when Azure Functions V2 was released. Azure Functions store your secret on disk before 2.0. Azure Functions, when slot swapping environments, swap the content of the disk including the secrets.

What this setting does is ensure that Functions stores secrets on your file system by default. It's expected behavior when using a local development environment.

If you want to read more, there is an entire article on that behavior.

Conclusion

To fix the issue, you can either use the workaround or update the Azure Storage Emulator to 5.9.

Wrapping Node.js Azure Table Storage API to enable async/await

Maxime Rouiller — Thu, 14 Mar 2019 19:30:00 +0000

I love the latest and greatest. Writing code by using the new language syntax is fantastic.

What happens when your favorite library doesn't? You are stuck trying to find a workaround. We all hate workarounds, but they are the glue that keeps our code together at the end of the day.

Between the runtime, the frameworks, the libraries, and everything else... we need everyone on the same page.

Recently, I had to use Azure Node.js Table Storage API.

First, let me say I know. Yes, there is a v10 that exist, and this is the v2. No, v10 doesn't support Table Storage yet. So, let's move on.

Here's the code I wanted to see:

let storage = require('azure-storage');
// ...

async function getAllFromTable() {
  let tableService = storage.createTableService(connectionString);
  let query = new storage.TableQuery()
    .where('PartitionKey eq ?', defaultPartitionKey);
  return await queryEntities(tableService, 'TableName', query, null);
}

Here's the code that I had:

async function getAllFromTable() {
  return new Promise((resolve, reject) => {
    let tableService = storage.createTableService(connectionString);
    let query = new storage.TableQuery()
      .where('PartitionKey eq ?', defaultPartitionKey);

    tableService.queryEntities('TableName', query, null, function (err, result) {
      if (err) {
        reject(err);
      } else {
        resolve(result);
      }
    });
  });
}

The sight of function callbacks gave me flashbacks to a time where code indentation warranted wider monitors.

The workaround

Here's the temporary workaround that I have for now. It allows me to wrap highly used functions into something more straightforward.

async function queryEntities(tableService, ...args) {
    return new Promise((resolve, reject) => {
        let promiseHandling = (err, result) => {
            if (err) {
                reject(err);
            } else {
                resolve(result);
            }
        };
        args.push(promiseHandling);
        tableService.queryEntities.apply(tableService, args);
    });
};

Overview of the workaround

We're using async everywhere
Using Rest parameters args allow us to trap all parameters from that API
We're wrapping the proper promise and inserting it into the arguments
We're calling the relevant API with the proper argument.

Conclusion

That's it. While the Node.js Storage v10 is having table storage implemented, I recommend wrapping table storage code into a similar structure.

This will allow you to use the new language syntax while they update the library.

How to build a multistage Dockerfile for SPA and static sites

Maxime Rouiller — Thu, 21 Feb 2019 19:00:00 +0000

When you are a consultant, your goal is to think about the best way to save money for your client. They are not paying us because we can code. They are paying because we can remove a few dollars (or a few hundred) from their bills.

One of the situations we often find ourselves in is building a single page application (SPA). Clients want dynamically driven applications that don't refresh the whole page, and a SPA is often the perfect choice for them. Among the many tools used to build a SPA, we find Angular, Vue, and React.

I've found that delivering websites with containers is a universal way of ensuring compatibility across environments, cloud or not. It also prevents a developer's environment from having to install 25 different tools/languages/SDKs.

It keeps thing concise and efficient.

If you want to know more about Docker containers, take a few minutes, in particular, to read about the terminology.

The problem is that we only need Node.js to build that application, not to run it. So, how would containers solve our problem? There's a concept in Docker called Multistage builds where you can separate the build process from the execution.

Here’s a template you can use to build a SPA with Node.js.

Dockerfile template for Node.js

Note: this is a template taken from the VueJS documentation.

#build stage for a Node.js application
FROM node:lts-alpine as build-stage
WORKDIR /app
COPY package*.json ./
RUN npm install
COPY . .
RUN npm run build

#production stage
FROM nginx:stable-alpine as production-stage
COPY --from=build-stage /app/dist /usr/share/nginx/html
EXPOSE 80
CMD ["nginx", "-g", "daemon off;"]

There's a lot to unpack here. Let's look at the two stages separately.

Build Stage (Node.js)

Multistage docker builds allow us to split our container in two ways. Let's look at the build stage.

The first line is a classic. We're starting from an Alpine image that has Node.js pre-installed on it.

Note: Alpine Linux is a security-oriented, lightweight Linux distribution based on musl libc and busybox. Its main characteristic is it runs everywhere and is extremely small, around 5MB.

We're configuring /app as the working directory. Then, we do something unusual. We copy our package*.json files before copying everything else.

Why? Each line in a Dockerfile represents a layer. When building a layer, if a layer already exists locally, is retrieved from the cache instead of being rebuilt. By copying and installing our packages in a separate step, we avoid running npm install on dependencies that didn't change in the first place. Since npm install can take a while to install, we save some time there.

Finally, we copy the rest of our app and run the npm build task. If your application doesn't have a build task, change the name to whatever tasks generate an output folder like dist.

The result? We have a correctly built Node.js application located in /app/dist.

Production Stage

We've generated our SPA or static site with Node.js but... our application isn't using Node.js. It's using HTML/CSS/JS. We don't need a Node.js image to take our application to production. Instead, we only need an HTTP server. Let's use the NGINX Docker Image as a host.

We copy the output from our previously defined build-stage /app/dist folder into the NGINX defined folder /usr/share/nginx/html as mentioned in their docs.

After exposing port 80, we need to run NGINX with the daemon off; option to have it run in the foreground and preventing the container from closing.

Building the Dockerfile

This step is easy. Run the following command in the folder containing the Dockerfile.

docker build -t mydockerapp:latest .

Running the Docker container locally

Running the application on your machine is of course just a simple command away.

docker run -it -p 8080:80 mydockerapp:latest

This command is doing two things. First, it runs the container in interactive mode with the -i flag. That flag will allow us to see the output of NGINX as it runs. Second, it maps port 8080 of your local machine to port 80 of the container.

Opening your browser to http://localhost:8080 will show you your website.

Conclusion

I'm using Docker more and more for everything. I'm building applications that are single use with current technology. Docker empowers me in running applications with older versions of frameworks, runtime, languages, without causing tooling versioning issue with my machine.

While technology may continue to evolve, I'm never afraid that my Docker container won't work anymore. Things have been stuck in time if only for a moment.

That means I don't have to upgrade that AngularJS 1.X app to stay cool. If it works, it works.

Are you using Docker in unusual ways? Share them with me on Twitter!