Sun Sees Amazon Changes the Game Even for Hardware Vendors

The announcement that Sun has partnered with Amazon to make Open Solaris available on Amazon Web Services is fascinating.  It’s free, so Sun sees no revenue from it.  One wonders if Amazon has charged them for the inconvenience, so it may carry a cost.  In fact somebody somewhere paid a cost to at least cover the testing and development of whatever provisioning is required to get it started.  So why do it?

At the moment, Amazon is running away with the cloud computing show.  Last I heard there are over three hundred thousand developer accounts there.  It’s a thriving ecosystem, and if Amazon sold no more new customers, one has to suspect that just the growth centered around those existing customers would be significant.

Suddenly, this is a platform that matters for everyone that is trying to establish their own platform.  If you want your OS (Open Solaris) to have a chance, you’d better look into Amazon Web Services.  There is no Microsoft equivalent yet, so that’s a problem.  As I’ve said, Ballmer would’ve done better to buy Amazon than Yahoo, so perhaps now he’ll give that a try.  If you want your database or application server (hello Larry Ellison) to thrive, you’d better look into Amazon Web Services.  If you want your language (hello Python, Ruby is already there with Heroku) to be ubiquitious, you’d better look into Amazon Web Services.

In fact, as if to underscore this realization, the Amazon partnership is just one aspect of Sun’s official launch of Open Solaris.  But, it is a critical one.  It will be interesting to see how well it does, and whether there are aspects of the Cloud Computing world’s needs that give it any special advantages.  I’ve heard of a few things, but it hasn’t really sounded compellling so far (see Jason Perlow for more).  There’s an awful lot of momentum behind Linux already.

The availability of Amazon Machine Images does another thing.  These are freeze dried snapshots of a particular collection of software installed on a machine.  This makes them easy to propogate.  The best practice combination of various pieces of software can be combined, converted to an image, and made available for broad consumption.  This lowers operating costs and helps ensure that the “good” combinations are more prevalent in this ecosystem.

Sun’s announcement is a fasciniating indicator of just how important Amazon Web Services has become.  Look for more indicators as we go forward.

Bug or Architecture Flaw? (Fail or No Fail)

Blaine Cook, Twitter’s lead architect, has left the company.  Predictably, the blogosphere is flaying him pretty good.  Michael Arrington asks , “Amateur Hour Over At Twitter?”

Ouch!

Blaine, I feel for you.  People expect and are pretty tolerant of a few bugs, but the problems at Twitter have been going on for long enough that it’s clear there were deep-seated architectural flaws that were not going away very soon.  Twitter is taking the right steps–they’ve got a new VP of Engineering and Ops as well as two new scaling experts.  Cook, rightly or wrongly is firmly under the bus.

What follows next is important.  The new gang has a limited window in which to fix the problem.  This won’t be easy.  Fixing deep architecture issues on a live system that can’t keep up is one of those nightmare scenarios that’s painful beyond belief. 

What can we learn from this? 

First, Twitter is just the latest example of an important service that has all the ingredients for success except for the ability to scale properly. 

I gave up for the last time on Technorati not long ago for similar reasons.  For a long time it was my blogging hub.  I used it for search and to monitor how well my own messages were penetrating the blogosphere.  But it was wildy inconistent.  It was easy to switch to Google for Blog Search, after all, they are the search experts?  But that Technorati Authority seemed like it was worth hanging around for. 

And then one day my Authority dropped almost 100 points.  In one day I went from over 300 to just a little over 200.  What’s up with this?  I waited for it to come back–at various points in the past, something similar had happened and then corrected itself in a day or two.  No such luck.

Eventually, I stayed away long enough, that it was time to log in again.  I didn’t remember my account info, so I simply searched for SmoothSpan to find my blog.  There was my answer for what had happened:  I saw two SmoothSpans!  One had my old over 300 authority, one the new authority. 

But I could tell neither was really right.  In other words, the true authority was some mix of sites from one and some from the other.  Thinking about how this could happen revealed a classic architecture flaw: Technorati had created more than one record for the same thing and couldn’t keep them straight.

Twitter’s situation is similar.  Supposedly they were rolling out a new caching system of some kind when their latest troubles hit.  Caches create more than one copy of the data intentionally, to make it easier to scale.  The trick is to keep it all running smoothly and to feed the cache from the one true version of the data.

Second learning point:  It may be a bad idea to worry about scaling later.  This topic has been debated from time to time.  Some have advanced the notion that to worry about scaling up front is a premature optimization.  Scaling is not a premature optimization!  It is fundamental architecture.  The number of developers who can deliver a highly scalable web property is a tiny fraction of the number of developers who can get “almost there”.  The difference between having one architecture versus the other is a healthy heaping of FAIL.

My last company, Callidus Software, understood scaling.  We got it so well it became a major differentiator for the product.  We could literally go to customers where the likes of Oracle and SAP (who supposedly understood scaling) could not go because their systems wouldn’t handle the scale.  There’s nothing quite like being the only game in town for a big customer that has to have a solution.

