Cloud Computing

Microsoft Certified: Azure Administrator Associate–Exam Changes

March 26, 2019 Azure, Azure, Azure Administrator, Azure CLI, Certification, Cloud Computing, Infrastructure, Microsoft, Platforms No comments

Earlier during Microsoft Ignite 2019 conference, Microsoft Learning team has rolled out exams various role based certification exams for Administrators, Developers, Architects and DevOps engineers.

Initially there was a requirement for passing two exams: AZ-100 and AZ-101

  • AZ-100 – Microsoft Azure Infrastructure and Deployment
  • AZ-101 – Microsoft Azure Integration and Security
  • AZ-102 – (Upgrade Exam) – Microsoft Azure Administrator Certification Transition

As on 20th March, Microsoft has made announcement to simiplify these requirements by introducing a single exam, instead of taking two exams. Here is how it would look like. 

image

What’s included in AZ-103 ?

You can find them detailed out in  official exams page here, but I will give a quick list taken from the official page

Manage Azure subscriptions and resources (15-20%)

  • Manage Azure subscriptions
    • May include but not limited to: Assign administrator permissions; configure cost center quotas and tagging; configure Azure subscription policies at Azure subscription level
  • Analyze resource utilization and consumption
    • May include but not limited to: Configure diagnostic settings on resources; create baseline for resources; create and rest alerts; analyze alerts across subscription; analyze metrics across subscription; create action groups; monitor for unused resources; monitor spend; report on spend; utilize Log Search query functions; view alerts in Log Analytics
  • Manage resource groups
    • May include but not limited to: Use Azure policies for resource groups; configure resource locks; configure resource policies; implement and set tagging on resource groups; move resources across resource groups; remove resource groups
  • Managed role based access control (RBAC)
    • May include but not limited to: Create a custom role, configure access to Azure resources by assigning roles, configure management access to Azure, troubleshoot RBAC, implement RBAC policies, assign RBAC Roles
Implement and manage storage (5-10%)
  • Create and configure storage accounts
    • May include but not limited to: Configure network access to the storage account; create and configure storage account; generate shared access signature; install and use Azure Storage Explorer; manage access keys; monitor activity log by using Log Analytics; implement Azure storage replication
  • Import and export data to Azure
    • May include but not limited to: Create export from Azure job; create import into Azure job; Use Azure Data Box; configure and use Azure blob storage; configure Azure content delivery network (CDN) endpoints
  • Configure Azure files
    • May include but not limited to: Create Azure file share; create Azure File Sync service; create Azure sync group; troubleshoot Azure File Sync
  • Implement Azure backup
    • May include but not limited to: Configure and review backup reports; perform backup operation; create Recovery Services Vault; create and configure backup policy; perform a restore operation.
Deploy and manage virtual machines (VMs) (20-25%)
  • Create and configure a VM for Windows and Linux
    • May include but not limited to: Configure high availability; configure monitoring, networking, storage, and virtual machine size; deploy and configure scale sets
  • Automate deployment of VMs
    • May include but not limited to: Modify Azure Resource Manager (ARM) template; configure location of new VMs; configure VHD template; deploy from template; save a deployment as an ARM template; deploy Windows and Linux VMs
  • Manage Azure VM
    • May include but not limited to: Add data discs; add network interfaces; automate configuration management by using PowerShell Desired State Configuration (DSC) and VM Agent by using custom script extensions; manage VM sizes; move VMs from one resource group to another; redeploy VMs
  • Manage VM backups
    • May include but not limited to: Configure VM backup; define backup policies; implement backup policies; perform VM restore; Azure Site Recovery
