Many developers favor IaaS-based solutions due to the flexibility they provide over the simpler, yet traditionally more limited management surface of a PaaS platform. That said, there's no reason why a great IaaS platform couldn't allow the user to progressively increase their management complexity only as needed, and until then, support managing VMs as if they were a simple, atomic unit, as opposed to a taxonomy of individual yet collaborative resources (e.g. NIC, VNet/Subnet, NSG, public IP, availability set, resource group). If the underlying infrastructure remained flexible, yet the Azure CLI provided a VM-centric view for simplicity, we could help ease developers into Azure (further supporting the goal of "IaaS++"), while providing them with a smooth transition to greater control as their app's mature.
The following illustrates a straw man experience for getting started with Azure VMs, with the goal of simplifying the overall E2E, and reducing the amount of friction and concepts needed to onboard to IaaS with Azure (e.g. NICs, NSGs, VNets). Much of the work needed to get here is tracked on GitHub (and discussed further in Appendix A), but requires lots of design discussions and clarity.
In the following examples, stdout is used to illustrate some of the side-effects that each command has, which also helps speak to the enhancements being proposed. The actual text used is by no means meant to be representative of what we might actually display.
North Star (Single Node.js VM):
$ az vm create -n todo --image NodeLTS
[Info] Creating resource group: todo-group
[Info] Setting default resource group: todo-group
[Info] Creating availability set: todo-as
$ az vm scp ./app app
[Info] Copying the contents of "./app" to "~/home/joncart"
$ az vm open-port -p 80
[Info] Configuring NSG to allow inbound traffic on port 80
$ az vm ssh "node index.js"
[Info] Connecting to VM: todo
[Logs] App is listening on port 80...
Appendix A: How do we get here?
Allow auto-creating a resource group as part of VM creation, which is located in a default datacenter
Allow setting a default resource group, so that subsequent commands can omit it entirely.
Allow provisioning VMs from all marketplace images (e.g. all Bitnami images), which prevents many scenarios from needing to provision a base VM (e.g. UbuntuLTS) and then immediately install very commonly needed software (e.g. Node.js)
Provide a VM alias for provisioning machines based on the latest LTS version of Node.js, which alleviates the need to lookup the full URN (e.g. bitnami:nodejs:4-3:latest) and/or creating a base Ubuntu machine that you then manually install Node.js on.
Allow auto-creating an availability set if one is specified, that doesn't already exist, in order to maintain the abstraction of the vm create command managing an atomic unit
Allow setting a default VM/VMSS name (possibly inferred from a config file in a project's repo?), so that subsequent commands can omit it entirely.
Allow exposing extra ports at VM creation time, which has the effect of configuring the auto-created NSG, and preventing users from needing to manually manage it
Add support to the existing vm open-port command to allow opening a specific port, which can be used as a short-cut for the az network nsg rule create command, and prevents the user from needing to "manually" manage the NSG
Provide a "shortcut" command that allows SSHing into, and SCPing files to a VM by name as well as SCPing, without needing to lookup it's public IP and/or admin username first
Many developers favor IaaS-based solutions due to the flexibility they provide over the simpler, yet traditionally more limited management surface of a PaaS platform. That said, there's no reason why a great IaaS platform couldn't allow the user to progressively increase their management complexity only as needed, and until then, support managing VMs as if they were a simple, atomic unit, as opposed to a taxonomy of individual yet collaborative resources (e.g. NIC, VNet/Subnet, NSG, public IP, availability set, resource group). If the underlying infrastructure remained flexible, yet the Azure CLI provided a VM-centric view for simplicity, we could help ease developers into Azure (further supporting the goal of "IaaS++"), while providing them with a smooth transition to greater control as their app's mature.
The following illustrates a straw man experience for getting started with Azure VMs, with the goal of simplifying the overall E2E, and reducing the amount of friction and concepts needed to onboard to IaaS with Azure (e.g. NICs, NSGs, VNets). Much of the work needed to get here is tracked on GitHub (and discussed further in Appendix A), but requires lots of design discussions and clarity.
North Star (Single Node.js VM):
Appendix A: How do we get here?
Allow auto-creating a resource group as part of VM creation, which is located in a default datacenter
Allow setting a default resource group, so that subsequent commands can omit it entirely.
Allow provisioning VMs from all marketplace images (e.g. all Bitnami images), which prevents many scenarios from needing to provision a base VM (e.g.
UbuntuLTS) and then immediately install very commonly needed software (e.g. Node.js)Provide a VM alias for provisioning machines based on the latest LTS version of Node.js, which alleviates the need to lookup the full URN (e.g.
bitnami:nodejs:4-3:latest) and/or creating a base Ubuntu machine that you then manually install Node.js on.Allow auto-creating an availability set if one is specified, that doesn't already exist, in order to maintain the abstraction of the
vm createcommand managing an atomic unitAllow setting a default VM/VMSS name (possibly inferred from a config file in a project's repo?), so that subsequent commands can omit it entirely.
Allow exposing extra ports at VM creation time, which has the effect of configuring the auto-created NSG, and preventing users from needing to manually manage it
Add support to the existing
vm open-portcommand to allow opening a specific port, which can be used as a short-cut for theaz network nsg rule createcommand, and prevents the user from needing to "manually" manage the NSGProvide a "shortcut" command that allows SSHing into, and SCPing files to a VM by name as well as SCPing, without needing to lookup it's public IP and/or admin username first