Scaling is something the Cloud Platform world may eventually deliver for us.  So far, they are more about Utility Computing, which is the ability to add more machines quickly and easily.  That’s Amazon’s model.  Whether your software can use more machines (i.e. whether it scales), is up to you.  Teasing apart the aspects of an application that make it scalable and handing them over to a platform will be a ticklish business.  It’s likely to a good deal of rewriting.  But either way, your team can get it right the first time, do a rewrite under fire, or rewrite for a Cloud Platform that shows how its done.

Does your team understand scaling?  Really?  How do you know?

Related Articles

A recent interview with Blaine Cook.  Interesting note on eventual consistency: Twitter only allows API’s to update once per minute.  The team is 5 full-time developers and that includes 1 new person.  Tight team, but that’s good.

Michael Arrington mentions he read this post in a Seesmic video.  Scan down through the comments to see it.  He’s involved in a big slugfest over whether this was character assassination on Cook, whether the fault lies with Ruby on Rails, and so on and so forth.  It’s important not to lose track in all of that emotional content of the main issue here, which is that scaling matters, a relatively small set of developers have lived through it and know what to do, and it is hard to fix after the fact.

Despite the fact that there’s basically a flamewar on Techcrunch over this, others seem to reach a similar conclusion.  Larry Dignan has a good post over at ZDNet.

Microsoft Mesh: All Your Devices and Data Are Be Ours

I’ll bet your blog reader is probably overflowing with posts about Microsoft’s Mesh announcement this morning.  Sorry to add one more, but it is an important announcement and there is some analysis I want to get out onto the table.

Mesh Product Director Mike Zintel sums up the Mesh vision well: 

“The coolest thing about Live Mesh is how it smashes the abrupt mental switch that I have to make today as I move between being ‘on the web’ and ‘in an application.”

“At the core of Mesh is [the] concept of a customer’s mesh, or collection of devices, applications and data that an individual owns or regularly uses. The Mesh Account Service persists the relationship among these resources and authorizes access to them. The mesh is the foundation for a model where customers will ultimately license applications to their mesh, as opposed to an instantiation of Windows, Mac or a mobile account or a web site. Such applications will be seamlessly installed and run from their mesh and application settings persisted across their mesh.”

Ray Ozzie adds to this that the Web is “the Hub of our social mesh and our device mesh.” And goes on to say that, “in scenarios ranging from productivity to media and entertainment, social mesh notions of linking, sharing, ranking and tagging will become as familiar as File, Edit and View.”

Mesh starts out for individuals, which I suspect is intended to minimize adoption friction.  Lots of cool sounding functionality has been considered and incorporated into the design.  There are objects that range from data to applications, and data is not limited to files.  There is some sort of role-based security around these objects, and objects can be stored in all sorts of places.  Most importantly, there is pub/sub synchronization, replication, and update alerts and feeds to keep people aware when changes are made.

At the moment, Live Mesh is an invitation only “Technology preview.”  The current version only does synchronization of Windows computers, but its intent is to extend to other devices.  Mobile and Mac are promised within the next year.

How is this really different?  Josh Catone mentions similarities with Dropbox, SugarSync, and Microsoft’s own FolderShare.  Interestingly, I’ve seen a demo of software that syncs across PC’s and mobile devices not long ago from SoonR as well.  It works today for a number of devices.  Their motto is “The Anywhere Workforce.”  I vividly remember a couple of years ago seeing a PowerPoint slideshow played back over a Motorola Razor at my home using SoonR.  How long before Microsoft has made it that far?

As Catone points out, the difference is that Live Mesh is intended to be a platform.  It is feeds of all shapes of sizes plugged into your data and applications.  These feeds are used to sync your data objects, and to keep you and others abreast of when these updates are happneing.  Since its a platform, the feed mechanisms are open and accessible to third parties.  There is a demo, for example, of Twitter tweets being synced to the Mesh Notifier.  Clearly Microsoft will want a piece of the burgeouning feed aggregation world.  FriendFeed and friends look out!  In addition, there is an offline component too, which provides one possible answer to the likes of Google Gears or Adobe AIR.

In a nutshell, that’s what Live Mesh is, now what does it mean?  Will it work?  What can we do to prepare for it?

Analysis

Scoble loves it.  A veritable toolbox of feeds going every which way.  Everything is a feed, including your, um, feeds.  I’m not surprised Scoble loves it, but his description doesn’t make it sound like the one highly differentiated must have thing that will keep Microsoft a vital part of all our lives.  In particular, if your promise is connectivity ala feeds between all things, how does that reconcile from this passage from Scoble:

Unfortunately they aren’t even close to being finished. Mac support? Coming in the future. Nokia support? Unclear. iPhone support? Ask Steve Jobs (translation: will be very limited due to Apple’s complete control of that platform). Firefox support? Yes! Linux support? What’s that?

Can a ubiquitous “operating system” to store all your data, manage all your feeds, and connect it all to every computer and mobile device you own succeed if it is owned and operated by a company whose reputation is to take unfair advantage of any access you give it?  Isn’t this the very poster child of what you would want to have be very Open Source and very Swiss in its dealings?

Phil Wainewright sees this issue clearly when he brings up “how the company seems to lurch from launching fresh, Web-savvy solutions one day but then falling back into its crusty old server-centric habits the next.”

Clearly such a platform will rely on third parties to get excited about supporting it.  Will Steve Jobs let it onto the iPhone when he hasn’t even allowed the Flash Player?  Will Sony support it wholeheartedly when they see the XBox team has a huge lead on them because of the usual Microsoft “our guys get all the early advantages” ploy?

