Microsoft Azure Cloud Series – Azure Resource Manager – Part 3

Hello everybody, time to get in-depth with Azure Resource Manager.  But, before I dive into the Azure Resource Manager, I would like to quickly review some of the basics in Azure.  I will start with a rundown of the Azure Global Footprint.  Then, I will go into how Azure charges are incurred.  And finally, I will dive into the Azure Resource Manager V2 and comparing it to the older Azure Service Manager V1.  Sit tight and let’s go for an Azure Ride 😉

Azure Global Footprint
Azure Resource Manager

Microsoft Azure itself is deployed around the world and involves the concept of regions, which is where you select to place and run your code.  Each region has a Microsoft Azure data center.  These data centers are massive facilities that host tens of thousands or, in some cases, hundreds of thousands of servers.  Currently, Microsoft has:

  • Four regions in North America
  • Two regions in Europe
  • Two regions in Asia
  • One region in Japan

As shown above, Microsoft also has a number of Content Delivery Network (CDN) edge points.  They can be used to cache your content and deliver it even faster to end users.

Once you build an application, you can choose any location in the world where you want to run it and you can move your workloads from region to region.  You can also run your application in multiple regions simultaneously or just direct traffic and end users to whichever version of the app is closest to them

How are Azure Charges Incurred?

This may be different for many of you who are familiar with hosting providers and on-premises systems

Simply, with Microsoft Azure, you pay only for what you use:

  • There are no upfront costs
  • There is no need to buy any upfront server licenses; this is included in the price
  • VMs (IaaS and web/worker role) usage is by the minute
  • VMs (IaaS only) that are stopped in Microsoft Azure, only storage charges apply
  • Likewise, if you use a SQL database, through the SQL Database feature in Microsoft Azure, you do not have to buy a SQL Server license—this is also included in the price
  • For compute services, such as VMs and websites you only pay by the hour

This gives you the flexibility to run your applications very cost effectively
You can scale up and scale down your solutions or even turn them on and off as necessary. This also opens up a wide range of possibilities in terms of the new types of apps you can build.

Managing Azure Deployments

Microsoft Azure currently have two management models:

  • Azure Service Manager (ASM) has been around since 2009 and has been due for an upgrade..
  • Azure Resource Manager (ARM), released last summer, supports modern deployment practices. It is designed to be extensible to all current and future services.

Azure Service Manager V1

  • Traditional way to deploy and manage applications hosted in Azure
  • Azure Portal https://manage.windowsazure.com
  • PowerShell / CLI (default mode)
  • REST API

Azure Resource Manager V2

  • Modern way to deploy and manage applications hosted in Azure
  • Azure Portal https://portal.azure.com
  • PowerShell / CLI (ARM mode)
  • REST API
  • Azure Resource Management Library for .NET

Why and what is Azure Resource Manager?

Today’s challenge with Azure Service Manager V1– it’s difficult to…

  • Set and manage permissions – only co-admin and service admin
  • Monitor and have alerting rules – limited to Management Services and basic KPI in portal
  • Billing – through the billing portal
  • Deployment – complex PowerShell to gather all components for an application
  • Visualize a group of resources in a logical view, including monitoring/billing

ASM V1 Portal – Resource Centric Views

Azure Resource Manager

After working with the current ASM V1 for a number of years now, here’s the breakdown:

  • Resources are provisioned in isolation
  • Finding resources is not so easy
  • Deployment is more complex than on-premise
  • Management of app is challenging
  • Proper use of resources becomes more abstract
  • Isolation makes communications a challenge

Ok, Rob, then why does Microsoft still keep ASM V1 in production?  

Answer:  As of the writing of this blog post, not all features have been ported over to Azure Resource Manager V2.  Once all features and services have been ported over, I expect Microsoft to end of life Azure Service Manager V1.

Azure Resource Manager Overview

Azure Resource Manager

Azure Resource Manager enables you to work with the resources in your solution as a group.  You can deploy, update or delete all of the resources for your solution in a single, coordinated operation.  You use a template for deployment and that template can work for different environments such as testing, staging and production.  Resource Manager provides security, auditing, and tagging features to help you manage your resources after deployment.

Benefits of ARM

  • Desired-state deployment
    • ARM does desired-state deployment of resources. It does not do desired-state configuration inside these resources (e.g., VMs), although it can initiate the process of desired-state configuration.
  • Faster deployments
    • ARM can deploy in true parallel as compared to semi-sequential in ASM
  • Role-based access control (RBAC)
    • RBAC is fully integrated with Azure Active Directory
  • Resource-provider model
    • Resource-provider model is intended to be fully extensible.
  • Common interface for Azure and Azure Stack
    • When Azure Stack is released, same API model for on-premises and Cloud

