Digital Walkabout

Scalable Cloud Computing

One of the principal issues discussed regarding Cloud Computing is scalability. Many look to CC as the answer to their scaling needs, others are skeptical and question CCs capability to scale. 

The scalability issue centers on the compute model. We have already seen the breakdown of CC into the three compute models of Hosted Services (thin client, centralised architecture, data and capabilities exclusively in the cloud), Attached Services (traditional desktop client, client-server architecture, data and extended capabilities in the cloud), and Rich Internet Services (rich client, p2p architecture, data and capabilities distributed, clients part of the cloud). This categorisation helps one to map these models to various platforms and architectures. For example, Web 1.0 is an analogy of the Hosted Service model, whilst Web 2.0/3.0 can be compared to the Rich Internet Service model. 

The issues surrounding scalability in CC can be easily analysed through these models. Experience has clearly shown that thin client models scale best for applications with simple capabilities and data models - those most often associated with task workers. Thick client models scale best for applications with complex data models, processing and capabilities - applications targetted for everyone else. The same applies for CC. Complex applications require a greater level of interactivity with data - users working with macro-micro-nano views of data, graphics-intensive applications, disconnected or intermittently connected clients, high levels of integration between systems all involve greater requirements on concurrency, processing and data management. As Web 2.0 developed out of the growing desire to bring complex applications to the Web and to support their requirements, Rich Internet Services are being developed to do the same for the Cloud. 

When organisations first made their forays into CC, they began with Hosted Services as a replacement for Desktop applications. Whilst this made sense with task worker apps, which have a relatively low interactivity with data, this failed visibly with mobile professionals, "hot desktop"-ers, contract/outsoruced staff and telecommuters, which typically have high interactivity with data. Principally, these failures were characterised by an impedance mismatch between rich client requirements and user experience, and the data and network architecture of Hosted Services. High data interactivity drives complex data models, and often is the motivator for CDM, in applications; such applications can only scale when they distribute the burden of processing complex data models. This scalability is lost in the Hosted Services model, since all processing must take place on the server. When this is coupled with the challenging UX requirements of such applications, which include resolving inconsistencies between many online transaction processes, the resource requirements exponentiate. With Hosted Services, long-lived sessions holding open anywhere from 250 MB to 1.5 GB of memory will strangle concurrency and performance. 

Users began to demand a solution to this, and developers came to the same conclusion they did for data intensive web apps, mobile apps and MMOR games - a greater and more balanced distribution of processing across the broader topology, which itself meant returning to the innovations of 15 years ago and managing clients and servers alike as equivalent nodes in the network. This breaks down the definitions and barriers between client and server which results in greater scalability. When clients are defined based on the sequence and direction of messages/requests, this enables heretofore client hardware to be used both as consumers and providers in CC. With the inherent efficiencies of presentation and resource management of today's mobile client hardware, the benefits are hard to miss. When web apps themselves followed this path to greater scalability, one must wonder why it has taken as long as it has for consumers, developers and providers alike to reach the same conclusion. 

Similar parallels can be found in virtualization. Gartner makes some pointed observations about this in their report from October 2008, firmly predicting a downturn in VDI adoption as the cost/benefit ratio becomes clearly with time and experience. I would equally support such a prediction for Hosted Services. 

Simplexity and Leaky Abstractions

Recently I have read some suggestions that CC suffers from Simplexity and Leaky Abstractions - the former claimed since CC is seen to "take something incredibly complex and try to wrap it in something simpler, [only to] just shroud the complexity";  the latter since "All non-trivial abstractions, to some degree, are leaky." 

Yet, I am one to argue that, regarding Simplexity, it is more a case of discovering a simple truth, and not one for sweeping complexity under the rug. This returns to an argument I have long made - exposing operational semantics in anything other than low-level or internal APIs is absurd, as this breaks the basic principle of automation, which is loose coupling. This is one thing that Web Services and REST have had right from the start - exposing only axiomatic semantics and hiding operational semantics. Without making the latter opaque, there is little chance one can ever decouple atoms from business logic. One should never have to know the details in how the services they consume work, rather, one should only have to understand the relationships of the services they consume, when they can impact the consumer - which is what choreography addresses. 

Regarding CC, it is the discovery of what service providers have done as both a business and technological model - business in respect to hiding the complexity of what they provide to their consumers, technology in respect to the ease of integration - mashing-up - their services. It is a natural progression of models from distributed computing, whilst providing the abstractions in terms of definition and description. To drive a car, one doesn't necessarily need to fully understand the internals of the engine, drive train, suspension, electrical system, etcetera. One only needs to understand the abstract interfaces - steering, brakes, accelerator, gear box, environmental controls, etcetera - and how they function (and most drivers seemingly under. This is the difference between operational and axiomatic semantics. Those who cannot get over operational semantics would, in essence, still have drivers use a manual choke and crank starter, because "you just have to understand how it works, man."

Which is a good segue to Leaky Abstractions - by definition, this places all practical technology abstractions, which could hardly be referred to as "trivial", as "leaky". The author's own example of driving a car in the rain exposes the flaws in this argument. The abstract interfaces of the car have everything to do with control, speed, internal environment, status monitoring of the car, whether in motion or not. "The weather can never be completely abstracted away" is neither here nor there, because the constraints of climate on driving a car have to do with the laws of physics, human biology, etcetera, and not whether the  internals of driving a car having themselves been encapsulated. 