Erick Schonfeld captures the flavor of a nagging doubt that has been in my mind.  He sees Live Mesh as a response to efforts to take browser-based apps onto the desktop and into Microsoft’s face.  Live Mesh is taking applications off the desktop and pushing them into the Web’s face.  They demo geneology changes being updated whenever a family member makes a changed, but Erick points to web-based Geni which already does this automatically.

Which one is better?  Do you want lots of copies of data being synced, or one copy being edited collaboratively by many?  This debate has been waged for years, but the general consensus has tended towards one copy with collaborative editing.  Desktop-think wants to keep going the other way.  And, it is very convenient if it’s just you in charge of your data–this blog with me editing it coming to many of you via RSS.  But, if many of us have to work on it, a Wiki is a better idea.

The Live Mesh vision is then useful, but probably overreaching.  It isn’t the “one great thing to restore Microsoft’s dominance.”  There are a lot of questions about whether Microsoft will reach a critical mass in getting others to play along with it.  Suppose they follow their standard playbook (and I see no deviation yet):

- Get their teams early exposure.

- Preannounce to freeze the market.

- By the time others can get there, the Microsoft apps are all doing it better than anyone else will be able to emulate for some time.

- Use this as the competitive edge to increase share for Microsoft apps and position the others as being “not quite up to the Windows standard.”

That strategy doesn’t work in the web world and will backfire mightily if they try it.  Imagine LiveMesh with nobody but Microsoft’s apps talking to it along with whatever files they can drag along and other open API’s that their own engineers tie into.  It becomes a modestly useful feature, not a platform, provided it is well implemented.

Here is my next concern.  There are 100 engineers at work on Live Mesh already, and lots of key functionality (like version control) nowhere in sight.  Aside from the Tactics of Monopoly, the other Fail mode is creating a giant monolith of software.  Vista is a painful example of how far things can go wrong.  Mesh is, at its core, another attempt to rework the document and folder file system.  Microsoft promised this in Longhorn for years but never delivered.  Now Microsoft is adding to that challenge the need to build something that (sorry!) meshes well with the web.  That’s no small order.

Many are saying this is all Ozzie and is his third iteration of a vision that started with Lotus Notes.  Groove is another one, lest we forget that.  Is this the right vision to be on?  Did the first two iterations demonstrate enough goodness that we want to build this stuff into the OS and fabric of every PC and device we own?  It doesn’t seem like it, but perhaps.  OTOH, what if we were all using an online backup service of one kind or another (Mozy et al), and we could access the backups from any device, publish an RSS feed of the versions, and so on. 

The world used to say Microsoft gets it right by the Third Try.  Microsoft is a little slow.  After the Third Try comes Fourth System Effect (with appologies to Brooks’ Second System Effect) where they go way overboard and manage to produce a Vista.

Lest I leave on that purely negative note, it’s always helpful to ask what they should have done or what they should now do.  It’s the “What would Google do?” sort of game, although it’s more like, “What do modern web companies in general do?”  Google’s recent AppEngine announcement is a prime example that touches all the bases:

-  Start small:  one language (Python), one application type (web apps).  You can build something small quickly without 100 cooks in the kitchen and make it tight.

-  Involve the community:  10,000 betas, first come first served, no special favorites and ramping up almost immediately to 20,000 betas.

-  Be open:  SDK was open sourced day 1.  It didn’t take long for the community to take the SDK and bring it up on Amazon Web Services.  Google doesn’t care, it’s all good.  It’s Open.

-  Piggyback on an innocuous beginning:  AppEngine is built on technology Google had created to do lots of other things internally.

-  No special advantages:  Google usually integrates after the launch of a new service so that everyone is on an even playing field and the service gets out the door faster.

There are lots of ways a service like LiveMesh could’ve followed this formula.  I’ll let you fill in the blanks, but consider this too:  there are a fair number of organizations out in the wild that can follow such a formula (and some are already far along the path).  We don’t really need Microsoft to get there.  That’s the piece Microsoft needs to wrap their heads around better.

BTW, the mental barrier between being on the web or in the application (going back to Mike Zintel) is already broken.  I don’t feel it a bit when I spend most of my day in the browser using web apps. 

I guess this is what Microsoft is worried about.

Amazon Rolls Out Better Service: The Cloud Wars Continue

The good stuff just keeps right on coming in the Cloud Computing world.  No sooner do we get the Intuit QuickBase announcement than Amazon is piping up with news that they now have Gold and Silver Premium Support Plans. 

The rates on these plans are pretty comparable to what I’m used to from the Enterprise Software (e.g. the bad old perpetual license) world:  10% for Silver of your monthly Amazon fees and 20% for Gold.  What you get is:

Both plans include fast and predictable response times, an unlimited number of support cases, and personalized support from our team of developer support engineers. Because it can be tricky to figure out exactly where a problem resides, developers with AWS Premium Support also have access to a set of client-side diagnostic tools.

The Gold plan also includes round the clock (24 hours per day 7 days per week 365 days per year) coverage, telephone support, and 1 hour maximum response time for issues designated as urgent.

