The Daily Parker

Politics, Weather, Photography, and the Dog

Wednesday afternoon

I spent the morning unsuccessfully trying to get a .NET 5 Blazor WebAssembly app to behave with an Azure App Registration, and part of the afternoon doing a friend's taxes. Yes, I preferred doing the taxes, because I got my friend a pile of good news without having to read sixty contradictory pages of documentation.

I also became aware of the following:

Tomorrow morning, I promise to make my WebAssembly app talk to our Azure Active Directory. Right now, I think someone needs a walk.

Third day of summer

The deployment I concluded yesterday that involved recreating production assets in an entirely new Azure subscription turned out much more boring (read: successful) than anticipated. That still didn't stop me from working until 6pm, but by that point everything except some older demo data worked just fine.

That left a bit of a backup of stuff to read, which I may try to get through at lunch today:

Finally, summer apparently arrives in full force tomorrow. We're looking forward to temperatures 5-10°C above normal through mid-June, which will continue northern Illinois' drought for at least a few more weeks.

Can't find app with name "<function-name-here>"

I hope this helps someone else having this problem deploying a .NET function to Azure App Services.

At my day job, we created a new Azure directory and subscription for my group's product. As the product has gotten closer to release, we realized we needed a more complete separation from the company's Azure assets and our group's. So far, so good. I had some annoyances updating our deployment pipelines, but nothing I hadn't expected.

Then I tried to deploy our one function app. I followed the basic script in PowerShell:

Import-Module Az
Connect-AzAccount
CD c:\source\solution\project\bin\Debug\net5.0\
func azure functionapp publish function-name-dev

The script failed with: Can't find app with name "function-name-dev"

Undeterred, I modified the script:

Import-Module Az
Connect-AzAccount -Tenant 'guid' -SubscriptionId 'guid'
az account set --subscription 'guid'
CD c:\source\solution\project\bin\Debug\net5.0\
func azure functionapp publish function-name-dev

Same result. Googling and searching through Stack Overflow didn't help either. After a lot of experimentation, I finally got an error message that pointed me down the correct path, but only when I tried to create a new function app in the same subscription:

The following tenants require Multi-Factor Authentication (MFA). Use 'az login --tenant TENANT_ID' to explicitly login to a tenant.

And that was the solution. My new script, which worked fine, now looks like this:

Import-Module Az
Connect-AzAccount -Tenant 'guid' -SubscriptionId 'guid'
az login --tenant 'guid'
az account set --subscription 'guid'
CD c:\source\solution\project\bin\Debug\net5.0\
func azure functionapp publish function-name-dev

I may refine it further as I may have some redundancies in there. But I have now deployed the function app and tested it, much to my satisfaction.

What a difference a small change can make

I've just made a change to the side project I'm working on that will reduce my database costs about 94%. Maybe 96%. This is only in the dev/test environment, so it may make less of a difference in production, but still... Sometimes taking something out of your code can make an enormous difference.

I promise I'll write a lot about what I've been working on once it launches.

Sunday not-so-funday

Bit of a frustrating day, today. I spent 2½ hours trying to deploy an Azure function using the Az package in PowerShell, before giving up and going back to the AzureCLI. All of this to confirm a massive performance issue that I suspected but needed to see in a setting that eliminated network throughput as a possible factor. Yep: running everything completely within Azure sped it up by 11%, meaning an architecture choice I made a long time ago is definitely the problem. I factored the code well enough that I can replace the offending structure with a faster one in a couple of hours, but it's a springtime Sunday, so I don't really feel totally motivated right now to do so.

Lest you worry I have neglected other responsibilities, Cassie already got over an hour of walks and dog park time today, bringing her up to 10½ hours for the week. I plan to take her on another 45-minute walk in an hour or so. Last week she got almost 14 hours of walks, however. I blame the mid-week rain we got.

I also have a 30-minute task that will involve 15 minutes of setup, 10 minutes of tear-down, and 5 minutes of video recording. I will be so relieved next fall when all of our chorus work happens in person again.

Before I do that, however, I'm going to go hug my dog.

What I'm reading today

A few articles caught my attention this week:

Also, I'm just making a note to myself of Yuriy Ivon's rundown on Microsoft Azure Cosmos DB, because I'm using it a lot more than I have in the past.

Microsoft suffers DDOS attack on its DNS servers