Configure and manage virtual networks (20-25%)
  • Create connectivity between virtual networks
    • May include but not limited to: Create and configure VNET peering; create and configure VNET to VNET; verify virtual network connectivity; create virtual network gateway
  • Implement and manage virtual networking
    • May include but not limited to: Configure private and public IP addresses, network routes, network interface, subnets, and virtual network
  • Configure name resolution
    • May include but not limited to: Configure Azure DNS; configure custom DNS settings; configure private and public DNS zones
  • Create and configure a Network Security Group (NSG)
    • May include but not limited to: Create security rules; associate NSG to a subnet or network interface; identify required ports; evaluate effective security rules
  • Implement Azure load balancer
    • May include but not limited to: Configure internal load balancer, configure load balancing rules, configure public load balancer, troubleshoot load balancing
  • Monitor and troubleshoot virtual networking
    • May include but not limited to: Monitor on-premises connectivity, use Network resource monitoring, use Network Watcher, troubleshoot external networking, troubleshoot virtual network connectivity
  • Integrate on premises network with Azure virtual network
    • May include but not limited to: Create and configure Azure VPN Gateway, create and configure site to site VPN, configure Express Route, verify on premises connectivity, troubleshoot on premises connectivity with Azure
Manage identities (15-20%)
  • Manage Azure Active Directory (AD)
    • May include but not limited to: Add custom domains; Azure AD Join; configure self-service password reset; manage multiple directories;
  • Manage Azure AD objects (users, groups, and devices)
    • May include but not limited to: Create users and groups; manage user and group properties; manage device settings; perform bulk user updates; manage guest accounts
  • Implement and manage hybrid identities
    • May include but not limited to: Install Azure AD Connect, including password hash and pass-through synchronization; use Azure AD Connect to configure federation with on-premises Active Directory Domain Services (AD DS); manage Azure AD Connect; manage password sync and password writeback
  • Implement multi-factor authentication (MFA)
    • May include but not limited to: Configure user accounts for MFA, enable MFA by using bulk update, configure fraud alerts, configure bypass options, configure Trusted IPs, configure verification methods

Now that said. Wishing all the best to all exam aspirants who would want to become an Microsoft Certified: Azure Administrator Associate.

Azure Cosmos DB – TTL (Time to Live) – Reference Usecase

October 9, 2018 .NET, .NET Core, .NET Framework, Analytics, Architecture, Azure, Azure, Azure Cosmos DB, Azure Functions, Azure IoT Suite, Cloud Computing, Cold Path Analytics, CosmosDB, Emerging Technologies, Hot Path Analytics, Intelligent Cloud, Intelligent Edge, IoT Edge, IoT Hub, Microsoft, Realtime Analytics, Visual Studio 2017, VisualStudio, VS2017, Windows No comments

TTL capability within Azure Cosmos DB is a live saver, as it would take necessary steps to purge redudent data based on the configurations you may. 

Let us think in terms of an Industrial IoT scenario, devices can produce vast amounts of telemetry information, logs and user session information that is only useful until we operate on them and take action on them, to be specific up to finate period of time. Once that data becomes surplus, we need an application logic that purges these old records.

With the “Time to Live” or TTL, Microsoft Cosmos DB provides an ability to have your documents automatically purged from database storage after a certian period if time(which you configured)

  • This TTL by default can be set on a document collection level and later can be overridden on a per document basis.
  • Once the TTL is set, Cosmos DB service will automatically remove the documents when its lifetime is over.
  • Inorder to track TTL, Cosmos DB uses an offset field to check when it was last modified.  This field is identifiable as “_ts”, which exists in every document you create.  Basically it is a UNIX epoch timestamp. This field is updated everytime when the document is modified. [Ref: Picture1]

image

[Picture1]

Enabling TTL on Cosmos DB Collection:

You can enable TTL on a Cosmos DB collection simply by using Azure Portal –> Cosmos DB collection setting for existing or during creation of  a new collection)

TTL value needs to be set in seconds – if you need 90 days => 60 sec * 60 min * 24 hour * 90 days = 7776000 seconds

image

[Picture2]

Below is a one of the reference architecture in which Cosmos DB – TTL would be essentially useful and viable to any Iot business case:

image

[Picture3]