I have to say that while I can see the premium support is valuable for those who view Amazon as Mission Critical, something about it just doesn’t feel right to me.  I guess it’s just that it’s a holdover from the old days, and costs about the same in terms of being a percentage of what you paid for the software/service.  It feels wrong to me because SaaS is a Service, so why do I need to pay for Service? 

It also doesn’t feel right that it costs about the same as my old perpetual license maintenance contracts.  SaaS is supposed to be cheaper, and it’s supposed to be demand-driven.  I’d expect to have fewer incidents too, so given all that, I would have felt better about a by-incident fee.  In other words, Tech Support On Demand.  Don MacAskill at SmugMug apparently feels the same way.   Commenters on SmugMug also bring up another way of looking at the, “Didn’t I already pay for the Service?” issue when they say that the SLA situation has still not been adequately addressed.  Likewise, the comments over on TechCrunch have others echoing, “Why must I pay more when I already bought a service I just want to have work?”

Perhaps this is just a temporary bout of cognitive dissonance.  The fact is, you’re paying for additional service and this is a practice that other SaaS companies follow.  It should also be a fact that you will need it a lot less from a SaaS vendor but you’ll probably still want to have it if you view the service as mission critical.  Unfortunately, you pay the same regardless of how much you use it, which is decidedly not-SaaS.  In general, the service ought to just run. 

Amazon is in an odd position too since they deal with your code in their cloud.  That’s going to create more opportunity for cases where the experts in Tech Support are needed to help you figure out what’s happening and how to fix it.

This is a good move for Amazon, and it also signals we’re starting to move out of the Platform-as-a-Service as an experiment stage and into the PaaS as a production business reality stage.  As others have commented, it’s a natural stage of maturation.

Phil Wainewright suggests that this about Amazon getting serious towards the Enterprise.  Stacey Higginbotham and Josh Catone echo much the same sentiments.  It’s a step, but there is so much more that Enterprise IT hits you with when you want to sell to them that I have a hard time seeing it as a big push, but it’s a step.  Everyone, of course, says they’re serious about the Enterprise, but there is a lot entailed.  That’ll be the topic for a blog post here at some point. 

I think Phil’s most telling insight is that Enterprises want to be able to ask their support questions in private so nobody can see their dirty laundry.  That’s worth paying a little bit for. 

 

Get Ready for the Affinity Platforms!

What’s an Affinity Platform?  That’s what I’m calling the mix of a Cloud Computing Platform with an already-successful application.

Geoffrey Moore says that you dare not launch a platform until you have a successful application.  There are, of course, counter-examples to this.   Amazon Web Services is my favorite case where there was no already-successful application.  Amazon EC2 and S3 had little to do with Amazon’s core business from the perspective of the customer.

But in the main, Moore is right.  Why adopt a platform unless there is synergy beyond the platform making your developer’s lives easier?  If it is attached to a successful application, the platform can offer so much more.  For starters, customers hope to gain some demand generation (e.g. sales leads and faster adoption) by drafting behind the already-successful application.  That’s very valuable when you look at the cost of acquiring customers for most businesses. 

Who Has An Affinity Platform?

Intuit are the latest to the party.  See my breaking news blog post for details.   The application here is QuickBooks, and to a lesser extent QuickBase (lesser only because there are fewer customers!).  QuickBooks has a base of 3.6 million users according to Intuit, so it is indeed a very successful application.  What Intuit has done with their SaaS platform is to provide instant integration to data in their SaaS QuickBooks, as well as to make the community available to developers on the platform.  It’s hard to imagine not wanting to tap into that SMB installed base if you are building something remotely business-oriented.

Salesforce.com is probably the original Affinity Platform (Cloud Computing + Successful App).  Force.com lets you build apps that seamlessly connect to Salesforce’s CRM data.  They have a thriving ecosystem in terms of numbers, but most of the developers I talk to find the cost of Force.com is prohibitive to build a company around.

Facebook:  Yep, they have a platform, hugely successful applets, and a wildly successful application.  The formula works on the consumer side too, not just business.

FlickR just announced a new website dedicated to developers, and they’ve had API’s for quite a while.  I’m not sure I would quite call it a platform, but a healthy set of API’s to help spur an ecosystem is a worthwhile start for any company that owns a thriving application whose data is online.

Who Should Get An Affinity Platform?

Amazon:  Funny, but why wouldn’t AWS tie in much better with the retail business?  Perhaps Amazon would say it does, and that is somewhat true, but the tie in goes out not in.  I can use the billing service (outbound to me), but I can’t write cool apps that work well for Amazon’s retaillers.  What if, for example, I wanted to write an app that gives the retaillers up-to-the-minute competitive pricing and let’s them adjust their offering prices in real time? 

Adobe:  I was thrilled to see Adobe get involved with the Intuit announcement.  But, there’s a lot more they could be doing.  They have a growing coterie of SaaS apps including BuzzWord and PhotoShop Express.  They’ve got Flex, which is very valuable for any platform.  It’ll be interesting to see how Adobe plays it.  If they run too headlong out there, they may be in competition with those they want on their side.  For example, both Intuit and Salesforce are involved with Flex.  Sarah Perez has a great post on Adobe’s Online Empire.

