The Cloud Line

Publish/Subscribe, at least how I am using the terms in this instance, refers to a useful software design pattern wherein one software entity receives unsolicited messages from another entity upon the occurrence of some event of interest. In the non-software, real-world of everyday experience we encounter this basic pattern all the time. A simple example is when you “subscribe” to a magazine and when a new edition is “published” you receive it. Closer to the software example is the RSS news feed, where your PC desktop newsreader application “subscribes” to a particular feed and receives updates (articles) as they are “published”.

In the realm of software architecture this pattern is imminently useful because it effectively decouples the sender (publisher) from the receiver (subscriber). More commonly, and especially over the internet, when software entities interact they do so in a manner that is referred to as “synchronous”.  That is, the exchange of information between the sender and receiver is performed in a manner that causes each to wait upon the other for the completion of its half of the transaction. For instance, software entity A asks software entity B if it has any data and entity B must process the request and return the data (or not) whilst A is kept waiting (blocking in software terms) while the request is processed. This approach is very common yet inefficient in that resources are pent up in the request and wait period due to the tight coupling between the publisher and subscriber. This problem is compounded when there is more than one entity wanting the data and made even worse when the two entities are communicating over the internet.

Now in the above examples and in the discussion to follow I am conveniently bypassing the underlying technical reality that there is still some form of asking (polling) going on here. It is still the case, however, that the overall mechanism afforded by the publish/subscribe paradigm is much more efficient, in addition to being conducive to implementing more elegant and extensible design patterns overall.

Last week at the Microsoft Build conference in Anaheim, California, Microsoft announced the commercial release of a publish/subscribe service built on top of its Windows Azure AppFabric Service Bus technology (I will shorten this to Service Bus from now on in the interest of avoiding having to navigate the somewhat arcane and confusing Microsoft product naming conventions associated with Azure and its constituent services). Microsoft Windows Azure is a commercial platform-as-a-service (PaaS) product that, at least in my humble opinion, represents the state of the art in commercial cloud services today. The Azure platform has numerous aspects but the overriding concept is that software developers can leverage various features and capabilities, all at cloud scale, as services rather than attempting to purchase or develop solutions for common design and scaling problems. The Service Bus is one of these services and one that I have experimented with in my own cloud-based product for a couple of years now. You can think of the service bus as an internet-scale pipeline that two applications, residing in completely different networks and/or geographical locations, can use as a relay service to shuttle messages back and forth without either needing to concern itself with the network characteristics or constraints of the other.

The new part of the Service Bus announced at Build was the Service Bus Queue. This is a classic message queue feature that layers on top of the Service Bus and delivers a true publish/subscribe capability at internet scale. This infrastructure service offering facilitates a powerful architecture wherein one software entity can spontaneously generate messages and put them on the Service Bus then go about its business. Correspondingly, software entities that have interest in what the sender might be publishing can register for messages, even including some filtering criteria for the messages it is distinctly interested in, and then receive and process those messages when they are available. This facility is leveraged by both the sender and the receiver (or receivers) without forcing either to implement complex software and hardware (server) infrastructure to facilitate it. Moreover, the entities can reside in different locations/networks and can even be based on completely different (i.e. non-Microsoft) technologies.

The publish/subscribe methodology is certainly not new. Many commercial products have been around for years that can be installed on servers and leveraged by the companies that license them. The difference here is in the fact that the Azure Service Bus can be consumed as a service and operates on a scale, including redundancy and reliability characteristics that are truly world class, that few application developers would ever have access to outside of academia or large corporate infrastructures.  In keeping with the general theme of this blog, this technology is of note because of the power that it puts in the hands of small, independent software development teams to create truly internet-scale applications on small budgets and short timescales.

I fully expect to see a wide range of compelling applications and services built on top of the Service Bus Queues made available within the Microsoft Azure PaaS offering. I for one am preparing my team for incorporating the queue functionality into our telemetry framework product. We will be initially incorporating the functionality as an add-on feature to be experimented with while not changing the existing runtime system components. Incidentally, this ability to test out tangential system features without affecting the production runtime components is another benefit of message queuing technology – the level of decoupling between sender and receivers means that new receivers can be added at any time with no impact to the existing ones. I fully expect, however, that our core components will be refactored at some point in the near future to remove them from their current synchronous relationships and instead insert Service Bus Queues into their interconnections. This will make our overall platform offering much more scalable and extensible with very slight changes in the existing software components.

