Trolling is an art, from its humble beginnings on Usenet in the 80's it is now an oblique and black practice demonstrated daily in my Twitter stream by some of the best technologists around. The stakes are high, the winner often enjoys attitude hegemony over their topical clique. Winning jabs demonstrate deep insider knowledge of an inherent vulnerability of a subject, and the more you think about them, the more they implant themselves.   

But sometimes the troll falls on its face from a disproportion of attitude and preparation--flame without fact. Observe this seeming zinger: 

MelbourneIT dumps VMware vCloud Express http://bit.ly/k3DsA1 (HT @eekygeeky) < Service providers need better margins?

— Andi Mann (@AndiMann) June 2, 2011

The author of the Tweet wants the reader to conclude that some problem has occurred in a competitor's service provider cloud account, and that pricing/margins are to blame! The author in this case sells a potentially competitive (sorta) alternative and is looking to score some quick points. 

One small problem, the author of the tweet hasn't actually read the article: 

"Melbourne IT chief technology officer Glenn Gore said that the company learned many lessons during the beta program, but wished only to offer a commercial IaaS product based on VMware's vCloud program, code-named "Redwood", to large customers. Most of these, he said, had already made the transition to paid services."

In insider speak, the service provider has moved from the .8 version of the product with a different code-name and interface, to the newest 1.0 version with a different GUI/interface/API and program. It has also transitioned customers from a free beta program to a paid set of services based on the updated product. The service provider's new interface and product is doing well with high paying large accounts--that is--the opposite of margin pressure.  

Instead of being a knowing insider, the troll here has outed themselves as the opposite. This is not the path to troll fame and fortune kids. 

My simple tips for effective trolling!

1.  Read the article, probably twice, you want the comment to age well the more a reader understands about the topic and the more attention they pay--remember this is about highly informed attitude hegemony. 

2.  Be more oblique than you might otherwise be. Trust me, it’s how the cool kids do it. 

3.  Read the article again. 

 

 

After my usual walk across the street to Starbucks to start my morning I was browsing Gmail and saw the daily AWS forum digest email. I've been reading it for the last three years, in 2008-09 it was a pretty cool way to see what people were up to in an emerging space, and it was almost always worth the time to read every post every day. Lately, for the last few months I'd stopped reading them as well as the EC2 search tag on Twitter--the posts and problems have just gotten too repetitive. Randy Bias had a Twitter quote a few months back about the massive technical debt inherent in EC2, and since I read it that tweet has been circulating in my mind. The usual meme has @jeffbarr busy on blog posts, signaling massive new innovations coming to our greedy little cloud community hands. 

Maybe it was the calming aroma of my Sbux chai, or nostalgia, but this morning I decided to open the AWS forum mail. 

Same old, same old. Rampant EBS IO issues, strange instance state behavior and problems connecting to instances (these are often newbie user errors). I threw out a tweet lamenting the dull consistency of these problems over the years, Randy's 'technical debt' on my mind. These disappearing instances, network and load balancing limitations, zombie instances, and shaky, inconsistent disk throughput compared to traditional data center solutions are some of the main reasons why the Sr. Architect of Netflix's movie streaming solution honestly recommend existing enterprise applications should not be deployed to EC2 without a scaling and availability refactoring. He said this while being a big fan of the platform. He was willing to re-write his app and got a good ROI for his content distribution and web interactivity use case. 

Still nobody can argue with AWS's 0-60 momentum in the online content, batch analytics/rendering and start-up market. A VC would laugh at you these days if you told them you weren't building your consumer web application on the 'cloud'.  AWS's innovation has been in two primary areas: operational and business efficiency, and in turning everything they do into a thoughtful URI. As the great Simon Wardley says "servers on the internet, innit?" S3 represents the summit of this efficient and URI focused innovation model. 

But are these two areas of innovation enough to shift core business user behaviors on core data-center servers and networking? In July I last blogged that in order to win even complex analytical and web applications they would significantly need to improve their network topology and performance. The zealots told me I was crazy, the world was shifting, and that applications would be re factored to fit the EC2 model. A week later EC2 released cluster compute instances--but with a completely different network control model (direct switch connection configuration) and with a new AMI/hypervisor layer. This crude, but expedient method of meeting obvious market demand for higher performance stuck in my head--it looked like a hack. 