Oracle/SAP:  Interesting conundrum for these mega-players.  Traditionally, they want to own an awful lot, so it’s a bit hard to completely trust them.  Yet, they clearly have ecosystems.

Google:  Yes, they have a PaaS offering in AppEngine, and a killer app in Search.  How can they get the two together?  With Yahoo cutting search engines out, Google can do the opposite and be more inclusive.  One of the issues for interactive apps is getting everything indexed.  Dynamic content is a lot harder than static, and indexing inside something like a Flex application is also hard.  Google could fix these problems in interesting ways.  Search inside a database is also a common problem that Google has the means to fix.

Microsoft:  Another dilemma for these guys.  They’ll argue they’re already doing it (as big companies often do), but the problem is that they don’t really have a cloud platform yet and most of the data from their successful apps is not in the cloud and is therefore not very accessible.  I think the best starting point is Exchange and Sharepoint.  Again, they’ll argue they already do this.

EMC:  You’ve got a ton of backups from people’s PC’s and small businesses inside your cloud via Mozy.  Backup is your killer app.  What can you do for them as a next step?  What apps would you write for people to access if EMC had a platform that tapped into this stuff?  Seems like it might make the ultimate desktop/mobile/whatever else syncing environment if nothing else.  Maybe you could also seamlessly migrate people to cloud apps if they wanted to go there.

Anyone else that has a highly successful application with tons of data in the cloud should be looking at how to leverage that in the platform world.  BTW, you don’t have to build a soup-to-nuts platform, you just need a way for people’s apps to be enabled to what you have to offer.  Most of the app may even run somewhere else and just call on your platform for services. 

eBay:  Hugely successful app, but seemingly plateaud.  So many things work well as auctions, eBay could launch a platform play.  For example, frequent flyer miles and other affinity programs.  I can’t remember the last time I got a First Class upgrade from my miles.  It should be possible to bid miles and auction off the benes to whoever bids the most.  Better for customers as they can get stuff they need.  Better for airlines as they get the miles off their books faster.  Better for eBay because it opens up whole new lines of business.

Who Should Use an Affinity Platform:  Sales 2.0 Opportunity

Anybody that needs customers and demand generation for starters.  Forgot rewriting your entire app for any of these platforms.  What is a minimal module that plugs your business into the ecosystem?  Everyone I talk to that is plugged into Salesforce looks to them for this purpose.  They get two benefits.  First, there is a halo effect from being connected to a successful application and platform.  Second, they get sales leads from the ecosystem.

Network Effects

The Cloud Computing world is rapidly growing up.  There’s tremendous new functionality that’s been announced in just the last six months or so, and no doubt a lot mroe is on the way.  There’s been talk and concern about lock-in.  Overt lock-in isn’t going to work, but Affinity Platforms have a more insidious kind of lock-in. 

Ultimately, there isn’t just one cloud, there are many.  And, it’s costly to shift data between clouds.  The best advantage will be had if apps run in whatever cloud hosts the system-of-record data they need to operate on.  Companies like Intuit control hugely valuable data of that kind.  Once your app and customers are used to easily plugging into that data, it’ll be pretty hard to go elsewhere even though it will likely be technically feasible.

Amazon Announces Persistent Storage for EC2

This is big, big news for Cloud Computing.  A whole new layer of robustness and convenience has been added to Amazon’s EC2 service.

One of the biggest obstacles users of Amazon’s EC2 cloud machine instances have to overcome is persistent storage.  Amazon refers to storage on EC2, at least in the past, as “ephemeral“.

If something happens to your EC2 instance, the data is lost.  You can’t simply reboot like a real physical machine and get back to where you were.  This is a real problem when hosting your MySQL or other database.  It’s a really bad thing if the EC2 instance goes down and you lose all your database data.  Developers have been working around it, and there is even a startup or two focused on such problems, but it has been a real thorny issue.

Now Amazon has announced that you can simply mount some S3 storage on your EC2 instance and run with that.  Simple.  To the point.  Powerful.

To quote Amazon:

These volumes can be thought of as raw, unformatted disk drives which can be formatted and then used as desired (or even used as raw storage if you’d like). Volumes can range in size from 1 GB on up to 1 TB; you can create and attach several of them to each EC2 instance. They are designed for low latency, high throughput access from Amazon EC2. Needless to say, you can use these volumes to host a relational database.

To quote one of the commenters:

“Needless to say, you can use these volumes to host a relational database.”

… and that’s the line we’ve been waiting for. w00t!

Needless to say, it is the line the vast community of AWS users have been waiting for.  Well done Amazon!

Also pay attention that this is a “low latency, high throughput” connection.  That’s also big.  S3 is wonderfully robust, but it has had latency and performance issues that somewhat slow its use for a high performance case like relational DB table space.  It appears that Amazon has opened up a special channel for this purpose that overcomes these issues.

So far this is just an announcement, and the service is not yet available for general consumption.  One wonders a bit whether the announcement isn’t a slight bit of response to Google’s AppEngine rollout, but who could blame Amazon?

One of the big back and forths in the Cloud Wars is going to be the use of standard relational databases like MySQL versus specialized “Cloud” databases like SimpleDB and BigTable.  Amazon just made it easier not to have to choose.  With AWS, you can go either way.

Hurry, The Cloud Computing Platform Opportunity is Perishable!