ARM Definitions and what they mean?

  • Resource – Atomic unit of deployment
  • Resource group – Collection of resources
  • Resource provider – Manages specific kinds of resources
  • Resource type – Specifies the type of resource

Ok, let’s dive into the details of each now.

Resource Group (RG)
Azure Resource Manager

A Resource Group is a Unit of Management providing:

  • Application Lifecycle Containment – Deployment, update, delete and status
    • You can deploy everything included in a resource group together, thereby maintaining versions of an application along with it’s resources
  • Declarative solution for Deployment – “Config as Code”
    • Resource Group’s are .json, declarative/configuration code
  • Grouping – Metering, billing, quote: applied and rolled up to the group
    • Resource groups provide a logical grouping of resources
  • Consistent Management Layer
    • In the V2 portal, everything is controlled in a RG. RGs can be accessed via REST APIs and resource providers
  • Access Control – Scope for RBAC permissions
    • You can only use RBAC in the new portal and the highest level generally used for RBAC is the resource group level.

But, Rob, that sounds great, but should these resources (VM’s, DB’s, Storage, etc) be in the same Resource Group or in a different one?

Hint:  Do they have common life cycle and management?
Azure Resource ManagerAnswer: It’s up to you

Resource Groups Best Practices

  • Tightly coupled containers of multiple resources of similar or different types
    • When resources are in the container, they have a common life cycle. You can deploy these things together, put RBAC on them together with one request and they can know about each other
  • Every resource *must* exist in one and only one resource group
    • Every resource must be in ONE resource group, important for RBAC
  • Resource groups can span regions
    • Don’t have to live in same location, can deploy to multiple regions

A few final thoughts on Resource Groups and their deployment scenarios before we move on.

  • Most significant question is of lifecycle and what to place in a resource group
  • Can apply RBAC, but is this right for a particular resource group?
  • Sometimes resources are shared across multiple applications, in other words a VM could be stored in a storage account in a different resource group
  • Lifecycle is distinct and managed by different people
  • There is no hard and fast rule

Resource Providers

A Resource Provider is used by the Azure Resource Manager to manage distinct types of resources – in your JSON template, you will have code that shows what the resource provider expects to see in order for the resource provider (sitting out in Azure) to build the resource that you want…for example a SQL Server or SQL DB or VM.

Resource providers are an extensibility point allowing new resource providers to be added in a consistent manner as new services are added to Azure – anyone can write their own provider

Resource Provider Types Examples
Azure Resource Manager

Ok, Rob, how do I know what resources providers are available?

Using PowerShell, log in to your Azure account and then run
Get-AzureRmResourceProvider
Azure Resource Manager

Tools typically used with ARM

  • PowerShellBlog Post coming soon
    • PowerShell is used to deploy the ARM templates and can be used to download log files from the Resource Group to analyze issues
  • Troubleshooting in the portal – Blog Post coming soon
  • Visual Studio
    • Although not required, will more than likely be the tool of choice for creating the ARM templates – Blog Post coming soon

Well, that wraps up my blog post on Azure Resource Manager.  We covered a lot and have much more to go.  Stay tuned…..Until next time, Rob.

Microsoft Azure Cloud Series – Understanding the Stack, Who Manages What? – Part 2

In today’s IT, there are lot of discussions in the about different terms like PaaS, IaaS, and SaaS.  So what do all of these cloud acronyms mean?

I’m going to give you the simplest explanation I can, to help you understand the difference between SaaS, IaaS, and PaaS. First, let’s expand those acronyms! Software as a Service, Infrastructure as a Service, and Platform as a Service are all just different types of clouds.

Understanding the Stack

New Choices for Delivering IT

The cloud provides options for approach, sourcing, and control.  It delivers a well-defined set of services, which are perceived by the customers to have infinite capacity, continuous availability, increased agility, and improved cost efficiency. To achieve these attributes in their customers’ minds, IT must shift its traditional server-centric approach to a service-centric approach.  This implies that IT must go from deploying applications in silos with minimal leverage across environments to delivering applications on pre-determined standardized platforms with mutually agreed upon service levels.  A hybrid strategy that uses several cloud options at the same time will become the norm as organizations choose a mix of various cloud models to meet their specific needs.

