Showing posts with label security. Show all posts
Showing posts with label security. Show all posts

Monday, May 07, 2018

The Black Mirror Episode You'll Never

I’m no fan of the TV show Black Mirror – the plots are obvious and the pace is excruciatingly slow. But nevertheless, here’s a story for consideration.

Our tale begins in a world where all data is stored in the cloud. This means people don’t have their own computers but can instead log into whatever machine is handy wherever they go.

All is lovely until our hero one day notices a slight error in some data. This is supposed to be impossible because the system breaks every file into pieces that are replicated millions of times and stored separately, blockchain-style. Any corruption is noted and outvoted until it’s repaired.

As he investigates, our hero finds that changes are in fact happening constantly. The system is infected with worms – we’ll call them snakes, which has nice Biblical overtones about corruption and knowledge – that move from node to node, selectively changing particular items until a new version becomes dominant. Of course, no one believes him and he is increasingly ignored because the system uses a reputation score to depreciate people who post information that varies from the accepted truth. Another security mechanism hides “disputed” items when they have conflicting values, making it harder to notice any changes.

I’m not sure how this all ends. Maybe the snakes are controlled by a master authority that is altering reality for its own purposes, which might be benevolent or not. The most likely result for our hero is that he’s increasingly shunned and ultimately institutionalized as a madman. Intuitively, I feel the better ending is that he ends up in a dreary-but-reality-based society of people who live outside the cloud-data bubble. Or perhaps he himself has been sharded and small bits begin to change as the snakes revise his own history. I can see a sequence of split-second images that illustrate alternate versions of his story co-existing. Perhaps the best ending is one that implies the controllers have decided the episode itself reveals a truth they want to keep hidden, so they cut it off in mid

Friday, February 23, 2018

Will CDP Buyers Consider Private Clouds as On-Premise Deployment?

Most Customer Data Platforms are Software as a Service products, meaning they run on servers managed by the vendor. But some clients prefer to keep their data in-house. So before releasing the CDP Vendor Comparison report – now available here – I added a line for on-premises deployment.

This seemed like a perfect fit: a clear yes/no item that some buyers consider essential. But it turned out to raise several issues:

- on-premises vs on-premise. I originally used “on-premise”, which is how the term is typically rendered. One of the commenters noted this is a common error. A bit of research showed it’s been a topic of discussion but on-premise is now more widely used relating to computer systems.  On-premises actually sounds a bit pedantic to me, but I’m using it to avoid annoying people who care. (Interestingly, no one seems too concerned about whether to use the hyphen. I guess even grammar geeks pick their battles.)

- private clouds. Several vendors argued that on-premises is an old-fashioned concept that’s largely been replaced by private clouds as a solution for companies that want to retain direct control over their systems and data. This resonated: I recalled seeing this survey from 451 Research showing that conventional on-premises [they actually used “on-premise”] deployments now account for just one-quarter of enterprise applications and the share is shrinking.


Percentage of Applications by Venue:
24% Conventional (on-premise, non-cloud)
18% on-premise private cloud
15% hosted private cloud
14% public cloud
13% off-premise non-cloud
Source: 451 Research, Strategy Briefing: Success Factors for Managing Hybrid IT, 2017

My initial interpretation of this was the on-premises private clouds meet the same goals as conventional on-premises deployments, in the sense of giving the company’s IT department complete control. But in discussions with CDP vendors, it turned out that they weren’t necessarily differentiating between on-premises private clouds and off-premise private clouds, which might be running on private servers (think: Rackspace) or as “virtual private servers” on public clouds (think: Amazon Web Services). Clearly there are different degrees of control involved in each of these and companies that want an on-premises solution probably have their limits on how far they’ll go in the private cloud direction.

- public clouds. One vendor speculated that most remaining conventional deployments are old systems that can’t be migrated to the cloud. The implication was that buyers who could run a CDP in the cloud would gladly do this instead of insisting on an on-premises configuration. This survey from Denodo suggested otherwise: while it found that 77% of respondents were using a public cloud and 50% were using a virtual private cloud, it also found that 68% are NOT storing “sensitive data” in the public cloud. Presumably the customer data in a CDP qualifies as sensitive. I don't know whether the respondents would consider a “virtual private cloud” as part of the public cloud.  But I think it’s reasonable to assume that a considerable number of buyers reject external servers of any sort as an option for CDP deployment, and that “on-premises” (including on-premises private clouds) is a reasonable term to describe their preferred configuration.