As I write this post, many are predicting that the big announcement from Google tonight will be that it’s opening up BigTable for the world to use.  At least Kevin Burton and Mike Arrington think so.  I hope so, because the world needs a lot more cloud computing choices.  I wonder how many have figured out just how little time remains to introduce new cloud computing platforms?

Ray Ozzie has said, “[the cloud market] really isn’t being taken seriously right now by anybody except Amazon.”  He’s right on the mark:  it isn’t being taken seriously by anyone except Amazon.  The distant runner up is Benioff’s Force.com.  I say distant because there are a lot of problems with it, not the least of which is an economic model that makes it completely untenable for anyone but big corporate IT to use.  Technically, it is a completely closed and proprietary environment that offers only minimal leverage.  It’s true, they’re very seirous about it, so in that sense we should add them to the list, but the way they’re going about it makes it seem less than serious.

Here’s an important tip for various big industry players who’ve made noise about Cloud Computing at various points:  it’s a perishable opportunity!  You don’t have forever to contemplate how to get in and start winning.

Why?

Because ultimately it boils down to differentiation and commoditization like any market.  The longer you wait, the more bipolar the market becomes.  Allow Amazon to get too strong and you’ll have two choices:

-  Copy Amazon’s API’s very closely and charge a lot less. 

-  Launch a radically different approach that offers big advantages in some other way.

The middle ground will be untenable.  An API or service that is only slightly better than Amazon’s but is incompatible won’t succeed.  We’ve seen this time and time again in our industry.  It’ll play out the same way here.  For a brief time everyone can be slightly different.  Then the world will discover the differences don’t matter and they’ll gravitate towards one player.  If someone already has huge momentum (e.g. Amazon), you must either be incredibly differentiated or much cheaper.  Both are pretty hard to do.

We could ask whether Amazon has already reached a stage that only the two options can fly.  I don’t think so.  Not quite anyway.  It takes longer than you’d think, although their success has been phenomenal.  My prediction is that the window to introduce a major new cloud computing platform initiative is not quite 2 years.  If you’re not out by end of 2009, you will face a major uphill struggle.  In fact, if you’re not a great big player, the window is much less.

There are significant challenges for the big players to execute quickly enough:

-  Sun never seems to execute on anything quickly enough.  Sorry guys, but the company just doesn’t evolve very fast.  That’s why you’re buying properties like MySQL, right?

-  Google wants to be a precision machine, focused on squeazing margin out of a lucrative model.  What would they do, if like Amazon, they announced this thing and suddenly had more traffic to it than their core properties?  They have a history of absorbing startups and then taking a long time to get the thing to a level they feel is commensurate with their standards.  Cloud computing is in many ways worse.  They lose control and let other people’s software run inside their firewalls on their servers. 

-  Microsoft is in the unenviable position the old RISC world was in against Intel.  They have to build everything themselves on their platforms.  There is no synergy with third parties.  It’s ironic really.  The Intel/Microsoft PC Kiretsu could divide and conquer and they were so successful even Apple finally went Intel because the others couldn’t afford to do it themselves.

-  Yahoo?  People used to talk about them in the same breath, but clearly the wheels are coming off that stagecoach.  For a big player, cloud computing is not a little investment.  Particularly now when there is quite a lot of momentum already built.  Yahoo’s bets are laid, and they’re a lame duck besides.  Count them out.

-  IBM?  Could be.  They’ve made announcements but the follow up is weak.  IBM could certainly afford to throw enough services at the problem to get it going until the technology catches up.  They can sure sell such a thing.  The biggest challenge they have is their command and control culture may never let it reach critical mass.

-  Tata et al:  Big Indian or Chinese.  Why not?  These are huge companies overseas.  They have the expertise to do quite a lot.  The Asian markets are hot, hot, hot, and they’re not that well served by Amazon.  These guys would be my bet for the odds on Dark Horse players if they get it and can get their act together.  They’re ideal as low cost providers and like IBM, they can throw service at it until they get it right.  There is surprisingly little technology required at this stage to get started at the level Amazon is at.  You need an EC2 and an S3 clone and a bit of window dressing that does something they don’t.  How about an identity system?  I’ve written about that before.  Wouldn’t you think if a service was announced business would fly to it overseas?

Meanwhile, Amazon is coming to a sort of crossroads as well.  The traffic to Amazon Web Services exceeds the traffic to the rest of their properties combined.  This is no longer a remaindering strategy for unused MIPs as many VC’s I talked to late last year seemed to feel.  Amazon is now experiencing significant growth and scaling pains for the service.  EC2 just went down for about an hour for many customers.

This is both good news and bad news for Amazon.  The good news is that they’re learning how to keep these systems up and they others haven’t even started up that learning curve.  The bad news is it annoys customers mightily. 

The other thing I watch Amazon for is signs they’ll offer anything with AWS that they didn’t already have to build for their core business.  The availability of something interesting and new would be a further signal that this is not just a remaindering business.  More importantly, it would be a further barrier to entry and exit around their valuable property.  As it stands, EC2, S3, and SimpleDB are pretty low level.  They do not represent big barriers.  All that is available in one form or another via Open Source to others who want to play.  Amazon’s expertise in billing and payment processing is more differentiated, but not compelling and as currently offered, very Amazon-centric.

