I get strange looks when I talk to developers about the difference between developing an application to a product versus developing an application to a service.  The application you write on premise is written to a piece of software purchased, installed and configured on a piece of computer hardware that you privately own.  The application you write in the cloud is written to a set of services that are available to you as well as the public to exploit.  So let’s explore how they are different.

When you write your application for your on-premises server there are expectations that you have from this set of hardware and software.  You can expect that you will connect successfully every time you logon.  You control what applications run on this server so you expect the same level of performance every time.  You know and control the security context of your data.  You configured the software and hardware so you expect that if something goes wrong all you have to do is look at a logged event and you can most likely figure out what happened.  For the most part you have a pretty good pulse on the behavior of your application for your privately owned, managed and maintained server.  On the other hand, you also know that if you run out of compute on this server you now have to move to a different, more capable configured system.   And if it turns out that your server has more compute capacity than your application needs, you have wasted compute and now need to migrate other workloads onto the same server to better utilize the compute you have.  Lastly once it is all up and running you need to maintain the hardware and software.  It is some of these reasons why you may be looking at the cloud in the first place where the hope is to lower your overall cost of computing.

Now you decide to either move your application or build your application in the cloud.  In the cloud you have the same capabilities that you have on premise:  authentication services, application services (Cache, messaging, etc.), database services, and availability services, to name a few.  But you also have significant new opportunities such as ability to scale on demand and the cost benefits of pay-as-you-go on commodity hardware.   If you desire you can develop your application to these services similarly to how you wrote your on-premise application and for the most part it will work. 

However building a great cloud application requires a little more.

Maximizing the performance, scalability and manageability of cloud applications written for Windows Azure requires architecting and coding to exploit the unique features of the cloud platform.  Examples include:

• Capturing application telemetry throughout your code so you can proactively react to the applications behavior in real-time.
• Exploiting scale-out of compute and storage nodes for great scale or utilizing multiple data centers for greater availability.  Designing your application to grow through deploying new “scale units” (groupings of compute, storage, and database) allows provisioning for both planned and unplanned growth.
• Tolerating any single component failing while ensuring the app continues to run.  The best cloud applications in the world support this but it does require you to write your application expecting a potential component failure and responding to that outage in real-time without notable impact to the end user.
• Leveraging cache for data retrieval whenever possible, and spreading database requests across a number of separate databases (shards) to support scalability and maximize performance.

To help jump start the learning process of writing a great cloud application this blog points to seven reusable cloud components with sample code and documentation that you can leverage for almost any PaaS application that you are developing on the Microsoft Windows Azure platform.

What we created:  The AzureCAT (Microsoft’s Customer Advisory Team in engineering) has been part of the design, build and deployment of hundreds of Azure PaaS applications.   We learned a lot from this and decided to write and share these seven reusable components below to help others see what we mean by writing to a service.  We wrote them as a single end to end application to ensure the components work seamlessly.  The application itself is a rather simple application that registers users, logs in and adds comments.  It was built and tested at scale requiring telemetry and sharding code to be added to ensure great performance.

The sample code and documentation for the seven reusable components will benefit anyone who is writing a PaaS application.   The components are:

1. Configuration – configuration files are key to helping make management of your application seamless
2. Logging – the logging of application, event and performance telemetry
3. Data Access – this is actually two components:  a) retry logic for database commands and connections and b) sharding using a custom hashing algorithm
4. Caching – writing and reading user data into/from cache
5. Scheduling – background worker role to collect telemetry data every minute and move it into a custom ops database in SQL Azure
6. Reporting –reporting on the telemetry collected into the SQL Azure ops database
7. Application Request Routing (ARR) – technology in IIS for routing users to multiple hosted services (application workload load balancing)

Below is a link to the material – The application code is posted on MSDN’s CodeGallery:

• Cloud Service Fundamentals in Windows Azure
• Cloud Service Fundamentals Wiki page

Summary:  This introductory blog will be followed by several others drilling into each of the components in much more detail.  If you read this blog and take
away that great cloud applications require you to write code to exploit the cloud services to their fullest, then it has met its purpose.   The code samples are real and they work (i.e.
they function together). They are derived from real-world implementations and have been tested at scale.