<?xml version="1.0" encoding="utf-8"?>
<rss xmlns:atom="https://www.w3.org/2005/Atom" xmlns:sy="https://purl.org/rss/1.0/modules/syndication/" xmlns:dc="https://purl.org/dc/elements/1.1/" xmlns:content="https://purl.org/rss/1.0/modules/content/" xmlns:wfw="https://wellformedweb.org/CommentAPI/" xmlns:slash="https://purl.org/rss/1.0/modules/slash/"
  version="2.0">
  <channel>
    <title>Cloud Solution Architect</title>
    <atom:link
      href="https://docs.microsoft.com/archive/blogs/cloud_solution_architect/feed.xml"
      rel="self"
      type="application/rss+xml" />
    <link>https://docs.microsoft.com/archive/blogs/cloud_solution_architect/feed.xml</link>
    <description />
    <lastBuildDate>Thu, 29 Nov 2018 15:03:15 GMT</lastBuildDate>
    <language>en-US</language>
    <sy:updatePeriod>hourly</sy:updatePeriod>
    <sy:updateFrequency>1</sy:updateFrequency>
    <item>
      <title>Azure 101: Networking Part 1</title>
      <link>https://docs.microsoft.com/archive/blogs/cloud_solution_architect/azure-101-networking-part-1</link>
      <pubDate>Fri, 05 Oct 2018 17:12:15 GMT</pubDate>
      <dc:creator><![CDATA[Brian Christopher Harrison]]></dc:creator>
      <guid
        isPermaLink="false">https://blogs.msdn.microsoft.com/cloud_solution_architect/?p=4615</guid>
      <description><![CDATA[Welcome back to the Azure 101 series. In the previous blog posts, I covered two of the most commonly...]]></description>
      <content:encoded><![CDATA[<div>Welcome back to the Azure 101 series. In the previous blog posts, I covered two of the most commonly asked for topics from customers: Governance and Monitoring. These topics cover a number of services within Azure and so I wanted to make sure that all of you at the very least understood what those services were and through a simple video demonstration how they worked. This blog series is not meant to go into much depth as there are many other training mechanisms available to go into depth about a specific service and for some of you, you may actually have access to a Cloud Solution Architect like myself that can help teach you everything that you need to know.</div>
<div>&nbsp;</div>
<div>In this blog post we are going to continue talking about some the these services that almost all customers should be aware of as they are either designing, architecting or potentially deploying applications and systems into Azure, by focusing on Networking. Some of you might be thinking that this particular topic is not going to be of any interest to you, but I assure you, I have run into very few customers who have not needed to use at least one of the many networking services that are available. In fact, if you are deploying Infrastructure as a Service (IaaS) based systems or deploying a system that requires any kind of Hybrid connectivity, then networking is going to be of extreme importance.</div>
<div>&nbsp;</div>
<div>This is a very hefty topic and there are a lot of available services within Azure to use, so like I have done with the Monitoring blog post, I will be breaking this one up into two parts. In this one we will focus on the basic networking infrastructure that you will be laying down to allow for devices to talk or not talk to one another. In the second one, we will talk about some of the networking devices that are available for use from Azure. Let’s get started with a list of these basic foundational networking services that I will be demonstrating in this particular blog post:</div>
<div>&nbsp;</div>
<ul>
 	<li>
<div>Virtual Networks &amp; Subnets</div></li>
 	<li>
<div>User Defined Routes &amp; Network Security Groups</div></li>
 	<li>
<div>VPN Gateways</div></li>
 	<li>
<div>Azure Firewall</div></li>
</ul>
<div>&nbsp;</div>
<div>All of these services can be used to make up what your network would look like within the Azure regions and then can provide both private and public access to resources or devices that exist within.</div>
<h3>Virtual Networks &amp; Subnets</h3>
<div>Everything begins with the Virtual Network. You do not have the ability to create Virtual Machines in Azure without there being a Virtual Network to place it in. You do not have the ability to connect to your On-Prem DataCenters for Hybrid traffic to flow to without there being a Virtual Network for the VPN connection to talk to.</div>
<div>&nbsp;</div>
<div><span><strong>NOTE</strong>:</span> The only reason for not needing a Virtual Network in your Azure subscription, is if you are developing or deploying a Native Cloud application that is leveraging all Platform as a Service based Azure services and you do not require any level of private connectivity.</div>
<div>&nbsp;</div>
<div>A Virtual Network is your basic networking infrastructure where you segment your customer defined private IP ranges (CIDR), where these segments are called Subnets. Once the network has been defined and deployed within Azure, networking traffic using an IP within the defined CIDR ranges can flow openly between any devices that those IPs have been assigned to. We will talk about the devices that can be placed into Virtual Networks and Subnets in Part 2. These Virtual Networks are not just self-contained networking pockets, they are also connection points for you to provide a much larger environment for your enterprise to use.</div>
<div>&nbsp;</div>
<div>For example, the Virtual Network is the entry point for one or more Virtual Private Network (VPN) connections to other networks outside of Azure, such as your On-Prem DataCenters. In addition, you can also connect multiple Virtual Networks together across multiple Azure regions to provide you with a Software Defined or Cloud Defined Geographically distributed network and this is just the beginning of what you can do. We will take a look at how you can control and secure this Azure based network traffic in the next section.</div>
<div>&nbsp;</div>
<div>So with that, let’s take a look at the VNet interface within the Azure Portal</div>
<div>&nbsp;</div>
[embed]https://vimeo.com/293448043/9da2033e4d[/embed]
<h3>User Defined Routes &amp; Network Security Groups</h3>
<div>The next area to discuss is the two features that are used within the scope of the Virtual Network that allow you to control and secure the traffic that is flowing in and out of your Virtual Network and these are called User Defined Routes (UDR) and Network Security Groups (NSG).</div>
<div>&nbsp;</div>
<div>A UDR is nothing more than a flat table of Next-Hop based routes where you define the source type of traffic and source endpoint and then specify what it's next hop our route should be. The most common use case of this is for traffic coming into a public endpoint may be routed to a virtual application for Intrusion Detection/Prevention services, before going to the actual intended web/application server. So the UDR is how you will control traffic within the scope of your VNet, because UDRs are directly tied to your virtual networks as you saw in the video above.</div>
<div>&nbsp;</div>
<div>A NSG is flat table of stateless firewall rules that can be placed on either a NIC card within a Virtual Machine or Virtual Appliance or it can be assigned to an entire Subnet. You can actually layer NSGs on top of one another to provide a more secure architecture for certain devices within a Subnet, where as other can be left more open. A typical NSG will require the following pieces of information:</div>
<div>&nbsp;</div>
<ul>
 	<li>
<div>Name</div></li>
 	<li>
<div>Priority</div></li>
 	<li>
<div>Source IP Range</div></li>
 	<li>
<div>Source Port</div></li>
 	<li>
<div>Target IP Range</div></li>
 	<li>
<div>Target Port</div></li>
 	<li>
<div>Traffic Direction (Inbound/Outbound)</div></li>
 	<li>
<div>Allow/Deny Action</div></li>
</ul>
<div>&nbsp;</div>
<div>Both of these services can be managed separately, but as you saw in the video on Vnets, they are directly applied to them. So with that, lets take a look at each service individually:</div>
<div>&nbsp;</div>
[embed]https://vimeo.com/292861646/70f401936b[/embed]
<h3>Virtual Private Gateways</h3>
<div>The next area of networking that I want to discuss, is Virtual Private Gateways and it is these combined set of services that allow you to provide traffic flow to/from your Virtual Network and any external network, such as your On-Prem DataCenter. There are three different kind of Virtual Private Gateways that are supported with two of them going across the internet through an IPSEC tunnel where as the last one requires a physical circuit between Azure and your external network there by ensuring that the connection and traffic flow is truly private.</div>
<div>&nbsp;</div>
<div>No matter which version of the gateway you plan on implementing, there are three resources within Azure that you will need to implement and then connect to one of your Virtual Networks. The first is the most important and that is what is called a "Gateway Subnet". This is a specialized Subnet within your Virtual Network that can only be used for connecting Virtual Private Gateways to a VPN connection of some kind. Only one Gateway Subnet can be created per Virtual Network, but assuming you provide the Subnet with enough of an IP range, than that single Subnet can be used for multiple VPN connections.</div>
<div>&nbsp;</div>
<div>The last two resources that are required are the Gateways themselves, the Local Gateway and the VPN Gateway. The Local Gateway is where you define the configuration of your external network's VPN access point with the most important piece being the external IP of that device so that Azure knows exactly how to establish the VPN connection. The VPN Gateway is the Azure resource that you tie into your Gateway Subnet within your Virtual Network. Once you have all three items configured and the connection has been made, then traffic should flow.</div>
<div>&nbsp;</div>
<div>Now, I mentioned above that there are three different kinds of Virtual Private Gateways, but I never really mentioned what the main differences are:</div>
<div>&nbsp;</div>
<ul>
 	<li>
<div>Point to Site - This VPN connection will run through an IPSEC tunnel over the internet. The endpoints will be a software defined VPN connection such as you would install on your laptop and then still connecting to a VPN gateway within Azure. This allows for a dedicated connection to Azure from your external network and is great for allowing your developers or contractors access to Azure when necessary.</div></li>
 	<li>
<div>Site to Site - This VPN connection will also run through an IPSEC tunnel over the internet with endpoints being your external network's VPN device and the VPN Gateway within Azure.</div></li>
 	<li>
<div>Express Route - This connection runs over a dedicated pair of physical circuits that will connect your external network to Azure. THis can be done through a number of different approaches depending on how your external network is setup and can be implemented using a large list of supported network vendors. See the document list below for more information.</div></li>
</ul>
<div>&nbsp;</div>
<div>So with all of this information as a starting point, let's take a look at how all of these pieces are plugged together within the scope of Azure:</div>
<div>&nbsp;</div>
[embed]https://vimeo.com/293569694/c1825bf84d[/embed]
<h3>Azure Firewall</h3>
<div>The last area of networking that we should discuss in this blog post is the brand new service, Azure Firewall. You might be a little confused here if you have read all the way through this blog post, because you might remember me describing the NSG as a stateless firewall that gets applied to Subnets or NICs. So what exactly is an Azure Firewall and how is it different from the NSG?</div>
<div>&nbsp;</div>
<div>The official statement from the Azure documentation is the following:</div>
<div>&nbsp;</div>
<div><em>Azure Firewall is a managed, cloud-based network security service that protects your Azure Virtual Network resources. It is a fully stateful firewall as a service with built-in high availability and unrestricted cloud scalability.</em></div>
<div>&nbsp;</div>
<div>As you can see from that statement, there are definitely some differences between the Azure Firewall and the NSG, but what are the major ones?</div>
<div>&nbsp;</div>
<ul>
 	<li>
<div>Stateful Service</div></li>
 	<li>
<div>Not applied to a single NIC or Subnet</div></li>
 	<li>
<div>Highly Available and Scalable based on demand</div></li>
 	<li>
<div>All network filtering rules can be applied across multiple subscriptions and virtual networks</div></li>
 	<li>
<div>White Listing capabilities for outbound HTTP/S traffic based on FQDN</div></li>
</ul>
<div>Lets' take a look now at what the service looks like within the Azure Portal.</div>
<div>&nbsp;</div>

[embed]https://vimeo.com/293454308/73e41e2adb[/embed]

<h3>Conclusion</h3>
As I stated at the top, the Azure Networking set of services are vast, so this set that I have provided here are only the first set and are primarily focused on networking infrastructure, not specific device types. In the second part of this blog post, we will start focus on specific networking devices available within the scope of Azure, such as the different types of Load Balancers, and Domain Services like Azure DNS and Azure Traffic Manager. We will also spend some time talking about how you can provide public endpoints for either individual VMs or Load Balancers within the scope of your Virtual Network.
<h3>Additional Resoures</h3>
<ul>
 	<li>
<div><a href="https://docs.microsoft.com/en-us/azure/virtual-network/virtual-networks-overview">Azure Virtual Network</a></div></li>
 	<li>
<div><a href="https://docs.microsoft.com/en-us/azure/virtual-network/security-overview">Network Security Groups</a></div></li>
 	<li>
<div><a href="https://docs.microsoft.com/en-us/azure/virtual-network/virtual-networks-udr-overview">User Defined Routing</a></div></li>
 	<li>
<div><a href="https://docs.microsoft.com/en-us/azure/vpn-gateway/vpn-gateway-about-vpngateways">Virtual Private Gateway</a></div></li>
 	<li>
<div><a href="https://docs.microsoft.com/en-us/azure/firewall/overview">Azure Firewall</a></div></li>
</ul>]]></content:encoded>
    </item>
    <item>
      <title>Azure 101: Monitoring &amp; Logging Part 1</title>
      <link>https://docs.microsoft.com/archive/blogs/cloud_solution_architect/azure-101-monitoring-logging-part-1</link>
      <pubDate>Tue, 04 Sep 2018 15:26:40 GMT</pubDate>
      <dc:creator><![CDATA[Brian Christopher Harrison]]></dc:creator>
      <guid
        isPermaLink="false">https://blogs.msdn.microsoft.com/cloud_solution_architect/?p=4595</guid>
      <description><![CDATA[Originally I was going to have my next Azure 101 post be about Networking as that is another set of...]]></description>
      <content:encoded><![CDATA[<div>Originally I was going to have my next Azure 101 post be about Networking as that is another set of services that every customer needs to learn about no matter what type of application or system you are planning on deploying. However, more important is the type of monitoring and logging that you may want to implement.</div>
<div>&nbsp;</div>
<div>In some cases, you might already have specific tools in place that you are already familiar with and of course the question would be "Can and/or Should those tools be implemented or integrated with Azure services?" For customers though that are modernizing and developing for the Cloud and specifically for Azure, it is going to be important to know what information is available from different Azure services and how can that information be ingested and visualized from a reporting and alerting perspective.</div>
<div>&nbsp;</div>
<div>So to stick with the Azure 101 series of blog posts, let's take a video look at all of the 1st-party services that are available in Azure that would fall under the topic of monitoring and logging. Many of these services and features are available for free to all customers. This will not be a deep discussion about how you should build your specific monitoring and logging strategy, but more just a walk-through of each of the available services.</div>
<div>&nbsp;</div>
<div>To start off, let's list what the different feature or services are that are available within Azure:</div>
<div>&nbsp;</div>
<ul>
 	<li>
<div>Azure Monitor</div>
<ul>
 	<li>
<div>Activity Log</div></li>
 	<li>
<div>Diagnostics</div></li>
 	<li>
<div>Metrics</div></li>
 	<li>
<div>Network Watcher</div></li>
 	<li>
<div>Alerting</div></li>
</ul>
</li>
 	<li>
<div>Application Insights</div></li>
 	<li>
<div>Log Analytics</div></li>
 	<li>
<div>Azure Advisor</div></li>
 	<li>
<div>Azure Security Center</div></li>
</ul>
<h3>Azure Monitor</h3>
I am sure that you noticed above that there are a number of sub-bullets underneath of the Azure Monitor topic and that is because if you go to the Azure Monitor service within the Azure Portal, you will see a large list of available services or features underneath. So each of the sub-bullets above correspond to a different feature that is available within and fall in the Monitoring and Logging topic.
<h4>Activity Log</h4>
Let's start with one that I believe to be the most important for every customer and that is the Activity Log. This feature provides you with a way to view the logging of every single Create, Update, List, or Delete action that is performed against a single subscription. These actions can be performed through the Portal, one of the Scripting mechanism (CLI or PowerShell) or through one of the many Azure SDKs (Software Development Kits) and they will show up as an entry within the Activity Log. By default, this service stores Activity Log entries for 90 days, but there are ways to export that information so that it can be archived for longer. So with that as a starting point, let's take a look at the Activity Log service:

[embed]https://vimeo.com/261478068/6aafbea3aa[/embed]
<h4>Diagnostics &amp; Metrics</h4>
<div>The next area of Azure Monitor to discuss is actually two items that I am going to combine together because they are both very tightly aligned with Logging and Alerting functionality and that is Diagnostics and Metrics. Every resource type within Azure has to ability to be monitored and logged, but each resource is going to provide different data and in some cases, those resources may need to be monitored in as close to real-time as possible and that is why we have two different capabilities.</div>
<div>&nbsp;</div>
<div>The diagnostics function provided a way for certain types of logs to be stored where these logs contain pertinent pieces of information for a resource type within Azure. For example, the a Virtual Machine has both Boot and Guest OS diagnostics that can be turned on at creation time. These logs are placed into a Storage Account for retrieval later, but many other resource types within Azure also have diagnostic logs and how you retrieve them and then consume them is a big part of your monitoring and logging strategy.</div>
<div>&nbsp;</div>
<div>On the flip side, the metric feature provides you with near real-time data about a particular resource. Going back to the Virtual Machine example, the diagnostic logs are going to be more heavily used for troubleshooting after something has already gone wrong. What if you wanted to be more pro-active and get a warning about something happening before it actually breaks? That is where metrics come into play, for some resource types within Azure, you have the ability to look at metric data, such as CPU percentage or bandwidth in or out. These are near real-time pieces of data that you can use and track to monitor the health of your resources and be more proactive.</div>
<div>&nbsp;</div>
<div>Lets take a look at both of these features and how they can be leveraged from within the Azure Portal:</div>
<div>&nbsp;</div>
[embed]https://vimeo.com/287441670/f647a18ce7[/embed]
<h4>Network Watcher</h4>
<div>The next area that I want to focus on isn't so much an area of monitoring and logging, but it does give you access to a lot of information pertaining to Azure Networking and some of it can easily be stored off like Diagnostic Logs. Network Watcher is more a set of tools to help you provide network troubleshooting capabilities like Packet Capture or Route validation and the like. Network Watcher provides a set of almost 10 tools that can provide information about how your network is working. Some of the tools are tied into Log Analytics which we will discuss in the next blog post, but most of them are available for free directly within the Azure Portal. A complete list of the tools can be found below:</div>
<div>&nbsp;</div>
<ul>
 	<li>
<div>Network Topology</div></li>
 	<li>
<div>Network Performance Monitor</div></li>
 	<li>
<div>Connection Monitor</div></li>
 	<li>
<div>IP Flow Verify</div></li>
 	<li>
<div>Next Hop</div></li>
 	<li>
<div>Security Group View</div></li>
 	<li>
<div>VPN Diagnostics</div></li>
 	<li>
<div>Packet Capture</div></li>
 	<li>
<div>Connection Troubleshoot</div></li>
</ul>
<div>Let's take a look at these different tools and how they can be used within the Portal:</div>
<div>&nbsp;</div>
[embed]https://vimeo.com/288061104/9d6b94c86a[/embed]
<h4>Alerting</h4>
<div>The last area that we want to take a look at in this post is the Alerting capabilities within Azure Monitor. We have already taken a look at many of the logging features and all of these can be used to drive a particular Alert action, such as sending an email or triggering an Azure Function or Azure Automation Runbook, but how does this happen and how can you make sure that the right people are being notified.</div>
<div>&nbsp;</div>
<div>Along with the Metrics features that we discussed above, the Alerting features were recently overhauled within Azure. So let's take a look at this new feature and function set within the Azure Portal:</div>
<div>&nbsp;</div>
[embed]https://vimeo.com/288066527/323e11d4e6[/embed]
<h3>Conclusion</h3>
<div>I am sure that you noticed that I have not completely covered everything that was in the bulleted list at the top of the post and that is because there are just too many different features and functions that fall into the monitoring and logging capabilities to go into one post. In the next post, I will try and fill in the gaps and focus on the visualization of all this log data of which there are number of different features and functions within Azure that fall into that category as well.</div>
<div>&nbsp;</div>
<div>One thing to keep in mind here, with all of these great capabilities, I can't really help you put together a generic strategy for which ones you use and which ones you don't, nor should you want me to. There are a lot of different questions that you need to ask yourself about how you can use all of these features that I have shown you, but at least now you have a starting point and will learn even more in the next post. For more information about each of the items that I have shown you, I have provided links to the main documentation pages for each one. See you next time.</div>
<h3>Additional Resources</h3>
<ul>
 	<li>
<div><a href="https://docs.microsoft.com/en-us/azure/monitoring-and-diagnostics/monitoring-overview">Monitoring in Azure</a></div></li>
 	<li>
<div><a href="https://docs.microsoft.com/en-us/azure/monitoring-and-diagnostics/monitoring-overview-activity-logs">Activity Log</a></div></li>
 	<li>
<div><a href="https://docs.microsoft.com/en-us/azure/monitoring-and-diagnostics/monitoring-overview-of-diagnostic-logs">Diagnostic Logs</a></div></li>
 	<li>
<div><a href="https://docs.microsoft.com/en-us/azure/monitoring-and-diagnostics/monitoring-overview-metrics">Metrics</a></div></li>
 	<li>
<div><a href="https://docs.microsoft.com/en-us/azure/network-watcher/network-watcher-monitoring-overview">Network Watcher</a></div></li>
 	<li>
<div><a href="https://docs.microsoft.com/en-us/azure/monitoring-and-diagnostics/monitoring-overview-unified-alerts">Azure Alerts</a></div></li>
 	<li>
<div><a href="https://docs.microsoft.com/en-us/azure/monitoring-and-diagnostics/monitor-alerts-unified-usage">Create and Manage Alerts using Azure Monitor</a></div></li>
</ul>]]></content:encoded>
    </item>
    <item>
      <title>A Serverless ToDo List</title>
      <link>https://docs.microsoft.com/archive/blogs/cloud_solution_architect/serverless-todo-list</link>
      <pubDate>Mon, 03 Sep 2018 14:10:50 GMT</pubDate>
      <dc:creator><![CDATA[Scott Semyan]]></dc:creator>
      <guid
        isPermaLink="false">https://blogs.msdn.microsoft.com/cloud_solution_architect/?p=4565</guid>
      <description><![CDATA[The code referenced in this article can be found here:...]]></description>
      <content:encoded><![CDATA[<em>The code referenced in this article can be found here: <a target="_blank" href="https://github.com/ssemyan/TodoServerless">https://github.com/ssemyan/TodoServerless</a></em>

With the move to the cloud, DevOps has become an important part of software development. With DevOps the same people who write the software are in charge of deploying it. However, many development teams are realizing that building and maintaining pools of VMs and their associated networking, storage, backups, etc. is a lot of work. Therefore, there is much interest in creating applications that no longer rely on VMs, but instead use a cloud-based framework. This is also known as Serverless Computing.

From <a href="https://en.wikipedia.org/wiki/Serverless_computing" rel="noopener" target="_blank">Wikipedia</a>: 

<blockquote>
Serverless computing is a cloud-computing execution model in which the cloud provider acts as the server, dynamically managing the allocation of machine resources. Pricing is based on the actual amount of resources consumed by an application, rather than on pre-purchased units of capacity.</blockquote>

With serverless, you rely on the cloud provider to ensure the platform is highly available and performant under load. Because the cost model is based on actual usage, you don’t worry about over or under provisioning, instead you let the platform expand and contract resources as needed. <a href="#note">*</a>

There are many ways to do <a href="https://azure.microsoft.com/en-us/overview/serverless-computing/" target="_blank">serverless in Azure</a>. One common pattern is to use <a href="https://azure.microsoft.com/en-us/services/functions/" rel="noopener" target="_blank">Azure Functions</a> for compute and <a href="https://azure.microsoft.com/en-us/services/cosmos-db/" rel="noopener" target="_blank">CosmosDB</a> for data storage. Combined with <a href="https://azure.microsoft.com/en-us/services/storage/" rel="noopener" target="_blank">Azure Storage</a> for static web hosting and <a href="https://azure.microsoft.com/en-us/services/active-directory/" rel="noopener" target="_blank">Azure Active Directory</a> for authentication, you can easily build an application with high availability and that will scale as needed. 

To illustrate this pattern, I developed an example that takes advantage of some of the Azure serverless products. The application is a simple ToDo list – a user logs in, sees a list of their ToDo items, and can create new items or mark existing items as complete (by deleting them). A user can only see (and work with) their items. A screenshot is below: 

<img src="https://msdnshared.blob.core.windows.net/media/2018/09/ServerlessTodoSS.png" alt="Serverless ToDo List Screenshot" class="aligncenter" style="width: 80%;border: solid grey 1px;margin-top: 30px;margin-bottom: 30px" />

The architecture is a single page web application (SPA) for the front end with the HTML and JavaScript hosted in Azure Blob Storage. Data is stored in CosmosDB (using the SQL API). The backend is composed of C# compiled Azure Functions using the <a href="https://docs.microsoft.com/en-us/azure/azure-functions/functions-reference" rel="noopener" target="_blank">1.x SDK</a>. Azure Active Directory is used to provide authentication. The simple diagram below illustrates this. 

<img src="https://msdnshared.blob.core.windows.net/media/2018/09/ServerlessTodo.png" alt="" class="aligncenter" style="width: 80%;margin-top: 30px;margin-bottom: 30px" />

The proxy feature of Azure Functions allows you to host your web content in blob storage but make it appear as if the content is all being served from the same URL. This also allows you to enable authentication on the entire site. You can read more about the proxy functionality <a href="https://blogs.msdn.microsoft.com/appserviceteam/2017/02/22/azure-functions-proxies-public-preview/" rel="noopener" target="_blank">here</a>.

It is important to be able to work locally to develop and debug the application without the need to connect to cloud resources. In Azure this is made possible by using the <a href="https://docs.microsoft.com/en-us/azure/cosmos-db/local-emulator" rel="noopener" target="_blank">CosmosDB Emulator</a> and the <a href="https://docs.microsoft.com/en-us/azure/azure-functions/functions-run-local" rel="noopener" target="_blank">Azure Functions CLI</a> (command line interface). When developing locally, authentication is disabled. Thus, you can work completely disconnected from the internet. 

This sample does not include scripts to create the necessary resources in Azure or to deploy the application. The <a target="_blank" href="https://github.com/ssemyan/TodoServerless">Github</a> project includes instructions on how to set up for local development and how to deploy to Azure. To deploy the project from Visual Studio, simply right click on the api project and choose deploy, then either create a new functions project or choose an existing one. 

Hopefully this simple project illustrates how you can easily create an application that has high scalability and high availability right out of the box without the need to manage VMs or other compute or data resources. 

<a name="note">*</a> Note: not all serverless applications are appropriate for a pay as you go model. In some cases you want to limit the amount you may potentially spend (e.g. when you don’t know how heavily an API will be used.) In this case you would use a normal App Service Plan sized to your expected load and price point. More info on pricing can be found <a href="https://azure.microsoft.com/en-us/pricing/details/functions/" rel="noopener" target="_blank">here</a>. 
]]></content:encoded>
    </item>
    <item>
      <title>Azure 101: Governance</title>
      <link>https://docs.microsoft.com/archive/blogs/cloud_solution_architect/azure-101-governance</link>
      <pubDate>Tue, 14 Aug 2018 21:01:43 GMT</pubDate>
      <dc:creator><![CDATA[Brian Christopher Harrison]]></dc:creator>
      <guid
        isPermaLink="false">https://blogs.msdn.microsoft.com/cloud_solution_architect/?p=4555</guid>
      <description><![CDATA[UPDATE: Added additional resource at bottom

I have worked with a lot of different customers over...]]></description>
      <content:encoded><![CDATA[<div><strong>UPDATE: </strong>Added additional resource at bottom</div>
<div></div>
<div>I have worked with a lot of different customers over the years and many of them were just betting started with Azure. Although these customers were of different sizes and were in different industries, they absolutely had something in common and that was the process and knowledge that they needed to be successful with their Azure deployments. One of those areas of process and knowledge is something that I believe every customer no matter if they are deploying only one system or a million within Azure will need to have and that is Governance.</div>
<div></div>
<div>What exactly do I mean by Governance? Governance is made up of a number of core services that Azure provides to all customers for free, but at a high level the term typically refers to the following:</div>
<div></div>
<ul>
 	<li>
<div>Resource Organization</div></li>
 	<li>
<div>Resource Security</div></li>
 	<li>
<div>Auditing</div></li>
 	<li>
<div>Cost Controls</div></li>
</ul>
<div>Each of these areas correspond to one or more Out of the Box (OOTB) services within Azure and when combined together they will make up a particular customer's governance policy or process. I am not about to sit here and tell you that I can tell you how to put together your own governance policy, because each and every customer's policy or process is going to be different based on the way that they run their business and how they manage their systems and applications.</div>
<div></div>
<div>What I can do however, is give you an overview of all the core services that you will need to understand to help build your own governance policy. I would like to do that for you so that you can get the necessary information in a nice concise set of videos. In these videos, I will give you a brief overview of each service as well as discuss some of the ways that they have been and should be implemented by customers. Each video will be fairly short, but combined together, they should give you a good understanding of how you can get started building your own governance policy.</div>
<h3>Resource Organization</h3>
<div>The first place to get started is in how you organize your resources within your Azure subscription. Defining a resource organization policy to define how they should be categorized is extremely important and is the starting point for all of the other pieces of the governance policy.</div>
<div></div>
<div>The two major pieces that are required here are Resource Groups and Tags and it is these two items that you will use to categorize your resources. Along with the subscription itself, these are the items that most azure services use as a basis for applying policies and security and all three of these pieces of information are made available within the billing reports to use for the filtering and sorting by your finance team for cost controls.</div>
<div></div>
<div>So with that in mind, let me give you a demonstration of how the resource groups and tags are managed within the portal and how they can be used to find resources more easily:</div>
<div></div>
[embed]https://vimeo.com/260853413/0e37194477[/embed]
<h3>Resource Security</h3>
<div>Within the scope of Azure subscriptions, there are three main areas of security with respect to the resources that are deployed within. The first is the user based security to either allow or deny users and/or groups to perform certain operations against those resources. The second is with respect to the resources that have already been deployed and locking them down so that they cannot be touched. The last is probably the one that every customer needs to understand the best, but many do not even implement and that is Azure Policies. Azure Policies allows you to apply conditions around the manipulation of resources within a Azure subscriptions and/or resource groups.</div>
<div></div>
<div>To give a better understanding around all of these areas, let me show how they can be applied and manipulated within the Azure Portal. I will not be showing every single possible permutation, but just a walk through of each service so that you can understand how to get started and how you might want to implement them within your own Governance policy.</div>
<div></div>
[embed]https://vimeo.com/261381720/0a9322f8a6[/embed]
<div></div>
[embed]https://vimeo.com/284438304/64aa7a3454[/embed]
<div></div>
[embed]https://vimeo.com/261388209/55a204b3bc[/embed]
<h3>Auditing</h3>
<div>
<div>The next area to talk about is not really part of a Governance Policy, but is more the way that Cloud Admins and/or Architects validate that the Governance Policy is being implemented correctly. I am specifically referring to Auditing which tracks all create. update, or delete actions that are performed within Azure within the scope of a given subscription. Within Azure, each action that is performed will show up in a simple table format, but is available in a full JSON details as well within the Activity Log feature.</div>
</div>
<div></div>
<div>As we talked about above, Policies are a preventative or proactive measure where as the Activity Log Auditing can be used in combination with Azure Alerts to provide a more reactive approach. Let me now show what I am referring to by giving you a walk-through of the Activity Log feature and how it can be used as part of your monitoring and alerting approach, but also how it can be for long-term logging of actions.</div>
<div></div>
[embed]https://vimeo.com/261478068/6aafbea3aa[/embed]
<h3>Cost Controls</h3>
<div>The last area to discuss is around Cost Controls. I talked above about how Subscription, Resource Group, and Tag information can be used as part of your cost control process, because that information is available with each resource entry within your subscription's billing report. In order to make this effective, it will be important that your finance team is involved in defining your resource group and tagging strategy.</div>
<div></div>
<div>Once you have the information coming through into your billing report so that the finance team can actually get the level of reporting that they are looking for, how can they bubble that up into something that can be consumed by executives. By default a subscription billing report is nothing more than a large CSV file that can be considerable in size depending on how many resources your have deployed within the subscription. So to make it possible to view your cost controls and understand how you you can provide charge back to specific departments or other internal organizations, Microsoft has acquired a great product Cloudyn</div>
<div></div>
<div>Cloudyn is a cost management system that takes in those billing reports along with all of the resource group and tagging information so that can more easily find out how much the IT department spent on your internal HR system that is deployed in the South Central US region of Azure. However, unlike the other services that I have talked about above, I do not have a demonstration of this system because I don't have access to one, but there is a great demo available that you view that was created by the Microsoft Partner Network. See below:</div>
<div></div>
[embed]https://vimeo.com/236808014[/embed]
<h3>Conclusion</h3>
<div>Hopefully these videos and discussions will help you get started with the design and implementation of your Governance policy. If you are interested in implementing any of these services within your own subscriptions, I have also included a link to the main documentation for each service in the Addition Resources below.</div>
<div></div>
<div>At the end of the day, the information that I have provided and the demonstrations that I have shown is just a starting point for you. If you should have any questions, please feel free to reach out to me, or you can always talk to your local Microsoft Cloud Solution Architect or a Cloud Solution Architect from one of your local Azure System Integrators. <b><u></u></b></div>
<h3><b><u>Additional Resources</u></b></h3>
<ul>
 	<li><a href="https://docs.microsoft.com/en-us/azure/architecture/cloud-adoption/appendix/azure-scaffold">Azure Enterprise Scaffolding for Governance</a></li>
 	<li>
<div><span><u><a href="https://docs.microsoft.com/en-us/azure/architecture/cloud-adoption-guide/adoption-intro/azure-resource-access">Resource Management Basics</a></u></span></div></li>
 	<li>
<div><span><u><a href="https://docs.microsoft.com/en-us/azure/azure-resource-manager/resource-group-overview">Resource Manager Overview</a></u></span></div></li>
</ul>
<ul>
 	<li>
<div><span><u><a href="https://docs.microsoft.com/en-us/azure/monitoring-and-diagnostics/monitoring-overview-activity-logs">Azure Activity Log</a></u></span></div></li>
 	<li>
<div><span><u><a href="https://docs.microsoft.com/en-us/azure/role-based-access-control/overview">Role Based Access Control</a></u></span></div></li>
 	<li>
<div><span><u><a href="https://docs.microsoft.com/en-us/azure/azure-resource-manager/resource-group-lock-resources">Resource Locks</a></u></span></div></li>
 	<li>
<div><a href="https://docs.microsoft.com/en-us/azure/azure-policy/azure-policy-introduction">Azure Policy</a></div></li>
 	<li>
<div><span><u><a href="https://docs.microsoft.com/en-us/azure/cost-management/">Azure Cost Management</a></u></span></div></li>
</ul>
&nbsp;]]></content:encoded>
    </item>
    <item>
      <title>Best Practices: Collaborative Approach to ChatBot Design using Bot Framework Tools</title>
      <link>https://docs.microsoft.com/archive/blogs/cloud_solution_architect/best-practices-collaborative-approach-to-chatbot-design-using-bot-framework-tools</link>
      <pubDate>Mon, 30 Jul 2018 23:15:57 GMT</pubDate>
      <dc:creator><![CDATA[Brian Christopher Harrison]]></dc:creator>
      <guid
        isPermaLink="false">https://blogs.msdn.microsoft.com/cloud_solution_architect/?p=4545</guid>
      <description><![CDATA[There are already many articles and documents that have been created on how to develop a ChatBot...]]></description>
      <content:encoded><![CDATA[There are already many articles and documents that have been created on how to develop a ChatBot using the Microsoft Bot Framework and how they can easily be integrated with many of the Cognitive Services that Microsoft provides. Matter of fact, you will see links to many of them listed below in the Additional Information section. However, I have not seen much in the way of best practices for the actual design of the Bot, specifically the conversation flows and what actions should the user be able to perform as well as how.

For the more traditional type of application, be it a Native, Mobile or Web based application, there are many tools out there to help with the design process, such as UI mock-up and API stubbing tools and let's not forget about the the all important process flow and entity relationship diagrams. All of these items can be used by application designers and architects when working with the business owner to make sure that the application is going to meet all of the user's needs and the business's requirements.

In the world of Bot Applications, because the technology is still so new, there aren't quite as many options, but Microsoft has done a great job in putting together some simple Command Line tools that can provide a great deisgn mechanism for working out how a Bot should be developed.
<ul>
 	<li>ChatDown</li>
 	<li>LuDown</li>
 	<li>QnAMaker</li>
 	<li>BotMaker</li>
 	<li>Bot Emulator</li>
</ul>
I am bringing this up, because I have been working with a great customer (Genex) to help them build out the first of what I hope will be many ChatBot applications. We have been using these tools in a very collaborative way directly with the business owners to make sure that the design aligns with exactly what they are looking for.
<h3>The Collaborative Approach</h3>
<div>The title for this section might sound a little counter intuitive and it certainly does not fit with the design and development methodology for more traditional applications. When we kicked off this project with the customer, I made sure to let the business owners know as well the technical lead at Genex that we would be working together to help drive the success of this Bot application. What I meant by that is we would be collaborating on the design while I still did the majority of the actual NodeJS development.</div>
<div>&nbsp;</div>
<div>In traditional software development the software designer or architect would perform the following steps pretty much on his/her own:</div>
<div>&nbsp;</div>
<ul>
 	<li>
<div>interviews with business owners and key stakeholders to gather requirements</div></li>
 	<li>
<div>write everything up into a requirements document</div></li>
 	<li>
<div>create the necessary diagrams and mockups</div></li>
 	<li>
<div>submit them for approval and review</div></li>
</ul>
<div>&nbsp;</div>
<span><strong>NOTE:</strong> Before anyone starts writing up nasty comments on the Blog Posting, I do understand that the best software companies and developers are always asking for and accepting customer and user feedback, but that is usually a one-way street with the exception of a very limited set of beta testers and even then it is much later in the development process. </span>
<div>In the case of this Genex ChatBot, right from the beginning, I made sure that the Technical Lead at Genex was in constant talks with the business owners and was getting approval for each conversation that we created. In addition, using the tools that I mentioned above, the business owners themselves could review and make changes to the proposed mockups or integrations on their own without worrying about how to develop anything themselves.</div>
<div></div>
<div>Now you might be asking, how that is possible and why would you ever want a business owner to be that deeply engaged in the design and development process? One very simple answer: "Application Success"</div>
<h3>Getting Started - Conversation Flows</h3>
<div>We started by designing what conversations or dialogs would actually be available to the user and what actions would the user be able to perform using those conversations. In this application's case, there were four distinct conversation paths:</div>
<div>&nbsp;</div>
<ul>
 	<li>
<div>User Profile Updates</div></li>
 	<li>
<div>Predictive Analytics Response</div></li>
 	<li>
<div>Knowledge Base Search</div></li>
 	<li>
<div>Claim Management System Status Check</div></li>
</ul>
<div>&nbsp;</div>
<div>The first and last ones are pretty straight forward in that they are just integrations with the Genex Claim Management system, but we are providing integration against it using this ChatBot application. The first is making updates to that system and the last is making information requests from the system.</div>
<div>&nbsp;</div>
<div>The second item is performing a request of a Azure Machine Learning model that has already been created and made available as a web service. The Knowledge Base search is something that is completely homegrown, but can be easily developed using the QnA Maker capabilities within Azure.</div>
<h3>Conversation Flow Design</h3>
<div>Now that we know what types of conversation the user will be having with this Bot application, we need to figure out how the conversations should flow. This can be done in a very collaborative way using the ChatDown tool.</div>
<div>&nbsp;</div>
<div>We started with the easiest one to understand, which was the User Profile updates. In this case, we focused on the ability for the user to make Phone, Email, or Address changes to their User Profile within the Claim Management system. The ChatDown tool uses Markdown language to show a simple conversation between a User and the Bot. This can then be converted to a "transcript" file that can be read by the Bot Emulator so that the business owners can see what the conversation would look like in a Chat window without any development having even been done yet.</div>
<div>&nbsp;</div>
<div>The process that we used to make this as collaborative as possible was the following:</div>
<div>&nbsp;</div>
<ol>
 	<li>
<div>I created the first ChatDown file to correspond to the updating of a User's Phone number</div></li>
 	<li>
<div>I converted the first file to a transcript</div></li>
 	<li>
<div>I then taught the tech lead at Genex about the anatomy of the Chatdown file and how the Chatdown tool works</div></li>
 	<li>
<div>I then showed the transcript within the Bot Emulator so that he could see what the conversation would look like</div></li>
 	<li>
<div>I then gave the Tech Lead homework to create the remaining Chatdown files and convert them to transcripts</div></li>
 	<li>
<div>Lastly, the Tech Lead sat down with the business owners and showed them how to use the Bot Emulator to view the transcripts themselves so that they could provide feedback so that changes could be made prior to development</div></li>
</ol>
<div>&nbsp;</div>
<div>One additional step that could be used and I will probably be introducing in the future is to actually give the business owners access to the ChatDown files before they are converted so that ownership of the conversation design is completely on them rather than the developers. An example straight from the Genex Bot application can be found below, both the ChatDown file and the Bot Emulator image of the transcript</div>
<h3>Remaining Conversation Patterns</h3>
<div>Remember that I mentioned a much longer list of tools above that would be available for use, other than just ChatDown. The ChatDown tool should always be the first place you start when designing each of the conversation flows. However, what happens when you want to use the QnA Maker or LUIS to help define the conversation flow in a more dynamic and user friendly way?</div>
<div>&nbsp;</div>
<div>That is then when you look at the LuDown tool or the QnA maker tool. Both of these tools also use markdown language to help describe either Questions and Answers for a FAQ and/or possible language based intents. Because the markdown language is so easy to understand, you can use the exact same collaborative process that I listed above just replacing ChatDown with one of the other tools.</div>
<div>&nbsp;</div>
<div>This gives the business owners more responsibility during the design process for your ChatBot and makes them feel more involved there by making the application more successful.</div>
<h3>Conclusion</h3>
<div>In conclusion, there are some very collaborative ways to build and design a great Bot application making sure that all of the right people are actually helping to drive the success of the application. This collaborative process is made much easier because of all the great CLI tools that the Azure Bot Framework team have made available. To close this out, I want to show you how easy it is to work with these tools, by showing a video of some work that I did with Genex on their application using the ChatDown, LUISDown, LUIS APIs and Bot Emulator tools.</div>
<div>&nbsp;</div>
<div>

[embed]https://vimeo.com/282393179/2c37a3d4ee[/embed]

</div>
<div>&nbsp;</div>
<div>Lastly, in addition to all that I have discussed and shown, please take a look at all of the links below that can help you find out even more information about the Azure Bot Framework and the Framework tools that are available.</div>
<h3>Additional Tools</h3>
<ul>
 	<li><a href="https://docs.microsoft.com/en-us/azure/bot-service/?view=azure-bot-service-4.0">Azure Bot Service Documentation v4 Preview</a></li>
 	<li><a href="https://github.com/Microsoft/botbuilder-tools">Azure Bot Builder Tools</a></li>
 	<li><a href="https://github.com/Microsoft/botbuilder-tools/tree/master/Ludown">Azure LuDown</a></li>
 	<li><a href="https://github.com/Microsoft/botbuilder-tools/tree/master/Chatdown">Azure ChatDown</a></li>
 	<li><a href="https://github.com/Microsoft/botbuilder-tools/tree/master/QnAMaker">Azure QnA Maker</a></li>
 	<li><a href="https://github.com/Microsoft/BotFramework-Emulator">Azure Bot Emulator</a></li>
</ul>]]></content:encoded>
    </item>
    <item>
      <title>Terraform for the ARM Template Developer</title>
      <link>https://docs.microsoft.com/archive/blogs/cloud_solution_architect/terraform-for-the-arm-template-developer</link>
      <pubDate>Wed, 27 Jun 2018 14:35:26 GMT</pubDate>
      <dc:creator><![CDATA[Scott Semyan]]></dc:creator>
      <guid
        isPermaLink="false">https://blogs.msdn.microsoft.com/cloud_solution_architect/?p=4515</guid>
      <description><![CDATA[The files used in this article can be found here:...]]></description>
      <content:encoded><![CDATA[<em>The files used in this article can be found here: <a target="_blank" href="https://github.com/ssemyan/BasicAzureLinuxVmTerraformTemplate">https://github.com/ssemyan/BasicAzureLinuxVmTerraformTemplate</a></em>

In a previous post - <a href="https://blogs.msdn.microsoft.com/cloud_solution_architect/2016/11/11/creating-azure-resources-with-arm-templates-step-by-step/" target="_blank">Creating Azure Resources with ARM Templates Step by Step</a> – I explain how to use Azure ARM templates to describe and deploy resources in Azure. 

With many companies adopting a multi-cloud strategy, the idea of a single toolset to deploy to different public clouds has become popular. The open source tool <a href="https://www.terraform.io/" target="_blank">Terraform</a> tries to address this by providing a common framework to create and modify infrastructure whether on-prem or in the cloud by abstracting out the specific APIs. 

The goal of this post is to compare the Terraform way of doing things with my previous article on ARM templates. If you are new to ARM templates, you may want to refer to my other article first. I list some Terraform resources at the end of the article including basic tutorials and install instructions. 
 
For this article I've kept the resources and file structures similar to my ARM example. One change, however, is I now use managed disks instead of storage account based disks. 

<b>Providers</b>

Terraform allows modification and configuration of all types of resources - from on-prem physical machines to cloud-based resources. This is accomplished via different <i>providers</i> that abstract out the underlying APIs. You can see a list of Terraform providers <a href="https://www.terraform.io/docs/providers/index.html" target="_blank">here</a>. Documentation for the Azure provider can be found <a href="https://www.terraform.io/docs/providers/azurerm/index.html" target="_blank">here</a>.

In ARM Templates, resources are referred to by type and the API version that they exist in:

<pre> {
  "name": "MyVnet",
  "type": "Microsoft.Network/networkInterfaces",
  "apiVersion": "2016-09-01",
  ... 
}</pre>

With Terraform, you specify the resource as it is named in the provider and then give it a local name you can refer to it by in the Terraform (in the example below, the resource type is <i>azurerm_virtual_network</i> - a vnet from the azurerm provider - and the local name for this vnet - used only in the Terraform file - is <i>vnet1</i>):

<pre>resource "azurerm_virtual_network" "vnet1" {
  name                = "MyVnet"
  ... 
}</pre>

The provider must be downloaded and be available locally. This is done by running the <i>init</i> command which downloads all the providers referred to by the template files (similar to how <i>npm install</i> downloads the node packages from <i>packages.json</i>).

<img src="https://msdnshared.blob.core.windows.net/media/2018/06/TerraformInit.png" alt="" width="684" height="457" class="alignnone size-full wp-image-4525" />

<b>Commands and Files</b>

When running ARM templates with PowerShell, there are two main commands: <i>Test-AzureRmResourceGroupDeployment</i> is to test a deployment (looking for errors) and <i>New-AzureRmResourceGroupDeployment</i> which does the actual deployment. Each command accepts a single template file and parameter file to be run in that resource group. For example:

<pre>New-AzureRmResourceGroupDeployment -ResourceGroupName $resourceGroupName -TemplateFile $templateFilePath -TemplateParameterFile $parametersFilePath
</pre>

With Terraform you have four main actions – init, plan, apply and destroy. 
<ul>
<li><i>terraform init</i> will prepare the directory, download any listed providers, etc. You run it once in a new Terraform project and then again if anything changes</li>
<li><i>terraform plan</i> will show all the changes that potentially will be made if the Terraform is run. It is like doing a test run</li>
<li><i>terraform apply</i> does the actual creation or change of the resources</li>
<li><i>terraform destroy</i> will delete the resources described in the template files</li>
</ul>

Note: with the terraform commands, you don't have to specify the input files. Instead, Terraform will load and combine the all the relevant files in the current directory. Template files end with <i>.tf</i> and variable files are named either <i>terraform.tfvars</i> or <i>*.auto.tfvars</i> - thus, you can separate and name your files whatever you like (e.g. all the networking resources in a file called <i>networking.tf</i>, all the networking variables in a file called <i>networking.auto.tfvars</i>, etc.)

<b>Resource Groups</b>

The first difference between ARM and Terraform to point out is resource groups. When running ARM templates, the template runs within a resource group that must already exist. If you have resources that span resource groups, you will need to deploy them separately (one per resource group). 

Terraform allows resource group creation so you can have multiple resource groups (and their associated resources) within a single Terraform definition. 

<b>Parameters and Variables -&gt; Variables and Locals</b>

ARM templates have parameters (that may change between deployments), variables (that change less often) and the actual resource definitions (which don’t generally change). With ARM, parameter values can be placed into a separate file (e.g. <i>parameters.json</i>) or entered at runtime. 

Terraform parameters are called <i>variables</i> and their values can be stored in a file (e.g. <i>terraform.tfvars</i>), entered on the command line (e.g. <i>var 'access_key=foo'</i>), or via environment variables (e.g. <i>set TF_VAR_access_key=foo</i>). 

For comparison here is a parameter definition in ARM (contained in the <i>.json</i> template file):

<pre>"parameters": {
    "location": {
      "type": "string",
      "defaultValue": " westeurope",
      "metadata": {
        "description": "Which region to use."
      }
    }
}</pre>

Here is the same parameter (called a variable) in Terraform (contained in a <i>.tf</i> template file):

<pre>variable "location" {
  description = "Which region to use."
  default = "westeurope"
}</pre>

Setting a value for a parameter in an ARM <i>parameters.json</i> file looks like:

<pre>"parameters": {
        "location": {
            "value": "centralus"
        }
}</pre>

Setting a value for a variable in a Terraform <i>terraform.tfvars</i> file looks like:

<pre>location = "centralus"</pre>

In ARM templates, you use variables to store values that do not change as often as parameters but that you don’t want to code in-line with your resource descriptions. An example might be the name of the VNET. In Terraform, these are called locals. 

For example, for the virtual network name, I use the name of the resource group with "-vnet" post-pended. 

With ARM, this looks like this:

<pre>"variables": {
    "virtualNetworkName": "[concat(parameters('resourceGroupName'), '-vnet')]"
}</pre>

With Terraform, this looks like this:

<pre>locals {
  virtualNetworkName = "${var.resourceGroupName}-vnet"
}</pre>

When making use of parameters and variables in ARM templates you refer to them like so:

<pre>{
      "name": "[variables('publicIpAddressName')]",
      "type": "Microsoft.Network/publicIpAddresses",
      "apiVersion": "2016-09-01",
      "location": "[parameters('location')]",
      "properties": {
        "publicIpAllocationMethod": "[variables('publicIpAddressType')]"
      }
}</pre>

With Terraform, they are referred to as:

<pre>resource "azurerm_public_ip" "basicvm" {
  name                         = "${local.publicIpAddressName}"
  location                     = "${var.resource_group_location}"
  ... 
  public_ip_address_allocation = "${local.publicIpAddressType}"
}</pre>

<b>Resources and Dependencies</b>

The next difference to note is how resource dependencies are determined when defining resources. With ARM you must explicitly specify that a resource depends on another resource by either nesting the resources or listing them in the <i>dependsOn</i> property. With Terraform, dependencies are implied by referring to the dependent objects, so no explicit dependency declaration is needed (although it can be done if you want to control the order of creation). 

For example, here is how I create a NIC with ARM:

<pre>{
      "name": "[variables('networkInterfaceName')]",
      "type": "Microsoft.Network/networkInterfaces",
      "apiVersion": "2016-09-01",
      "location": "[parameters('location')]",
      "dependsOn": [
        "[concat('Microsoft.Network/virtualNetworks/', variables('virtualNetworkName'))]",
        "[concat('Microsoft.Network/publicIpAddresses/', variables('publicIpAddressName'))]",
        "[concat('Microsoft.Network/networkSecurityGroups/', variables('networkSecurityGroupName'))]"
      ],
     "properties": {
        "ipConfigurations": [
          {
            "name": "ipconfig1",
            "properties": {
              "subnet": {
                "id": "[variables('subnetRef')]"
              },
              "privateIPAllocationMethod": "Dynamic",
              "publicIpAddress": {
                "id": "[resourceId(resourceGroup().name,'Microsoft.Network/publicIpAddresses', variables('publicIpAddressName'))]"
              }
            }
          }
        ],
        "networkSecurityGroup": {
          "id": "[resourceId(resourceGroup().name, 'Microsoft.Network/networkSecurityGroups', variables('networkSecurityGroupName'))]"
        }
}</pre>

In the above ARM example, I specify that the VNET, Public IP, and network security group must be created before the NIC can be created by listing these resources in the <i>dependsOn</i> section. 

The Terraform version looks like:

<pre>resource "azurerm_network_interface" "basicvm" {
  name                = "${local.networkInterfaceName}"
  location            = "${var.resource_group_location}"
  resource_group_name = "${azurerm_resource_group.basicvm.name}"

  ip_configuration {
    name                          = "ipConfig"
    subnet_id                     = "${azurerm_subnet.basicvm.id}"
    private_ip_address_allocation = "dynamic"
    public_ip_address_id          = "${azurerm_public_ip.basicvm.id}"
  }
}</pre>

In the example above, because I refer to the subnet and public IP via the ID of the object, this means Terraform will create these resources first (and then obtain the IDs of the created objects) before creating the NIC.

<b>Data</b>

Sometimes you need to retrieve a value from an existing resource to use. In ARM, you have helper functions such as <i>resourceId</i> that will look up the ID of a resource previously created based on the name. For example: 

<pre>"variables": {
          "nsg_id": "[resourceId('MyResourceGroup', 'Microsoft.Network/networkSecurityGroups', 'MyNsg')]"
}</pre>

This will create a variable 'nsg_id' by looking up the ID of an NSG contained in the resource group 'MyResourceGroup' with the name 'MyNsg' and obtaining the resource ID for it.

To do the same thing in Terraform, we use the 'data' resource type. For example, to get the ID of an existing NSG and output it at the end of the Terraform we would do:

<pre>data "azurerm_network_security_group" "test" {
  name                = "MyNsg"
  resource_group_name = "MyResourceGroup"
}

output "nsg_id" {
  value = "${data.azurerm_network_security_group.test.id}"
}</pre>

<b>State</b>

The last item to note, is the concept of state. ARM Templates are stateless in that they describe the end state of the resources. When run, the ARM mechanism will determine what needs to be done to make the changes to the resource group to match the state described in the template. This may mean creating or modifying resources as needed. Unless run in <i>incremental</i> mode, running an ARM template will not remove resources not listed in the template. 

Terraform, however, requires that the state of the deployment be persisted. This includes all the changes that Terraform has made. This state is used to determine what to change or delete when the template file is changed. If the state file is lost or corrupted Terraform does not know what has been created and therefore will simply try to recreate everything. For groups working together, it there are ways to share state across users. State in Terraform is a large topic and more information can be found <a href="https://www.terraform.io/docs/state/" target="_blank">here</a>.

<b>Conclusion</b>

I hope this article has given experienced ARM template developers a better idea of how Terraform works. The source code can be found here: <a target="_blank" href="https://github.com/ssemyan/BasicAzureLinuxVmTerraformTemplate">https://github.com/ssemyan/BasicAzureLinuxVmTerraformTemplate</a>

To run this Terraform against your Azure account (which will create a Linux VM along with the associated networking), you must either create a service principal and enter the associated values in the <i>.tf</i> file, or log in to Azure using the Azure CLI (e.g. <i>az login</i>). This process is described in detail <a href="https://docs.microsoft.com/en-us/azure/virtual-machines/linux/terraform-install-configure" target="_blank">here</a>.

Before you run the Terraform, change the values in the <i>terraform.tfvars</i> file including setting the ssh key (if you need help creating a key, you can refer <a href="https://blogs.msdn.microsoft.com/cloud_solution_architect/2016/08/24/generating-ssh-keys-for-azure-linux-vms/" target="_blank">here</a>). You then run the terraform by issuing the following in the directory:

<pre>terraform init
terraform apply</pre>

The Terraform will first show you what will be created and ask for a confirmation. After typing 'yes', the resources will be created, and the resulting public IP and ssh command returned. 

<img src="https://msdnshared.blob.core.windows.net/media/2018/06/TerraformApply.png" alt="" width="834" height="482" class="alignnone size-full wp-image-4535" />

To destroy the installation and delete all the resources that were just created, type:

<pre>terraform destroy</pre>

<b>Additional Resources</b>

<a target="_blank" href="https://docs.microsoft.com/en-us/azure/terraform/">Official Terraform on Azure Documentation from Microsoft</a>

<a target="_blank" href="https://blogs.msdn.microsoft.com/eugene/2016/11/03/creating-azure-resources-with-terraform/">Creating Azure Resources with Terraform by Eugene Chuvyrov</a>

<a target="_blank" href="https://www.terraform.io/docs/providers/azurerm/index.html">Official Azure Provider for Terraform</a>

<a target="_blank" href="https://github.com/terraform-providers/terraform-provider-azurerm">GitHub repo for the Azure Provider including examples</a>

For a more opinionated take, here is an article from Sam Cogen - <a target="_blank" href="https://samcogan.com/terraform-and-azure-whats-the-benefit/">Using Terraform with Azure - What's the benefit?</a>]]></content:encoded>
    </item>
    <item>
      <title>Understanding RPO and RTO considerations of Azure Solutions</title>
      <link>https://docs.microsoft.com/archive/blogs/cloud_solution_architect/understanding-rpo-and-rto-considerations-of-azure-solutions</link>
      <pubDate>Wed, 02 May 2018 19:29:10 GMT</pubDate>
      <dc:creator><![CDATA[Trey Talbott]]></dc:creator>
      <guid
        isPermaLink="false">https://blogs.msdn.microsoft.com/cloud_solution_architect/?p=4505</guid>
      <description><![CDATA[Traditional on prem Disaster Recovery (DR) discussions almost always include requirements around RPO...]]></description>
      <content:encoded><![CDATA[Traditional on prem Disaster Recovery (DR) discussions almost always include requirements around RPO and RTO.  I was asked recently if given more and more hybrid (onprem to cloud) and cloud to cloud DR deployments, if RPO and RTO are still relevant.

&nbsp;

In short, RPO and RTO are still extremely relevant design considerations.

&nbsp;

To make sure we are using these terms consistently:
<ul>
 	<li>RPO stands for recovery <strong>POINT</strong> objective, i.e., how much data is one potentially prepared and willing to lose, worse case</li>
 	<li>RTO stands for recovery <strong>TIME</strong> objective, i.e., if/when the ‘bad thing’ happens, how much time does it take to be back up and running again</li>
</ul>
&nbsp;

Many clients first reaction is they want RTO and RPO of zero (i.e. NO data loss with no downtime).

&nbsp;

While this is technically possible, RPOs of zero require synchronous replication.  Synchronous replication by design require multiple writes/updates/deletes in multiple locations <strong>before</strong> giving an ACK back to the application.  These additional transactions to multiple locations <strong><em>may</em></strong> introduce unacceptable performance, typically due to network distances and associated latency (think speed of light overhead).

&nbsp;

More traditional IaaS Azure business continuance and disaster recovery solutions like Azure backup and Azure Site Recovery (ASR), as well as many of our Azure Marketplace partner protection solutions, are generally asynchronous by design and therefore provide RPOs &gt; 0.

&nbsp;

From a design perspective it is nearly impossible to guarantee specific RPOs and RTOs for these type of solutions because many variables are outside of your control, HOWEVER, here are some general guidelines…

&nbsp;

RPO of backup solutions are most dependent on the backup policies.  For example, if someone setups up a daily backup policy, then the RPO is closer to a day.

&nbsp;

RPO of replication solutions are often most dependent on the distance separating the two sites.  For example, when someone configures ASR to replicate across two regions, then the RPO is more likely to be in the ~seconds to many seconds range.

&nbsp;

When designing for RTO it is important to understand the variables that are not always in your control.  For example, if someone initiates a restore, the time it takes to be back up and running is dependent on variables like the size of the restore, available network bandwidth, speed of the disk drives/VMs, etc.

&nbsp;

In a more traditional DR failover scenario whether onprem to cloud or cloud to cloud, it is common to use a service like Azure Site Recovery.  Since the data has already been replicated, the RTO in this case has many dependencies including how long it takes to provision the DR infrastructure on the ‘other side’, speed of the disk drives/VMs, time to run the recovery plan, time to propagate the appropriate DNS changes to point to the ‘other’ side, etc.  Generally in the ~minutes to many minutes range.

&nbsp;

In summary, it is difficult to guarantee RPO/RTO targets as there are many dependencies not necessarily in your control but it is still critically important to understand your RPO and RTO targets from a requirements gathering perspective.  Knowing if your requirements are truly RPO and/or RTO of zero, a minute or two, a few hours, daily, etc, can help you design the most appropriate Azure based solution.]]></content:encoded>
    </item>
    <item>
      <title>Changing the License Type for an existing Virtual Machine Scale Set to use the Azure Hybrid Use Benefit</title>
      <link>https://docs.microsoft.com/archive/blogs/cloud_solution_architect/changing-the-license-type-in-an-existing-virtual-machine-scale-to-use-azure-hybrid-use-benefit</link>
      <pubDate>Tue, 20 Mar 2018 15:43:05 GMT</pubDate>
      <dc:creator><![CDATA[Pete Rodriguez]]></dc:creator>
      <guid
        isPermaLink="false">https://blogs.msdn.microsoft.com/cloud_solution_architect/?p=4425</guid>
      <description><![CDATA[If you are an enterprise customer that has existing Windows Server licenses that you want to use in...]]></description>
      <content:encoded><![CDATA[<p>If you are an enterprise customer that has existing Windows Server licenses that you want to use in Azure, you can take advantage of the Azure Hybrid Use Benefit to bring those licenses to the cloud. We have those steps documented for a number of scenarios here: <a title="https://docs.microsoft.com/en-us/azure/virtual-machines/windows/hybrid-use-benefit-licensing" href="https://docs.microsoft.com/en-us/azure/virtual-machines/windows/hybrid-use-benefit-licensing">https://docs.microsoft.com/en-us/azure/virtual-machines/windows/hybrid-use-benefit-licensing</a>. However, what if you want to convert to AHUB once you’ve already deployed your VM Scale Sets? The methods described in the above article do not currently include how to do this for an existing VMSS deployment. </p><p>Here is the PowerShell to make the change:</p><p>$rg = "TestVMSS-RG" #change for your resource group</p>
<p>$VMScaleSetName = "PeteVMSS02" #change for your virtual machine scale set name<br>
$vmss = Get-AzureRMVMss -ResourceGroupName $rg -VMScaleSetName $VMScaleSetName</p>
<p>$vmss.VirtualMachineProfile.LicenseType = "Windows_Server"</p>
<p>Update-AzureRmVmss -ResourceGroupName $rg -VMScaleSetName $VMScaleSetName -VirtualMachineScaleSet $vmss</p>
<p>Update-AzureRmVmssInstance -ResourceGroupName $rg -VMScaleSetName $VMScaleSetName -InstanceId "*"&nbsp;&nbsp;&nbsp; </p>]]></content:encoded>
    </item>
    <item>
      <title>Query ASR Replicated Item Status using Powershell</title>
      <link>https://docs.microsoft.com/archive/blogs/cloud_solution_architect/query-asr-replicated-item-status-using-powershell</link>
      <pubDate>Thu, 01 Mar 2018 01:56:56 GMT</pubDate>
      <dc:creator><![CDATA[RajNemani]]></dc:creator>
      <guid
        isPermaLink="false">https://blogs.msdn.microsoft.com/cloud_solution_architect/?p=4415</guid>
      <description><![CDATA[In this short blog post, I am going to show how to query the status of replicated items in an Azure...]]></description>
      <content:encoded><![CDATA[In this short blog post, I am going to show how to query the status of replicated items in an Azure Site Recovery (ASR) vault.  My objective for this post is to share some of the details of ASR Powershell API/object model that may not be obvious immediately.  There are two reasons for this in my opinion.  The first is the fact that the object model does not necessarily map to the UI elements/object that are exposed in the portal which makes it a bit challenging to know where to start.  I am referring to objects such as ASRFabric and ASRProtectionContainer, which you will see in the script below, that do not have corresponding UI elements in the portal.  The second reason is that there are no end-to-end script examples (that I could find) which walk through the process of setting up the flow to be able to successfully query for the status of the replicated items.  Now that i have provided a bit of context for the post, here is the script flow.
<ol>
 	<li>Create a service principal and gather the CLIENT_ID, CLIENT_SECRET, and your AAD TENANT_ID.  You can find more details <a href="https://docs.microsoft.com/en-us/azure/azure-resource-manager/resource-group-create-service-principal-portal">here </a>on how to create a Service Principal in Azure</li>
 	<li>Assign Site Recovery Contributor RBAC role to the Service Principal to relevant subscriptions.  You can find more details <a href="https://docs.microsoft.com/en-us/azure/azure-resource-manager/resource-group-create-service-principal-portal">here </a>on how to assign a RBAC role to a Service Principal in subscription</li>
 	<li>Login using service principal credentials</li>
 	<li>For each Subscription that you are interested in
<ol>
 	<li>Get all the Vault objects in the Subscription</li>
 	<li>For each Vault
<ol>
 	<li>Import the Vault settings file</li>
 	<li>Get a list of Fabric objects in the Vault</li>
 	<li>For each Fabric object
<ol>
 	<li>Get a list of ASR Protection Container objects</li>
 	<li>For each container object
<ol>
 	<li>Get a list of replicated items</li>
 	<li>Query the status and format for display as desired</li>
</ol>
</li>
</ol>
</li>
</ol>
</li>
</ol>
</li>
</ol>

[code language="powershell"]



# Variable Declaration
$CLIENT_SECRET = &quot;Service Principal client secret&quot;
$CLIENT_ID = &quot;Service Principal client ID also known as Application ID&quot;
$TENANT_ID = &quot;AAD Tenant ID&quot;

Write-Host &quot;Logging you in...&quot;
$secpasswd = ConvertTo-SecureString $CLIENT_SECRET -AsPlainText -Force
$mycreds = New-Object System.Management.Automation.PSCredential ($CLIENT_ID, $secpasswd)
Add-AzureRmAccount -ServicePrincipal -Tenant $TENANT_ID -Credential $mycreds

# Clear the contents of log file
Clear-Content -Path FILE_PATH_OF_VMSTATUS_LOG_FILE

# Enter the subscriptions where ASR is enabled
$Subscriptions = &quot;An Array of subscription names that the Service Pricipal has access to (recommend Site Recovery Contributor RBAC role)&quot;
foreach ($Subscription in $Subscriptions)
{
    # Select the subscription
    Select-AzureRmSubscription -SubscriptionName $Subscription

    # get the list of recovery services vaults in the subscription
    $VaultObjs = Get-AzureRmRecoveryServicesVault
    foreach ($VaultObj in $VaultObjs) 
    {
        # get and import vault settings file
        $VaultFileLocation = Get-AzureRmRecoveryServicesVaultSettingsFile -SiteRecovery -Vault $VaultObj
        Import-AzureRmRecoveryServicesAsrVaultSettingsFile -Path $VaultFileLocation.FilePath

        # get the list of fabrics in a vault
        $Fabrics = Get-AzureRmRecoveryServicesAsrFabric
        foreach ($Fabric in $Fabrics)
        {
            # get containers and protected items in a container
            $Containers = Get-AzureRmRecoveryServicesAsrProtectionContainer -Fabric $Fabric
            foreach ($Container in $Containers)
            {
                $items = Get-AzureRmRecoveryServicesAsrReplicationProtectedItem -ProtectionContainer $Container
                foreach ($item in $items)
                {
                    # Initialize an empty error array for capturing error(s) of each protected item
                    $ItemError = &quot;&quot;
                    foreach ($ASRerror in $item.ReplicationHealthErrors)
                    {
                        $ItemError=$ItemError,$ASRerror.ErrorMessage
                    }
                    
                    # Capture the status of machines which are in critical state to a file
                    If(-Not($item.ReplicationHealth -eq &quot;Normal&quot;))
                    {
                        $ASRVMHealthStatus=$Subscription+&quot;`t&quot;+$VaultObj.Name+&quot;`t&quot;+$Item.FriendlyName+&quot;`t&quot;+$Item.ReplicationHealth+&quot;`t&quot;+$ItemError
                        $ASRVMHealthStatus | Out-File -Append -FilePath FILE_PATH_OF_VMSTATUS_LOG_FILE
                    }
                }
            }
        }

        # remove vault settings file
        rm -Path $VaultFileLocation.FilePath
    }
}

 


[/code]
]]></content:encoded>
    </item>
    <item>
      <title>Cost Optimization on Azure</title>
      <link>https://docs.microsoft.com/archive/blogs/cloud_solution_architect/cost-optimization-on-azure</link>
      <pubDate>Fri, 23 Feb 2018 16:45:46 GMT</pubDate>
      <dc:creator><![CDATA[Jason Boeshart]]></dc:creator>
      <guid
        isPermaLink="false">https://blogs.msdn.microsoft.com/cloud_solution_architect/?p=4376</guid>
      <description><![CDATA[Cost is always a concern with customers when it comes to the cloud. I've had a number of...]]></description>
      <content:encoded><![CDATA[Cost is always a concern with customers when it comes to the cloud. I've had a number of conversations with customers lately around how they can take advantage of various offers and benefits on Azure to reduce their costs, and I thought I'd share some of them here as well. There are many things you can do to optimize cost, some of which have some caveats and some which may take more effort than others, but this should give you some ideas of things to consider if you'd like a lower Azure bill (and who doesn't love lower bills). Let's take a look through some of the options available, which type of resources they apply to, and how to leverage them in your environment. Because compute costs are typically the largest driver of costs, much of the focus here is on Azure Virtual Machines.
<h3>Reserved Instances</h3>
We recently announced the general availability of reserved instances on Azure, and this was great to see come to fruition. For VM workloads that are static and predictable in nature, this is a fantastic offer that can save upwards of 70% depending on the VM size. For workloads that are up and running 24x7x365 and are unlikely to change in VM size this certainly an option that should be looked at. Reserved instances are purchased in 1 or 3 year terms, with payment required for the full term up front. Once purchased, we match up the reservation to running instances, and decrement the hours from your reservation. Reservations can be purchased through the Azure Portal and since reserved instances are a compute discount, they are available for both Windows and Linux VMs. For more information take a look at the following documentation.

<a href="https://azure.microsoft.com/en-us/pricing/reserved-vm-instances/">https://azure.microsoft.com/en-us/pricing/reserved-vm-instances/</a>
<a href="https://docs.microsoft.com/en-us/azure/virtual-machines/windows/prepay-reserved-vm-instances">https://docs.microsoft.com/en-us/azure/virtual-machines/windows/prepay-reserved-vm-instances</a>
<h3>Azure Hybrid Benefit</h3>
For customers who have made an investment in Windows Server licenses the Azure Hybrid Benefit gives customers usage rights for Virtual Machines on Azure. When applied to vitrual machines in Azure, you will not be charged for the Windows Server license and will instead be billed at the Linux rate. To be eligible for this benefit, current Windows licenses must be covered by Software Assurance. Each 2-processor license or each set of 16-core licenses are entitled to two instances of up to 8 cores, or one instance of up to 16 cores. The Azure Hybrid Benefit for Standard Edition licenses can only be used once either on-premises or in Azure. Datacenter Edition benefits allow for simultaneous usage both on-premises and in Azure. Most customers are typically licened by core, so you'll use that model for your calculation. If you have questions about what licenses you have, you can reach out to your license reseller or your Microsoft account team to get more information. Applying this benefit is easy, and can be done at deployment time for new VMs and can be enabled or disabled at any time on existing VMs.

We have also announced plans to provide similar capabilities for SQL Server licenses, but have not yet made this fully available. I mention this so that you be on the look out for this availability in the near future.

<a href="https://azure.microsoft.com/en-us/pricing/hybrid-benefit/">https://azure.microsoft.com/en-us/pricing/hybrid-benefit/</a>
<a href="https://docs.microsoft.com/en-us/azure/virtual-machines/windows/hybrid-use-benefit-licensing">https://docs.microsoft.com/en-us/azure/virtual-machines/windows/hybrid-use-benefit-licensing</a>
<h3>Enterprise Dev/Test or PAYG Dev/Test Subscription</h3>
The Enterprise Dev/Test and Pay-As-You-Go Dev/Test offers are a benefit you can take advanatage of to save costs on your non-production environments. This benefit gives you several discounts, most notably for Windows workloads, charging you the Linux rate for virtual machines. This also applies to SQL Server, and any other Microsoft software that is covered under Visual Studio subscription (formerly known as MSDN). There are a few requirements for this benefit, one being that it's only for non-production workloads, and another being that any users of these environments (excluding testers) must be covered under Visual Studio subscription. In short, for non-production workloads, this allows you save money on your Windows, SQL Server and other Microsoft Virtual Machine workloads.

Below are the full details of each offer. If you are a customer on an Enterprise Agreement, you'd leverage the Enterprise Dev/Test offer, and if you a customer without an Enterprise Agreement and are instead using PAYG accounts, you'd leverage the Pay-As-You-Go Dev/Test offer.

<a href="https://azure.microsoft.com/en-us/offers/ms-azr-0148p/">https://azure.microsoft.com/en-us/offers/ms-azr-0148p/</a>
<a href="https://azure.microsoft.com/en-us/offers/ms-azr-0023p/">https://azure.microsoft.com/en-us/offers/ms-azr-0023p/</a>
<h3>SQL Server Developer Edition</h3>
As of April 1, 2016, Microsoft has made SQL Server Developer Edition a free product for non-production use. This is yet another way you can save on Azure costs for your non-production environments. On the Azure Marketplace you can find SQL Server 2016 and SQL Server 2017 images for Developer Edition, which will eliminate the additional cost for SQL Server, and for previevious version you can provision a new Windows VM and download SQL Server Developer Edition from your Visual Studio Subscriber Downloads, provided you have a Visual Studio subscription. For full licensing infomration, take a look at the following links. Bottom line, for non-production workloads that use SQL Server you should look closely at taking advantage of this offer. One side note, there is no way to convert an existing SQL Server VM to another license type, you'll have to provision a new VM and migrate your databases to the new server.

<a href="https://www.microsoft.com/en-us/sql-server/sql-server-2017-pricing">https://www.microsoft.com/en-us/sql-server/sql-server-2017-pricing</a>
<a href="https://download.microsoft.com/download/7/8/C/78CDF005-97C1-4129-926B-CE4A6FE92CF5/SQL_Server_2017_Licensing_guide.pdf">https://download.microsoft.com/download/7/8/C/78CDF005-97C1-4129-926B-CE4A6FE92CF5/SQL_Server_2017_Licensing_guide.pdf</a>
<a href="https://download.microsoft.com/download/B/C/0/BC0B2EA7-D99D-42FB-9439-2C56880CAFF4/SQL_Server_2017_Licensing_Datasheet.pdf">https://download.microsoft.com/download/B/C/0/BC0B2EA7-D99D-42FB-9439-2C56880CAFF4/SQL_Server_2017_Licensing_Datasheet.pdf</a>
<h3>BYOL SQL Server Licenses</h3>
If you are a customer on an Enterprise Agreement and already have an investment in SQL Server licenses and they have freed up as part of moving resources to Azure, you can provision BYOL images off the Azure Marketplace, giving you the ability to take advantage of these unused licenses and reduce your Azure VM cost. You've always been able to do this by provisioning a Windows VM and manually installing SQL Server, but this simplifies the creation process by leveraging Microsoft certified images. Take a look at the following blog post from the initial announcement, and you'll find these marketplace images available for you today to take advantage of.

<a href="https://azure.microsoft.com/en-us/blog/easily-bring-your-sql-server-licenses-to-azure-vms/">https://azure.microsoft.com/en-us/blog/easily-bring-your-sql-server-licenses-to-azure-vms/</a>
<h3>Azure Cost Management (Cloudyn)</h3>
Last year Microsoft purchased Cloudyn and has since rebranded it Azure Cost Management. This is a free service that will anaylyze your Azure workloads and provide recommendations, such as right-sizing VMs and purchasing reserved instances. There's a whole host of features that give you the ability to evaluate, report and budget your Azure costs, so it's a great tool to take a look at to get an idea of where your money is going. For Azure services there is no charge for the service itself, and there is a paid tier if you need support and integration with other cloud providers. Definitely get this set up and leverage it to analyze your spend. Take a look at the following documentation for more details.

<a href="https://azure.microsoft.com/en-us/services/cost-management/">https://azure.microsoft.com/en-us/services/cost-management/</a>
<a href="https://docs.microsoft.com/en-us/azure/cost-management/overview">https://docs.microsoft.com/en-us/azure/cost-management/overview</a>
<h3>Azure Advisor</h3>
Along with Azure Cost Management, Azure Advisor is another service to take a look at to identify areas of inefficiency. Azure Advisor evaluates your environment and provides recommendations on high availability, security, performance and cost. It's a good idea to pay attention to the recommendations as a whole, but specific to cost it will make recommendations around resizing or shutting down unused VMs, identifying where you might be able to take advantage of Azure SQL Elastic Pools, and unutilized ExpressRoute circuits that may be costing you money. Azure Cost Management will give you more details on your compute, but it's still a good practice to check Advisor regularly for all the recommendations it provides.

<a href="https://azure.microsoft.com/en-us/services/advisor/">https://azure.microsoft.com/en-us/services/advisor/</a>
<a href="https://docs.microsoft.com/en-us/azure/advisor/advisor-overview">https://docs.microsoft.com/en-us/azure/advisor/advisor-overview</a>
<h3>Right-Size/Shut Down/Deallocate VMs</h3>
One of the things that Cost Management and Advisor may recommend is right-sizing or shutting down VMs. Changing VM size is easy on Azure, and if you have VMs that typically sit idle, this is a great way you can reduce your costs. Shutting down unused systems is important as well, as often times VMs are created for a test environment or a project that maybe never took off, but nobody went back and cleaned up the environment afterwards. Identifying these systems is important, as they drive up your bill unnecessarily. It's also important to take a look at the usage patterns of your systems. If you have systems that are primarily used during business hours (or another regular time period) you should evaluate if you can shut them down when they are not being used. I've had customers succefully use Azure Automation to run scripts that will stop/start VMs on a schedule. Below are a couple examples of this (both of which are avialble in Azure Automatin), you can use these scripts or modify them as appropriate. Bottom line, it's important to evauluate the size, usage and usage patterns of your VMs to ensure they are as cost effective as possible.

<a href="https://gallery.technet.microsoft.com/scriptcenter/Scheduled-Virtual-Machine-2162ac63">https://gallery.technet.microsoft.com/scriptcenter/Scheduled-Virtual-Machine-2162ac63</a>
<a href="https://gallery.technet.microsoft.com/scriptcenter/ShutdownStart-VMs-by-tag-3f1e9afd">https://gallery.technet.microsoft.com/scriptcenter/ShutdownStart-VMs-by-tag-3f1e9afd</a>
<h3>Use Visual Studio Subscrption (MSDN) Keys</h3>
If you have a Visual Studio subscription (formerly known as MSDN) you do have the ability to use the license keys on Azure Virtual Machines. There are some limitations to this, they can't be used on production systems, other users of these systems must also be covered under the appropriate VS license, and you can't use this benefit for the Windows Server or Windows client VM licenses, but for things like SQL Server this could be another way to reduce your VM costs. You could provision a BYOL image, enter a key from your VS subscription and eliminate the costs for SQL Server for that VM. Take a look through the following documentation for the specific requirements and limitations.

<a href="https://azure.microsoft.com/en-us/pricing/licensing-faq/">https://azure.microsoft.com/en-us/pricing/licensing-faq/</a> (the last FAQ has details on this licensing)
<a href="https://www.visualstudio.com/wp-content/uploads/2017/03/Visual-Studio-2017-Licensing-Whitepaper-March-2017.pdf">https://www.visualstudio.com/wp-content/uploads/2017/03/Visual-Studio-2017-Licensing-Whitepaper-March-2017.pdf</a> (page 14 specifically has more details)
<h3>Migrate to PaaS Services</h3>
Lastly, as you move workloads to the cloud, a natural evolution is to start with IaaS services and them move them to PaaS as appropriate, and in an iterative process. PaaS services typically provide a substantial savings in both resource and operational costs. The challenge is that, depending on the type of service, varying levels of effort will be required to move to these servcies from both a time and resource perspective. You may be able to easily move a SQL Server databse to Azure SQL DB, but it may take substantially more effort to move your multi-tier application to a container or serverless based architecture. It's a good practice to continuously evaluate the architecture of your applications to determine if there are efficiences to be gained through PaaS services. Azure makes it easy to test these out with little risk, giving you the ability to try out new architecture patterns relatively easily. That said, it's typically a longer journey and may not be of immediate help if you're looking for quick wins from a cost savings perspective. The Azure Architecture Center is a great place to get ideas for transforming your application, as well as best practices across a wide array of architectures and Azure services.

<a href="https://docs.microsoft.com/en-us/azure/architecture/">https://docs.microsoft.com/en-us/azure/architecture/</a>
<h3>Wrap Up</h3>
Customers are always looking at how they can shave costs across their IT environments, and as I've detailed here, there's numerous ways you can drive lower costs throughout your Azure environments. There is no one-size-fits-all solution, so you'll need to evaluate your environments and leverage the capabilities that fit. Some are going to provide more benefit than others, and there may be some work to realign resources to take advantage of these, but they're definitely worth looking into further.]]></content:encoded>
    </item>
  </channel>
</rss>