Note to Werner Vogels:  it’s time look for key innovations in AWS to build lock in while you continue to make the service more robust.

Note to others:  Time is running out.  Get in the game or move on.

Note to self:  Look for a dip and buy AMZN stock.

Related Articles

Google responded well to the challenges I set forth above with App Engine.  See my blog post for more details.  By focusing on language support instead of raw virtual machines, they’ve actually raised the bar in the sort of way I keep saying Amazon needs to above and below in the comments.  I stick to my 2 year prognosis.  If you aren’t a Big Player here within 2 years, the window will close.  What Google has done is raise the ante on what you must deliver to be in the poker game.

ISVs Say “No” to Force.com

There are a couple of interesting posts from Sinclair Schuller and Renee Boucher Ferguson about an incident that took place at the OpSource SaaS Summit in San Francisco recently.  Apparently Phil Wainewright conducted a show of hands survey about the attendees intentions with respect to SaaS.  They had three choices. 

From an audience said to be about 250 ISV’s, 30 or 40 plan to build their own SaaS platform but let someone else host it–they don’t want to build a data center.  That’s definitely something I’ve been saying for a long time and it resonates with what I’m hearing around the Valley.

10 hands went up on the issue of using some else’s platform as well as hosting elsewhere.  Okay, it seems to me there aren’t very many platforms to choose from yet, so not surprising the response is way down.  In fact, I’ve said before that a lack of good platforms has impeded the creation of new SaaS companies.  There’s too much technology to build in today’s capital-shy VC market where companies are expected to bootstrap to customers on just a whiff of capital. 

The last question was the kicker.  Asked how many would build on Force.com for their application, only 2 hands went up and they said they were undecided.

Opps!  This is not the press they were looking for, I’m sure.  The two pundits discuss several reasons why this might be the case including:

- OpSource’s Treb Ryan suggests people don’t want to foreclose the option to partner with other players besides Salesforce.

- Schuller says that Force was an extension platform for Salesforce, and isn’t necessarily a great general purpose platform.  He goes on to raise the issue of IP and Business risk trusting everythign to Salesforce’s proprietary language.  Lastly, he summarizes the value of Force.com as marketing, not product.

I agree with Sinclair on a couple of his points, but both of these articles miss the biggest reason why ISV’s avoid Force.  I’ll explain in a moment, but I want to comment on the other issues.

First, on the idea that Force is just an extension platform and may not be a good general purpose platform, again, I agree.  I’ve suggested in the past that Force suffers from being “Same Old Platform as a Service”.  It adds value, but it isn’t revolutionary.  In my opinion, the value add is not commensurate with forcing development in a purely proprietary and non-open language.

Schuller’s second point about trusting your IP to this company and its proprietary language is another one I agree with.  I’ve said in the past that Platform Vendors need to act like Switzerland, and Salesforce ain’t no Switzerland.

Okay, that’s fine and well, but are those compelling arguments?  Won’t a few go with Salesforce just to partake of their tremendous momentum, particularly in light of their most recent quarter?

The answer is they can’t, and that’s the real big issue that the other commentators haven’t mentioned.  Force.com is too expensive.  The economics of SaaS are stark, and never more so given the capital raising climate of today.  SaaS vendors should be able to deliver their service for about 25% of what they charge for it.  Some do it for less (Salesforce in particular is a little more than half that), and some do it for more (Google’s “SaaS” is much more expensive, but still around 40%).  See my post on Multitenancy for more detail on this.  Here’s the punchline:  Force is priced at about $50 a seat month.  If you’re going to get that 25% Cost of Services, that means you’d have to charge $200 a seat month for your SaaS offering.  That’s 2x the premium offerings from Salesforce itself.  It’s a total non-starter for those who’ve done the math. 

Folks I’ve talked to who are starting SaaS companies are well aware of this.  Their view is that Salesforce is not a platform for developing your flagship app, it’s a platform for generating sales leads, which ties back to Schuller’s comment that Force is all about marketing not technology.

Note that Salesforce is trialing much lower pricing as we speak, but it’s pitched as promotional pricing only.  That’s a problem too.  Having already showed their (potentially greedy) hand, how do ISV’s trust that even with the right pricing SFDC won’t raise the stakes and instantly take all the profit out of their business at some future point?

Platform vendors have to be Switzerland. 

Force.com will likely sell reasonable well to Corporate IT for internal projects because they’re not price sensitive.  It may already be too late to reverse course well enough to bring on many ISV’s.

NYT Correctly Calls the Biggest Microhoo Challenge (Hint: It’s the Microsoft Rift With the Web)

I’ve been complaining about Microsoft’s unneccesary Rift with the Web for quite a while, and occasionally taking grief for it from Microsoft supporters.  The NYT has a great article about how the incompatibility of Microsoft’s proprietary with Yahoo’s Open web technology is the biggest obstacle that the combined entity will face.  When we reach a stage where the NYT sees that Microsoft has a Rift, it’s pretty hard to deny the Rift exists.

What if the merger signalled the end of the Rift?  Wouldn’t it send an amazing message to the world if Microsoft flat out abandoned their insistence on their own platforms.  They don’t have to kill those platforms, they just need to quit insisting on them to the exclusion of all else.  Can you imagine a world with Microsoft pushing Linux, PHP, MySQL and all the rest?

