Windows Azure Development

Azure Cosmos DB–Setting Up New Database using Azure CLI–Sample

October 1, 2018 Azure, Azure Cosmos DB, Codes, CosmosDB, KnowledgeBase, Microsoft, PowerShell, Windows Azure Development No comments

Purpose of this article is to help you with few steps of commands to provision a new Azure Cosmos DB database instance through Azure CLI or Azure Cloud Shell.

Here is the snippet:

 <# 
   This Bash script should help you create a Azure Cosmos DB instance using Azure CLI with bare minimal configuration 
#>

export ACCOUNT_NAME="thingx-retail-store-db"
export DB_RESOURCE_GROUP="thingx-dev"
export DB_LOCATION="southcentralus"
export DB_NAME="Products" 
export DB_THROUGHPUT=1000  ## bare minimal for 500 read and 100 write configuration for a 1KB document.
export DB_COLLECTION_NAME="Groceries"

##Optional: If resource group does not exist create a new one 
az group create --name $DB_RESOURCE_GROUP --location $DB_LOCATION

##1.0 Create the Azure Cosmos DB Account 
az cosmosdb create --name $ACCOUNT_NAME --kind GlobalDocumentDB --resource-group $DB_RESOURCE_GROUP

##2.0 Create Products database in the account  
az cosmosdb database create --name $ACCOUNT_NAME --db-name $DB_NAME --resource-group $DB_RESOURCE_GROUP

##3.0 Create Groceries collection in Products database
az cosmosdb collection create --collection-name $DB_COLLECTION_NAME --partition-key-path "/productId" --throughput $DB_THROUGHPUT --name $ACCOUNT_NAME --db-name $DB_NAME --resource-group $DB_RESOURCE_GROUP

For the ease of this article I used Azure Cloud Shell, that you can launch from your azure portal by clicking on the Shell icon on the top portal menu.

Now you are ready to execute all the commands listed above in the sample bash script

Create New Azure Cosmos DB Account

 <span data-mce-type="bookmark" style="display: inline-block; width: 0px; overflow: hidden; line-height: 0;" class="mce_SELRES_start"></span>
az cosmosdb create --name $ACCOUNT_NAME --kind GlobalDocumentDB --resource-group $DB_RESOURCE_GROUP

Create Products Database in the account

az cosmosdb database create --name $ACCOUNT_NAME --db-name $DB_NAME --resource-group $DB_RESOURCE_GROUP

Create Groceries collection in Products database

az cosmosdb collection create --collection-name $DB_COLLECTION_NAME --partition-key-path "/productId" --throughput $DB_THROUGHPUT --name $ACCOUNT_NAME --db-name $DB_NAME --resource-group $DB_RESOURCE_GROUP

Now if you browse Azure Portal you can see resources created in “thingx-dev” resource group.

Upon browsing with Data Explorer you can see the Groceries collection inside Products DB.

So that’s the few silly easy steps to create Cosmos DB database from Azure CLI or Azure Cloud Shell. Hope that makes it easy for you.

New Microsoft Azure Certifications

September 16, 2018 Azure, Azure SDK, Azure Tools, Certification, Emerging Technologies, MCP, Microsoft, Microsoft Learning, Windows Azure Development No comments

Microsoft has recently announced new certification exam tracks for Azure Administrators, Developers and Architects. Here are the line ups that should help you move your career with right certifications.

The three new Microsoft Azure Certifications are:

Microsoft Certified Azure Developer
Microsoft Certified Azure Administrator
Microsoft Certified Azure Architect

These certifications would essentially split the previous MCSA/MCSE: Cloud Platform and Infrastructure track and introduce new exams for individual certification track.

So far I only have limited information available about all the exam numbers for each individual track, as recently Microsoft has made BETA exams available for Microsoft Certified Azure Administrator track.

If you don’t have 070-533 exam certification from previous tracks then doing the following exams would would provide you Administrator track certification.
- AZ-100: Microsoft Azure Infrastructure and Deployment
- AZ-101: Microsoft Azure Integration and Security
If you previously passed 070-533 exam, you can do the following Recertification/Transition exam to earn the Microsoft Certified Azure Administrator credential.
- AZ-102: Microsoft Azure Administrator Certification Transition

These exams are still in BETA, would commence general availability in coming months. Will keep you posted about newer exams for other tracks as we get to know more.

References: https://www.microsoft.com/en-us/learning/exam-list.aspx

Azure Cosmos DB – Programatically Connect to a preferred location using the SQL API

May 29, 2018 .NET, Azure, CosmosDB, Microsoft, VisualStudio, Windows, Windows Azure Development No comments Cosmos Db SDK, SQL API

Cosmos Db is a multi-region scallable, globally-distributed database solution as part of Microsoft Azure Platform. With a button click, Azure Cosmos DB enables you to elastically and independently scale throughput and storage across any number of Azure’s geographic regions. It offers throughput, latency, availability, and consistency guarantees with comprehensive service level agreements (SLAs), that no other database service can offer. [REF]

