Automating Microsoft Azure Infrastructure Services

Chapter 1. Introduction

The Microsoft Azure PowerShell cmdlets are one of the primary tools in use today for automating Microsoft Azure from the Windows platform. The cmdlets take the native automation capabilities of PowerShell and add in the ability to provision compute and other services on the fly in Microsoft Azure. This mix of technical capabilities has truly opened the doors to cloud automation in Microsoft Azure, providing the ability to deploy solutions that are both complex and at scale.

Why Use the Microsoft Azure PowerShell Cmdlets?

Prior to the dawn of cloud computing, deploying a new application was a fairly involved task. First, you had to order servers, wait for them to ship, unpack them from their boxes, set up the network, install an operating system, patch the operating system, and finally install software and configure your application. I am purposely glossing over the “organizational agility” needed to accomplish this if you were responsible for the application but another group was responsible for the infrastructure.

Thanks to cloud providers such as Microsoft and Amazon, you as the lucky individual living in the cloud-computing era can now skip many of these steps and focus on managing your application or infrastructure at a much higher level. The cloud removes the responsibility from you to manage hardware resources directly. Now it can be as easy as clicking through a web page-based wizard to provision numerous virtual machines and then logging in to deploy and configure your application. This is definitely a huge improvement in infrastructure and application management.

However, the cloud does more than give you the ability to spin up virtual machines from a web page. It also gives you the ability to treat virtual machines and other services as programmable resources. To show why this is important, I want to compare deploying the same application using three different techniques.

Comparing Deployment Methods

Deploying an Application in a Traditional Data Center

1. Order server and networking hardware.
2. Wait for hardware to ship.
3. Install and configure networking hardware.
4. Install and configure server hardware (apply firmware updates as needed).
5. Install a base operating system on the server hardware.
6. Patch the base operating system.
7. Install software applications and roles.
8. Deploy applications.
9. Repeat steps 3 through 8 (and likely steps 1 and 2, depending on how accurate the initial planning was) for staging, development, and testing environments.

Deploying an Application in the Cloud (Without Automation)

1. Launch the management portal.
2. Create and configure each virtual machine.
3. Patch the base operating system.
4. Install software applications and roles.
5. Deploy applications.
6. Repeat steps 2 through 5 for staging, development, and testing environments.

Deploying an Application in the Cloud (with Automation)

1. Identify repeatable processes.
2. Create automation configuration and scripts for step 1.
3. Deploy scripts for application.
4. Repeat step 3 for staging, development, and testing environments.

Comparing the methods, you can see that with the cloud, your return on investment with automation is measured in agility. If your organization can benefit from an agile approach to infrastructure deployment and management, where you can quickly spin up and tear down computing envionments, then you are probably reading the right book.

History

The Microsoft Azure PowerShell cmdlets started as two distinct projects. The first was an official product created by one of the engineering teams to create a set of scaffolding cmdlets that allowed Windows users to create Node.js applications that could run as a Microsoft Azure cloud service. The second set of cmdlets were created over the years by various technical evangelists (including myself) in the Microsoft Developer and Platform Evangelism (DPE) team.

The cmdlets built by the evangelism team at first covered only the basics of creating and deploying cloud services and were built specifically for two purposes:

• Automate the creation and deployment of demos for evangelism efforts
• Serve as source code samples to demonstrate the Microsoft Azure Service Management API

When I joined the Microsoft Azure evangelism team, one of the projects I took over was the PowerShell cmdlets. Working with a few solid developers, we started slowly adding new functionality as time and budget permitted. I came from a background of troubleshooting and debugging, so one of the very first areas we improved was the diagnostics cmdlets for cloud services (sadly, these did not see the light in the official release). After diagnostics, we added support for SQL Database (known as SQL Azure at the time), then Traffic Manager, and finally the last major work in evangelism was the cmdlets for Microsoft Azure Infrastructure Services.

With the eminent launch of Microsoft Azure Infrastructure Services, the engineering team became very interested in the cmdlets and worked very closely with us on identifying the capabilities and answering questions that came up during development. When the initial cmdlets were complete, the integration work with the engineering team that owned the Node.js cmdlets merged what was a code sample and a set of cmdlets built for developers into what would be the first release of the Microsoft Azure PowerShell cmdlets.

A year after the intial launch of the cmdlets, I joined the Microsoft Azure runtime team as a senior program manager and worked with some amazing developers and testers to add much more functionality to the original cmdlets that I helped initially build. In addition to this core team that handled virtual machines, cloud services, and the core Service Management API, Microsoft now has several teams for various services. These teams are focused on making a great automation experience for Microsoft Azure via PowerShell as well as command-line tools that run natively on Mac and Linux. The cmdlets have grown at such a rapid pace that this book is focused only on the subset related directly to infrastructure services.

Open Source

Like most of the SDKs and tools for Microsoft Azure, the PowerShell cmdlets are completely open source and licensed under the Apache 2.0 license. The source is hosted in a GitHub repository located at https://github.com/Azure/azure-sdk-tools. Feel free to fork or clone the repository, file bugs, or even submit changes back to the cmdlets. If you would like to contribute, there is a page that describes the agreements needed that I would highly recommend as your first step: http://azure.github.io/guidelines.

Summary

Now that you know why automation in the cloud is important and have a little background on how the Microsoft Azure PowerShell cmdlets came to life, let’s dive right in. The only thing you will need going forward is a Microsoft Azure account.