Cloud as Quality Attributes

When I think about cloud computing, I often think about systems running elsewhere. As in, a catchall description of software that runs "in the cloud". Remote and encapsulated. This is a desirable property, a black box system, where we only have to know about, and understand, the external interface. We design components this way no matter where they run, in an attempt at good engineering. Components should be simple to use, and this is done by hiding away much of the complexity. Cloud based solutions are exactly that. The word "cloud" itself works well as a descriptor for abstract information hiding. We let our software run somewhere else, or use someone else's software, not necessarily understanding how it all works inside. It just gets the job done. Why can't we take an alternative perspective to cloud whereby we take some of the underlying principles of cloud and apply them to our software directly, as its being designed and implemented?

Any software architecture has quality attributes, or, non-functional constraints that speak to how the software should behave outside of the problem domain. The same quality attribute, for example, might be applied to a variety of problem domains. The database is replicated. Any task will retry upon failure at most five times. The maximum response time is three seconds. These are all principles that we as programmers and architects think about every day, whether formal or informal. I think the cloud can teach us a thing or two about these quality attributes in how we design our software. You'll discover, quickly, that if you were to take some arbitrary legacy system, and migrate it into the cloud, that it will not work as expected. Unless of course, you have the help of the cloud provider who specializes in supporting that particular platform. The system doesn't work properly, because it didn't take cloud quality attributes into consideration.

The top-down approach of build the system first, then deploy to cloud will only get us so far. Rather, thinking in terms of quality attributes that'll enable the system to fully utilize the cloud is viable in the long-term. These things are baked into the software. The software is aware of cloud capabilities at a fine-grain level. The software knows about the various services made available to it, from any given cloud provider. That said, is the provider willing to offer fine-grain services such as these to the cloud consumer? Or will we continue to deploy monolithic systems and hope for the best? It will probably be a combination, somewhere between deploying to the cloud as usual, and next-generation systems designed around the services that applications can take advantage of.

Thinking about what makes an application deployment successful enables successful design in the first place. So the systems of today, the ones being built right now, absolutely have to consider adapting to different environments. Adapting to the services available. If you think about this in great detail, you'll discover the true quality attributes necessary for your software to thrive, no matter the problem domain. You'll discover too, potentially, that nothing out there really solves the specific deployment scenario you're facing, or will be facing very soon. That in and of itself is exciting research, the realization that you have a need for your own type of cloud infrastructure.