Click here to Skip to main content
65,938 articles
CodeProject is changing. Read more.
Articles / Hosted-services / Azure

Azure Series - Part 1A Azure Websites

2.17/5 (3 votes)
24 Mar 2015CPOL7 min read 6.5K  
Azure Series - Part 1A Azure Websites

So in the last blog post, I reviewed how to create a Azure Website, and the steps involved which is useful, but there are probably some lingering questions at this point. Namely, what are all these menu tabs across the top; and why am I creating a site to begin with.  

The biggest benefit to using Azure Websites is not only the amount of time saved, which was discussed in the last post but additionally includes the overall cost and the maintainability associated with the platform. A quick tour around the Azure pricing calculator (found here), shows what I'm talking about with basic monthly costs. But the real savings come in maintenance, when you create a Virtual Machine, you need to coordinate the backups that are required, as well as patching the OS, maintaining up time, and setting up load balancing.

With Azure Websites, all that does not become your problem. And with Azure Websites, you are letting Microsoft handle and manage that. Rather than having direct access to the VM, instead Microsoft lets you have access to the site and the ability to make any changes you want within. But they take over management of the VM it sits on. This also gives them the ability to move your site from one VM to another to manage up-time and make sure that standard maintenance doesn't cause any service interruptions.

Think about that from a small business perspective, if you only had to pay a developer to build a web application, and configure the website. And then monitoring it would be infinitely cheaper than paying an administration to monitor and do maintenance on the server.

So the real question is what all can you do to configure an Azure Website and exactly how flexible is the platform and the answer is "EXTREMELY". So I want to take a moment to go through the screens available.

Dashboard Menu

First the "Dashboard" menu, this menu serves as the start screen for Azure Websites, and displays a variety of statistics which can be used for monitoring of the application. This includes statistics like the following:

  • CPU Time
  • Data Out
  • File System Storage
  • Memory Usage

This is not a replacement for information from analytics or metrics like Google Analytics, but allows you to keep an eye on the statistics that directly affect the overall health of your application. If you are seeing high CPU time, or Memory Usage, then you are likely to want to consider standing up multiple instances (more on that later).

This menu also allows for the creation of "Deployment Slots" which are one of the most attractive features of Azure Websites. Deployment slots allow you as the developer to push a new deployment to a location where you can perform any kind of testing you want to ensure that your releases work properly. And when you are ready, you simply click a "Swap" button to exchange the current site for the new site. This allows for significantly more freedom, and the ability to ensure the quality of your deployments before you push them out there for production.

You can also perform the following actions from the dashboard:

  • Download a Publishing Profile  
  • View Connection Strings
  • Setup Deployment from Source Control

In short, this allows for several options for configuration of your site. But this is only the tip of the iceberg.

Monitor Menu

The next tab is the monitor, which shows a chart form of the statistics above. This is a chance to view the data in a graphical form, which also allows you to see when your application is being hit the hardest, and when your peak times are. This kind of information can be useful when determining how you scale your application.

This shows you more statistics like:

  • CPU Time
  • Data In
  • Data Out
  • HTTP Server Errors
  • Requests

This allows for a more complete look at the application health. Additionally, though I would still advise the use of Google Analytics, to provide the most complete picture, as well as internal logging within your application.

Web Jobs Menu

This menu provides the developer with the ability to configure and create Web Jobs. These web jobs serve the purpose of batch services, windows, services or scheduled processes within your Azure Website application. It's important to note that one of the biggest strengths of Azure Websites is that you don't have to manage the underlying VM. But that can also be one of the biggest drawbacks. Because of this, your access to the underlying VM is minimal, meaning if you have batch processes you would like to execute, they will require the use of Web Jobs. This is where you create and configure your web jobs to deploy them from Visual Studio.

Configure Menu

This is one of the most important menus in an Azure Website, this is where you setup and configure your application. This is where you make changes like setting connection string, uploading SSL certificates, configure domains, etc. But this is where you have the most control over the environment.

The options available to configure for your Azure Web Application are as given below:

  • .NET Version
  • PHP Version
  • Java Version
  • Python Version
  • Managed Pipeline
  • Platform (32 / 64 bit)
  • Web Sockets
  • Always On
  • Certificates
  • Domain Names
  • SSL Bindings
  • Authentication / Authorization
  • Application Logging 
  • Site Logging
  • Performance Monitors
  • Application Settings
  • Connection Strings
  • Handlers
  • Virtual Directories

That's a lot of options, and definitely gives you a granular level of control. All of this allows you to either go in and tune your application to work at its peak or work with a basic rollout configuration.

One thing to note is that there are more options here than just Microsoft technologies. This is because over the past year, Microsoft has made a definite effort to go Cross Platform with their offerings. Including supporting PHP, Java, and Python applications in Platform as a Service, and additionally support the idea of Virtual Machines that use operating systems other than Windows / Windows Server.

Scale Menu

This menu is where we really look at one of the strengths of Azure Platform as a Service. Earlier, we talked about how if your application is getting tested as far as load, and requires additional resources. One of the most common ways to handle that is to implement another server setup for load balancing. Now in Infrastructure as a service, this would require a new VM, networked to the first and configured to allow load balancing.

Azure Platform as a service takes this multi-hour process down to a much simpler level. In Azure Websites, at this point, you can simply go in and increase the number of instances by 1. By adding another instance, you are adding another VM to support your website. It really is that simple.

But they make it even easier (I know right), you have the option of setting rules. Such as if your CPU usage rises above a certain point,, you can have Azure automatically stand up another instance to support the new demand. Additionally, you can set rules on the other end that if your demand on the CPU drops below a certain level, Azure will automatically spin down an instance. If you are using a pay as you go plan, it means that you can truly make sure that you only use what you actually need and then actually pay for it. Minimizing overall costs!

Linked Resources

Azure allows you to link resources together, allowing for ease of management. For example, you might have a database, mobile services, service bus, etc. This makes these resources easily grouped together so you don't have to search for them.

Backups

By default, Azure provides many backup options free of charge to support your website. But if you require additionally backups, then the application can be configured to do that. Backups are usually stored in Azure Blob storage.

Final Thoughts

In short, Azure offers a lot of options to you as the user. It is important to note that with all these options available, there are some drawbacks. Like for example, because you don't have access to the underlying VM, you can't use its built in SMTP server features. Instead, you have to rely on external services (like SendGrid) to send emails. But that being said, the options available make this a very attractive option for not just web sites, but Web API, and other web based services. The idea being that you can quickly and cheaply provide full support for your web applications within Azure.

License

This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)