So in the predictable twitter backlash to my 'same old problems' post, I leaked the thought that had been ruminating in my mind the last few months since Randy's comment..what if technical debt was preventing them from innovating in areas core and vital to enterprise buyers? What if they never cross the chasm to the enterprise mainstream (like say HP blades + RHEL have, utterly devastating UNIX systems), what if like Netscape or Yahoo......

Boom. A hush fell across the room and all eyes were staring--did that dude just say AWS wasn't innovating? (I didn't, just that they weren't in some areas) Wow he must be paid to say that, or just a dumb @ss right? 

***

In 2004 I was responsible for crafting some of the early response to Red Hat's incursion into Sun Solaris. RHEL became deadly when one thing happened--when they started becoming highly compatible with traditional data-center software. Yes, they started in web stacks early, but Matt Szulik was laser focused on being a cheaper version of UNIX, with higher availability and higher performance. Even before it was called RHEL all of the engineers I worked with in 1998 at Level 3 considered Linux more resilient and faster. It was a diamond in the rough, waiting to explode. Szulik knew this, packaged it as RHEL and hammered relentlessly on compatibility, tier 1 workloads, and the core of enterprise budgets.

AWS innovations aren't doing this, and are not focused on single node performance and availability, they regard 'the enterprise' as wrong headed around architecture and are out to convert them to their pure distributed system design paradigm. They will win some converts, they have won Neflix and new start ups and many like workloads. They are also famous for a 'take it or leave it' negotiating stance with enterprises. They don't believe in salespeople en-mass, and obviously think this article was written by a dumb @ss. 

They are innovative as heck, they are fashionable as heck--but to what end. Where is their end game? How big is the batch processing and re-factored web application market? Its not even clear that developers care about all of this IaaS fuss. What does their somewhat hack like cluster offering tell us about their commitment to the hardest infrastructure innovations?There is no central conflict with enterprise vendors as there was with Linux. No technology is good at everything, R&D managers have to decide where to innovate and fight the universal physics of software development.  

And let's not forget when it comes to web applications, the PaaS monster is out there, growing, lurking and ready to remove the complexity of managing a distributed system for developers.        

 

 

 

 

 

 

 

{Warning: The following is a well intentioned rant from an individual who clearly spends too much time thinking about cloud infrastructure services. He would once again like to apologize to his mother that he didn't go to medical school, and instead chose a remote, cult, fringe sector of the technology industry.}

It was a great week in the clouderati blogosphere, I couldn't wait till the weekend to re-read and absorb the absurdly important and insightful goodness that hit the intertubes. So here we are, its past midnight on a Friday night, I've got a full pint of Pellegrino, I'm wearing sunglasses, hit it. 

Mr Hoff kicked off a series of blogs about the shouting match brewing between private "cloud" and public "cloud" infrastructure security approaches, with a core theme pivoting around tiered vs. topologically interchangeable network organization. Mr Urquhart wondered aloud about the potentials and limitations of EC2 as a cloud API standard, Ms Macvitte sent smoke signals about the new application world where schema-less data passing of just in time bits replaced the old world of cache ready, HTML content, and Mr Cole sent a simple message in a bottle to the future of the cloud, more features please. 

Watching every tweet, blog, forum post and customer story coming out of the cloud every day for years is a bit like watching a time lapsed 'picture a day' face study. Sometimes you see patterns, but as the fractal unfolds over the fullness of time the information turns out to be the jitter of perspectives more than a core transformation. 

The themes this week, however, were not jitter--they are the cutting edge of the "cloud" evolution. The cutting edge of cloud has shifted from an "if" to a how, and the minds who saw the cloud coming years before the general public are now confronting the balancing act between intrinsically lower featured, topologically insensitive cloud formations represented by certain volume leading de facto standards--and the increasingly technically possible emergence of more topologically calibrated and therefore feature rich clouds. Because simple infrastructure clouds came first, they have largely defined the market--but the voices of "no thanks!" are too powerful and persistent to write off purely as technological laggards--there are important architectural reasons they have abandoned or stayed home so far. 

Instead of devolving my Friday night fun into an armed shouting match about discerning customers dissatisfaction with current offers, I wanted to try on a thought model that's been stuck in my mind all week. (I've tested with no less a cloud expert than Mr. Swidler himself)

