An Introduction to Microsoft Azure - Part 1 of 2
Introduction to Azure
Azure is Microsoft’s cloud solution platform, offering a variety of tools and services that allow you to build, deploy and manage applications in Microsoft-managed datacenters.1
So what can you do on this platform?
Build out infrastructure solutions including virtual machines, virtual networks, storage and backup solutions, site recovery, and high-performance computing solutions with large parallel jobs. You can move virtualized servers from your on-premise environment to the cloud or use a combination of both in a hybrid model.
Develop applications for web and mobile and use Azure to help prototype and test those applications.
Work with data by easily spinning up new SQL databases. Additionally, you can use the HDInsight product to process and analyze huge amounts of data.
Manage identity and access through the use of Active Directory or even multi-factor authentication.
And that is not all—the list keeps growing. Azure has grown significantly in the last year with Microsoft making regular product announcements. For example, a new offering now in a preview release offers cloud-based predictive analytics or machine learning2.
Web Development on Azure
As a technology solution provider for marketers and agencies, our projects typically have a database-driven, web-based component. As such, our primary area of interest and experience thus far has been the use of Azure for database-driven web development. Currently, with Azure, there are at least three common ways to handle web development projects:
Azure Cloud Services
If you are experienced in delivering web applications, you most likely host your applications internally or partner with a commodity web hosting provider. The Azure Website model is most like that of a traditional hosting company, but with several distinct advantages. With Azure websites, you are free to use the language of your choice (C#/ASP.NET, PHP, Python, etc.) and the database server of your choice (Microsoft SQL, MySQL, MongoDB, etc.) even within the same hosting plan (see Figure 1).
Figure 1: Selecting the application coding language
And by using the language and database of your choice, that means you can also use the CMS of your choice (Sitefinity, WordPress, Umbraco, etc.).
In fact, Azure has a gallery option that will allow you to create a new website based on a CMS, and it will perform all of the installation for you (see Figure 2)
Figure 2: The gallery makes it easy to install common CMS, blog and forum software.
A key advantage of Azure Websites is that they allow you to scale your applications to meet customer demand. You can set the size and number of Virtual Machines (VMs) on which the site runs, or you can configure auto-scaling so that the application will scale based on CPU usage.3 In Figure 3, you can see how easy it is to change the “instance size” to a larger machine. This is called scaling up since the same virtual machine is used; you are just increasing the resources it has. You can also increase the “instance count” which is called scaling out. This increases the number of copies of that website across multiple servers.
Figure 3: Configuring the scaling options
To deploy code out to an Azure Website, the most familiar way will likely be with standard File Transfer Protocol (FTP). This allows your development team to have easy access to deploy single files or a whole site out to the website. However, Azure Websites provide additional ways to deploy your code to production as well including the following4:
Deploying directly from Visual Studio
Using command line tools and the Azure API
Backing up code and related databases on Azure Websites is easy. The management portal allows for simple setup of daily backups to an Azure storage account (see Figure 4).
Figure 4: Configuring automated backups
Azure Websites come with a free SSL certificate if you are running your site on <yoursite>.azurewebsites.net. If you are using a custom domain instead, adding a custom SSL certificate is easy as well. After purchasing the certificate, simply upload the certificate to the website through the management portal and attach it to the site (see Figure 5).
Figure 5: Configuring SSL Certificates
Another great feature of Azure Websites is site monitoring. Through the management portal, it is easy to get important data about the health of your application over the last hour, 24 hours or 7 days (see Figure 6).
Figure 6: monitoring common data
One relatively new feature of Azure Websites is WebJobs5. WebJobs allow you to run background scripts on demand, continuously or on a schedule. These WebJobs can be in the format of batch files, .exe files, PowerShell files, as well as a few other common types. For example, you might want to have some code running on the server each night at a specific time that sends orders placed on your website to a fulfillment company (see Figure 7). WebJobs provide an easy way to accomplish this.
Figure 7: Creating a new WebJob
As with a typical commodity hosting environment, with Azure Websites you don’t have to worry about setting up servers or handling any of the infrastructure. Microsoft will handle Operating System updates, security patches, etc.
To summarize, Azure Websites are an excellent choice for most website needs on Azure. With simple setup, language selection, robust scaling, automated backups and recurring tasks, and SSL security, Azure Websites should be your first choice when considering building on Azure for the web.
A second option for web development on Azure is the use of Cloud Services. The management portal allows for easy administration of many cloud service features, just like when using Azure Websites. However, with Cloud Services, you have additional control over the machines on which the code is running. With Cloud Services, you can actually remote desktop into the server that is running the website. This can be helpful when debugging applications or quickly changing settings on live. It is important to note that, generally speaking, you don’t want to remote into the servers to make changes. The Azure infrastructure might move the Cloud Service to another server internally and those settings will be lost. All settings that are required for the app to run must be done via configuration files or setup scripts of some type.
Additionally, with Cloud Services you can install items on the server, which cannot be done on Azure Websites. For example, let’s say that your web application requires some other specific software on the server to run. With Azure Websites this is not possible, but with Cloud Services, you can create scripts to install this other software when your code is deployed to the server.
Code deployment works a little differently on Cloud Services too. With Cloud Services, you cannot FTP your files to the website. Instead you can publish the files directly through Visual Studio or using the management portal you can upload the configuration and build files directly. This is a key difference from Azure Websites. Recall with Azure Websites you can easily deploy single files via FTP. For Cloud Services, you need to publish out the entire file collection as a group. And this deployment process through Visual Studio can take 30 minutes or longer depending on the project size.
However, one helpful deployment advantage for Cloud Services is that you have two environments per Cloud Service: staging and production. So when the developer publishes code from Visual Studio, the code can be pushed to the staging instance, which can be loaded in the browser for smoke testing. Then when the testing is complete, you can perform a “swap” from the management portal and exchange staging for live (see Figure 8). If you detect a problem with the code deployment, simply swap again to re-establish the last good site configuration as live once again.
Figure 8: Cloud sites allow you to easily swap code
Note that at the time of this writing, Azure Websites have a similar concept known as “deployment slots” which are currently in preview release.
Another difference between Azure Websites and Cloud Services is that with Cloud Services, you cannot scale up without redeploying the files. From the management portal you can scale out (add more server instances), but you cannot scale up and change the size of the server without redeploying the code.
At the time of this writing, Cloud Services do not offer a way to back up the site files easily, as was the case with Azure Websites. In most cases, however, you will have a copy of your code locally since it must be deployed through Visual Studio in the first place.
With Cloud Services there are no WebJobs available. Instead Cloud Service apps have what are called Worker Roles. Both WebJobs and Worker Roles are similar in that they can be used to run background processes separate from your front-end website. As described above, WebJobs can be simply uploaded and configured easily through the management portal. Worker Roles must be deployed from Visual Studio just like the website code itself. General speaking Worker Roles can handle more intensive applications and can make use of custom software that can be deployed as part of the Cloud Service.
A final similarity between Azure Websites and Cloud Services, is that in both cases, Microsoft will manage all the operating system updates, security patches, etc. You only have to worry about coding your application.
The final way to deploy web applications to Azure is through the use of Azure Virtual Machines. A virtual machine on Azure is very similar to running a virtual machine in your own on premise environment. With Virtual Machines, you have complete control over the server. You may install any software you want or need. But the tradeoff is that you have to completely manage the server including operating system updates, security patches, etc. Virtual Machines require a staff member with much more IT experience than the other two options previously discussed. Another potential downside with Virtual Machines is that you don’t get all of the automatic rich features provided with Azure Websites and Cloud Services. For example, auto scaling, staging and production deployments, and automated backups are all absent from Virtual Machines, unless you set up mechanisms to handle them.
Choosing the Right Solution
Given the three choices for building Web applications on Azure, which is the right choice? The answer, of course, is that it depends on the project requirements6. Microsoft has provided a nice image to summarize some of the features (see Figure 9).
Figure 9: Image taken from http://azure.microsoft.com/en-us/documentation/articles/choose-web-site-cloud-service-vm/
For most basic—or even advanced—web applications that make use of a standard programming language and database, Azure Websites are an ideal option. You don’t have to worry about infrastructure setup and you get a ton of cool features provided out of the box.
If your web project requires custom software on the server, or you need to specify startup tasks that run when the code is deployed, then Cloud Services might be a better way to go. You still don’t have to bother with the infrastructure, but you have more control over the server.
With Virtual Machines, you have ultimate control over the server, but you are required to maintain it. This solution might be ideal if you are moving existing Virtual servers to Azure or if your application requires legacy code not supported in one of the other environments.
Smooth Fusion is a custom web and mobile development company and leading Progress Sitefinity CMS Partner. We create functional, usable, secure, and elegant software while striving to make the process painless for our customers. We offer a set of core services that we’ve adapted and refined for more than 250 clients over our 18 years in business. We’ve completed more than 1800 projects across dozens of industries. To talk to us about your project or review our portfolio, send us a message and one of our project managers will reach out to you quickly.