Skip to content

Motivation

Jason R. Shaver edited this page Sep 16, 2016 · 1 revision

Motivation and Frequently Asked Questions

The landscape for developer tooling is constantly evolving, driven by new patterns (NoSQL, REACT) as well as the evolving needs of end-users (mobile apps, SaaS).

With the growth of Linux on Azure and our push to enable any application, regardless of framework and platform, we took a hard look at our Azure XPlat CLI and the experience it provided to customers.

  • Inconsistent with customer expectations
  • Inconsistent with ecosystem
  • Functionality gap with PowerShell

Frequently Asked Questions

Why not update the existing XPlat CLI?

As we talked with customers and gathered feedback, it was quickly obvious that some major changes were going to be required:

  • Output required formatting, especially for automation
  • Difficult to use with other command-line tools (grep, AWK, sort)
  • Difficult to install and update

As a tool used by thousands of customers across the world, we are very sensitive to breaking changes.
Updating the XPlat CLI to resolve these concerns would result in breaking changes to almost every command and function.
By building our CLI as a new product, we are able to provide a roadmap for customers using our Azure XPlat CLI in production, while also building the quality of experience our customers expect.

The Azure XPlat CLI will continue to be our supported command-line tool for managing ASM (classic) resources.

Why is ASM (Classic, RDFE) not supported?

Service management (ASM) and resource management (ARM) are two distinct sets of incompatible APIs. While both are used to manage parts of Azure and they look similar in some cases, combining them into one tool creates more confusion for customers.

With ARM as the future of Azure, and decision to build a new CLI from the ground up, we are keeping the Azure XPlat CLI as the supported tool for managing ASM resources. The Azure CLI 2.0 Preview is built from the ground up with resource management in mind, and we believe it is a better product for it.

Why switch from the Node.js framework to Python?

By building a new CLI, we had a chance to talk with customers and the ecosystem about their scenarios and requirements, and some of the common themes we heard were:

  • Dependency management for Node.js adds maintenance costs for Linux distributions
  • Cloud tooling vendors prefer Python to match AWS CLI and GCloud CLI
  • Python offers a more mature platform for building CLIs
  • Python is typically available on Linux distributions by default

While none of these reasons precluded building the next CLI in Node.js, Python was the natural choice.