The constant cries of "commodity" in the cloud really revolve around a unit of CPU, memory and operating system. If your application is executable within one of these modest entities, ideally running in parallel on another for availability because the platform doesn't guarantee it, the cloud of today works pretty well. 

I call this the slime-mold model. Slime mold is a relatively unique protist, existing as a single cell organism until an abundance of resources appear, when they release a signalling chemical, and join into a larger but very basic organism. None of the cells are specialized, and the cytoplasm around them gives them only a very sparse inter connectivity and protection. 

Yet when uber application innovators such as Facebook talk about building complex applications cellular specialization is very important--I call this the neuron model. Even Google, known for only using commodity CPU/memory combinations organizes them not in vast data-center seas, but in 250 CPU switched clusters for performance and manageability. Because requests on Google or Facebook require hundreds of server to server messages each, the network locality of these servers, their performance and precise arrangement and configuration matter. Mr. Gourlay in fact suggests that in today's data centers 90% of all traffic is server to server. Corporate data-centers today, where much of the IT spend occurs, have even greater needs and requirements for specialized organization, tuning and configuration. In the thick cytoplasm of some public clouds today, there is very little QOS or SLA on the performance of that server to server traffic. 

The neuron is the ultimate example of cellular specialization. Slime mold doesn't have any--consuming simple food through massive parallelism doesn't require it, but if you are human there are 100 trillion specialized synaptic connections between your neurons. These are made possible only by a complex approach to organization--while your core cells are similar, one might say commodity, the way in which your DNA (software) allows them to organize, specialize and connect is anything but a commodity across biological existence. 

While the model is imperfect, it fits many of the themes from this last week. It also informs the future of the cloud. Will all computer applications become highly suitable for a slime mold model cloud? Or will the ability to create network constructs, compute in tight proximity, and future features we haven't dreamed up yet allow those currently on the sidelines to join the fun. 

Right now as is evidenced from Mr. Hoff's post above, the two sides are shouting at each other from the extremes. I for one hope we get the ability to form more complex topologies in public clouds very soon. 

 

 

 

 

 

 

Today @joeweinman kicked off a thought provoking piece, outlining some of the latest thinking in behavioral economics and applied it to the cloud computing market. Unlike Joe, I'm not a deep expert on all of the cognitive science behind these economic models, but I have a pretty simple equation that has pragmatically guided my working life straddling the business and technology DMZ. 

Want to see it? No problem I've written it out for you in my notebook:

What are the variables? Its a very simple construction:

P= Perception

B= Benefit

C= Cost

V= Value

The most important part of the equation for me is that P is multiplicative; it can go to 0 (no awareness, or complete bias), or it can get much lager than B itself. I view many of @joeweinman's 1-10's as expert methods of describing a range of the P effects in buyer behavior. 

Second, the P value affects both B and C, independently, and could rightfully be described as a separate trail each time its called (P1, P2 etc). Joe's rule #8 is a great example of cost perception irrationality/shift. 

Businesses are always looking for core "use case" examples and customers for new technologies, precisely because the 'P' variable is so powerful. Even intelligent customers can't always discern the validity and benefits of a new technology without some supporting social proof and narrative (we are sick of Animoto, but it was an epic social proof to the web-start up community around the cloud story). 

This simple math leads to a V output: sweet, a customer now has a value ranking for the offer. 

Now the magic really happens: time for marketing theory to kick in. We need to define the 'zone of tolerance,' or the range in which variability in ratios of offering V1, to offering V2 will not result in a change in buying behaviors. This can vary by product categories, but generally if an offering has a more than 40% higher V rating it will be seen not just as an alternative, but as a whole new category unto itself.