Hope that was helpful to get some understanding. For more references visit:  Cosmos DB Documentation

Azure Database for MariaDB: Public Preview

October 4, 2018 Azure Database for MariaDB, Managed Services, MariaDB, OpenSource No comments

During Ignite 2018, Microsoft has announced the availability of Maria DB support in Azure Database services. Today it has been opened for Public Preview for all Azure customers.

mariadbhero

What is MariaDB?

MariaDB is a community-developed fork of the MySQL relational database management system intended to remain free under the GNU GPL.Development is led by some of the original developers of MySQL, who forked it due to concerns over its acquisition by Oracle Corporation.Wikipedia

Azure Database for MariaDB: Public Preview Availability

The Azure Database for MariaDB service is now available in preview. It offers an enterprise-ready, fully managed database service that based on the Community Edition of MariaDB.

The service features open-source compatibility, built-in high availability, dynamic scaling, and flexible pricing. Customers can lift and shift to the cloud and use languages and frameworks of their choice, leveraging the power of MariaDB running on Azure.

To learn more about the service, view the service page, pricing, and documentation.

You can create a MariaDB server by using the Azure portal or Azure CLI.

More 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 , , ,

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 :

    image

    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

    Introduction to Kubernetes

    April 22, 2018 Cloud Computing, Cloud Native Computing Foundation, Computing, Emerging Technologies, Google Cloud, IaaS, OpenSource, PaaS, Platforms No comments

    What is Kubernetes?

    Kubernetes (a.k.a K8s) is an open-source system for automating deployment, scaling and management of containerized applications that was originally designed by Google and now maintained by the Cloud Native Computing Foundation.

    What Kubernetes can do?
    Kubernetes has a number of features in cloud computing world, it can be thought as a :

    • A container platform
    • A microservices platform
    • A portable cloud platform and a lot more

    Kubernetes defines a set of building blocks (“primitives”) which collectively provide mechanisms for deploying, maintaining, and scaling applications. The components which make up Kubernetes are designed to be loosely coupled and extensible so that it can meet a wide variety of different workloads. The extensibility is provided in large part by the Kubernetes API, which is used by internal components as well as extensions and containers running on Kubernetes.

    If you are interested  to know more, learn more about Kubernates  through Official tutorials:

    Some useful online training is:

    Kubernetes vs Service Fabric

    April 13, 2018 Application Virtualization, Azure, Emerging Technologies, Kubernates, Orchestrator, OS Virtualization, PaaS, Service Fabric, Virtual Machines, Virtualization No comments

    What is the difference between Kubernates and Service Fabric?

    It is a common question today among most of the business stakeholders, infrastructure specialists, and information technology architects.

     

     

     

     

     

     

     

     

     

    To answer in simpler words, quoting from this Reddit log :

    • Kubernetes manage/orchestrate containers and applications within. 
    • ServiceFabric is a framework for microservices based on one of three models; stateful, stateless, actor. Service Fabric provides a framework for creating micro services, runtime for managing distributed instances, and also provides the ‘fabric’ that holds everything together.

    A detailed comparison quoting from an MSDN blog  from here:

    Azure Container Service: If you are looking to deploy your application in Linux environment and are comfortable with an orchestrator such as Swarm, Kubernetes or DC/OS, use ACS. A typical 3 tier application (such as a web front end, a caching layer, a API layer and a database layer) can be easily container-ized with 1 single dockerfile (or docker-compose file). It can be continuously decomposed into smaller services gradually. This approach provides an immediate benefit of portability of such an application. Containers is Open technology and there is great community support around containers.

    Azure Service Fabric: If an application must have its state saved locally, then use Service Fabric. It is also a good choice if you are looking to deploy the application in Windows server ecosystem(Linux support is in the works as well!). Refer to common workloads on Service Fabric for more discussion on applications that can benefit from Service Fabric. Biggest benefit is that Service Fabric applications can run on-premise, on Azure or even in other cloud platforms also.