Featured Blog

Azure SQL Capacity Planning: Scenarios | Data Exposed

MarisaBrasile — Mon, 24 Aug 2020 16:55:52 PDT

Capacity planning plays a critical role in migrating an existing application or designing a new one. In the final part of this three-part series with Silvano Coriani, we'll review various Azure SQL capacity planning scenarios, as well as review best practices and recommendations on what to use when.

For an overview of Azure SQL Capacity planning, watch part one.

To learn about the differences between DTU and vCore, watch part two.

Watch on Data Exposed

Additional Resources:
Choose between the vCore and DTU purchasing models
vCore model overview
Service tiers in the DTU-based purchase model
Migrate Azure SQL Database from the DTU-based model to the vCore-based model
Query Performance Insight for Azure SQL Database
Troubleshoot with Intelligent Insights

View/share our latest episodes on Channel 9 and YouTube!

Known issue: Azure Sphere Memory Leak When Using TLS With libcurl

AzureSphereTeam — Mon, 24 Aug 2020 16:50:08 PDT

The 20.07 and 20.08 Update 1 versions of the Azure Sphere OS contain a bug that results in a memory leak for applications that use HTTPS connections via libcurl. This leak does not occur for HTTP (non-HTTPS) connections, Azure IoT C SDK connections, nor MQTT connections. Additionally, this leak does not occur when using the wolfSSL API directly to create a connection

The amount of data leaked is variable, depending on how the cURL handle is configured. We expect that it will be approximately tens of bytes leaked per HTTPS transaction.

The 20.09 OS release will include a fix for this bug. In the meantime, you can mitigate the problem by implementing a workaround.

Workaround

To work around this bug, disable the CURLOPT_SSL_SESSIONID_CACHE option when you create cURL handles. To do so, set the following option after cURL handle creation and once for each handle:

curl_easy_setopt(curlHandle, CURLOPT_SSL_SESSIONID_CACHE, 0);

For more details on how to do this, see CURLOPT_SSL_SESSIONID_CACHE explained in the cURL documentation.

This workaround will continue to work with the 20.09 release, but you may prefer to revert the workaround so that you can enable SSL session ID caching.

Solution

The fix for this will be part of the 20.09 release, and the fix will take effect whether the OS is delivered as an OTA update or via recovery. After the device has updated to 20.09, you can either revert applications that use the workaround to enable SSL session ID caching, or you can leave it disabled.

Developer Forum Moving from MSDN to Q&A

urban-eric — Mon, 24 Aug 2020 14:33:56 PDT

Bing Ads API Development forum on MSDN is now moving to Microsoft Q&A! We’ve listened to your feedback on how we can enhance the forum experience. Microsoft Q&A allows us to add new functionality and enables easier access to all the technical resources most useful to you, like Microsoft Docs and Microsoft Learn.

Now until September 8, 2020:

You can post any new questions on Microsoft Q&A or MSDN.

From September 8, 2020 until September 21, 2020:

New posts – Post any new questions in the Microsoft Advertising development forum’s new home on Microsoft Q&A. The MSDN forum will not allow any new questions.
Existing posts – Interact here with existing content, answer questions, provide comments, etc.

September 21, 2020 onwards:

The MSDN forum will be closed to all new and existing posts and all interactions will be in Microsoft Q&A.

Please start using Microsoft Q&A today! To make sure that we see your question, tag it with 'advertising-api'.

We are excited about moving to Microsoft Q&A and seeing you there. Learn More

Blue/Green Deployment with Azure Front Door

gamullen — Mon, 24 Aug 2020 14:15:25 PDT

Azure Front Door is a powerful global routing solution that provides high availability and performance acceleration, among other features, for HTTP/HTTPS applications. The end users of the application are automatically routed to the nearest Microsoft “Point of Presence” (POP), and from there across the Microsoft global networking fiber to either a backend in Azure, or to the best “exit” POP for external (“Custom Host”) backends.

Blue/Green