The comments on the Simplexity and Leaky Abstractions of CC have more to do with the cynicism of those who feel it to be another victory of style over substance, and less to do with any real issues with CC. I do concur that the taxonomy blur does leave one disorientated and wondering what the buzzwords truly represent. Whilst I do not expect CC to be the end-all of computing models, I see it as yet another step in the right direction, and evolution of compute models, and driving technology toward the democratization of innovation, content, community and commerce.

Cloud Computing adds more risk to privacy?

http://tinyurl.com/csyud8

I must admit this is a worry. Social networking is already subject to abuse by those seeking an information windfall. Preferences, location, and more, all freely available for the gleaning. Those who engage in social networking not only submit to living within a fishbowl, but to giving up any ownership over whatever they do in that fishbowl  - to use Facebook as an example, here is just a tiny selection about the information collected:

“Facebook may also collect information about you from other sources,  such as newspapers, blogs, instant messaging services, and other users  of the Facebook service through the operation of the service (e.g.,  photo tags) in order to provide you with more useful information and a  more personalized experience.

By using Facebook, you are consenting to have your personal data  transferred to and processed in the United States.” Add to this the fact that, in essence, Facebook now owns everything you put on it, in perpetuity.

Whilst consumers pushed back on Google to relinquish their ownership of anything running on the Chrome browser, Google continues to use their CC Hosted Services license terms to bot users' searches, GMail content and profiles, to better target those users with online adverts. 

If the privacy of such information can be secured, there may be some room for negotiation. Despite the worry and subtelty of it all, this has been done in prima facie fashion, and these same vehicles make it rather easy to raise awareness of their privacy concerns. Yet, when the privacy itself is compromised, and combined with the ever growing desire (fixation?) on transparency, one’s information can be subject to grievous abuse. Transparency, whilst a necessary aspect for conducting many endeavours, has become the rallying call for a degradation of privacy, an excuse to invade the privacy of users without cause or justification,  with the expected egregious outcome. This is a very slippery slope; in the name of 'security', human rights have been repeatedly degraded and  innocents made to unjustly suffer the consequences of what is now becoming termed as 'transparency'. The 'fervour' of anti-terrorism is only the latest manifestation of this. It is very easy to twist any invasion of someone's privacy into harmful device. Think you have "nothing to hide"? Think again. There's a little thing called "identity theft". Yet less brute, are such information as your reading or viewing preferences. These may be in vogue or acceptable today; tomorrow, they might not be.

Yamamoto Tsunetomo’s Hagakure provides a splendid analect regarding privacy: “It is a fact that fish will not live where the water is too clear. But if there is duckweed or something, the fish will hide under its shadow and thrive.... This fact should be understood with regard to people’s conduct.” This fact should be just as well understood with regard to people’s information. The new 'transparency' (= intrusion) suffocates. For those who wish for a return to the rigidity of the Victorian era or the Cold War, they may be very pleased with this trend. For the rest of us, we need to continue to advocate, raise awareness, and push back on invasion of privacy, and we find Facebook, Google, and other social networking platforms and channels only too willing to help.

Siftable Computing

Thanks to Gary Sage and Gervais Douglas for this. This is a an interesting approach to visualising a modular architecture. It is peer-to-peer rather than client-server, but of course peer-to-peer can act as a transport to client-server, yet providing the global/neutral perspective necessary to understanding multi-party relationships.

http://www.ted.com/talks/david_merrill_demos_siftables_the_smart_blocks.html

Dropping SOAP: Shavit and de Icaza

Intriguing:

"With the release of Moonlight 1.0 last week, I had the opportunity to speak with Novell’s Miguel de Icaza about OS interoperability as it relates to RIAs. Moonlight is the Linux port to Microsoft’s RIA platform, Silverlight.

One of Silverlight’s advantages over Flash is that it includes a subset of .NET, including WCF for easy communication with the servers that do the real work behind RIA widgets. When Silverlight was a Windows-only platform, interoperability wasn’t an issue; companies that wrote Silverlight apps probably had Windows servers, so the client and server ran the same platform.

But Moonlight brings Linux into the fold on the client side, and that raises the question of interoperability. For now, the question is largely one-directional: how can developers design Silverlight apps that run on Linux but talk to Windows servers? But if Silverlight comes to compete broadly with Flash as a platform, companies may start having to worry about Windows clients talking to Linux servers, too.

De Icaza suggested that one solution may be to just drop WCF, which uses SOAP. Although there’s certainly an architectural appeal to creating more cohesive communication between clients and servers, de Icaza said, he’s seen a general movement back to the simpler REST protocol. [Ed note: Microsoft offers a REST kit for WCF – but SOAP is the more common use. WCF with REST loses an important WCF characteristic: strong types.]

But de Icaza was careful to add a disclaimer: his work doesn’t focus around enterprise applications. In those tightly controlled environments, using WCF and SOAP still makes sense, he said.

Of course, SOA is all about the enterprise, so that’s a pretty big disclaimer for any architect working behind a corporate firewall. But data from many services within an enterprise eventually finds its way to the user in one form or another, and maintaining two protocols — one for internal communication and the other for external publishing — defeats one of SOA’s main objectives: modularity and reusability of services. What happens if that tax calculation service needs to communicate with a RIA shopping cart next year, for instance?

The saying goes that if you live on the cutting edge, you risk getting cut. SOA architects should keep a careful eye on RIAs, lest they have to re-architect their brand new systems."

You can read the entire article at:

http://itknowledgeexchange.techtarget.com/soa-talk/