The Azure IaaS Virtual Machine is in Beta and anyone can request access.
For those have worked with Azure VMs in the past (Web, Worker, and VM Role) this is simply an addition, a new option.
There are some interesting contrasts, parallels, and dependencies when we consider both the PaaS and IaaS options (MSFT likes to draw the contrast that way, but fundamentally they are still machines what you can do and need to know is different).
MSFT already has lots of documents out there on the IaaS stuff. I don’t intend to regurgitate what they have already documented. They stuff they have not documented is far more interesting.
And there is a gallery of OS images that you can build machine from using the GUI portal. And you can create and upload your own VHD images (a bit like VM Role).
In my next post I will begin exploring the PowerShell that is available to drive this stuff from the ground, that is a bit more interesting (at least to me).
First of all, what is the Virtual Machine? If it isn’t a Web, Worker, or VM Role; what is it.
It is a bit like a VM Role, but without any agents to interact with the Azure Fabric, and the storage supports persistence. Beyond persistence, it is just a machine. Mind you, the way I state this it does not sound like much, but it took a lot for MSFT to work through extrapolating the PaaS provisioning and storage into supporting this. There is a lot there. Just go look up the TechEd talks.
Now, we all know that MSFT al about platforms, so the Virtual Machine by itself is just as uninteresting as it sounds. Add in Virtual Networks and it gets a bit more interesting.
Virtual Networks allow defining of address allocation spaces. And those can be divided into subnets. If you know the SCVMM IP Pool model, it is similar to that with some implementation differences.
A Virtual Network is also a container or a boundary. All machines within a Virtual Network can freely communicate with each other over the network. No matter the IP that was allocated to the VM, no IP subnet isolation. A Virtual Network can also span services – provided they are in the same Affinity group and Region. It all links.
A Virtual Network also supports the Gateway. The Gateway is a way to ling the Virtual Network defined in Azure with an SSL VPN endpoint on the ground, in your enterprise. This is just like any point-to-point VPN that you have used to connect branch offices, or to another business. Before this we only had Azure Connect and its support for IPv6 and that it only acted as a machine to machine forwarder, fundamentally different.
One other concept is the VHD. There are two types. Image and OS.
An Image can be provisioned into multiple VMs and is prepared so that Azure can customize it. The Windows OS is prepared with sysprep, and the Linux OS is prepared with the Azure Linux Agent deprovision command. The concept is the same.
When a new VM is created from an image it can and will be customized. And, the Fabric also automatically creates a management endpoint (SSH or RDP).
An OS can be used by one Virtual Machine. It is not provisioned, and therefore not customized. It is just created an powered on. You have to define everything, but it allows you to bring your own, pre-configured machine into Azure (without building it in space).
In the next few posts we will get a bit more into this and specifically driving it all with PowerShell.
The last concept is the Services. IaaS Virtual Machines still run within a Service just like PaaS VMs. But the two shall not mix.
You can create a Service without a deployment, this is androgynous, lacking either PaaS or IaaS gender. As soon as the deployment is defined the service becomes either IaaS (meaning that it can run Virtual Machines) or PaaS (meaning that it can run VMs (or Roles)). Thus the entire Service becomes stateless or persistent.
The two can interact over the network, but not through Azure Fabric Services.
I think that in the next post I am going to dive straight into the PowerShell.
No comments:
Post a Comment