Anthony Chu

Azure Cosmos DB can replicate a single account's data to as many of Azure's 30+ regions as we want to. Applications around the world can read from the closest location to minimize latency. Write operations, however, are still sent to a single designated write region.

Update: July 19, 2018 - Cosmos DB now has multi-master support to allow writing to the closest region!

Thankfully, the write region can be changed. A read region can be designated as the new write region in a matter of seconds, and this change can be initiated programmatically via a REST API. If our application's dominant workload changes regions based on time of day, we can respond by changing the write region to the one with the most activity. Sometimes this strategy is called "follow the sun" or "follow the clock".

Today, we'll look at how to use Azure Functions to automatically change a Cosmos DB account's write region on a schedule. We'll do this using Azure's newly announced Managed Service Identity feature.

Today, I begin a new chapter in my career as a Cloud Developer Advocate at Microsoft.

I'll be joining a new and rapidly growing group of advocates led by Jeff Sandquist (there has been a constant stream of announcements like this one recently). I'll be on Scott Cate's team; our focus is on helping .NET developers get the most out of Azure.

Photo of the sweet lights in Bryan Liston's office (used with permission)

Today is my last day at BuildDirect. It's time for my next adventure.

It's been an amazing two and a half year journey. We built a talented and cohesive team with a great culture. Together, we persevered though challenges and celebrated successes. We grew from an online retailer to a marketplace platform.

There are so many things I'm grateful for. I was encouraged to to pursue my passions and I got to work with awesome new technologies everyday. I had the opportunity to play a small leadership role and help shape the way we deliver software. I learned a lot from everyone in the company and had the privilege to mentor others. I made many friendships and memories that will last a lifetime.

It's been the best 2.5 years so far in my career. Thank you to everyone at BuildDirect!

Nested virtualization has finally arrived on Azure. It is available on Dv3 and Ev3 virtual machines. This enables a lot of scenarios. For instance, you can run a VM inside a VM, and Windows containers can now run with Hyper-V isolation.

The most exciting part about nested virtualization coming to Azure for me is I can finally run a fully functional dev machine in the cloud. This is particularly useful because I want to set up VMs with Windows, Visual Studio, Docker (Linux and Windows) for presentations and demos. Prior to this, I had to run a lot of my Docker presentations from my laptop.

I might even want to run a dev machine in the cloud instead of on Parallels on my Mac.

The default user accounts in Azure API Management don't store a lot of data about the user; they mostly just store a name and an email address. But what if we want to store more information about each user and pass it along to the backend API?

In this article, we'll store additional information about our API Management users in a Cosmos DB collection. When our API is called, we'll query Cosmos DB for the user data using an API Management policy and pass this information to the backend via an HTTP header.

In addition, we'll leverage the API Management value cache to prevent calling Cosmos DB on every request.