As an extreme example, compare the costs of buying and provisioning a new server and database from scratch with or without a cloud computing offering. For a buyer looking to have such a stack provisioned in less than a few hours the ratios of costs etc between traditional and cloud oriented offerings would be in the thousands of percent ranges. That buyer might also be less concerned about the long lasting operating variables of the solution--their need was immediacy. Sound familiar? This is exactly how cloud computing began to dominate the purchasing behaviors of undeserved developers even in large enterprises.

Its why the #1 template on Rightscale is an all in one LAMP development stack in a VM. 

P has classically also had very strong association with brand based powers. Its interesting to see how people will potentially leverage their brands to affect the customer P in the cloud. A few off the cuff thoughts:

Microsoft: Integrated, easier, all in one

Amazon: lowest cost, highest convenience 

VMware: Highly adaptable, portable/flexible, uniquely powerful engineering, next generation stack  (disclosure, I work there, but I'm not speaking for any official party line, just some thoughts) 

Rackspace: customer commitment, customer commitment

IBM: trusted advisor, holistic researcher, can I sell you a mainframe

As I observe the powerful swirl of emerging customer use cases, product launches, brand reinforcement, FUDing, and more I keep this little equation close by. It might not always tell me exactly how to formulate the the all important P variable, but it gives me a framework for understanding what's at stake, and how, at a high level, market competition is taking place. 

This week no fewer than four people I respect in the cloud ecosystem cautioned me not to get to enraptured with cloud APIs. The argument was similar across their critiques: lots of talk about them, very little buying through them, they are interesting for geeks and obscure outside that circle.

I was shocked--but my shock in itself was alarming to me. Am I over rotated on the broad platform characteristics of cloud computing? Are cloud infrastructure services more valuable as a complete resource management applications than as modular horizontal platforms? 

The argument against API centrality, as far as I can surmise goes something like this:

Chill on the API love fest man. What really matters are the core functions of resource management, provisioning and user management. What's really new about the cloud isn't an API, we've had those, its the standardization and control of server and network resources en mass. Also, wake up, most people are going to consume whatever prescriptive GUI framework the cloud provider puts forth and be happy. Customers of XYZ big hosters are going to pay far more for a portal experience than an API. 

Here is my critique back:

1. A buyer, is not always just a buyer. Say 90% of cloud resource 'buyers' use a non API method of consuming resources. This doesn't refute the importance of the API. See reason #2.
2. Innovation happens elsewhere. Twitter knows this well. Do you use Twitter or do you use Tweetdeck on the Twitter platform? Assuming you follow the logic of the resource, network and user management argument above--it actually should create more incentives to open up an ecosystem of potential consumption and integration methods. The cost of creativity gap between a large organization, and a lean entrepreneur to create value ad above the core provisioning management system is vastly different. Twitter is a relatively simple distributed messaging system; the possibilities in infrastructure and data services are even greater. 
3. Heroku, Engine Yard, JungleDisk, Storsimple; these are not just alternative management and control GUI's, they fundamentally ad another layer of real value. They are early examples of #2--and these are very early days. 
4. If you are really pursuing a managed hosting offering where the customer is more interested in the service relationship than the platform automation and compatibility the API may definitely be less relevant. The managed hosting marketing is also orders of magnitude larger than the current cloud infrastructure market; however, none of that means the attributes of the managed hosting market = the cloud infrastructure market. They are juxtaposed but separate along key strategic axes. 
5. Smart buyers with long term vision care about the API story for all of the above reasons. It is a necessary but not sufficient aspect of the offering to them--but again bad logic to confuse sufficiency with necessity. 

*

The question behind the question has to do with the strategic nature of cloud infrastructure services in the long term. Are they a corner case deployment, a hackers liberation sandbox with some interesting but limited mutations, or the fundamental platform of the future?

I have opinions there :)

 

 

Seth Godin really nailed it in his blog today:

Initiative is very difficult to teach to 28 students in a quiet classroom. It's difficult to brag about in a school board meeting. And it's a huge pain in the neck to do reliably.

Schools like teaching compliance. They're pretty good at it.

To top it off, until recently the customers of a school or training program (the companies that hire workers) were buying compliance by the bushel. Initiative was a red flag, not an asset.

The Atlantic found a similar correlation between initiative (leadership outside a classroom) and success in teachers in low income schools: 

