Introduction

Microsoft Azure is a comprehensive set of building blocks that can used as standalone or mixed services to get complex systems and services. Infrastructure-as-a-Service blocks, as virtual machines and/or virtual networks, in spite of being very common in the IT vendors' scenario, are actually great services. Today, the real value-added service in the cloud computing momentum is PaaS (Platform-as-a-Service).

The Azure Website is an advanced PaaS platform to deploy complex web applications to the cloud, without having a steep learning curve, thus leveraging the existing skill sets. Think about Websites as simple FTP-like endpoints, where we can upload our site's contents (binaries or just plain text/resources) and let them run as they are. In addition, websites offer enterprise-level services, such as scaling, backup, monitoring, logging, and more, around this simple deploy-and-go concept. Last but not least, these Websites provide the capability to deploy applications in several different languages.

At the time of writing this book, Azure Websites support the following:

• .NET applications (with frameworks greater than or equal to Version 2.0)
• PHP applications (up to the Version 5.5 of PHP)
• Java (through the Jetty or Tomcat container)
• Python (both 2.7.3 and 3.4.0 Versions)

  Tip

  More generally, these Websites support every language and platform that can run on IIS, with FastCGI, plus Python and Java.

The architecture perceived by users of Azure Websites is charming. It is described as follows:

• A user initiates one or more server farms (also known as Web Hosting Plans). A plan is intended to be a website container tied to a particular pricing scheme.
• In a specific farm/plan, users create one or more websites.
• For each website, users can choose the execution platform just like they did for the monitoring options, run time configuration, and so on.
  • These options, as the running binaries of the Website, are completely isolated from each other, as they were in a sandbox.
• Finally, as users group Websites into farms, they can let specific farms scale up and/or out, resulting in all the Websites running on the initial machine being replicated across all the instances allocated in the farm.

The scenario explained earlier refers to the standard pricing scheme, which is the one we work with along the chapter as the most complete Websites offer of Azure.

At the time of writing this book, the pricing schemes are as follows:

• Free: These Websites run in a shared environment. Many options are restricted, no scaling is permitted, and one free web farm is permitted per location.
• Shared: These Websites run in a shared environment, but options and scaling are supported.
• Basic: On these Websites, some advanced options are restricted.
• Standard: These Websites provide a fully featured Azure Websites service.

Therefore, a company can deploy its production services into a single server farm (web-hosting plan), which should considerably scale up and/or out. At the same time, for testing and/or staging environments, the same company can run its services into another smaller web farm (probably, with a smaller machine and no redundancy at all).

What is the drawback of the Websites service? Customization of the runtime environment. In fact, the more abstraction the environment offers, the less control there should be over resources. What could happen if, for example, a single Website (hosted in the same machine/web farm of other N websites) needs an MSI component installed on the underlying operating system? In the case of installation, what guarantees that there will be no conflicts between the existing Websites? Finally, how can we scale out if there is some manually handled configuration of the operating system?

To build complex systems that need to release these constraints, Cloud Services is the right service to choose. In other cases, or better, when we can avoid relying on Cloud Services, Website is probably the leader.

Azure Websites can be simply deployed through FTP or Web Deploy, can have virtual directories and multiple applications, and can also have staging slots. We learn how to deploy an ASP.NET application in the Deploying a Website recipe. After deploying, the governance of the Website or the Websites' pool is up to Microsoft; however, advanced configuration, scaling, certificates and SSL, diagnostics, and monitoring is left to the user, as we will see in the Administering and Monitoring a Website recipe.

We stated that FTP and Web Deploy are the deployment methods of Websites. The Websites service can also be linked with a source code repository, taking the most recent version of the committed code and integrating it automatically. This method (extended and maintained internally by Microsoft) now supports several third-party providers as the built-in integration with the SaaS version of TFS, Visual Studio Online. In the Source versioning and continuous integration with Git and TFS recipe, we will see how to set up the source control integration with Git and Visual Studio Online (VSO).

In the last two recipes, we dig into the support of alternative software platforms such as PHP and Java. First, in the Logging abstraction from .NET and PHP recipe, we will learn how to integrate logging into applications. Later, in the Deploying Java with Azure Websites recipe, we will see how to run Java with Tomcat or Jetty.