What is multi-region scalability or global distribution ?

What it means is that once you select this option, and underlying platform will ensure that your main database is replicated across other global regions you have defined.

So when a customer/application requests the data from a certain geo location:

Cosmos Db will serve the data from nearest available regional copy to provide low latency in accessing the database. Inorder to achieve it is recommended to deploy both the application and Azure Cosmos DB in the regions that correspond.
Incase that nearest available region is not defined, it would serve from nearest available or main copy. This could be East US or West US depending on your deployment decisions.
As BCDR(Business Continuity and Disaster Recovery) plan, Incase main copy is not available, it would faillover to serve the requests from any backup region.

Benefits?

Ensured AVAILABILITY @ 99.99% – Azure Cosmos DB offers low latency reads and writes at the 99th percentile worldwide.
Faster READS: It ensures that all reads are served from the closest (local) region. To serve a read request, the quorum local to the region in which the read is issued is used.
Reliable WRITES: The same applies to writes. A write is acknowledged only after a majority of replicas have durably committed the write locally but without being gated on remote replicas to acknowledge the writes.

PS: The replication protocol of Azure Cosmos DB operates under the assumption that the read and write quorums are always local to the region where the request has been issued.

How to turn on – Cosmos Db and multi-region replication?

In CosmosDb instance settings select Replicate data globally page, then select the regions to add or remove by clicking regions in the map.

Azure Cosmos DB enables you to configure the regions (associated with the database) for “read”, “write” or “read/write” regions.

Then configure Manual/Automatic failover options as well. I would cover this in later articles.

All that said, you are in good hands of Azure Platform as a Cosmos Db customer or user.

NB: For the purpose of this article, I have configured my instance to run different regions with write region as East US and read region as West Europe,North Europe and West US.

Programatically Connect to a preferred location using the SQL API:

Now coming to the context of this blog, as a application developer some times you would like to programatically control the access to these regions while using Cosmos Db .NET SQL API.

In CosmosDb.NET SDK version 1.8 and later, there is the ConnectionPolicy parameter for the DocumentClient constructor has a property called Microsoft.Azure.Documents.ConnectionPolicy.PreferredLocations.

All reads will be sent to the first available region in the PreferredLocations list. If the request fails, the client will fail down the list to the next region, and so on.
SDK will automatically send all writes to the current write region.
SDK will only attempt to read from the regions specified in PreferredLocations.
For example: If you have 4 read regions defined in your cosmos Db instance and you only have 2 regions defined in PreferredLocations in connectionPolicy, requests from other two regions would never be served from SDK.

NB: The client application can verify the current write endpoint and read endpoint chosen by the SDK by checking two properties, WriteEndpoint and ReadEndpoint. **SDK version 1.8+.

Following code snippet would make it easiter to implement:

 
   //Setting read region selection preference. 
   connectionPolicy.PreferredLocations.Add(LocationNames.EastUS); // applications first preference
   connectionPolicy.PreferredLocations.Add(LocationNames.WestEurope); // applications second preference

Full Source Code: https://github.com/AzureContrib/CosmosDB-DotNet-Quickstart-Preferred-Location

References:

Azure Cosmos DB – Connection Policy – Setting Connection Mode and Connection Protocol

May 13, 2018 .NET, Azure, CosmosDB, Microsoft, PaaS, VisualStudio, Windows, Windows Azure Development No comments Azure Cosmos DB, Cosmos Db SDK, Cosmos DB SQL API, SQL API

Recently I have been trying multiple ways to optimize CosmosDb SQL.NET SDK integration calls from my web application that sits within a VNET.

After carefully analyzing different options available within Cosmos Db SQL API’s have realized there are different aspects we could optimize in achieving minimal turn around time. In this article I am going to discuss about one such useful find, that is to use Cosmos Db SQL SDK connection policy to use diferent networking options to improve the latency between web application and cosmos db API calls.

Connection Policy:

Performance of an client application has important implication based on – how SQL .NET SDK connects to Azure Cosmos DB , because of expected client-side latency due to networking conditions. There are two key configuration settings available for configuring client Connection Policy – the connection mode and the connection protocol.

There are two connection mode options provides by Cosmos Db SQL.NET SDK:

Gateway Mode(which is default): This mode is the default option being used and works with all Cosmos DB SDK versions. Since it is only accessible over HTTPS/TCP, it is more secure and best choice for applications that run on a constrained secure corporate network. If you are using the .NET Framework version of the CosmosDb SQL.NET SDK, then proably this is the only connection mode that would work for you.

Connection Protocol – TCP: 443 is the CosmosDb port, 10255 is the MongoDB API port.
Connection Protocol – HTTPS: Default 443

Direct Mode: This is a new mode which will work only on .NET Standard 2.0 onwards. It provides you an ability to choose between TCP or HTTPS more efficiently. Only caveat is that you would need .NET Standard 2.0 as target framework for your client application.