Things that you might think would help a new teacher achieve success in a poor school—like prior experience working in a low-income neighborhood—don’t seem to matter. Other things that may sound trifling—like a teacher’s extracurricular accomplishments in college—tend to predict greatness.

What the heck does this have to do with cloud computing? Well previously I said:

Cloud infrastructures are the ultimate friend of the unproven idea. The impulsive act of computational creativity not worth pushing through a heavy-weight process.

Taking a step back didn't Columbus spend 7 years lobbying various Monarchs for the capital to try his geographic experiment? Wikipedia tells us the first time he asked for money:

The king submitted the proposal to his experts, who rejected it.

Eventually his initiative and salesmanship succeeded. Ultimately it took him only five weeks to sail to North America. That's right: seven years of debating the voyage--five weeks to find success.

The other fascinating suggestion the Wiki post makes is that the one thing he got right was the wind patterns--that is, the trend, the vector of environmental change. The king's best mathematicians all were fixed on the world being larger than Columbus suspected, crunching the numbers in their 10 year business plan to get to China. The key turned out to be the wind patterns not the ultimate destination. Anyways somebody smarter about VC like @adventurista should write a post on that.

*

The migration of economic control from the 1400's until now is pretty stunning. Its all about how important of a person you had to ask to really get something exciting done. Seth's blog is timely precisely because of this trend. We need a different approach to education because we are entering a phase where the opportunity costs for individuals as well as corporations suppressing initiative are growing.

Sound too radical? Think again, its an increasingly main-stream view of the impact of cloud computing. Check out the recent "Get I.T. out of the boardroom" cloud computing marketing campaign from VMware. It features the company COO. 

But its really not as simple as "let everyone take their own initiative," companies will need thoughtful, policy rich, and technology enabled mechanisms of dolling out this increasing license to self-starting projects and development. The current architecture divide between classic enterprise IT and developer driven clouds is too wide. We need technology to help create a spectrum of user control--not just at the IaaS layer, but at the PaaS layer as well. 

The companies, and economies, that learn how to re balance traditional ideals of control vs. initiative will have major, and I think, strategic advantages.

@GeorgeReese did something pretty cool today. He dared to ask how much a traditional security approaches were really worth vs. a cloud based approach. Yes, the discussion was short on heavy details--but it put a very pointed dollar sign bullseye on the most cited hesitation about cloud adoption over the last two years. 

His simple point reminded me of a Ron Paul talk that asked how much foreign policy and military should be costing the US. I'm not very political or deep on the topic-but I know market positioning, and not too many politicians were asking the question in such a pointed way--it stuck and created a mini-movement. 

If the only answer the establishment can give is "well that's how much we have always spent" the question succeeds in its purpose--to show the prior spending to be ritual and habitual. 

@beaker was up to the task of peeling back the onion on the argument, reminding us that while the cost of running an IaaS might be lower, the cost of VM/Application security might be similar. He also asked what if the cloud approach and vulnerability resulted in a near complete loss of data.

 That question left me wondering if the improved economics of the cloud won't open the door to very interesting advances in security survivability. Its one thing to ensure against any potential breach--but if we can elegantly run our applications across 10's of data-centers for similar costs as we run it in two home grown ones today--shouldn't it be easier fail over redundantly against attacks just as we do against hardware failures? Obviously this is a complex issue, and there are almost always single points of failure in any system that a truly dedicated and genius attacker could assail..but isn't this how Twitter account security really works today? Everyday I hear of somebodies account on Facebook or Twitter getting hacked...but the services overall and the average user experience remains feasible. 

Redundant arrays of less expensive clouds... an interesting topic. 

Finally, and most tactically important--this is an opportunity for cloud providers to showcase their security procedures and protections. The time is 'now' to help create powerful cloud audit and security procedures, technology and products. The more clear a cloud's security story is the more chance it has to drive disruptive levels of adoption. There is clearly room in George's model for the IaaS to be more expensive and still be compelling. Smart cloud providers will invest in security related features, differentiate themselves from a race to the bottom, and capture the most lucrative part of world-wide infrastructure spending.