So, bravo to Microsoft for pushing the envelope in PaaS technologies once again.

I suppose that it is appropriate to start this blog by defining what the terms “Cloud” and “Cloud Computing” are to me and why I am bothering to write about them. It goes without saying that these terms have been overused as of late to the effect of rendering their meaning ambiguous at best and outright meaningless at worst. These days it seems like anything internet-related gets the cloud label slapped on it by default. In my view the terms “cloud” and “cloud computing” refer to the trend towards software applications being built in a fashion where the primary computing power and data storage services are managed in a centralized location and accessed via a variety of user interface technologies such as browsers, televisions and mobile phones. This means that you can access your applications and data through any number of different peripheral devices, any one of which could be lost or destroyed without in any way affecting the application or data.  In some ways this is a shift back to an earlier era of computing where centralization was the way of it and interacting with applications and data involved using a dumb terminal that had little or no storage or computational power.

Now the interesting part, and the primary focus of this blog, is how these cloud applications are actually built and deployed today. After all, applications that meet my basic criteria for being called “cloud based” have been around for a while – take SalesForce.com for instance. The thing that makes cloud computing interesting is how technologies and business models are evolving to allow cloud-based applications to be built and deployed by very small teams of individuals with little or no capital expense requirements. It is this enabling infrastructure that could, for instance, result in the next FaceBook or SalesForce application being built by a moonlighting software team on a shoestring budget. This is the exciting part for me since it means that we are likely to see a proliferation of highly innovative and useful cloud applications going forward. This in turn will drive the move towards separating applications and data from hardware, allowing for inexpensive and possibly even disposable forms of computing devices to begin displacing the traditional PC.

The general focus of this blog is on a class of commercial cloud services that offer computational and data storage facilities that completely abstract concepts such as servers, firewalls and data storage mechanisms. Some refer to this as Platform as a Service (PaaS).  PaaS is a relatively recent phenomenon and legitimate PaaS providers include heavyweights such as Microsoft, Amazon and Google. These providers, to varying degrees, provide complete application development and data storage environments that can be leveraged by development teams of any size. Whereas previously a software vendor or consultant looking to build an internet based application had to either construct his or her own network operating center or look to lease these resources from a hosting vendor such as RackSpace, the Cloud Computing paradigm largely abstracts the IT infrastructure and thereby allows the developer to push the application into the “cloud”, relying on the service provider to provision computers and storage infrastructure as-needed.

One of the more compelling aspects of the cloud computing service offering is the concept of paying for the resources you use rather than for machines sitting in racks. In the latter case, it is necessary to build up a collection of hardware resources capable of servicing the maximum load your application might encounter. With the cloud paradigm, you pay only for the resources your application actually requires. These include the traditional metrics such as memory, storage and bandwidth as well as more advanced services such as queuing, transactions and caching. These advanced services encapsulate often complex operations into simple to use building blocks that can be assembled to perform common operations with very little work on the part of the developer. One thing I find interesting about this is that as software developers we have long referred to operations or algorithms using terms such as “expensive”, meaning that they consume large amounts of one or more critical resources such as memory or disk space.  In the cloud computing paradigm, the term “expensive” actually translates directly to a financial definition as well, which leads to applications being designed with the cost of services and resources very much in mind. This leads to cost-effective applications that enable business models that are minimally encumbered by infrastructure and operational costs.

In my daily, professional life, my own use of cloud computing technology is focused primarily on M2M (Machine-to-Machine) applications. This is, up to now, a quiet little corner of the computing universe where sensors, actuators and intelligent microcontrollers carry out behind-the-scenes operations that include comfort control, lighting control, process control and even security and life-safety functions. These devices and the networks that connect them are all around us, though we scarcely realize or appreciate their presence – unless of course they malfunction in some way. Like pretty much all other forms of computing technology, these devices and networks have evolved rapidly over the past 10-15 years with more and more of them shipping with IP connectivity and the ability to be remotely accessed. My specialty is in combining these intelligent device networks with cloud computing to form large-scale application platforms that aggregate vast numbers of data and control points. Specific applications include energy management and intelligent environments of many kinds.