Recently, I have been getting more familiar with Azure. It’s good. Since it’s initial launch way back in 2010, Azure has been maturing and has become a leading contender for businesses seeking to take advantage of Cloud technologies. Whilst Azure was later to market than it’s competitors, this has allowed it to be more forward thinking and to direct itself more towards the service aspects of Cloud, rather than just a new home for old servers and apps.

My initial impression, which is formed not only from experience but by the Azure documentation, is that it is targeted at cloud native applications, an environment for companies to build new apps in and for the cloud. This makes sense. Whilst it is entirely possible and valid to lift and shift your existing business processes, as embodied in the applications a business uses, into the cloud, it is certainly not the same as developing new cloud native apps.

Typically, large companies will have a mixture of bought and internally developed apps. In almost all cases, these applications were designed for a client-server or standalone on-premise environment, with connectivity “out” to the world. Moving those apps to the cloud is a task not to be underestimated, from recent experience. It would be a little bit like taking old fashioned analogue telephone handsets and installing them on the space station.

The trade-off for a business is how much cost is involved in the migration as opposed to re-development whilst at the same time delivering an overall cost saving by migrating to the cloud.

One final comment is that Azure is, in practice, a server only environment. Client’s are not “allowed”. As far as I can tell without wishing to delve into the mysteries of Microsoft licensing, virtualising Windows 7 or 8 is forbidden under nearly all license agreement types. There is no technical reason I know of that it would not work but I’m fairly sure Microsoft are intending to stop that particular use case, which is a bugbear if you are using Azure as a lab environment.