Typical Service Models

Software as a Service

Software as a Service (SaaS) delivers business processes and applications, such as CRM, collaboration, and email, as standardized capabilities for a usage-based cost at an agreed, business-relevant service level. SaaS provides significant efficiencies in cost and delivery in exchange for minimal customization and represents a shift of operational risks from the consumer to the provider. All infrastructure and IT operational functions are abstracted away from the consumer.

Platform as a Service

Platform as a Service (PaaS) delivers application execution services, such as application runtime, storage, and integration for applications written for a pre-specified development framework. PaaS provides an efficient and agile approach to operate scale-out applications in a predictable and cost-effective manner. Service levels and operational risks are shared because the consumer must take responsibility for the stability, architectural compliance, and overall operations of the application while the provider delivers the platform capability (including the infrastructure and operational functions) at a predictable service level and cost.

Infrastructure as a Service

Infrastructure as a Service (IaaS) abstracts hardware (server, storage, and network infrastructure) into a pool of computing, storage, and connectivity capabilities that are delivered as services for a usage-based (metered) cost. Its goal is to provide a flexible, standard, and virtualized operating environment that can become a foundation for PaaS and SaaS.

IaaS is usually seen to provide a standardized virtual server. The consumer takes responsibility for configuration and operations of the guest Operating System (OS), software, and Database (DB). Compute capabilities (such as performance, bandwidth, and storage access) are also standardized.
Service levels cover the performance and availability of the virtualized infrastructure. The consumer takes on the operational risk that exists above the infrastructure.

Understanding the Stack

Infrastructure as a Service with Azure Virtual Machines

In short, IaaS gives you a server in the cloud (virtual machine) that you have complete control over. With an Azure VM, you are responsible for managing everything from the Operating System on up to the application you are running.

On-demand data centers, also known as IaaS, provide compute power, memory, and storage, typically priced per hour, based on resource consumption. You pay only for what you use, and the service provides all the capacity you need, but you are responsible for monitoring, managing, and patching your on-demand infrastructure.

The biggest advantage of IaaS is that it offers a cloud-based data center without requiring you to install new equipment or to wait for the hardware procurement process. This means you can get IT resources that otherwise might not be available.

This mode of operation will feel most like a typical on premises virtual machine where you remote desktop into the server to manage it instead of sitting down in front of a physical keyboard and mouse.

Platform as a Service – Azure Cloud Services

An Azure Cloud Service consists of two components: your application files (source code, DLLs, etc.) and a configuration file. Together, these two elements will spin up a combination of Web Roles and Worker Roles to execute your application. With Cloud Services, Azure handles all of the tedious Operating System details for you, so you can focus on what matters – building a quality application for your users.

A Web Role is an Azure VM that is pre-configured as a web server (running IIS) and will automatically have your application loaded on it by the time the server fully spins up. This will create the public endpoint for your application – usually a website, but it could also be an API or something similar.

Worker Roles run alongside your Web Roles and are responsible for performing computing functions to support your application. Typically, the Web Role will accept some sort of user input and queue up an action for the Worker Role to process at a later time. This allows the Web Roles to be more responsive and to fire-and-forget tasks to be processed later.

Understanding the Stack

Software as a Service – Basecamp, Salesforce, Office 365, Azure Websites

Finally, Software as a Service applications are built and hosted through 3rd party vendors who typically charge for a certain level of service – $30/month for X projects and Y users.

Azure Websites can serve as a SaaS offering as well. You can configure a WordPress, Drupal, OpenX, or even phpBB site with a single click. No code, no deployment hassles, and minimal configuration. Azure Websites lets you stand up the service you need in minutes, not hours or days.

Most SaaS applications today are built on a cloud platform due to the low cost of entry – with prices continually falling – and the ability to scale up as your customer base grows. If Dropcam, SmugMug, or Netflix got one million new customers tomorrow, their infrastructure (Amazon Web Services) would be able to accommodate them.

Conclusion

  • Software-as-a-Service (SaaS) means you’re renting the app or software
  • Platform-as-a-Service (PaaS) means that you’re renting everything but the app or software
  • Infrastructure-as-a-Service (IaaS) means you’re renting only the hardware as well as the tools used to manage the hardware

While each Azure Compute (IaaS) offering has their pros and cons, I personally prefer to build my projects around PaaS. With PaaS, you get the maximum possible amount of flexibility before you have to start worrying about the tedious world of OS maintenance, versions, security, patches, etc. Until next time, Rob.