No, me neither.  I guess they’re in for a rough ride!

Amazon Ran Out of Capacity

As I suggested in my original post on the topic, Amazon’s recent S3 outage was due to running out of capacity.  Specifically, they ran out of authentication capacity.  In part, this problem was due to the fact that Amazon wasn’t monitoring exactly this part of their capacity envelope very well.  High Contrast has the Amazon quote telling us that it was also due to just a few customers radically increasing their load on the system in an unpredictable way:

the surge was caused by at least one very large customer plus several other customers suddenly and unexpectedly increasing their usage. 

So far, most of the pundits are in something of a denial mode.  They argue that nothing really new and interesting is happening here.  All services go down, including the electric company.  Vinnie Merchandani says corporate data centers have been going down a lot more often than 99.999% uptime allows for since forever.  Folks like Nick Carr seem to feel the biggest issue in this outage was that users didn’t have timely information and Amazon is fixing that.

This all misses a bigger point.  What these writers are doing is attempting to apply the old standards and methods against the new world of Cloud Computing.  The trouble is, there is something genuinely new at work here that goes beyond the inevitability of some outages and the need to be more transparent with customers about what is going on.  The problem Amazon and other would-be cloud platform purveyors face is predictability.  The world they deal in is radically less predictable than corporate data centers of old because the Internet today has much lower friction and higher connectivity between different web sites that make load spikes increasingly sudden and intense.  There is a cascade of dominoes effect that is enabled by the low friction web that wasn’t nearly so twitchy in the past. 

The premise of any large computing infrastructure is that by sharing the load across many customers (and in Amazon’s case, sharing excess capacity from their core retail business), we enable headroom for such load spikes.  But how realistic is that concept?

Consider this Alexa plot of CNN and Flickr traffic over time:

 

Do these two curves look predictable to you?  Take CNN, for example.  To handle the big spikes requires 2-3x overload capacity.  Flickr is a little less crazy except for one massive event that involved a doubling in a very short time.  This latter even was permanent in its effect, so if you were counting on temporarily borrowing some headroom, you would have had to keep it in place indefinitely and grow from there.  Ironically, that chart was brought to my attention at Amazon Startup Project where they used it to sell the idea of unlimited headroom a startup can’t afford to purchase by using Amazon Web Services.

These charts are displaying non-linear behaviour, the hardest of all phenomena to predict.  This non-linearity is becoming more and more common because the Internet has become extremely viral.  It is crosslinked, the very meaning of the word “web”, and messages travel along the links with almost no friction.  Viral has become a virtue, and much of the current innovation is focused around how to make the viral spread of information more likely.  Social Networks are all about such behaviour.  Take a look again at those CNN spikes.  Now let’s imagine your cloud computing infrastructure is hosting a bunch of different blogging, micro-blogging, video, photo sharing, and other social sites.  The CNN spikes no doubt represent something newsworthy happening.  The greatest likelihood is that each spike will be echoed at some level across all of these sites that are in the business of spreading information.  Friction has been lowered to the point it is almost non-existent when it comes to the spread of memes on the Internet.  We have major spikes from world events, such as the assassination of a world leader.  In the Internet, we can have major spikes from such inane moments as Scoble shedding tears of delight over new Microsoft secret software.  And the whole thing is wired together.  That one tear on Scoble’s cheek breeds a thousand or more accounts ranging from poking fun to trying to guess what this secret software is.  There is a ravenous beast poised over the keyboard waiting for something interesting to pass onto its network of other ravenous beasts.

This is decidedly non-linear behaviour and impossible to predict.  The answer is major cloud computing infrastructure providers will need to have considerable excess capacity available on tap at all times to avoid outages.  Take Amazon.  Web bandwidth to their web services now exceeds to total traffic to all of their other properties.  What might have once been a nice remaindering business allowing them to resell their excess capacity is now driving the need for more capacity.  They have just a few choices.  They can invest in a lot more hardware and lower the margins on their business, or they can implement some strategies to limit the availability of the service to some customers.  It strains credulity to think they’ll limit capacity to their retail business.  How will they decide?  Tiered pricing of some kind? 

Think in terms of other unexpected networked events.  I’m reminded of financial markets and the law of unintended consequences.  Look at today’s housing market.  Remember Long Term Capital, a hedge fund with Nobel Laureates who had mathematical proofs they would continue making money.  Right up until they unpredictably went bankrupt.  BTW, this sort of thing used to happen with the electrical grid too.  In both cases, the financial markets and the electrical grid, elaborate means were put into place to artificially inject friction to damp the machine’s oscillations before it could destroy itself.  There are elaborate rules in the stock exchanges about shorting stocks that are falling.  They inject a form of friction back into those markets to prevent total free fall. 

Perhaps this points the way to new technology for Cloud Computing infrastructure.  A gentle injection of the right kind of friction at the right point for a limited time might prevent suddenly massive spikes and outages.  It’s an area ripe for innovation.  Meanwhile, Amazon could sorely use some competition.  If a customer could contract for emergency capacity from elsewhere, or even better, if the Cloud Computing Providers could share slack capacity as the electrical companies do, it would be tremendously helpful when the inevitable load spikes arrive.