Skip to main content

Designing Great Cloud Applications


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 seven reusable components will benefit anyone who is writing a PaaS application.   The components are:



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


    • Comments

    Post a Comment

    Popular posts from this blog

    Python and Parquet Performance

    In Pandas, PyArrow, fastparquet, AWS Data Wrangler, PySpark and Dask. This post outlines how to use all common Python libraries to read and write Parquet format while taking advantage of  columnar storage ,  columnar compression  and  data partitioning . Used together, these three optimizations can dramatically accelerate I/O for your Python applications compared to CSV, JSON, HDF or other row-based formats. Parquet makes applications possible that are simply impossible using a text format like JSON or CSV. Introduction I have recently gotten more familiar with how to work with  Parquet  datasets across the six major tools used to read and write from Parquet in the Python ecosystem:  Pandas ,  PyArrow ,  fastparquet ,  AWS Data Wrangler ,  PySpark  and  Dask . My work of late in algorithmic trading involves switching between these tools a lot and as I said I often mix up the APIs. I use Pandas and PyArrow for in-RAM comput...
    Post a Comment
    Read more

    Kubernetes Configuration Provider to load data from Secrets and Config Maps

    Using Kubernetes Configuration Provider to load data from Secrets and Config Maps When running Apache Kafka on Kubernetes, you will sooner or later probably need to use Config Maps or Secrets. Either to store something in them, or load them into your Kafka configuration. That is true regardless of whether you use Strimzi to manage your Apache Kafka cluster or something else. Kubernetes has its own way of using Secrets and Config Maps from Pods. But they might not be always sufficient. That is why in Strimzi, we created Kubernetes Configuration Provider for Apache Kafka which we will introduce in this blog post. Usually, when you need to use data from a Config Map or Secret in your Pod, you will either mount it as volume or map it to an environment variable. Both methods are configured in the spec section or the Pod resource or in the spec.template.spec section when using higher level resources such as Deployments or StatefulSets. When mounted as a volume, the contents of the Secr...
    Post a Comment
    Read more

    Andriod Bug

    A bug that steals cash by racking up charges from sending premium rate text messages has been found in Google Play.  Security researchers have identified 32 apps on Google Play that harbour the bug called BadNews. A security firm Lookout, which uncovered BadNews, said that the malicious program lays dormant on handsets for weeks to escape detection.  The malware targeted Android owners in Russia, Ukraine, Belarus and other countries in eastern Europe. 32 apps were available through four separate developer accounts on Google Play. Google has now suspended those accounts and it has pulled all the affected apps from Google Play, it added. Half of the 32 apps seeded with BadNews are Russian and the version of AlphaSMS it installed is tuned to use premium rate numbers in Russia, Ukraine, Belarus, Armenia and Kazakhstan.
    Post a Comment
    Read more