Blue/Green (or Canary) Deployment is a methodology to introduce application enhancements to a small subset of end users, and if all goes well, slowly increase the ratio until all users are on the new deployment. In case things do not go perfectly, it’s simple to just stop routing requests to the new buggy backend. This is a much safer way to introduce code changes than just suddenly pointing all users at the new enhancements.

Azure Front Door makes Blue/Green simple. This article will explain how.

Frontend

Azure Front Door provides a nice configuration tool called “Designer.” It allows you to easily connect your frontend(s), backend pool(s) and routing rule(s) together. You essentially go through the Designer when you create your Front Door, but then you can use it later for configuration changes. Here is what it might look like after completion:

The first step is to configure the frontend.

Azure Front Door Frontend Definition

The main item here as it relates to blue/green is “Session Affinity.” This determines whether the end user always gets routed to the same backend after first accessing the Front Door.

Whether or not you enable this depends on your application, and the type of enhancements being rolled out. If it’s a major revision you will likely want to enable Session Affinity, so that if the user is initially routed to the new codebase she will continue to use it. If the enhancement is relatively minor, for example involving a single page with no dependencies on other parts of the application, you could potentially leave this disabled. If in doubt, enable Session Affinity.

Backend Pools

This is where you configure the host(s) that will end up satisfying your users’ web requests.

In this example, I just chose two relatively-random public endpoints. You would configure your existing backend website and the new one under test. I divided requests between my two on a 75% to 25% split. You would likely send more traffic to the current website than the new one, and then likely direct more to the new one as it proves itself to be bug free.

Here is a screenshot of the definition of one of the two backends. Note the three parameters circled which, with one other, will be discussed in relation to how a configured backend gets chosen by Azure Front Door for a given request.

Azure Front Door Backend Definition

The following screenshot shows the two backends I configured as part of my backend pool. Note that the total of the “Weights” does not have to add up to 100 — I did that for clarity.

Azure Front Door Backend Pool Definition

Note that how much traffic gets routed to a given backend also depends on other parameters, which is discussed in excellent detail in this section.

For the purposes of a simple Blue/Green configuration, here is a summary on how you might configure these parameters.

Keep the backend under test disabled to start. Once you get all other parameters configured, you can enable it to start your Blue/Green testing.
The Priority of both backends should be the same. I recommend just leaving them at “1.”
As part of the Backend Pool configuration there is a section called “Load Balancing.” For the purposes of our discussion, the most important parameter here is “Latency sensitivity.” This value determines the highest number of milliseconds that a health probe can take for a given backend to be even considered for selection; setting it to zero disables the parameter entirely. I recommend you set it to a reasonably high value such as 500 (a half a second), meaning any backends responding in less than that time frame will be considered. The goal is to make sure both backends get used, as it’s possible they are in different data centers and present different latencies to the end user.

Backend Pool Latency Sensitivity

Any backends making it this far are finally selected based on weight.

Routing Rules

For the purposes of Blue/Green, the routing rules are relatively unimportant. What you select here depends more on how your web application works.

That said, consider enabling “Caching,” which in essence turns your Azure Front End into a Content Delivery Network (CDN). This will allow web content to be cached and delivered from the Front Door POP rather than the backend. The POP is closer, sometimes significantly closer, to the end user than the backend. This can dramatically improve application performance.

This documentation contains full details on Azure Front Door routing if your configuration starts to get more complex.

Conclusion

Configuring Blue/Green with Azure Front Door is relatively simple once you understand a few vital concepts. Give it a try!

Announcing release of Host Integration Server 2016 CU4

Chris Houser (HIS) — Mon, 24 Aug 2020 13:31:43 PDT

We are excited to announce the release of Host Integration Server 2016 CU4.

Cumulative Update 4 contains all functional and security fixes for customer-reported issues in HIS 2016, including those fixes previously released in CU1 through CU3. We recommend upgrading to CU4, to remain current on the latest fixes. Please test CU4 prior to deploying into production.

You can obtain the software from the Microsoft Download Center, at - https://www.microsoft.com/en-us/download/details.aspx?id=101737

For more information on HIS 2016 CU4, read the Microsoft Knowledgebase article posted to - https://support.microsoft.com/en-us/help/4576781