Rethinking IT, Part 2: Azure, Automated and Cloud-Ready
This time, we look at automation, cloud and mobile services and a few other things that will have IT pros redefining the roles they play in the organization.
Microsoft Azure won't completely redefine the role of IT, but the changes are coming incrementally. That's true not just of the nature of working with Azure, but working with any cloud solution these days. With Azure, IT pros will still find some familiar administration processes that are familiar even as those processes are moved from on-premise environments to the cloud.
In this second of three articles, we look at PowerShell, Azure Automation, Cloud Services, Mobile Services, Diagnostics, Virtual Networks, Express Route, Traffic Manager and SQL Server / Service.
(To read part 1, go here.)
The key to successful cloud implementations (private, hybrid or public) is automation and given the PowerShell "high" Microsoft has been on since 2006, it should come as no surprise that every aspect of your Azure resources can be controlled from the command line. There are a few steps to set this up. First, head to the Downloads page on Azure and click the Install link which will launch the Web Platform installer that lists all the items you need.
There are two ways to authenticate to your Azure subscription, either with a certificate or a login via Azure AD. The former is suitable for long-running automation jobs, as it'll always work (as long as the certificate is valid) but harder to share among several administrators, whereas the latter is easier to get started with, but the credentials provided expire after 12 hours, requiring logging in again. More details here.
If you have multiple subscriptions under one account make sure you use Select-AzureSubscription to set the correct one that you want to work with. You can also set a default subscription using the cmdlet in Fig. 1.
[Click on image for larger view.]
Figure 1. PowerShell provides powerful automation and scripting capabilities when interacting with Azure.
If PowerShell isn't your thing there's also a Cross-Platform Command-Line Interface (xplat-cli) that's open source (Apache 2.0 license), built on Node.js. For more information see here.
Recently announced in preview, this service builds on Service Management Automation (SMA) in System Center 2012 R2 and lets you build runbooks and workflows to manage your resources in Azure.
If you have developers that write code to run on Azure (using any number of languages), you will then use Cloud Services to run it -- the client-facing side on Web Role VMs and the backend processing on Worker Role VMs.
Each role can have one or several instances as defined in the cloud service configuration file (.csdef) which defines the service model for the application. The cloud service configuration file (.cscfg) specifies configuration settings for the cloud service and its individual roles, including the number of role instances. The service package (.cspkg) contains the actual application code along with the service definition file.
Each cloud service comes with a staging and a production slot and once you have updated your app, and tested it sufficiently when accessed through the testing URL, the process of upgrading the production code is simply a VIP (Virtual IP) address swap. If anything go wrong you can simply swap back to the previous version.
[Click on image for larger view.]
Figure 2. While Microsoft clearly would prefer if you used Windows 8 and Phone 8 for your apps, they provide a first class experience for building apps and their backend for all the other platforms.
Perhaps one of the hardest things to come to terms with as an IT pro is losing control. After all when it's your own infrastructure you have total control (and responsibility), whereas in a public cloud, some or even a lot of that control is taken away. One such area is diagnostics, the places to look when things go wrong.
Azure offers the umbrella of Windows Azure Diagnostics, WAD (is that going to be MAD, now that it's Microsoft Azure?); which can collect data from IIS logs on a Web Role, Windows event logs, Performance counters, crash dumps and Azure logs. It's best to set up a separate storage account to store incoming log data.
If you are already using System Center Operations Manager for your monitoring, you can import the Azure Management Pack and thus monitor your resources in the cloud; there's also a Management Pack for AWS.
By default all VMs or Web/Worker roles within a Cloud Service can communicate with each other, but by adding a Virtual Network they can communicate across Cloud Services. Moreover a Virtual Network can be used to extend your on-premises network to Azure through a secure link between the two.
There are two flavors of this: point to site, which links a single machine to your Azure network (using SSTP), suitable for testing and development work; and site to site (S2S). The latter is useful when you want a permanent VPN link between your datacenter and Azure.
A couple of things to keep in mind is that each Virtual Network can only have one S2S link so you'll need to plan your Virtual Networks and VMs/Cloud Services accordingly, you'll also need to define DNS servers for this hybrid scenario (see Fig. 3). If you want VMs in the cloud to be able to participate in your network you'll need to point them to your on-premises DNS servers. The built in DNS that Azure offers only supports name resolution and not SRV records for AD connections.
[Click on image for larger view.]
Figure 3. Creating a Virtual Network and setting up a link to your datacenter is only a few steps in a wizard.
A multitude of VPN devices are supported for S2S, including Routing and Remote Access in Windows Server 2012; there are configuration scripts available for download from the link above.
For unlisted VPN devices, it's generally not hard to figure out the right settings based on the configuration scripts. The tunnel is either an IKE v1 (static routing) or IKE v2 (dynamic routing) and like any infrastructure-altering project, planning is required. Microsoft provides guidance through several articles and this excellent blog post. The main issue to take into account is latency. Within a datacenter it's generally within a few milliseconds, whereas the roundtrip to an Azure datacenter could be in the order of 50 milliseconds or (much) more. Until recently there was no way around this issue but a new preview feature (February 2014) called Express Route promises hybrid cloud nirvana.
This feature is currently in preview and provides security (as it doesn't go over the public Internet), predictable performance (very low latency) with high throughput and comes in two flavors. You can either connect via an Ethernet exchange (max 10 Gbps) or use a WAN provider's MPLS network (max 1 Gbps) to connect Azure as a "branch office" in your network. Current providers for the Ethernet connectivity are Level 3 and Equinix and for the WAN option AT&T and Level 3.
During the preview period there are only two connectivity points (Washington D.C. and Silicon Valley, CA). It uses BGP for routing and there are two dedicated circuits, one for accessing Virtual Networks in Azure and one for connecting to Azure services that are accessed through public IP addresses. Properly configured the service will mean that no Azure-related traffic will be routed through your Internet connection (where you generally pay for download amounts).
Cost for a 1 Gbps Ethernet connection with 15 TB included egress traffic (uploading to Azure is always free) is $600 per month, and a 10 Gbps Ethernet connection with 250 TB included traffic is $10,000 per month. For more information see this talk from Build 2014; at the time of this writing, general availability was expected in May 2014.
This service lets you set up a Website or a Cloud Service in a U.S. region, a European region and an Asian region for instance (with the same content). Traffic Manager will then direct traffic to the nearest datacenter based on the client's location.
You can choose between three different load-balancing methods: Performance, Round Robin or Failover. The latter two are useful if you're load balancing between services in the same datacenter. Note that data doesn't actually flow through Traffic Manager; rather, that's the role of the DNS redirection feature. There's also a simple health probe built in that'll check if a web site is down for instance and transparently redirect traffic to another site if it is.
SQL Server versus Azure SQL
Many services and apps require database support. Similar to the choice you have between Web Sites and Web Cloud Service roles, you can either stand up IaaS VMs with SQL Server preinstalled or use Azure SQL as service. The IaaS approach works well if you need full access to all capabilities of SQL server and have the necessary DBA skills in-house. On the other hand you could select the SQL database service which relieves you of the responsibility for patching the OS or managing the SQL server itself.
There are some limitations as to features that are supported as well as size limitations with the service. The Web Edition database can be a maximum of 5 GB, whereas the Business Edition can grow to 150 GB per database. You can have 150 databases per server (although this can be increased to 500 with a call to support).
An area where Microsoft shines is the linking of their on-premises products to the cloud services. As an example you can use SQL 2012 SP1 CU2 or later to easily set up Azure as destination for a SQL Server native backup which is then triple replicated in the destination datacenter (default for all Azure-stored data) as well as (optionally) geo replicate that data to another datacenter.
We've covered quite a bit of ground this time out. Next time, I'll dive into Storage, HDInsight, Azure Backup, Recovery Manager, Media Services, Azure Active Directory, Service Bus, BizTalk Services and the new portal.