Christmas Eve and the AWS/Netflix outage to me aren't so much about whether or not the Cloud is viable or scary or dangerous. Rather, the event resonated with users across the United States because the Cloud delivers so much utility to each of us. And regardless of who was at fault--Netflix or Amazon Web Services, the event made it clear that there's no going back and that the Cloud has quickly become a part of our culture and our everyday lives. This is significant because while the Internet itself is a technology consumers have grown to love, Cloud is a way of delivering service that makes a service like Netflix streaming possible, and at a measly $8 bucks a month. The Netflix business model of delivering outsize utility for a low price point makes the business of streaming video all the more difficult. HBO, Cinemax, and the networks for me are unusable. I sense something beyond just making money remains in play at Netflix. Somewhere in that organization seems to beat a heart that quickens for humanity.
Saturday, December 29, 2012
Saturday, December 8, 2012
Cloud Cost Question: Dark Matter and Data Centers
If the cost of computing as accounted corporate data center leaves out critical elements, what of analysis that compares data center computing to Cloud Computing. Are we looking at Cloud through the wrong end of the telescope, so to speak? Is the framework through which most analysis assesses Cloud costs subject to the same Procrustean Bed as the corporate data center? The notable departure of Zynga's CTO notwithstanding, despite the many brilliant minds analyzing the Cloud, the Cloud has a market, a force, and a moment of its own that can't simply be stroked into a ready framework.
Monday, July 2, 2012
Cloud and Public Relations and the AWS US-EAST-1 Question
Christmas Eve AWS outage stings Netflix but not Amazon Prime
Latest outage raises more questions about Amazon cloud
Heroku, if you were a character on South Park, I would call you Kenny.Every time AWS has an episode you're killed. bit.ly/U7pu9wAs you may be aware Amazon AWS US-EAST-1 experienced two outages in June that resulted in widespread service interruptions and significant downtime for AWS marquis customers such as Netflix, Pinterest, Istagram, Heroku.
— Brian McCallion (@BrianMcCallion) December 25, 2012
While some of the Cloud community and analyst community may rationalize the outages in an attempt to “protect Cloud” my approach is to take a hard line with Amazon and to place the outages squarely in Amazon’s court. In my opinion the outages were avoidable and that Amazon’s datacenters suffered from a design or engineering flaw that resulted in not just one but two outages in June. And beyond the technical reasons for directing the issue to Amazon, my understanding is that effective public relations in the face of serious events is to accept responsibility, and work to remedy the issue so it doesn't happen again. For the Cloud to evolve into an enterprise technology such issues need to be addressed by the providers, and failures need not be rationalized, or excused.
I strive for and recommend the “design for failure” approach to Cloud and systems architecture. Yet I believe that if failures can be avoided by exercising design for failure at the datacenter level then Amazon failed to effectively execute the “design for failure principles” espoused by Werner Vogels. In the case of the June 14th and June 29th outages at Amazon US-EAST-1 I believe the outages could have been prevented the first time if Amazon’s datacenter had been able to run on generator power.
In the case of the June 29th outage the datacenter(s) lost power in much the same way and yet again no generator power to keep the systems available. The fact remains that other datacenters in the Ashburn Virginia region lost grid and continued to operate with no issue running on generator power until power was restored.
In my opinion Amazon needs to follow its own design principles and to avoid failing the same way twice, especially when standard datacenter design should have eliminated the first of the two failures.
Wednesday, June 20, 2012
How to Wield a Disruptive Sword without Destruction
Last week was pretty busy. Under cover of night I approached by ongoing quest for Cloud knowledge by seeking out the external human forms of various Clouderati at a Lucent-Alcatel sponsored Clouderati party where I met Reuven Cohen, George Reese, James Urquhart, Sinclair Schuller, Klint Finley, Alex Williams, Chris Gaun, Aneel Dash, Deborah Salons. As an envoy of the enterprise, I spend my days working with with Fortune 500 Corporate IT mid and executive level technology. In 2007 I launched a startup to market an idea I had developed based on my experience working with Ogilvy & Mather, JP Morgan Chase, Broadridge Financial Solutions, and Automatic Data Processing.
I developed the idea of DeployAgility based on my experience leading development teams and managing code at financial firms, and where unlike the warm and supportive culture of places like AWS, Etsy, and the forward thinking shops of today, and Production outages, and deployment errors, and bugs in Production are not met with a smile and a lesson. At JP Morgan Chase I worked as the architect of a consolidated bond data service. My early experience designing applications to process payments based on Screen Actor's Guild and other Talent contracts, building reporting solutions from multiple data sources and feeds for client's of Ernst & Young taught me among other things to never deliver late, never deliver code with bugs, and to code in a manner that would enable me to sleep at night knowing that as I worked I would invariably receive significantly altered requirements, priorities and deadlines. I figured out how to run my own test cases to really turn my code inside out, to make sure it was robust by using my imagination to run cases to break it. In part I think I succeeded as a developer not through any genius of algorithms, but rather through my drive to simplify, to drive to "an aesthetic" of minimalism. I visited a Japanese designer and sculptor in the Union Square neighborhood who explained how wood from a tree is already beautiful, how anything one adds to it subtracts from the beauty of the wood. When I write code I consider the work a form of sculpture where the code is written so as to strip away the distractions and reveal the underlying objects of my vision. In this respect I view coding just as any other form of writing.
Similarly when I set out to design a solution to what I and executives I worked with viewed as the problem with build and deployment of code across Development, QA, Staging, Production the consequences of the problem were pretty clear to me. Much of what happens between the start of a project and deployment of code to an application server depends on the ability to write code, manage it in source control, revise it, but label it, compile it, package it and deploy it to Production. In Sao Paulo in 2002 I had brought a long a book on the development process which I read at night in my air conditioned apartment about a block from the office. The situation I had been assigned to turn around was political as the costs and stewardship for an application for which tens of millions of dollars had been invested was now being transitioned from the original development team at Agency dot com to the team in Brazil. One of the notable challenges was that building the application had taken 72 hours and a large team of people.
The bond process I wrote at JP Morgan Chase ran daily to align data from multiple services into a source then served on the CFO portal, and Executive View. Prior to Puppet, and Chef, CF Engine I had focused on Agile Deployment methodologies in an effort I lead at Liberty Mutual's International Division to reinvigorate and application under development for several years and now being deployed in Sao Paulo, Brazil.
I also attended Forecast 2012, DeployCon, CloudExpo sessions, and met with va. Mobile is place to be for app development. At DeployCon the best prezos were from Mike Hoskins CTO of Pervasive Software (at least his vision of a Cloud of single function web services and applications composed of such services as the new paradigm for composing (as opposed to writing applications) echoes what I believe are of the fundamentals of object oriented programming: composition over inheritance and interfaces aka apis as opposed to inheritance. These two capabilities, while possible in C++ became clearer as Java strips away much of the noise of C++ and itself supplies a large library of useable objects with which to begin to build. Does anybody studying C++ and writing a String class? In Java 5 many of the original classes and containers were rewritten or reimplemented, yet beginning with a jdk immediately changed a Java programmers focus from writing basic objects to building applications from objects in the jdk.
At DeployCon Mike Hoskins presented a vision of PaaS that aligns with what I think will happen and how I think Cloud will disrupt the present day approach to application development and developers themselves. It goes well beyond the late to the game binary opposition I find in the discourse of DevOps / NoOps discourse. I wsnt do it justice here but after he stopped talking about his rough flight, Mike Hoskins articulated a vision of a service catalog of web services from which developers will compose applications. In the enterprise the term service catalog still means a catalog of stuff IT can do, like provision and configure an email account, reset a password, deliver a desktop, onboard a new employee and on the whole such service cstalogs remain firmly footed in the present IT world that thinks in terms of fiefdoms, stacks, and ine off builds of vms, app servers, web servers, identity service--but I digress.
In the world of real service catalogs and web services as specified and implied in SOA Architecture, just as all bugs become shallow when viewed by many eyes, I believe that a Cloud application architecture will shift the focus and level of abstraction at which developers and architects work from objects to the web services.
In this way portability and apis become the bonding point of these new organic building blocks and an entire ecosystem will emerge.
James Urquhart was fascinating in his role of MC at DeployCon through his commentary or lack of commentary following each presentation. After Mike's presentation words uttered by James severals times included the phrase "Cambrian explosion" of innovation and I think this is ezactly right. What james did not say was that due to Data Gravity the ecosystems will be specific to a Cloud. It's pretty clear which Cloud this will. And in this context I consider the presentation that followed. The Chief Scientist of Time Warner presented his strategy for PaaS without once naming a vendor, yet warning the many suppliers in the audience that if what they offered didn't "plug-in" to the framework he was building, that they would not be viable suppliers in his world. What he articulated in his presentation was essentially his revelation that presently his firm spends 70% of budget on maintance and that very little of IT spend buys innovation but rather supports the many layers of technology and application platforms the brief period of the last twenty years has left in the datacenter and the many people, processes, and surgical extractions and work arounds that form the technology and business and social superstructure that has grown around those artifacts. My question is whether in IT there can be a bloodless revolution and still achieve results that will place an enterprise at the top of the food chain.
I developed the idea of DeployAgility based on my experience leading development teams and managing code at financial firms, and where unlike the warm and supportive culture of places like AWS, Etsy, and the forward thinking shops of today, and Production outages, and deployment errors, and bugs in Production are not met with a smile and a lesson. At JP Morgan Chase I worked as the architect of a consolidated bond data service. My early experience designing applications to process payments based on Screen Actor's Guild and other Talent contracts, building reporting solutions from multiple data sources and feeds for client's of Ernst & Young taught me among other things to never deliver late, never deliver code with bugs, and to code in a manner that would enable me to sleep at night knowing that as I worked I would invariably receive significantly altered requirements, priorities and deadlines. I figured out how to run my own test cases to really turn my code inside out, to make sure it was robust by using my imagination to run cases to break it. In part I think I succeeded as a developer not through any genius of algorithms, but rather through my drive to simplify, to drive to "an aesthetic" of minimalism. I visited a Japanese designer and sculptor in the Union Square neighborhood who explained how wood from a tree is already beautiful, how anything one adds to it subtracts from the beauty of the wood. When I write code I consider the work a form of sculpture where the code is written so as to strip away the distractions and reveal the underlying objects of my vision. In this respect I view coding just as any other form of writing.
Similarly when I set out to design a solution to what I and executives I worked with viewed as the problem with build and deployment of code across Development, QA, Staging, Production the consequences of the problem were pretty clear to me. Much of what happens between the start of a project and deployment of code to an application server depends on the ability to write code, manage it in source control, revise it, but label it, compile it, package it and deploy it to Production. In Sao Paulo in 2002 I had brought a long a book on the development process which I read at night in my air conditioned apartment about a block from the office. The situation I had been assigned to turn around was political as the costs and stewardship for an application for which tens of millions of dollars had been invested was now being transitioned from the original development team at Agency dot com to the team in Brazil. One of the notable challenges was that building the application had taken 72 hours and a large team of people.
The bond process I wrote at JP Morgan Chase ran daily to align data from multiple services into a source then served on the CFO portal, and Executive View. Prior to Puppet, and Chef, CF Engine I had focused on Agile Deployment methodologies in an effort I lead at Liberty Mutual's International Division to reinvigorate and application under development for several years and now being deployed in Sao Paulo, Brazil.
I also attended Forecast 2012, DeployCon, CloudExpo sessions, and met with va. Mobile is place to be for app development. At DeployCon the best prezos were from Mike Hoskins CTO of Pervasive Software (at least his vision of a Cloud of single function web services and applications composed of such services as the new paradigm for composing (as opposed to writing applications) echoes what I believe are of the fundamentals of object oriented programming: composition over inheritance and interfaces aka apis as opposed to inheritance. These two capabilities, while possible in C++ became clearer as Java strips away much of the noise of C++ and itself supplies a large library of useable objects with which to begin to build. Does anybody studying C++ and writing a String class? In Java 5 many of the original classes and containers were rewritten or reimplemented, yet beginning with a jdk immediately changed a Java programmers focus from writing basic objects to building applications from objects in the jdk.
At DeployCon Mike Hoskins presented a vision of PaaS that aligns with what I think will happen and how I think Cloud will disrupt the present day approach to application development and developers themselves. It goes well beyond the late to the game binary opposition I find in the discourse of DevOps / NoOps discourse. I wsnt do it justice here but after he stopped talking about his rough flight, Mike Hoskins articulated a vision of a service catalog of web services from which developers will compose applications. In the enterprise the term service catalog still means a catalog of stuff IT can do, like provision and configure an email account, reset a password, deliver a desktop, onboard a new employee and on the whole such service cstalogs remain firmly footed in the present IT world that thinks in terms of fiefdoms, stacks, and ine off builds of vms, app servers, web servers, identity service--but I digress.
In the world of real service catalogs and web services as specified and implied in SOA Architecture, just as all bugs become shallow when viewed by many eyes, I believe that a Cloud application architecture will shift the focus and level of abstraction at which developers and architects work from objects to the web services.
In this way portability and apis become the bonding point of these new organic building blocks and an entire ecosystem will emerge.
James Urquhart was fascinating in his role of MC at DeployCon through his commentary or lack of commentary following each presentation. After Mike's presentation words uttered by James severals times included the phrase "Cambrian explosion" of innovation and I think this is ezactly right. What james did not say was that due to Data Gravity the ecosystems will be specific to a Cloud. It's pretty clear which Cloud this will. And in this context I consider the presentation that followed. The Chief Scientist of Time Warner presented his strategy for PaaS without once naming a vendor, yet warning the many suppliers in the audience that if what they offered didn't "plug-in" to the framework he was building, that they would not be viable suppliers in his world. What he articulated in his presentation was essentially his revelation that presently his firm spends 70% of budget on maintance and that very little of IT spend buys innovation but rather supports the many layers of technology and application platforms the brief period of the last twenty years has left in the datacenter and the many people, processes, and surgical extractions and work arounds that form the technology and business and social superstructure that has grown around those artifacts. My question is whether in IT there can be a bloodless revolution and still achieve results that will place an enterprise at the top of the food chain.
Saturday, June 16, 2012
Characters I've Met in the Cloud
After attending a Clouderati party and DeployCon the following day I started to question my very existence in the world of technology. It's as if I've been closeted. It reminded me a little of my childhood in what was once West Berlin, where my father burst onto the art scene, only to flame-out after publicly humiliating the most powerful gallery of the time and his sponsor, Rene Bloch. My father wanted to flood the gallery with water and have the people traverse islands constructed as part of the exhibit as they moved from one island after another each hosting the paintings and provisions that had sustained the artist as he moved through one way of viewing to another as he constructed and sometimes destroyed his works. That's another blog post entirely, perhaps a chapter in a novel.
The outrage, or intensity in the Cloud lies along several lines
1. Information Technology departments consume and build technology and they do not design or write code or develop new technology.
2. The professionals who manage your infrastructure today are equal to those at Amazon or any Cloud Startup, you can almost hear them say, "if they can do it, we can do it" and feel the soft undercurrent of the engineer and the Ubris of a great leader, once defeated and now beseeching the King for an opportunity for redemption.
3. Cloud Startups and the visionaries who project these realities into the world and who want to do what they want to do, but who also need money (the plight of every artist).
4. Utopians and Romantics. These are the standard bearers and the enterprise IT shops of the Global 2000. They want to get it right this time, fix the Cloud, build it internally, and keep their shop safe inside the little jar. They long for a time when things were simpler and bemoan the discord introduced by Cloud and the radical and dangerous ideas the Siren Song of Cloud sings into the ears of people who earn the real money and do the real business of business. These folks work tirelessly and patiently and bond together into a unified voice so as to better dissuade their captains from removing the wax from their ears, breaking their bonds, and swimming to the Sirens and the certain destruction they will deliver. For those of you who don't remember, Ulysses knew of the sirens, told his crew to put wax in their ears, and he alone heard the song and only the fact that he had the crew tie him to the mast kept Ulysses from swimming ashore and to his destruction.
Characters I Met in the Clouderati
Reuven Cohen
For some reason Reuven reminds me of Ed Kienholz, a brilliant sculptor who creates entire scenes that evoke familiar and powerful experiences and possessed a natural and perfect pitch for publicity and marketing his work and ideas. Reuven told me a fascinating story of a brand new city in China the size of San Francisco planned and built by bureaucrats and of course populated with no inhabitants whatsoever even as Beijing compresses ever more souls into its own Cloud of Commerce. For me this remains an allegory of the Corporate IT obsession with planning and building a Private Cloud for inhabitants / customers / developers with whom they are completely out-of-touch, unlike the wise and brilliant Mr. Cohen who successfully sold Enomaly to the Chinese government.
George Reese
For the purposes of this absurd conceit of transposing Clouderati characters onto the late 70s Berlin art scene, George reminds me a little of George Ricky, the sculptor who composed giant stainless steel sculpture designed and consumed by the corporate elite, yet maintains its integrity of form and its potency to teach, transform, elevate, and inspire. This "latch" work of George Reese connects him to George Ricky through the sense of "counter-intuitive angles that are oblique to the "apparent" design of the otherwise rectilinear form of the latch." I'm not sure explicating this last verse is worth the words and would probably obscure more than focus the meaning, but use your imagination and construct the meaning for yourself.
James Urquhart
Beyond reminding me a little of the contemporary Gary Sinise, in the world of this conceit of Berlin Artists, James echoes for me the persona of Samuel Beckett, an Irish writer who wrote in French, who I met briefly at the age of eight while Beckett was directing a rehearsal of "Crap's Last Tape." Once again, that experience is the subject of another blog that ostensibly has nothing to do with Cloud Computing, or a chapter in the book of my remembrance of the late70s Berlin art scene, which probably has a lot to do with my fascination not so much with the technology of Cloud Computing and more with the personalities, the sheer cognitive grip on the imagination that Cloud Computing holds for so many brilliant people of our time. James left his leftovers at the party. After I met James I then read his CNET blog and I understood why people like to meet the Clouderati in person: in person they are brilliant, interesting, yet human. In the Cloud they remain immortals.
Next Post will feature the following
NIST Definitions for the Following Terms
Echo Chamber
Diorama
Utopian Idealism in the Cloud
Siren Song
The work of the next posts will be along the lines of mapping corporate IT and the Cloud culture to their respective dioramas as well as explicating or evoking the Dioramas themselves such that each diorama escapes its limits and becomes something else.
The outrage, or intensity in the Cloud lies along several lines
1. Information Technology departments consume and build technology and they do not design or write code or develop new technology.
2. The professionals who manage your infrastructure today are equal to those at Amazon or any Cloud Startup, you can almost hear them say, "if they can do it, we can do it" and feel the soft undercurrent of the engineer and the Ubris of a great leader, once defeated and now beseeching the King for an opportunity for redemption.
3. Cloud Startups and the visionaries who project these realities into the world and who want to do what they want to do, but who also need money (the plight of every artist).
4. Utopians and Romantics. These are the standard bearers and the enterprise IT shops of the Global 2000. They want to get it right this time, fix the Cloud, build it internally, and keep their shop safe inside the little jar. They long for a time when things were simpler and bemoan the discord introduced by Cloud and the radical and dangerous ideas the Siren Song of Cloud sings into the ears of people who earn the real money and do the real business of business. These folks work tirelessly and patiently and bond together into a unified voice so as to better dissuade their captains from removing the wax from their ears, breaking their bonds, and swimming to the Sirens and the certain destruction they will deliver. For those of you who don't remember, Ulysses knew of the sirens, told his crew to put wax in their ears, and he alone heard the song and only the fact that he had the crew tie him to the mast kept Ulysses from swimming ashore and to his destruction.
Characters I Met in the Clouderati
Reuven Cohen
For some reason Reuven reminds me of Ed Kienholz, a brilliant sculptor who creates entire scenes that evoke familiar and powerful experiences and possessed a natural and perfect pitch for publicity and marketing his work and ideas. Reuven told me a fascinating story of a brand new city in China the size of San Francisco planned and built by bureaucrats and of course populated with no inhabitants whatsoever even as Beijing compresses ever more souls into its own Cloud of Commerce. For me this remains an allegory of the Corporate IT obsession with planning and building a Private Cloud for inhabitants / customers / developers with whom they are completely out-of-touch, unlike the wise and brilliant Mr. Cohen who successfully sold Enomaly to the Chinese government.
George Reese
For the purposes of this absurd conceit of transposing Clouderati characters onto the late 70s Berlin art scene, George reminds me a little of George Ricky, the sculptor who composed giant stainless steel sculpture designed and consumed by the corporate elite, yet maintains its integrity of form and its potency to teach, transform, elevate, and inspire. This "latch" work of George Reese connects him to George Ricky through the sense of "counter-intuitive angles that are oblique to the "apparent" design of the otherwise rectilinear form of the latch." I'm not sure explicating this last verse is worth the words and would probably obscure more than focus the meaning, but use your imagination and construct the meaning for yourself.
James Urquhart
Beyond reminding me a little of the contemporary Gary Sinise, in the world of this conceit of Berlin Artists, James echoes for me the persona of Samuel Beckett, an Irish writer who wrote in French, who I met briefly at the age of eight while Beckett was directing a rehearsal of "Crap's Last Tape." Once again, that experience is the subject of another blog that ostensibly has nothing to do with Cloud Computing, or a chapter in the book of my remembrance of the late70s Berlin art scene, which probably has a lot to do with my fascination not so much with the technology of Cloud Computing and more with the personalities, the sheer cognitive grip on the imagination that Cloud Computing holds for so many brilliant people of our time. James left his leftovers at the party. After I met James I then read his CNET blog and I understood why people like to meet the Clouderati in person: in person they are brilliant, interesting, yet human. In the Cloud they remain immortals.
Next Post will feature the following
NIST Definitions for the Following Terms
Echo Chamber
Diorama
Utopian Idealism in the Cloud
Siren Song
The work of the next posts will be along the lines of mapping corporate IT and the Cloud culture to their respective dioramas as well as explicating or evoking the Dioramas themselves such that each diorama escapes its limits and becomes something else.
Monday, April 23, 2012
Hardest Part of Cloud in Enterprise is that it Requires More than Just Writing a Check
This article addresses some of the important questions a colleague raised Friday afternoon about how and if the demands of Cloud Computing can or
must be “slotted” in to fit the rest of the IT organization.
This writer (highly regarded thought leader focused on
Enterprise Cloud Computing) argues no.
And in my opinion, Cloud Computing will not change to meet
the needs of the IT organization, and that rather, the IT organization needs to
change in order for a business to benefit from Cloud Computing. Cloud isn’t for
everyone, and can’t simply be bought—it does demand significant and
uncomfortable changes to an IT organization.
“It's a
mistake, though, to think that cloud computing will conform to the established
adoption pattern of IT innovation.
The reason is straightforward: Cloud computing brings automation
to the mix, and in every industry that automation has touched, profound
disruption has followed. IT will be no different. Those who think of cloud
computing as a segregated innovation, like virtualization, fail to recognize
how profoundly it will change enterprise IT as we know it.”>>>Read
more
Saturday, January 14, 2012
Subscribe to:
Posts (Atom)