Microsoft Azure and Office 365 suffered an outage yesterday that affected just about everything in their cloud:

Microsoft Corp. was hit by a massive cloud outage today that took most of its internet services offline.

Microsoft’s Azure cloud services, as well as Teams, Office 365, OneDrive, Skype, Xbox Live and Bing were all inaccessible due to the outage. Even the Azure Status page was reportedly taken offline.

The first reports of the outage emerged from users on Twitter, and were confirmed by the website DownDetector which showed that reports began flooding in at around 5 p.m. ET. It says it received thousands of notices from Xbox Live, Teams and Office users.

Microsoft 365’s Twitter status account posted another update at 6.35 p.m. ET saying that traffic was being rerouted to resilient DNS capabilities and that it was already “seeing an improvement in service availability.”

Today, Microsoft reported as a preliminary root cause "We are continuing to investigate the underlying cause for the DNS outage but we have observed that Microsoft DNS servers saw a spike in DNS traffic." In other words, it looks like they suffered a distributed denial-of-service (DDOS) attack on their internal name servers. The final analysis will come out next Thursday.

This outage was like the familiar "collective amnesia" trope in sci-fi where suddenly none of the characters recognizes any of the others, though they retain their normal personalities and abilities. (See, e.g.Dollhouse and Buffy. Joss Whedon lurves this trope.) For example, The Daily Parker was still running, but no one could get to it because the mapping from www.thedailparker.com to the Microsoft App Service hosting it has to go through Microsoft's internal name servers.

I wonder if this was a DDOS attack from inside the house?

The world keeps turning

Even though my life for the past week has revolved around a happy, energetic ball of fur, the rest of the world has continued as if Cassie doesn't matter:

And if you still haven't seen our spring concert, you still can. Don't miss it!

Azure DevOps gotcha upgrading to .NET 5

Also known as: read all error messages carefully.

I've just spent about 90 minutes debugging an Azure DevOps pipeline after upgrading from .NET Core 3.1 to .NET 5 RC2. Everything compiled OK, all tests ran locally, but the Test step of my pipeline failed with this error message:

##[error]Unable to find D:\a\1\s\ProjectName.Tests\bin\Debug\net5.0\ref\ProjectName.Tests.deps.json.
Make sure test project has a nuget reference of package "Microsoft.NET.Test.Sdk".

The test step had this Test Files configuration:

**\bin\$(BuildConfiguration)\**\*Tests.dll
!**\*TestAdapter.dll
!**\obj\**

I'll save you all the steps I went through to determine that the .NET 5 build step only copied .dlls into the ref folder, without copying anything else (like the dependencies definition file). The solution turned out to be adding one line to the configuration:

**\bin\$(BuildConfiguration)\**\*Tests.dll
!**\ref\**
!**\*TestAdapter.dll
!**\obj\**

Excluding the ref folder fixed it. And I hope this post saves someone else 90 minutes of debugging.

Illinois electric utility adds power for the Cloud

The Cloud—known to us in the industry as "someone else's computers"—takes a lot of power to run. Which is why our local electric utility, ComEd, is beefing up their service to the O'Hare area:

Last month, it broke ground to expand its substation in northwest suburban Itasca to increase its output by about 180 megawatts by the end of 2019. Large data centers with multiple users often consume about 24 megawatts. For scale, 1 megawatt is enough to supply as many as 285 homes.

ComEd also has acquired land for a new substation to serve the proposed 1 million-square-foot Busse Farm technology park in Elk Grove Village that will include a data center component. The last time ComEd built a substation was in 2015 in Romeoville, to serve nearby warehouses. In the past year, Elk Grove Village issued permits for four data center projects totaling 600,000 square feet and $175 million in construction. If built, it's a 40 percent increase in total data center capacity in the village.

Insiders say Apple, Google, Microsoft and Oracle have taken on more capacity at data centers in metro Chicago in the past year or so.

One deal that got plenty of tongues wagging was from DuPont Fabros Technology, which started work earlier this year on a 305,000-square-foot data center in Elk Grove Village. DuPont, which recently was acquired by Digital Realty Trust, pre-leased half of it, or about 14 megawatts, to a single customer, believed to be Apple.

One of the oldest cloud data centers, Microsoft's North Central Azure DC, is about three kilometers south of the airport here. Notice the substation just across the tollway to the west.