Connection Protocol – TCP: TCP would be more faster when client and db are in same VNET. Since TCP within the same network would be more faster, you would be amazed by the latency improvements by your client application. It would respond faster to you cosmos Db requests. NB In TCP mode apart from 443 and 10255 mentioned in Gateway more, we also need to ensure port range between 10000 and 20000 is open in your firewall configuration, because Azure Cosmos DB uses dynamic TCP ports.
Connection Protocol – HTTPS: Since client application and cosmosDb are in same network limits, you could see that HTTPS option is also a reliable, secure and faster access channel for you, but not highly performing as TCP.

A simplified diagram below :

Sample Code:

 string cosmosDbEndpoint = new Uri("https://mycosmosDbinstance.documents.net");
 string authKey ="cosmosDb-apiKey";
 DocumentClient client = new DocumentClient(cosmosDbEndpoint, authKey,
 new ConnectionPolicy
 {
    ConnectionMode = ConnectionMode.Direct,
    ConnectionProtocol = Protocol.Tcp
 });

Refer more :

You can find the completed sample here: AzureContrib/CosmosDB-DotNet-Quickstart-With-ConnectionPolicy

Azure Cosmos DB name changes

April 17, 2018 Azure, CosmosDB, Document DB, Emerging Technologies, Microsoft, Windows Azure Development No comments

An update from Microsoft Azure says that – As part of the transition from Azure DocumentDB to Azure Cosmos DB, the service and resource names are changing from “Azure DocumentDB” to “Azure Cosmos DB” on June 1, 2018.

How does that Impact?

When Microsoft introduced Cosmos DB, then have ensured that there was a smooth transition or migration of existing Document DB customers /tenants to Cosmos DB. This was achieved by without changing underlying service and resource names from “Document DB” to “Cosmos DB”.

So, if you were an existing customer of Document DB, you have noticed the only disappearance of Document DB name and old service showing simply Cosmos DB. You did not feel much difference apart from some additional configuration options as part of multi-modal data source configuration.

Your ARM deployment templates might need some changes in resource sizing, resource location, and some other configuration aspects.

There is no a pricing impact because of this change, but you will have to modify billing parameters that rely on the new names. Now with this deadline what Microsoft intends to have is to deprecate the use of Old DocumentDB naming and start migrating all customers/tenants to follow the new naming for the resource billing/sizing purposes.

To read more about the naming changes: https://azure.microsoft.com/en-us/updates/name-changes-cosmos-db/

What’s Azure Container Service (ACS/AKS)

April 12, 2018 Application Virtualization, Azure, Azure Container Service, Cloud Computing, Cloud Services, Computing, Containers, Docker, Emerging Technologies, IaaS, Kubernates, Microsoft, OpenSource, Orchestrator, OS Virtualization, PaaS, Virtual Machines, Virtualization, Windows Azure Development No comments

I will start with history: Sometime around 2016, Microsoft launched an IaaS service called Azure Container Service a.k.an ACS serves as a bridge between Azure Ecosystem and existing container ecosystem being used widely by the developer community around the world.

It helps as a gateway for infrastructure engineers and developers to manage underlying infrastructure such as Virtual Machines, Storage, Network Load Balancing services individually than the application itself. The application developer doesn’t have to worry about planet-scale of the application, instead, a container orchestrator can manage the scale up and scale down of your application environment based on peaks and downs of your application usage.

It offers an option to select from 3 major container orchestrators available today such as DC/OS, Swarm, Docker, and Kubernates. ACS along with your choice of container orchestrators works efficiently with different container ecosystems to enable the promise of application virtualization.

To make it simpler, ACS is your Super Glue to gel your Azure infrastructure and your container orchestrator together. Means you will be able to make your fully managed container cluster in a matter of minutes with Azure.

ACS is for making your microservices dream come true, by providing individual services scale according to the demand and automatically reduce the scale, if usage is low. You don’t have to worry, ACS and your container orchestrator will take care of you.

If you are a beginner to container-based infrastructure for your applications, you don’t have to take the pain at all of setting up Kubernates on your own, instead, ACS will simplify your implementation with a couple of easier click thru’s and your container infrastructure is ready to be fully managed by you. As simple as that.

What is Azure Container Kubernates Service (AKS) then?

As I am writing today, Microsoft has a new fully managed PaaS service called as Azure Container Service (AKS) or Managed Kubernates, meaning that Kubernates would be your default fully managed container orchestrator, if you choose Azure Container Service. But you would be able to deploy other open-source container orchestrators if you prefer to choose to have your own unmanaged Kubernates, Docker or DC/OS and then add your specific management and monitoring tools.

This service is currently available in PUBLIC PREVIEW, you can get started from here

Means though it is a fully managed service, you still have the option to manage it your own using your preferred set of tools and orchestrators.

Charging Model

Whether you manage your AKS service with your own set of tools and orchestrator or you use Fully Managed Kubernates, you only need to pay for resources you consume. No need to worry about per-cluster charges like other providers.

Useful References: