My thoughts in response.

I agree that for much of what wants to be done on a laptop/desktop, or on a tablet or smart phone for that matter, there is something 'thicker' than a dumb web browser required as the client.  

As the browsers acquire more heft, with both proprietary and more HTML5 based functionality, the browser becomes (at the very least) the fundament of any 'local client' technology.  Without this, the 'cloud applications' and the cloud storage of my data, my documents and collections will hit a wall.

In thinking about cloud storage of my personal possessions, I'd rather not think of things as 'documents'.  Rather, if one considers the active principle one of assembling and then 'rendering' a herd of data components (core data, meta-data, …) , we should use the term assemblage to replace the concept of document.  The assembly doesn't require physical proximity of data components, just a good and smoothly working linkage amongst them. 

I agree that, to the degree possible, the world will move toward the 'master data assemblage' (or what Duncan referred to as the ur-document) that resides in a cloud, and is sync'd for those situations where there is intermittent communication … which pretty much describes my iPhone and its use of AT&T Mobile's data plan.

The point is that it depends on accomplishing 'synchronization' well and correctly.  'Correctly', by the way, needs to cover issues of usability & user experience , safety (privacy & security), and economy (optimal utilization of compute, network and storage).  There is no single definition of 'correct' in these scenarios … the optimal recipe is going to completely depend on the context and the ability to adapt as the context changes for the mobile user.

In point of fact I've had a lot to say, and haven't done a very good job of getting it put in place as something worth reading.  I've also been told recently by Laura Schewel, with whom I'm working at creating an awesome data company that I think too much when I write.  I'll do what I can to rectify that.  

In trying to simplify the organization of my thoughts, notes, research, general collections of mental detritus, I've gone to a much more limited set of tools, most of them simpler.  Simple text editors instead of extensive word processing.  Snippet handlers to automate dates and tagging.  Collections of work notes, call notes, personal journal entries, interesing research all in one kick-ass data base that's replicated to my other machines (and to the cloud) with no overt action on my part.   We'll see if that same kind of streamlining can be used for the 'public' journalling I do (or... want to do ...) here.  

Just prior to leaving on vacation for the holidays, I spent an evening reading analyst retrospective pieces on 2010 and predictions for 2011.  For the most part, they were pretty fluffy.  A few, however, stood out. One of the pieces to which I kept returning was the 451 Group's 2011 preview - Enterprise security by Josh Corman, Steve Coplan, Andrew Hay, Wendy Nather and Chris Hazelton. (Sorry, folks... it's behind a paywall.)  I will say that it took several careful readings.  In part, multiple readings were required because the piece is dense and covers a lot of territory.  I also found my attention being drawn to several related issues that have been on my mind for the best part of the year.  With apologies to my friends at the 451 Group, here are the four aspects that I retained, and the associations that were generated while I read (and re-read) the piece.

There's no single security market.  

Throughout the piece, the security pros at 451 have gone out of their way to make clear that there is no single 'security market.'  There are markets, market segments that operate as 'markets', and highly interested communities of interest which provide technologies and services in response.  

In continuation – and as the logical consequence – of what we predicted in last year's preview, a pronounced schism has formed in the information security market between those that fear the auditor more than the attacker and a minority that attempt to solve for both.

Security strategies are the basis for drawing distinctions between the markets. The most interesting aspect of their analysis is the way in which they've drawn distinctions.  Among the most important, for the industry and the investment community, the authors have started with a distinction between those consumers of security offerings who are interested in meeting the criteria for compliance (i.e. passing the audit, getting the credential and avoiding the penalty) and those consumers driven primarily by the need for better infosec visibility, better security coverage, avoidance of 'security events' and improved response to security problems.  By drawing the distinction between compliance-centric and improvement-centric segments of the market, the 451 Group makes clear that it's not a distinction between the rich and poor, nor the large and small.   

Using security services to reduce the scope of self-management. Although one can detect some opprobrium (look it up) leveled at the market that holds compliance as its guiding principle, the 451 Group makes clear that by focusing on improvement in the measurable result and improved ROI, this market has come to rely on reducing scope (and thus exposure) of their security environments.  This has resulted in finding someone 'outside' (and paying them) to take the responsibility.  In this age of "cloud" and "everything-as-a-service", the delegation of responsibility to an outsourced service becomes more than a tactic, and increasingly a strategy.

Using security services as an enrichment strategy. For the market that holds with the strategy that improvement is paramount, service also plays an increasing role.  Specifically, they point to the increased value and dependence of this market on security 'enrichment' from third party sources, and open source / community feeds. 

The vendors respond, with mixed results, to a multi-market environment.

It's the view of the authors that providers of data loss prevention (DLP) offerings sought the creation of a viable middle market by taking extensive and complex systems and 'simplifying' them. The idea seems to have been to package for those organizations with fewer resources and less expertise, the products available to larger organizations with budgets that supported hiring in the expertise. 

At the same time the world was learning of the state-sponsored espionage and sensitive government and private-sector documents making their way into Wikileaks, the data loss prevention (DLP) vendors were 'simplifying' their offerings. We've remarked that this may be giving the market what it asked for, but not what it needed. Information protection is hard, although the answer isn't to oversimplify it.

The expanded market didn't materialize, while the high end market remained stagnant because this market embraced the compliance-centric strategy, and can't seem to get beyond concern about their handling of personally identifiable information (PII).  So, to pick up the first theme, the DLP vendors got smoked in by middle market that was reducing exposure, and went flat in the high-end where compliance is king.

The short story (according to the 451) seems to be: It sux to be a DLP product provider.  Does that mean, however, that life will be better for those vendors that find themselves in the services business, taking responsibility off of the individual company's staff, and allowing them to reduce direct exposure?  

The markets for mobile endpoint security get spotlighted.

When considering security aspects of mobile access and mobile devices, the 451 Group makes clear once again that there are multiple markets.  One of the most interesting sections of the piece discusses the approaches offered by the industry to address mobile endpoint security. The authors contend that the security vendors, by mistaking multiple markets for a single market, have conflated the protection against malware and the proper service management of configuration, activity and applications.  Yes, they're all security issues, and, yes, they all require special attention when an enterprise uses mobile endpoints.  But, that doesn't mean they're all the same market, nor should they be considered as addressable with a Swiss Army Knife collection of cures.  

Sandboxing: Virtualization is not just for OS and apps. Among the most promising, but potentially mismanaged approaches to mobile endpoint security is the use of virtualization on mobile devices to segment and protect the management of execution (operating systems and applications).  What the 451 guys make quite clear is that sandboxing as a strategy can and should be applied as well as to segment and protect data when it ventures out into the mobile world.  As I read this section, this brought me to exclaim: 'What this world needs is workable data provenance!!'  (This is a longer story, and one on which I can hold forth interminably.  Let's just leave it at this: I see it becoming the norm to operate IT environments on the basis of meta-data and rely on master data management to reduce redundancy, improve accuracy and establish 'immediate' consistency. The same mechanisms should be available to IT for the purpose of retaining a tamper-resistant history of a workload or data record, thus providing an authoritative "life story" and chain of stewardship or custody.) 

Data security and identity solutions -- the coming reliance on entitlement by policy.

While there are at least another four or five big ideas covered in the article, the last one I'd like to call out relates to the changing role of identity technologies in the determination of who's entitled to use which data and for what purpose.  The authors do a great job spotlighting the data enablement value proposition:

We also expect greater integration with identity solutions, with policy determining who can access which data (ideally within which contexts). For appropriate use cases, we have seen large enterprises re-entertain information/enterprise rights management. At the end of the day, organizations create value out of sharing information, so solutions need to first support the needs of the business and, second, assure that vital collaboration can be done within acceptable bands of risk.

This becomes imperative when, through the use of one or more 'outsourced' providers of infrastructure or management services, it becomes necessary to control which attributes of data an application can access.   The 451 Group calls out a scenario in which vendors in the data security arena become more active in integrating authentication and single sign-on technologies, in order to provide a more complete service offering to which corporate IT can delegate responsibility for data security.

--

I have not done justice to the range of issues covered in the article.  I know for a fact that the authors agonized over how to cover the important issues in a relatively short survey piece.  And, there are at least four or five additional themes covered, which I've left out of may coverage. They're worthy, but didn't move me to thought the way these four did.  If you have access to the article, I recommend you read it. As I went through it again this evening while writing this post, I came across another couple of gems, but they'll have to wait for another day.

From Wikipedia (that authoritative source of all knowledge):

In sport, a hat-trick (or hat trick) means to achieve a positive feat in the sport three times during a game, or other achievements based on threes.

Tonight, John Furrier (@Furrier) of Silicon Angle asked a number of the Cloud Club Alumni what we thought about the Heroku acquisition that was announced this morning.  Bernard Golden (@bernardgolden) CEO of HyperStratus , Randy Bias (@randybias) CEO of Cloudscaling and I all weighed in.  I threw something together quickly, and then thought it might be worth posting.

The Heroku deal is one third of a tremendous three-fer: Chatter.com (which was announced, and should be in place in February 2011), database.com (a scalable, almost direct replacement for a MySQL service, with no need for admins), and Heroku.  

First, one of the areas in which Heroku has been very successful, and popular with the developer community, is as the basis for web-based applications that build on top of social media -- mostly Twitter and Facebook. Salesforce has just announced what could, arguably, become 'the Twitter of business' with the establishment of its 'freemium' social networking service (Chatter.com).  After successfully rolling it out as a value-added feature of Salesforce, Chatter is being expanded to cover communities well beyond those who use Salesforce.com (or Force.com). With the acquisition of Heroku, and the effort to make Chatter available through a variety of APIs,  the availability of Heroku as a development platform for web-based applications deriving value from social networks is near perfection.

Take another look at one of the most innovative and well executed aspects of Heroku -- the 'add-on' exchange, that excellent collection of other SaaS and functional platform services that Ruby on Rails developers have at their beck and call.  With the availability of database.com, a new hosted service will show up in the Add-on catalog, taking its place with other data-oriented services like Cloudant, Amazon RDS, MongoHQ, Redis and, of course, the venerable Memcached.  Now in the mix there will be a highly scalable SQL-like data base service with the same low administrative 'overhead' that users of Heroku have come to expect.  Throw in some effort for a nice integration, likely to be followed VERY closely by more pieces of the Force.com catalog, and the RoR developer community has just picked up some powerful new tools with which to work.

This is an environment that will encourage agile development, based on a devops model, without the concerns of managing and administering infrastructure.  Certainly, there will be questions raised about integration with the rest of the SFDC infrastructure, though it's not at all clear that's high on the priority list.  For some insight as to how Salesforce.com and Heroku are presenting the impending union, see this post by Ben Kepes.

On returning home, I saw Ben Kepes' reaction to the announcement, the title of which pretty much says it all:

 BMC and Cisco Combine to Automate Cloud Delivery–Imitation is the Sincerest Form of Flattery 
The money quote from Ben: 

It’s nothing new – Enomaly, enStratus, Datapipe and many, many other providers (see here) are playing in a similar space – regardless of that, the fact that two stalwarts of traditional IT such as Cisco and BMC are at least dabbling in the hybrid cloud space is a guarantee of two things. Firstly that cloud, if we didn’t need any other proof, has come of age. Secondly it’s an indication that enterprise IT leaders are looking for solutions from these more venerable providers.

I then realized that what had been bothering me all day about the original announcement.  This was, in reality, a three-party transaction.  The three parties?

• The VCE coalition with Cisco acting on their behalf,
• BMC, and
• Acadia -- the joint venture originally founded by EMC and Cisco, and 'further capitalized by investments from VMware and Intel,' established to help partners and customers 'accelerate the transition to pervasive virtualization and the private cloud.'

Yep. Acadia is a party to the transaction that hasn't been mentioned.

What Cisco has done is secure a source of cloud delivery automation for vBlock which, in Ben's words, represents "…the seal of approval from a 'trusted' vendor (which) means a lot for many risk-averse CIOs."  

This is an arms deal, guys. And Acadia just got use of some serious firepower.  It would not have been the same had Cisco done the deal with the cutting edge, leading edge players that Ben mentions. They needed a non-affiliated source of management systems, with enterprise credibility, so as to properly equip Acadia.  With the BMC deal, they gave them a great present that should keep on giving for quite a while.

---

For those of you who've heard me hold forth on Acadia... you can stop reading here.

For those who haven't, here's the story in a nutshell: When VMware, EMC and Cisco announced the alliance around Cisco's UCS and the creation of Vblock infrastructure, it was clear that they were missing a key ingredient as part of the ecosystem: professional services. 

• None of the three founders entered this market with a PS organization of sufficient weight and focus that they could (or would want to) dedicate it to the delivery of Vblock. 
• Within the past few years, big infrastructure competitors have picked up major PS organizations, (e.g. HP's EDS and Dell's Perot Systems), and these organizations were not about to promote VCE's wares to their customer base.
• Engaging and convincing the big independent PS organizations that are still 'non-aligned' would require serious resources in the form of incentives, enablement and marketing expenditure, with no assurance that it would succeed in generating sales or gaining support.
• The most reasonable answer was to create their own captive PS organization - Acadia. 

The euro zone has serious infrastructure (IaaS) offerings that are home grown. … UK2Group's hosting companies and their newest offer, OnApp, are good examples.  In the realm of managed service providers catering to big enterprise, T-Systems and Orange Business Services represent formidable competition for the enterprise cloud services market.   Still, the US-based IaaS and, increasingly, PaaS players view Europe as an opportunity for which they have a technology advantage and, therefore, should also have a time advantage if they can get to market soon.

Among those most interested in the European markets are the 'pure play' specialists in cloud infrastructure. The group of players to which I refer are the companies that have developed their own, distinct approaches to cloud infrastructure or infrastructure management … the companies with a history of quickly implementing services in response to the demands of their cloud infrastructure clientele.  But in moving into the European market, conversations of competition generally end up with "What can we do to get into the market, and not find ourselves in a price competition with AWS as it expands into these territories?"  That seems to be the wrong question, based on the wrong premise.   

We've noticed that the interest in Europe exhibited by the 'pure play' infrastructure cloud service providers overshadows the respective efforts of competitive MSPs like AT&T and Verizon whose IaaS services have grown as extensions of conventional data communication and IT business services. The enterprise MSPs have enough of a challenge addressing their markets at home.  The enterprise ICT specialists like CSC Trusted Cloud or Unisys's Cloud Solutions don't make as much noise about their international / offshore efforts and may seem less geographically focused because their Global 1000 customers are already just that -- global.  For this group, considerations of different markets and the jurisdictional constraints with which they must comply are considerations at the outset.

In the course of Telematica's strategic consulting and our partnership with IVA, we're being asked directly by clients about how best to proceed into European and some Asia-Pacific markets and not be overwhelmed by other US players with deeper pockets.  

• We first caution them to remember that they're not entering markets without indigenous services.  
• Next, we find ourselves discussing with them the ways in which their offers can be made distinct and/or distinctly European.  
• As important, we find ourselves often making the point that IaaS companies must enter the European markets on the basis of strategic relationships with 'local' professional services, system integrators and other channel partners. 

In the course of the next few weeks, we will be discussing some of our findings and a few 'deeply held opinions' about the kinds of differentiation these IaaS players can employ to make progress entering new markets. While the initial focus is Europe, we're doing our best to identify those aspects that are of general interest when entering foreign markets, as well as the specific aspects that impact market entry in Asia-Pacific and South America.  I hope you enjoy the discussion and make your own opinions known.

Amazon Route 53 is a new service in the Amazon Web Services suite that manages DNS names and answers DNS queries. Route 53 provides Authoritative DNS functionality implemented using a world-wide network of highly-available DNS servers. Amazon Route 53 sets itself apart from other DNS services that are being offered in several ways:

A familiar cloud business model: A complete self-service environment with no sales people in the loop. No upfront commitments are necessary and you only pay for what you have used. The pricing is transparent and no bundling is required and no overage fees are charged.

Very fast update propagation times: One of the difficulties with many of the existing DNS services are the very long update propagation times, sometimes it may even take up to 24 hours before updates are received at all replicas. Modern systems require much faster update propagation to for example deal with outages. We have designed Route 53 to propagate updates very quickly and give the customer the tools to find out when all changes have been propagated.

Low-latency query resolution The query resolution functionality of Route 53 is based on anycast, which will route the request automatically to the DNS server that is the closest. This achieves very low-latency for queries which is crucial for the overall performance of internet applications. Anycast is also very robust in the presence of network or server failures as requests are automatically routed to the next closest server.

No lock-in. While we have made sure that Route 53 works really well with other Amazon services such as Amazon EC2 and Amazon S3, it is not restricted to using it within AWS. You can use Route 53 with any of the resources and entities that you want to control, whether they are in the cloud or on premise.

At the risk of falling back on the old bromide (among internet types) that at the end of the day, it's ALWAYS a DNS problem, let's just say that this is as important a commercial offer as AWS has added in some time.  

I expect to read some fairly low-key responses to the introduction of Route 53.  Many will consider this another box to be checked when making a comparison of cloud infrastructure services.  And while most of us in the 'chattering class' haven't had the time yet to dig into it, nor get a feel for its performance, the importance of DNS to the composition of cloud-oriented applications should actually be appreciated as being massive.

Ultimately, cloud infrastructure and platforms offer the basis on which applications are composed, on which data is consumed after being squirrelled away and on which numerous assemblies get 'wired together'.  They depend on the discovery functionality of DNS, on the namespace management it affords and perhaps most importantly the resolution of 'identity' and 'location (in the network topology)'.

I'm looking forward to getting more details as to how else AWS and its customers will end up using Route 53.  Consider this: The extent to which internet-based applications, infrastructure and platforms use DNS is almost unfathomable. The patterns of DNS use generate exceptionally voluminous piles of data, but exceptionally valuable data which, through analysis tells an amazing amount about the applications and their end users.  These breadcrumbs and fingerprints are capable of being revealed by the cost-effective use of services like…wait for it… AWS.  I consider Route 53 to be a basis on which cloud infrastructure can be better monitored and managed, and a basis on which (for both good and evil) application behavior and application 'consumption' can be analyzed in exceptionally creative ways.

The emergence of cloud computing is now an impetus to revisit B2B application messaging.  I encountered this interesting post by Mark Morley of GSX.

…With so much interest in everything Cloud at the moment, companies are starting to look at ways of not only deploying enterprise applications up to a cloud based environment but also looking for ways to provide integration to other cloud based services, whether they are private or public clouds.  AS4, with its web services capabilities has the potential to become the cloud based communications standard moving forwards.

AS4 is quite similar to AS2 in many ways however it operates within a web services context and unlike AS2, AS4 has enhanced interaction patterns and acknowledgement receipts. AS4 has the following characteristics:

• Provides acknowledgement receipts thus enabling reliable message delivery and retry in the event of a lost message
• Provides password authentication, digital signatures and encryption , confirms authenticity of the sender and ensures that the message is unaltered whilst in transit
• Offers  large file compression and transfer support
• Error generation, reports any errors to the message sender of the message receiver
• Message exchange patterns, allows a rich variety of interactions between the sender and receiver

AS4 refers to Secure B2B Document Exchange Using Web Services is a standard developed by a subcommittee of the OASIS ebXML Messaging Services Technical Committee.  For a good summary of the standard and the intent of the OASIS ebXML technical committee, take a look at The Drummond Group's site here.  For those who might need a teaser:

This profile (of the ebMS 3.0 specification) provides guidance for a standardized methodology for the secure and document-agnostic exchange of B2B payloads using Web services. By constraining the ebMS v3.0 specification and the underlying WS-* specifications for messaging packaging, transport, security, and business non-repudiation, the profile focuses on providing an entry-level on-ramp for Web services B2B messaging. The end goal of this profile development is to replicate and strategically extend the existing functional requirements currently satisfied by RFC4130 (AS2) by mapping those requirements onto the Web services platform. 

So, what's this got to do with cloud? Doesn't seem to be much more than a consideration of how to use Service Oriented Architecture principles and accepted practice as the basis for machine-to-machine business messaging.   Yes, this all about web services.  But, as Lori MacVittie points out in Let's Face It: PaaS is Just SOA for Platforms Without the Baggage, clouds are service-based models.  They are Service Oriented Architecture that's "… merely moved down the stack a bit, into the underlying and foundational technologies upon which applications are built."  In short, Lori considers the emergence of cloud computing and '-as-a-Service' approaches to be a do-over … the reduction and avoidance of the complexity that the industry loaded on itself in the early days by over-architecting and over specifying.  

For the sake of the industries that depend on application-to-application business messaging, let's hope that the OASIS takes the hint. 

After setting out four of the five ways in which make mistakes the result "… in the flow of data we think is so valuable either drying up, or never starting in the first place …" , he ends the list with

… cock-up avoidance technique number 5, which in my mind is the most important, but which I accept many of you might find controversial. This mistake is the mistaking of insisting that Government really should be in the business of publishing everything non-private it can.

"What heresy is this?" I hear you cry, "Aren't you in favour of as much open data as possible?" My answer is simple: No, not at the moment - I don't think any government anywhere is really up to it yet. In fact, right now, I think it is a rather dangerous idea. …

The preceding set of 'mistakes' is great, but what he goes on to say in the rest of the speech is … well, why don't you read it for yourselves.

Dave McCrory has recently provided excellent insights about OpenPaas in a series of posts this month, the most relevant to the polyglot persistence notion being this one.

In this diagram (above), there are two URLs each providing access to an Application. The first application on the left has a single Application Instance and that App Instance is bound (see Binding Labels) to a MySQL Instance (Service Instance) and a RabbitMQ Instance (Service Instance). The two Service Instances are created from the Service Catalog’s MySQL and RabbitMQ entries.

The second Application has three App Instances inside of it, all of which are bound to the SAME RabbitMQ Instance that the first Application is (this means that the two Applications can share information through the RabbitMQ Instance). The MySQL Instance is a separate MySQL Instance from the first Application MySQL Instance, although both are based/invoked from the MySQL Service in the Service Catalog. The Redis, Memcache, and MongoDB instances are all bound to each of the App Instances in the second application and are used by all three instances.

[My thanks and a hat-tip to Tim Freeman (@peakscale) for pointing this point out to me.]