Sign In

OUR NEWS

Looking for some insight or inspiration?

At Provoke we are fortunate to have some of the world's leading experts in Microsoft technology. Whether you want to know the latest in SharePoint and Office 365, understand the changing world of Unified Communications, or gain insight into the Cloud and Windows Azure, this is where to get it. Our News is the place to find the latest events, blogs and articles from the clever monkeys at Provoke and our partners.

Azure Hosting
Jan 15, 2014

By Christopher Pritchard, Solutions Architect, Provoke Solutions Wellington

​​​​​​​microsoft-azure.jpgI’ve been working at Provoke Solutions for around six years now, first as a web developer but recently as a Solutions Architect. This time period coincidentally covers the entirety of Windows Azure’s life, and as a Microsoft Gold Partner Provoke has always been keenly interested in what it can do for us and our clients. Personally, since I run a number of personal projects as well as produce a significant number of internal prototypes, I have always looked to see how Azure can work for me, and where it might serve as useful for whatever new client project is on the horizon. This post covers some of my recent experiences in that area, specifically around how it has facilitated rapid development.


As a company, we have developed a number of projects that leverage the platform, generally using Azure Web Sites or Web Roles to service content. It can be nice - a breath of fresh air in the murky world of web development - to be in a position where we don’t need to worry about setting up servers, provisioning databases, speculating as to the total space needed and so on. Azure and ‘Cloud Services’ in general are always marketed around their benefits for scaling, particularly around how in the cloud you can scale down far more easily than you can with physical hardware, but personally the ease with which you can scale up in the first place has been the best benefit to me. No need to go through the cost of buying machines, spending time (sometimes weeks) installing software and negotiating accessibility, putting together invoices for clients towards hosting costs or management; with Azure I am finding the simplicity of providing a monthly bill, or even dealing direct with a client’s Azure account, makes a number of conversations easier, not to mention the sheer beauty of going from nothing to fully functioning machines ready for hosting in less than ten minutes.


Two recent projects come to mind. Provoke is engaged in a number of charity efforts, and generally these projects have a number of characteristics that make them somewhat difficult to develop in comparison to our standard body of work. We work on them on a volunteer basis, they have limited resources assigned to them, and are typically very time-sensitive. For example, a week or so ago Provoke released a site supporting the Philippine's Typhoon disaster relief effort, www.helpthephilippines.co.nz, which went from 'decision' to 'hosted and usable' within a few days. Another example was www.ccfxmas.co.nz, a site that gathers funds to provide Christmas gifts and support to children with cancer – there was a limited budget, and despite integration with credit card processing and other complicated sub-systems this needed to be built, tested and announced via the charity marketing in less than a month. In such scenarios negotiating hardware and trying to speculate on the expected bandwidth or usage requirements can easily make a project unfeasible for the timeframe – by leveraging Azure we were able to sidestep these issues and succeed on time.


While Azure provides a number of services, providing nearly the entire requirements of enterprise-level infrastructure from Virtual Machines to Active Directory, there are a few services in particular which were of aid to me in the above projects: specifically, Azure Websites and Azure SQL Server. I’ll go into both in a little more detail, how in particular we got set up on them.


Azure Websites

Azure has two options for serving up a web server as a service: a light-ish version in the form of Azure Websites and a more multi-purpose, enterprise-scale option in Cloud Services (which used to be divided explicitly into Web Roles and Worker Roles, but now serves as the host for both). Websites are basically just Internet Information Services (Microsoft’s web server product) as a service – it fully supports having multiple instances, scaling up the number of processors and memory, assigning domain names and so on. I found it more than adequate for my purposes, and both the site URLs listed earlier along with a number of my personal projects are presently running on Azure Websites.


The process for getting a site up is simple:


1. First, creating a new Azure Website instance on an account is pretty straight-forward. After selecting it from the list of creation options, you need only specify a unique name (which ends up translated to the default URL http://<name>.azurewebsites.com), the region it should be hosted in and against what subscription. This will set up a site in short order with the Azure Welcome Page placed in its root directory, allowing you to immediately test the connection.


2. Next, from the site’s dash board, you can download the publishing settings as an XML file. Intended to be consumed by Visual Studio, inside this file you can find the FTP URL, Username and Password should you wish to connect to the server directly. It also contains the web deploy settings, which are what by default Visual Studio uses when it does its publishing.


3. Speaking of, once you open your project in visual studio (which needs not be a special site of any kind – any ASP.NET project will do), you access ‘publish’ from the project context menu. After selecting ‘import publishing settings’ and selecting the XML file from the previous step, clicking through to the end of the publishing wizard will push up your site and it should be visible in less than five minutes.


It’s as simple as that.


By default sites are in ‘free’ mode. While nice, this prevents scaling up the server count or assigning a vanity domain to the site. However, shifting from free to shared or higher (all of which are more expensive) is simple, and can be reversed as needed. Once you have shifted off free, assigning a new domain (or several domains) to your Azure site involves binding the domain through the domain provider to the site’s virtual IP address (which is provided on the dashboard), then adding an entry on the dashboard to allow requests to that domain through Azure’s firewall. Assuming Azure can verify that the domain exists and is correctly bound, you will be all done and your domain should be usable within minutes, depending on the global DNS table update schedule. I found the whole process very painless.


Azure SQL Server

Azure SQL Server is almost identical to the commercial SQL Server product – only drastically less expensive to buy and far easier to setup. It is literally as simple as the earlier steps for configuring a web site, except that instead of downloading the publishing details you copy the appropriate connection string for your client from the dashboard list (e.g. SQL Client for ASP.NET Entity Framework), and use that in your connecting software. Furthermore, except for systems hosted in Azure (like another Website), you need to find your local internet IP address, i.e. from a service like www.whatismyip.com, and add it to the Azure SQL Server dashboard which has a section around allowed IP addresses. This step is for security purposes, but once done you can connect to your Azure databases using SQL Server Management Studio and run queries just as if you were connecting locally.


For www.ccfxmas.co.nz, we used a database accessed via Microsoft Entity Framework 5, which generates its database schema on first load – this performed perfectly via the Azure SQL database, and in fact, while we developed the site on locally hosted web sites for ease of debugging, an Azure SQL database was used for storage from the very beginning.


There are some limitations. Azure SQL Server has a lower maximum size than what an on-premise database is capable of, starting at 1GB by default and scaling up at various price bands to (at the time of writing) 150GB. Unlike on-premise databases however, in Azure you are charged per the actual storage used (in your database scaling band) rather than for the total available.


Of course, should Azure SQL Server not be appropriate, an Azure VM running SQL Server could always be used instead.


In Summary

Overall, if you want to have a rapid development model, where you can get content out publically visible as soon as possible (which proves truly excellent for cross-device testing or client engagement), with a billing model that is easy to understand and easier to manage, then Cloud is an excellent choice and especially Azure in particular. Windows Azure is broad, comes with a whole host of functionality beyond the specifics I went over above, and is truly approaching the point where entire IT infrastructure can be run through it. You don’t have to be bound to the Microsoft stack of technologies either, if you don’t want to: While I am a .NET developer, one of my personal projects is a Node.JS web server I happily run from Azure, and it supports a number of Linux distros or PHP and Ruby servers as well, amongst other things.


I would recommend anyone go take a look and try it. Provoke supports, alongside developer/architects like myself who have Azure experience, a number of Azure Certified V-TSPs (Virtual Technology Specialists), and we’re willing to have a chat with any client who is interested in this space.

 ARTICLES