Posts Tagged ‘Doesnt’
Data visualization doesn’t matter
Last Updated on Friday, 25 May 2012 04:23 Written by Celframe Web Team Saturday, 9 June 2012 05:43
Visual.ly analyzed the top 30 infographics posted on their site and determined that data visualization doesn’t matter:
Data visualization certainly matters when it comes to conveying information effectively, but when it comes to sharing, the answer is no: having data to represent is not a critical ingredient in infographics. More than half, or 53%, of the top 30 graphics do not contain data visualization. And by data visualization, we mean visual objects that are sized, colored, or positioned to represent numerical values.
I think what they actually mean is that data visualization is not the sole factor of a successful visualization. Since they are only analyzing the top 30 infographics, the minority 47% that had data visualization are still very successful. It would be a different story if the 53% of infographics without dataviz were the top successes and the 47% with dataviz were the bottom losers.
My hunch is that the successful infographics posted on Visual.ly are popular because, like other viral content, they strike a nerve, are of the moment, are humorous yet relevant, or have some other je ne sais quoi.
Incomplete Thought: Why Security Doesn’t Scale…Yet.
Last Updated on Friday, 9 March 2012 03:12 Written by Celframe Security Team Saturday, 10 March 2012 01:45
There are lots of reasons one might use to illustrate why operationalizing security — both from the human and technology perspectives — doesn’t scale.
I’ve painted numerous pictures highlighting the cyclical nature of technology transitions, the supply/demand curve related to threats, vulnerabilities, technology and compensating controls and even relevant anecdotes involving the intersection of Moore’s and Metcalfe’s laws. This really was a central theme in my Cloudinomicon presentation; “idempotent infrastructure, building survivable systems and bringing sexy back to information centricity.”
Here are some other examples of things I’ve written about in this realm.
Batting around how public “commodity” cloud solutions forces us to re-evaluate how, where, why and who “does” security was an interesting journey. Ultimately, it comes down to architecture and poking at the sanctity of models hinged on an operational premise that may or may not be as relevant as it used to be.
However, I think the most poignant and yet potentially obvious answer to the “why doesn’t security scale?” question is the fact that security products, by design, don’t scale because they have not been created to allow for automation across almost every aspect of their architecture.
Yes, there exist security products that are distributed but they are still managed, provisioned and deployed manually — generally using a management hub-spoke model that doesn’t lend itself to automated “anything” that does not otherwise rely upon bubble-gum and bailing wire scripting…
Sure, we’ve had things like SNMP as a “standard interface” for “management” for a long while We’ve had common ways of describing threats and vulnerabilities. Recently we’ve seen the emergence of XML-based APIs emerge as a function of the latest generation of (mostly virtualized) firewall technologies, but most products still rely upon stand-alone GUIs, CLIs, element managers and a meat cloud of operators to push the go button (or reconfigure.)
Alongside the lack of standard API-based management planes, control planes are largely proprietary and the output for correlated event-driven telemetry at all layers of the stack is equally lacking. Of course the applications and security layers that run atop infrastructure are still largely discrete thus making the problem more difficult.
The good news is that virtualization in the enterprise and the emergence of the cultural and operational models predicated upon automation are starting to influence product roadmaps in ways that will positively affect the problem space described above but we’ve got a long haul as we make this transition.
Security vendors are starting to realize that they must retool many of their technology roadmaps to deal with the impact of dynamism and automation. Some, not all, are discovering painfully the fact that simply creating a virtualized version of a physical appliance doesn’t make it a virtual security solution (or cloud security solution) in the same way that moving an application directly to cloud doesn’t necessarily make it a “cloud application.”
In the same way that one must often re-write or specifically design applications “designed” for cloud, we have to do the same for security. Arguably there are things that can and should be preserved; the examples of the basic underpinnings such as firewalls that at their core don’t need to change but their “packaging” does.
I’m privy to lots of the underlying mechanics of these activities — from open source to highly-proprietary — and I’m heartened by the fact that we’re beginning to make progress. We shouldn’t have to make a distinction between crafting and deploying security policies in physical or virtual environments. We shouldn’t be held hostage by the separation of application logic from the underlying platforms.
In the long term, I’m optimistic we won’t have to.
QuickQuip: “Networking Doesn’t Need a VMWare”
Last Updated on Thursday, 8 March 2012 11:46 Written by Celframe Security Team Thursday, 8 March 2012 06:17
I admit I was enticed by the title of the blog and the introductory paragraph certainly reeled me in with the author creds:
This post was written with Andrew Lambeth. Andrew has been virtualizing networking for long enough to have coined the term “vswitch”, and led the vDS distributed switching project at VMware
I can only assume that this is the same Andrew Lambeth who is currently employed at Nicira. I had high expectations given the title, so I sat down, strapped in and prepared for a fire hose.
Boy did I get one…
27 paragraphs amounting to 1,601 words worth that basically concluded that server virtualization is not the same thing as network virtualization, stateful L2 & L3 network virtualization at scale is difficult and ultimately virtualizing the data plane is the easy part while the hard part of getting the mackerel out of the tin is virtualizing the control plane – statefully.*
*[These are clearly *my* words as the only thing fishy here was the conclusion...]
It seems the main point here, besides that mentioned above, is to stealthily and diligently distance Nicira as far from the description of “…could be to networking something like what VMWare was to computer servers” as possible.
This is interesting given that this is how they were described in a NY Times blog some months ago. Indeed, this is exactly the description I could have sworn *used* to appear on Nicira’s own about page…it certainly shows up in Google searches of their partners o_O
In his last section titled “This is all interesting … but why do I care?,” I had selfishly hoped for that very answer.
Sadly, at the end of the day, Lambeth’s potentially excellent post appears more concerned about culling marketing terms than hammering home an important engineering nuance:
Perhaps the confusion is harmless, but it does seem to effect how the solution space is viewed, and that may be drawing the conversation away from what really is important, scale (lots of it) and distributed state consistency. Worrying about the datapath , is worrying about a trivial component of an otherwise enormously challenging problem
This smacks of positioning against both OpenFlow (addressed here) as well as other network virtualization startups.