Microsoft Has Started the Clock Ticking on Web Office Apps

By now, you’ve heard Microsoft Office 2010 will include web versions of the Office apps.  Some speculated that Monday’s announcement by Microsoft was what led Google to upstage them with the ChromeOS announcement.  But did ChromeOS really upstage Microsoft, and what will be the impact of a thin client MS Office?

Having been a General in the Office Wars of the 80’s and early 90’s, I can tell you it is about to get ugly for the upstarts and their Webby Office Wannabes.  Zoho, Google Apps, et al have not yet achieved sufficient traction to be anywhere near critical mass players.  They’re not even as far along as the long line of players (including my own Borland with Quattro Pro) that Microsoft dispatched the first time around.  Guys, fair warning: this is the kind of down and dirty competitive fighting that Microsoft does extremely well.  Your days are numbered or at least your growth is capped unless you can find a way around the Redmond Horde, and a lot of folks have tried before you with a lot of resources in the form of dollars and IQ points.

Microsoft will be fighting from their competitive strength.  They own the Office market.  Wannabes have so far failed to even match Office functionality, have many serious incompatibilities (leading to adoption barriers), and have failed to introduce much in the way of innovations short of running in a browser.  Microsoft will shortly eliminate that point of differentiation and at the same time they’ll be adding a whole raft of juicy looking new functionality.  You already weren’t caught up to them on functionality and the bar is about to go higher.  This feature war game is something Microsoft can play all day long, holding your heads underwater until you’re just tired of it.  Even if you one up them on some apps, they have a whole suite and the power of inertia.  Whatever you build, they will deliver their own version of it very shortly thereafter.  It’s an arms race where they bury you much the way Reagan did the old Soviet Union.

The best news is that it’s all good for customers.  It’s all good for us.  At least for as long as it lasts.

This is Microsoft as we haven’t seen them in years.  They are only at their best when they get their backs against the wall.  Bing showed up after years and years of failure against Google and even Yahoo.  Now we’re getting Office 2010.  Real new functionality of interest has been lacking for an extremely long time.  Office 2010 is blowing out all sorts of cool stuff: it runs in a browser, lots of new visual coolness (take that Apple!), and lots of new collaborative functions.  Heck even Scoble is excited.  As he points out, those that declared MS Office dead four years ago turn out to have been very wrong.

So keep it up competitors.  This is good stuff.  You bring out the best in Microsoft.  We know you’re likely to fall on your swords (or theirs) doing it, but it is a valuable service.  Complacent monopolies are a bad thing.  And guess what?  You do have a chance in the war.  It ain’t over and the fat lady hasn’t sung.  But you had sure better get your acts together in a hurry because the sleeping grizzly bear is wide awake and she’s pissed you’re in her territory.

10 Things You Don’t Need to Do In the Clouds

Sometimes a breakthrough paradigm shift eliminates the need for all kinds of things.  Word processors and laser printers killed a lot of other things that were once thriving including typewriters, liquid paper, and Linotype machines.  So it is with the Cloud.  When I chat with my Director of Operations at Helpstream, we’re always chuckling about how much better life is in the Amazon Cloud for our company.

As I read through unread blog posts with Google Reader, I’m going to note 10 things we don’t need to worry about since we’re in the Cloud:

1.  NetApp’s new DataDomain data de-duping product.   NetApp bought a company with a cool technology.  Plug it in place of you tape backups and you can backup to hard disk because this thing eliminates redundant data–sort of a very backup-savvy compression algorithm.  But if you’re in the Cloud, who cares?  Your Cloud vendor worries about this stuff.  You just buy it by the gigabyte, as much as you like, and do whatever.  Backup already looks like it is a hard disk with S3 and especially Elastic Block Store.  This is one whole chunk of costs and complexity you can safely ignore because it just doesn’t matter to you and you couldn’t install it in your vendor’s Cloud if it did.

2.  Server power consumption.  It’s out of your hands.  Sure there are really cool new technologies, like Dell’s Fortuna server that is the size of a hard disk and uses 20-30W.  But it doesn’t matter.  You aren’t choosing the servers in your Cloud.  The good news is that any really large scale Cloud vendor like Amazon will be choosing servers with great performance per watt, because it lowers their cost basis.  If they’re selling a commodity, like EC2, they’ll have to pass those savings on to you too.  Best of all, you can feel good about these being more green solutions than you’re likely to have the expertise to create in your own data center.

3.  Worrying about big iron or little iron (or little big iron where a proprietary cpu is in a small chassis?).  Should I run the best servers Sun (or some other Big Iron vendor) can provide?  Or should I just run lots of little commodity “Lintel” (Linux + Intel/AMD) boxes?  Quit worrying about it, because you can’t affect this.  In all likelihood your Cloud vendor has Lintel.  You have no idea which hardware brand they use, so you can quit caring about that too.  All those specs, which rack form factor, yada, yada, just don’t matter any more.  You have a handful of virtual machines you can choose from.  There are relatively few specifications to focus on for those virtual machines.  Someone else has probably already figured out how to set up memcached or whatever on those machines and how to optimize the software for that footprint.  You should certainly try some experiments because your software may be different, but the search space is sharply limited.  That’s a good thing, isn’t it?  Now you can focus instead of poring over a gillion spec sheets outer joined to a gillion different purchase deals.

4.  Worrying about MIPs in general.  As Om Malik so correctly points out, its the megabits (of connectivity) not the MIPs that count these days.  We haven’t been able to get more MIPs like we used to for a while, because of the multicore crisis.  Sure, we get more cores, but we don’t get faster clock speeds.  Everyone is ooohing and aaaahing that the iPhone will get a 1.5x faster cpu.  Does anyone remember back when you got a PC twice as faster every 18 months?  They never felt twice as fast.  Most of the time you could only tell if you went back to the slower machine, which seemed sooooo slooooow.  People will hardly notice the faster iPhone, unless they go back to an older one.  Meanwhile, those in the clouds can get all the MIPs they want, provided they’re ready to use elastically scaled cores loosely coupled over a LAN.

5.  Wholesale bandwidth costs.  Why worry about it if all your data is in the Cloud?  All you care about is how fast an individual browser can access that Cloud.  Granted, a big office requires a fair bit of bandwidth, but nothing like a data center.  Moreover, your Cloud vendor probably has multiple data centers in multiple geographies as well as CDN capabilities, so you are now geographically distributed in terms of connectibility.

6.  Which load balancing box to buy.   Forget about it.  Your Cloud vendor does this for you, and even if they didn’t, you’ll have to use software because you don’t get to install any custom hardware in their Cloud.  With the advent of Amazon offering load balancing as a service of their Cloud, all you need to think about is how to use it with your application.  Life gets simpler and more focused again.

7.  Hardware monitoring.  Amazon’s new CloudWatch service tracks all the usual low level monitoring (cpu load, disk i/o, network i/o, and so on) on one minute intervals.  The data is kept around for two weeks.  This is all stuff you’d have to monitor somehow.  You’d have to find some monitor software, install it, learn how to use it, yada, yada.  With CloudWatch, you just have to learn to use what’s already there.  Amazon had to get this and a lot of other things to work just to have a Cloud.  You get a handy assist from that.  People who want to compare Amazon on a raw server cost basis never look at these kinds of costs.

8.  Creating multiple data centers for redunancy and for multiple geographies.  Werner Vogels, Amazon’s CTO, makes it sound so simple:

The Amazon Elastic Compute Cloud (Amazon EC2) embodies much of what makes infrastructure as a service such a powerful technology; it enables our customers to build secure, fault-tolerant applications that can scale up and down with demand, at low cost. Core in achieving these levels of efficiency and fault-tolerance is the ability to acquire and release compute resources in a matter of minutes, and in different Availability Zones.

Elastic availability of compute resources in multiple different Availability Zones (e.g. datacenters) in a matter of minutes?  First, it’s impossible for small companies to afford multiple redundant data centers.  They all reach a scale before dealing with that.  The Cloud levels that playing field so anyone and everyone can afford it day 1.  Just the sanity of having your data backed up to S3 with multiple copies in different physical locations is wonderful.  Second, even when you reach the size of being able to afford multiple data centers, it is a hugely expensive and complex undertaking.  Why would you ever want to deal with this if you didn’t have to?

9.  Exactly how to configure complex software like MySQL for my particular server instances.  Most of the Clouds have libraries of machine instances where somebody else (hopefully even the vendor who made the software) has set it all up, blessed it, snapshotted the image, and made it available.  Mount that image on an EC2 virtual server and away you go with something you know works.  Even if you are not on Amazon and don’t have Amazon Machine Instances like that, other clouds have these options too.  3Tera, for example, builds software for Cloud Owners and has what they call their Enterprise App Store.  These are pre-configured and ready-to-run instances. 

10.  Worry your engineers are spending valuable time worrying about infrastructure and worse physically visiting that infrastructure instead of doing something that gives your company a distinct competitive advantage.  Why build a datacenter if everyone else has one?  Let them make that investment while you invest elsewhere.  Werner Vogels gives a great example that is appropriate since the Indy 500 just ran Sunday.   Their site has a unique problem.  It requires a huge amount of resources to deliver a rich user experience:  multiple video streams including views from the cockpits of drivers’ cars with audio feeds and telemetry.  The challenge, as Vogel puts it, was that it isn’t used very frequently:

This is a high load application but it only runs three times a year. They found that they had to move a lot of engineers into data centers to keep their servers up. When they moved to cloud infrastructure they made 75% cost savings, the majority of which was on the people side; now they can manage everything from their armchair at home.

So there you have it.  10 things you don’t have to deal with if your data center is in the Cloud.  These are 10 things based on the pseudo-random collection of blog posts in my Google Reader RSS feeds.  There are many more out there, and I’m not even going to claim these are the 10 most important things.

Don’t you need fewer things to worry about so you can focus on what actually makes the difference?

What Now, Microsoft? (Pssst, It’s Not Too Late, and It’s Not About Yahoo!)

What should Microsoft do now?

Clearly, it is fighting a rear guard action where search is concerned.  Any deals with Yahoo are stopgap at best.  Microsoft probably believes they only need to slow the erosion to buy time for their own technologies to kick in against a large enough installed base, but that isn’t it.   That’s an incremental strategy that won’t get them anywhere very helpful.  Google will just keep peeling away share.  This strategy of hooking up with Yahoo is a classic violation of Sun Tzu’s (and every strategist since) ideas.  When you are the weaker player, don’t attack the strong one in their strength!

It’s about out flanking.  Doing the unexpected.   And realizing that your days of leveraging existing monopolies to reach into new spaces are about done.

Think about what the reaction would have been if Microsoft had bought Sun instead of Oracle.  For starters, they could have bought them for cash using a little more than 1 quarter of EBITDA.  Yes, Microsoft is cash machine.  But just imagine the signal they could have sent:  We are tearing down our walls!

No more anti-open source.  No more anti-Java.  Can you imagine what a ripple that would have sent?  That would have been some outflanking. 

And because it would be such a radical move, you’d have to believe it, unlike Oracle where it is easier to assume they’re just the glue factory and the race horse is done.

Think what such a move could have done in terms of reseating Microsoft at the head of the development tools table, which is where they started.  A jumpstart on Cloud Computing.  Throw in RedHat, market cap half that of Sun’s purchase price (another 1/2 quarter of cash generation for MSFT) and you’ve got Linux too.  Now Microsoft would’ve had a truly amazing platform story.  Almost scary amazing, in fact.

How can a Yahoo search deal even begin to compare to that?

Lots of strategic upset in such a move.  Imagine putting the internals of SQL Server behind MySQL.  Microsoft has always staked out the low end.  The don’t risk nearly so much cannibalization as Oracle does with MySQL.  Lots of organizations would love to have a paid (though admittedly still cheap) version of MySQL that just ran a lot faster when they needed it too.

But that deal is done.  Oracle got Sun.  It’s not something to be unwound.  It was a once-in-a-few-decades strategic alignment of the stars that went unnoticed in Redmond.  The old strategic religion is too strong for them to have ever considered it seriously.

What else should they be looking at with similarly game changing?

Twitter  ($1B might do it).  Clearly Twitter is pretty darned game changing, and some are saying its just the right thing for Microsoft.  But it will be awesomely expensive, and it isn’t clear how to use it as a beachead to build out nearly so horizontally as Google has. 

Facebook  ($10B?  Less?).  Another good example, even more awesomely expensive.  Would Microsoft build something out of it that would ever justify the cost?  Unclear.

Amazon (Too much!).  This would’ve been my favorite from a technology perspective, but it has all sorts of problems though  Hard to catch Microsoft + Amazon for Cloud Computing.  Their market cap is $35B, which is probably too painful to swallow, and it would take a significant premium above that.  The Cloud business is still a tiny portion of that, so MSFT is buying the world’s most successful e-tailer.  Margins are lousy on this stuff compared to MSFT’s core business, so it is dilutive to the franchise.

How about a bevy of SaaS Companies?

I like this idea.  They are not cheap, but the most expensive of all, Salesforce.com, is $5B or so.  Say they wind up paying $7B, but they’ve now bought by far the biggest SaaS player.  Let’s pick up a few more to round out the suite.  I’ll take Successfactors for HR at $500M (peanuts with Microsoft’s cash flow).  Let’s add RightNow for Customer Service at circa $300M.  We’ve got room for one more, and I’d round out the CRM suite potential with either Xactly Corp or Callidus Software.  Xactly is a pure play and cheaper, but might not be willing.  Callidus has a lot of baggage, but has built a good sized SaaS business.  Let’s kick in NetSuite for another $1B (or a little less after they somewhat missed).

Whoa!

Salesforce, SuccessFactors, RightNow, Xactly, and NetSuite.  In one fell swoop Microsoft becomes the biggest SaaS player on the planet.  They block Oracle and SAP from acquiring these companies, and I’m not too sure they wouldn’t love to annoy those companies anyway.  As a matter of fact, there should be any antitrust issues here because of SAP and Oracle.  These SaaS companies would totally sew up MSFT’s domination of the low end business software world too.  And the total price tag?  Maybe $9B and they totally dry up the well of companies that have any scale at all in the business model that is the coming thing.  Heck, round up to an even $10B and pick up whatever remains of the SaaS world.  Then launch a classic Microsoft all-out hypercompetitive battle against Oracle and SAP for world domination.  It’s a clear opportunity to destroy the fat maintenance margins of this group while maintaining their own margins in unrelated business units. 

That would liven up the Enterprise world again for sure!  Best of all, it’s got nothing whatsoever to do with Google.  Let them eat cake over there, trying to grow a market they already own most of.  Wait for Carol Bartz to show up with her metaphorical hat in hand.  You can still buy that search business a whole lot cheaper. 

Not bad for a few months cash flow.  Mr Ballmer, when are you going to get on with doing something exciting over there?  Or will Oracle steal a march on you again?

Jon Hansen’s Cloud Computing in the SaaS World

Jon Hansen runs an excellent podcasting/Internet radio show called PI Window on Business. Recently I was invited to join one of these casts, but couldn’t due to another commitment, but I wanted to pass along this program because it concerns Cloud Computing and SaaS. Host Jon Hansen is talking with guest and blogger Michael Dunham from Scio Consulting. They’re talking about the recent McKinsey study that claims the Cloud does not deliver any savings for large organizations, and the program starts with a pretty decent introduction to Cloud Computing.

They key differentiator in Cloud Computing is that like SaaS, it is a Service. The customer pays for it without worrying how it works. The entire infrastructure in the background is transparent. That’s as it should be, BTW. There isn’t a lot of value and there is tremendous cost in having to be aware of every implementation detail to use a service. Dunham likens the Cloud to the telecommunications infrastructure that’s existed for a long time.

I wanted to go back over a number of issues raised in the show and give my own perspectives. This will be a longish post, because it was a half hour show that touched on a lot of issues.

There were lots of interesting parallels raised in the show. One theme is that Cloud really isn’t something completely new. As mentioned, we’ve had telecommunications and other kinds of Clouds for a long time. One of Hansen’s first questions was, “Who needs to be involved with the Cloud?” Will it be confined to an Oligarchy of Concentrated Expertise with the Large Players?

First thing to note is that the Cloud benefits from scale. It is essentially a commoditization phenomenon. There’s not a lot of benefit in buying services from a Cloud that is too small, unless those services are very unique. That will therefore drive scale on the vendor side of the equation except for more specialized kinds of Cloud. A lot of people I talk to wonder if Amazon isn’t already so far ahead of the pack scale-wise that it will be hard to catch them. The good news is that their offering is pretty generic, so there is an opportunity to differentiate. The bad news is that except for the largest possible companies, the IBM’s, Sun/Oracles, and the like, Amazon may already be too far along and so it will be essential for the other players to differentiate.

“Is it safe to say the expansion is occurring as the market is decentralizing? “

I don’t think of it so much as decentralizing as changing the locus of centralization. We move from centralizing around large corporate IT datacenters to centralizing around relatively fewer Cloud vendors’ large datacenters. One of the reasons companies are starting to scramble on the vendor side is this centralization.

The Cloud aggregates transactions. If I am selling servers pre-Cloud, I have lots and lots of customers. Win or lose any particular one, and it is not a big concern. There are a lot of fish in the sea. But, whichever vendor is lucky enough to close Amazon on their servers, wins a whole ton of virtual accounts (Amazon’s customers) by default. The stakes are much much higher. We will see Cloud providers dictating to such vendors the same way Wallmart and GE dictate to their suppliers how business will be done. Major new forces are being created in the market because Cloud Vendors represent the collective buying power of all their customers.

“So the general user and population don’t need to worry about this?”

The general user already spends most of their computing time in the Cloud. Every web app is in the Cloud from the standpoint of an end user. Don’t we already spend the majority of the time on our PC’s in web apps? So we have the reverse of the “last mile” problem of residential Internet access. The “last mile” is in place as we use all these web apps. The Cloud is about the “first mile” where the datacenter begins. What is your web browser connected to?

As the Enterprise grows increasingly distributed, this again favors the Cloud which is purpose-built for a webby world. It’s no accident one of the biggest Cloud vendors is also one of the oldest and most successful Web businesses. They know how to do that stuff!

“What about reliability, dependency on expertise, and support for the Cloud?”

Well, how reliable are your web apps? Do they crash more often than your Microsoft apps (LOL)? Mine sure don’t.

Are we happy with where the expertise lies with these apps? Tim Chou started the SaaS business at Oracle many years ago, and he is the first one I heard talking about the idea of “Who better?” Would you rather have your apps supported by your internal IT? Not me. They’re smart, but this is the first and only time they’ve ever run whatever app we’re talking about, and they didn’t build that app. I want the vendor to run the app for me and support it. They developed it, and they’ve run it for a lot of customers over a much longer period than my IT people. They’re the world’s foremost experts. Who better?

“What is the importance of standards?”

Michael Dunham was very concerned that we haven’t evolved enough standards yet in the Cloud world. I’m a lot less concerned. Amazon is a very straightforward service to adopt. The differences between what you have to know there are no greater than the differences between Sun SPARC Solaris vs HP/UX vs IBM AIX vs Wintel vs Linux Intel in a traditional data center. They’re no different than Oracle vs DB2 vs SQL Server vs whatever other platforms. In fact, they’re actually much less because a big part of what Amazon provides comes from these very same standards already. They haven’t added that much. I think it’s pretty straightforward to understand and take advantage of it. Standards are not holding us back to any appreciable degree, though IT loves to clamor for standards. It’s just their way of delegating some of the responsibility to understand.

What’s much harder for IT is the loss of control. They’ve built a lot of distinctive competencies over thousands of procurement decisions made over many years. They’re loath to revisit that fabric. But the advantages compel them to at least consider it.

“How is the organization involved with Cloud decisions? IT? Purchasing? Does this hasten the obsolescence of the CIO?”

There is a profound impact, no doubt about it. But I don’t think that impact is really that different from mega trends that have been at work in IT for a long time. IT has largely gotten away from being the arms and legs. They manage the arms and legs. I was having coffee with a friend from a Big SI the other day. She was lamenting they hadn’t yet embraced the Cloud, but she went on to say it was for the best because Customers lose control, there are security risks, and all the other chestnuts.

I responded that customers had already lost control and had all the same risks. Most of them are not running their IT today. The bulk of the people costs are going to outsourcers of one kind or another, either overseas, or IBM, or some other large service organization. I’ve worked with Fortune 500 companies that told me only 5-15% of the IT employees were actually employees of the company versus outsourcers. Why is the Cloud so different? She blinked, laughed, and agreed.

“Is there a concern that the big players don’t have enough experience with the Cloud? Remember, nobody ever got fired for buying IBM. Is this a big leveler?”

First, the big players are not blind to all of this. The Cloud and SaaS are highly disruptive. It’s very hard for them to flick a switch and be there overnight. The cost to their business model is just too high, and as was mentioned on the program, it touches every part of the organization and every aspect of doing business.

With that said, big license sales are slowing and have been for some time. Maintenance is becoming an increasing component. Acquisition of other company’s maintenance bases has become the growth vehicle. Ultimately, the source of organic growth will be Cloud/SaaS.
As I say, the big players are not blind. I wrote the post on the Red Cloud. I believe Oracle made the Sun acquisition largely in response to the whole Cloud movement. Moreover, Oracle has been active for many years with a SaaS business. It’s doing very well, though they don’t advertise it very loudly. SAP is less far along with Business By Design, but clearly they also see they need to be developing the expertise.

For the time being, there is still a tremendous advantage for newer players. It is more of an architectural advantage. I’m talking about both their software and their organizational architectures. As was mentioned on the program, it’s easier to start clean sheet for the Cloud than convert after the fact. The bigger the company, the harder to convert, and the slower that conversion must be.

“McKinsey recently said the Cloud is more style than substance because:

 Nobody agrees on the definition
 It doesn’t scale to Enterprise
 It distracts attention from areas where tangible value can be unleashed.

Why would they say that? Are they being influenced because they’re in line with the old model and vendors?”

First, I did not think the McKinsey report reflected a very deep analysis. The coverage I saw on it was universally negative. From my perspective, they picked a conclusion and then drew up an analysis that supported their conclusion, so yes, I’d say they’re part of the Old School “Military Industrial Complex” around IT. They have an agenda.

SaaS eliminates a lot of value from the ecosystem for third parties like McKinsey precisely because it is service and that’s what McKinsey and the SI’s are in the business of delivering.

That particular report did a lot of silly things in analyzing the cost of the Cloud for larger organizations. The per-server cost for corporate IT were ridiculously low compared to many other estimates I’ve seen (just the power costs alone from data center studies I had seen were a big fraction of what McKinsey claimed). They burdened the analysis with a lot of costs that were irrelevant to the choice of Cloud or Data Center. That just added a lot of fixed costs that masked variable cost differences.

Given their great name, the study really doesn’t reflect very well on their expertise. But it will be a handy piece of collateral for those that want some air cover from the advantages the Cloud is bringing and the attendant disruptions that entails to an industry.

Pick Anything Favors SaaS, the Cloud, and Community

Loved Seth Godin’s post on the calculus of change.  In it, he talks about how a change in operating systems (from DOS to Windows) opened the door for people to reconsider their choice of word processors.  The incumbent top of the heap word processor of the day was Word Perfect.  But when Windows came out, Word Perfect wasn’t ready and Word was. 

The point of maximum disruptive timing is the point where people have to pick something.  Pick anything. 

Are we at that point today?

I’ll argue we are for a whole host of things.  Old systems are showing their age.  The last major revolution in my company’s (Helpstream’s) Customer Service world was 10 – 20 years ago.  That means it’s time to retool.  The same can be said for most Enterprise Software.  We live in an age of Java, MySQL, Open Source, Cloud Computing, and Web 2.0 Social Media.  None of that existed when the current set of incumbent top of the heap Enterprise Vendors made their bones.  Each one involves powerful disruptive forces. 

They are so powerful that they even affect demographics.  People that grew up with all that want it.  It has changed how they live their lives, how they interact, and what tools they insist on having to hand.

Having to retool, whether because the economy forces another round of efficiency improvement, or your competitors have already retooled and reaped the benefits, or your next generation of employees won’t use your status quo creates that “pick anything” environment that Godin so eloquently says is the key moment for an insurgent, and the best time for a marketer to grow their audience.

Note that the incumbents and most of the players still in place who chose them will not see this.  But they will feel its impact later, when they realize they have been late to the party and lost out as a result.

A Vision for Oracle’s Cloud Platform: The Red Cloud

Helpstream’s CEO (my boss), Tony Nemelka, penned a great piece on the Helpstream Blog about what the Oracle/Sun acquisition might mean.   A lot of attention has been focused on the potential for negative outcomes.  Will Oracle kill MySQL or at least damage it with worse than faint praise (fascinating post by fellow Enterprise Irregular Josh Greenbaum)?  Other note (quite rightly) that Oracle can’t really kill MySQL because of its Open Source basis.  I found WordPress founder Matt Mullenweg’s post to be particularly eloquent of this.

What I found intriguing about Tony’s post was the more positive scenario it envisions.  Read the post, but let me summarize for purposes of this discussion.

Tony was recently in Japan and has a long history there having been an executive for PeopleSoft, Epiphany, and then Adobe in charge of the region.  Needless to say, his contacts are pretty high up the food chain, so they know what’s going on.  In that world, the System Integrators are the gatekeepers for the market.  They’re very powerful, and the interesting discovery Tony made is that they absolutely love Force.com.  It’s not hard to see why.  The SaaS model squeezes the SI ecosystem.  The normal meat and potatoes business around just getting on-premises software installed is greatly reduced.  The business of just keeping the lights on is almost non-existant for SaaS.  Yet SI’s have a lot to bring to the table.  A good SI often understands the Domain, its Best Practices, and the key Business Processes better even than the software vendor.  Having access to a SaaS platform makes it possible for the SI to turn that valuable knowledge into product which can then be sold.  That’s why having a platform on which to do that is so important to them.

Tony goes on to speculate that Oracle is picking up the components necessary to create such a platform.  If nothing else, Oracle’s Japanese SI’s are screaming that they need one.  I have to imagine SI’s everywhere are grokking the essential value of a platform to the SaaS ecosystem.  There’s nothing about the Japanese market that would make that a unique requirement there.  So far, Oracle is really stuck in that department.  I suppose they would argue the coming Fusion represents such a platform.  At the same time Sun, like every big hardware vendor, was hard at work crafting a Cloud strategy.  They all know the Cloud is a tidal wave that can profoundly impact their businesses.  The Cloud represents the federation of many smaller deals into fewer gargantuan deals.  One over simplified way to view it is as a whole new sales and marketing channel.  Failing to suit up for the game guarantees a loss and the stakes are high. 

Some I’ve talked to say that Oracle just “doesn’t get it.”  They don’t believe in SaaS, they don’t understand SaaS, and they can never execute this kind of nuanced strategy until it is way too late. 

The idea that Oracle wouldn’t try or wouldn’t deliver anything is not something I’d want to put too much money on.  It’ll probably take them longer than anyone would like, or they might surprise us too.  Even Oracle can’t really fight the Cloud/SaaS tidal wave.  Remember that the guy at the top believes it in, don’t forget that Larry Ellison has put his money into SaaS companies many times.  It happens to be inconvenient at the moment for the various financial metrics Wall Street cares about for Oracle to switch wholesale to SaaS, but even that is something they can manage over time.  Also, we know Sun was working hard on their own Cloud strategy.  Suddenly there is a lot more Cloud DNA coming into Oracle. 

I suspect Oracle’s vision of what a PaaS (Cloud Platform) is will be a lot different than what you or I might choose.   If nothing else, it won’t be a clean sheet of paper approach.  Let’s think about what it might be.

First, I would expect the initial version will not be multitenant.  Multitenancy as it is delivered today is too deep in the guts of the application.  It forces too much change to architectures, which creates too much adoption friction for a platform at the outset.  Oracle will want to deliver the promise of running any app on their Cloud Platform, or at least any app built to run on their now very comprehensive stack.  It spans hardware (SPARC et al) to OS (Solaris) to DB (Oracle/MySQL) to App Server (BEA) to Business Intelligence (Hyperion) to <you get the idea, phew!>. 

Second, if not multitenant, what?  Think virtualization.   Don’t they need to buy VMWare to get that?  They may buy VMWare, but they don’t need it for virtualization.  Sun Solaris has a wonderful virtualization capability built right in.  I’ve used it before to create a SaaS application and it works extremely well.   Imagine an Amazon-like capability to start up these virtual Solaris machines.  If Oracle is smart, and they usually are, you’ll be able to start up virtual “appliances” in the Red Cloud (my new name for Oracle’s Cloud) that deliver database, app server, and many other functions.  Consider:

-  Storage:  This one is obvious.  Sun has a big storage business, Jonathan Schwartz has blogged about their great ZFS storage technology, and so Oracle can easily deliver the “Amazon S3″ storage piece of the Red Cloud.

-  Identity Management:  Control over who logs on to the Cloud.  Sun is strong in Identity Management, for example.  Oracle already had a business there.  The combination of the two would create a leader to rival IBM and possibly be the world leader.  Having Identity Management built into the Red Cloud would be a decided work savings over Amazon, for example.  And Identity Management is one of those things on-prem apps are used to farming out to another module.  Hence it would facilitate their migration to the Red Cloud.

-  Business Intelligence:  This is another of those modules everyone wants to OEM instead of having to build for themselves.  It’s an ecosystem component, like Identity Management, ETL, and a host of other things.  Oracle can again deliver a virtual appliance in the Red Cloud that makes it simple to connect.

-  Integration:  This will be essential to making the Red Cloud Appliances work.  But when you have one vendor that controls so much of the stack, they should be able to make it work better than anyone else.  This is where the vision of being the “Apple for the Enterprise” can best be seen.  This is where a lot of the Fusion work, as well as work from BEA could tie in.

OK, that’s a pretty darned impressive first tier vision if you ask me.  It’s taking the old pitch about buying a suite from one vendor and ratcheting it up significantly in terms of scope.  Not everyone will buy into it, but Big IT might just need something like this before they can start moving to the Cloud.   If Oracle can deliver such a thing, it will be an enormous business.  Someone I was talking to recently said they thought Microsoft was Oracle’s ultimate acquisition target, but I think Larry has a shot at rivaling much bigger entities if he can execute.  The IBM’s and HP’s are starting to appear on his horizon.

But there are some warts.  It will be a hodgepodge unless some Fusion-like glue can make it all fit.  It will be an enormously complex offering to market and sell.  It will be nearly impossible to take in the scope of it or understand all of it.  All of the Enterprise complexity that Big IT loves, but that SaaS has tried to ameliorate will be there.  Granted, this is better than the old on-prem complexity.  Oracle can deliver at least some of the SaaS advantages.  But what about cost?  Can we really get the SaaS cost advantages without multitenanacy?  In a word, “No!”  I just wrote an article about the pitfalls of thinking virtualization is a substitute for true multitenancy.  I stand by every word I said.  But Oracle has a unique opportunity to virtualize multitenancy itself, not in the first iteration of the Red Cloud, but in later iterations.

Whoa!  What the heck is Bob on about now?  Virtualizing multitenancy, what does he mean?

What I mean is a mechanism whereby single tenant applications can be made to have all the benefits of multitenancy without radical architectural change.  There are two ways this can happen. 

The approach is to have the database itself virtualize multitenancy.  The most popular model for multitenancy is what I call columnar:  a column in the database tells which tenant each record belongs to.  A suitable feature set in the database server can completely automate this and make it radically simpler for the application to work along this model.  A second common model gives every tenant their own set of tables.  Here again, special support in the database can radically simplify the implementation.  Note that Oracle already does partitioning (they may have invented it, but I am not sure of that), which is a feature that makes a bunch of physical tables look like a single table and that greatly improves scalability.  So now Oracle could deliver a Multitenant DB Appliance in the Red Cloud.

The second approach attacks the costs of being single tenant.  In my post on the subject, I talked about the idea of fixed costs and variable costs.  The difficulty is that the database server uses up a bunch of system resources on each virtual machine even if there is no data loaded into it.  This is because the database server is unaware of the other database servers in their respective virtual machines.  They are isolated.  But what if they were aware of each other and could pool those fixed cost resources to reduce the overhead?  What if the operating system itself facilitated this?  Those fixed costs could be dramatically reduced.  Moreover, if a comprehensive integrated feature set was aimed at reducing the cost of administering such as system, we would likely start closing in on true multitenant efficiency levels. 

That would be my vision for Oracle’s Red Cloud.  It would be a first-class Cloud platform, although much more Enterprisey and Old School than the New Cloud Age SaaS and Amazon-style Cloud visions.  Oracle and BigIT will view that as an advantage.  The biggest challenge in all this will be execution.  It is a gargantuan task on a level Oracle has never delivered before.  It involves both coordinating a lot of existing parts and pieces as well as delivering some genuine innovation (Virtual Multitenancy will be non-trivial!).   They may not be able to pull it off.  But the stakes are very high, and they will have years to work at it.

What do you think of the Red Cloud?

Does the Cloud make Single-Tenancy OK for SaaS?

Multi-tenancy and all its flavors seems to be on people’s minds lately.  I just finished going back and forth with Phil Wainewright on some of the nuances of multi-tenancy and how it impacts the cost model for SaaS.  Phil’s post was on some of the sophisticated nuances of multi-tenancy as expressed by some of the latest announcements from the SaaS Vatican, Salesforce.com.

More recently, it has come to my attention both through my fellow bloggers of the Enterprise Irregulars as well as via a trackback to my blog post that there are those who are now saying the Cloud has made the world safe for SaaS vendors to forget multi-tenancy and plunge ahead with single-tenancy.

Not so fast! 

Color me skeptical.  If you don’t have a multi-tenant architecture, you’re going to argue it isn’t necessary.  That doesn’t make it right.  Before we get too far along, let me define multi-tenancy:

Multi-tenancy is a software architecture that allows multiple tenants to be hosted on a single box (or cluster of boxes) just as easily and economically as a single tenant could be hosted on the same configuration.

The bloggers taking the position that single tenancy is good enough hoist a variety of flags in support of their position, but for me, it boils down to answering one simple question about your SaaS business and its customers:

Fundamentally, do you have an application that can successfully run multiple tenants on a single box or not? 

If a single box has enough horsepower to run multiple customers for your app, the argument for single-tenant is completely (pardon my near-pun) untenable.
 
Salesforce runs 55,000 customers on 1,000 commodity servers.  You just aren’t going to be able to do that with a single tenant architecture no matter how much virtualization you choose to run.  If nothing else, virtualization runs afoul of a fixed cost/variable cost phenomenon very quickly.  A lot of the basic system software allocates fixed overhead, whether we’re talking about your DB server, your app server, your web server, or whatever.  Virtualization does not share the resources required for the fixed overhead, only the the variable costs.  Multitenant shares the fixed overhead too.  Those variable costs put an upper limit on the number of tenants you can shove onto a single box, no matter how small the tenant’s needs may be.
 
The new articles maintain that the Cloud fixes all this through the magic of elasticity.  Really?  That’s hogwash.  The Cloud at best and if you really architected your app to take full advantage of elasticity may help a little bit.  But most of the problem is database, and elasticity and databases so far remain a very hard technical problem to solve.  Try dynamically varying your partitioning and/or federation scheme to really scale up and down in real time in the Cloud.  It’s hard enough to get apps to scale to arbitrary Enterprise needs at all.  Try doing that in real time so you get multitenant cost savings?  Good luck!
 
So if you can’t run an average of 55 customers on each of 1000 servers like Salesforce, how many can you run without multitenant?  3?  5?  10?  What does that do to your cost versus true multitenant?  What does that do to the overhead of maintaining the servers?  What does that do to your cost of delivering the service and to the resultant cost model you have to saddle you customers with?  What does that do to you competively if you’re up against a company that does have the true multitenant cost advantage?
 
One example on the cost subject that I am familiar with:  a lot of the Social Software companies wind up charging by page views or total participant seats.  In many ways, this is anathema to community where you should do everything you can to encourage participation and not penalize it.  This is especially true for outwardly facing communities where the company wants a predictable cost model and can’t imagine being charged by their continually changing customer base or especially the changing usage patterns of that base.
 
In fairness, there are some business model + company + market + architecture combinations where it wouldn’t matter because you can’t run multiples on a single box.  If you’re strictly selling to organizations that can’t run on a single box no matter what, single tenant is fine.  Perhaps this is what these other bloggers are saying, but I’m skeptical any Enterprise 2.0 app would have that requirement, and that’s the kind of software these bloggers are describing.  FWIW, Helpstream will run 150 customers and nearly 400K seats on a single box loaded to about 10% of capacity.  That’s nothing though.  Look to the Googles, Facebooks, Amazons, eBays, Twitters, and similar big web properties to see real capacity.  Now combine that kind of capacity with multiple tenants.  It is a powerful competitive position to be in.

As I say, one can imagine combinations where you couldn’t combine multiple tenants onto a single box.  A honking big transaction processing ERP app might be one.  For another, at Callidus, I had customers using as many as 150 CPU’s to generate all the sales commission calculations for a huge salesforce.  To give an idea, we had telcos paying 20K sales reps and insurance companies paying 250K reps.  That’s a lot of transactions paid to a lot of people!  But those kind of Enteprise deals are very unusual for SaaS companies, and that kind of app is pretty unusual too because of the number of transactions being processed and the complexity of the business logic.  Still, such apps could be successful in those markets with single tenancy.
 
The articles go on to talk about the advantages of being able to customize these multiple instances.  Frankly, that scares me too, because the whole SaaS model really starts to break apart there when you decide to radically customize each instance.  It may be a value add, but it is a radically different value add than SaaS.  In fact, at that point, it’s a hosted ASP model, not SaaS.  Useful for some organizations, but there is a reason that model never achieved broad market appeal. 
 
Lastly, let’s talk about the whole security business.  This is the 800lb Red Herring in the room.  The minute you go SaaS or Cloud, you have outsourced that problem.  You can listen to vendors argue all day long about which architecture is “safer”, but that is an over simplification of the myriad factors that matter to the point it is just marketing and not substance.  It has as much to do with process as code architecture, which is why most of the security related standards like SAS70 and HIPAA don’t spend a lot of time on software architecture so much as the processes that surround that software.  Don’t take my word for it.  Look at what happened to Amazon around the whole AmazonFail incident for lack of process on an area that didn’t even involve any code.  Their problem was due to a data change.

BTW, the multi-tenancy imperative gets stronger constantly due to the multicore crisis.  We no longer get faster cpus (i.e. faster clock speeds) every 18 months according to Moore’s Law.  Instead, we get twice as many cores.  The easiest way to take advantage of more cores?  You guessed it: stack more tenants into the same box. 

For more, read Michael Dunham’s excellent post over on Haut Tec.

AmazonFail Shows Data Matters Too

No software company in their right mind would change code and move it to production without extensive testing to make sure the new code wasn’t broken.  It’s a tried and true business process supported by tools like automated build (gather up all the files, compile as necessary, package, and produce a running version), source code control systems (check in and check out with auditing so all the files that go into a particular version are known and verified), and so on.  That’s all fine and well, and though I do sometimes find a company that hasn’t made it to even that basic stage of operational process, there is a level of complacency associated with having such a process working.  The AmazonFail incident shows us that there is a lot more than just program code at stake here. 

First, what was the AmazonFail incident?  It seems that Amazon suddenly started delisting Gay and Lesbian publications from their sales rankings.  This had the effect of removing the books from search according to the WSJ.  Needless to say, the incident resulted in a great hue and cry since many assumed Amazon had done this intentionally and took it as evil behavior (along the lines of Google’s “do no evil” mandate).  Before long there were charges of  online censorship, and Twitter and the blogosphere were lit up bright talking about it.  Rumors even emerged that the incident was a result of hackers.  Eventually the whole thing became known as “AmazonFail“, and there is a hashcode for that on Twitter if you want to read all about it.  As I write this, “#amazonfail” is the third most popular search term on all of Twitter.

Clearly it’s been a major PR black eye for Amazon, but what caused it?

Amazon calls it, “an embarassing and ham-fisted cataloging error.”  Ultimately it affected over 57,000 titles including books well beyond the Gay and Lesbian themes first reported.  A more detailed internal story comes to us from Andrea James of SeattlePi:

Amazon managers found that an employee who happened to work in France had filled out a field incorrectly and more than 50,000 items got flipped over to be flagged as “adult,” the source said. (Technically, the flag for adult content was flipped from ‘false’ to ‘true.’)

“It’s no big policy change, just some field that’s been around forever filled out incorrectly,” the source said.

Amazon employees worked on the problem well past midnight, and then handed it over to an international team, he said.

Doesn’t this sound just like the sort of problem that can be caused by making a minor code change and then rolling out the changed code to production without adequate testing?  First, it was a minor change.  One field was filled out incorrectly by one person in France.  Second, it created a huge problem as minor changes in code often can.  Third, the problem was not immediately obvious, nor was the cause, so it got pretty far along before it could be fixed.  Yet it wasn’t code, it was just data.

In this day and age of Cloud Computing, SaaS, and web applications, data is becoming increasingly just as critical as code.  Metadata, for example, is the stuff of which customizations to multi-tenant architectures are made of.  In that sense, it is code of a sort.  “Soft” heuristics are common in search applications that have to decide which words to ignore completely, how to weight different words, which words might be profanity (or adult content in this case), which words are positive, negative, might be Spam related, and all the rest.  That’s all critical metadata to a search engine such as Amazon’s.  There’s a lot of other critical data to consider including credit card and other privacy-related information, financial information (what if someone gets the decimal point wrong when entering sales tax for a particular area?), and so on.

Data drives modern applications so completely, that we have to think about what this means for the security and robustness of our applications.  We’re still in our infancy on that front.  Modern software will test all the data entered to be sure it doesn’t contain a malicious payload (the SQL injection attack is one way to hack by entering special data in a field exposed to users) and there are many similar low level tests that are made.  But what about the business process that ensures the integrity of that data?  How can a single individual in France create such a big problem for Amazon by changing a little bit of data?

Let’s assume for the moment that we choose to treat that data as code.  That would mean we do some or all of the following:

-  Archive all the data changes in the equivalent of a source control (also called a “version control“) system.  We’d know every version of the data that was entered, who entered it, when they entered it, and there would be comments about why they entered it.

-  The incorporation of that data into a production environment would happen only at carefully orchestrated times (called “releases”) and only after testing had been done to ensure no problems were created.

-  If a problem manifested itself, an automated system would be available to roll back the changes one or more versions until the problem went away.  This is an important step with extremely serious problems because earlier releases will have been functioning long enough that there are no known serious problems.  Rolling back gives time to find the error without exposing all the customers to it in the meanwhile.  The error is eliminated and then the updated change is tested, and rolled out again.

Does that sound hopelessly painful as a process?  It’s exactly what most software developers go through for even the slightest change to code.  I’ll admit it would be too painful for every data change.  Amazon must add, delete, or change thousands of new listings every day.  Each one can’t be a full development release cycle.  But it does seem that applications should have some safety valves built into their fabric, and into the all-important data that they rely on.  Changing a listing is different than changing some data that almost 60,000 books rely on in search.  That data should be marked as sensitive and handled differently. 

There’s lots of architecture and process work to think about in order to avoid or minimize similar problems in the future for a whole host of applications.

Related Articles

It’s the Data Stupid.  Vinnie Mirchandani offers more examples of how we get into trouble with data.

TechCrunch gets it all wrong in a guest post by Marry Hodder.  Hodder argues unconvincingly that this was all due to an algorithm gone wrong and kept secret.  What happened is precisely NOT an algorithm.

If it had been an algorithm, it would have been an unambiguous set of rules by Hodder’s own Wikipedia-quoted definition.  Algorithms are explicit for their creators, and they are not accidental.  That they may be hidden from users does not detract from their explicitness, purposefulness, or unambiguity.

To assume an algorithm is at fault, is to misunderstand what an algorithm is, or to assume to Amazon purposefully set about creating an explicit and unambiguous set of steps to discriminate against Gay and Lesbian titles.  While the conspiracy theorists may like to natter on about this theme, it ain’t so.

The problem here, and my point in this blog post, is that we assumed we could focus on the algorithm and ignore the data that fed it.  Clearly a bad assumption.  In so doing, we allowed a minor change by an individual to create a major PR problem.  If we really think it was all a conspiracy against all things Gay, why not look for more explicit evidence.  Did Patricia Cornwell’s books about Kay Scarpetta, which include some Gay themes (Scarpetta is Gay) disappear as well?  I don’t think so.

It’s been true since we’ve had computers:  garbage in leads to garbage out.  The data is just as important as the algorithms.

Catching Up With 3Tera in the Clouds

Recently I had a chance to catch up with 3Tera CEO Barry Lynn and SVP of Sales and Marketing Bert Armijo.  It’s been a little while since I chatted with these guys and they’ve been busy!

It’s now been roughly 3 years since their first beta test.  Incidentally, they claim that beta makes them the first Cloud vendor, since Amazon S3’s beta was 1 month later!  Not sure selling Cloud infrastructure is the same as selling the Cloud like Amazon (that’d be like making the gold pans before the gold is found), but I do applaud their pioneer spirit.  If not the first, they’re certainly among a very small group of original Cloud Thinkers.

Good Catching Up With You Guys.  What’s New Since We Talked?

Our latest version is 2.48, which was recently released.  The big change there is we’ve added support for Solaris and Windows, and there is integrated monitoring.  We now have service on 4 continents, soon to be 5.  And we have customers taking advantage of that.  A customer can get presence on 4 continents in a day with 3Tera.

How Many Customers Do You Have Now?

Several hundred live customers, mostly through partners.

We have a number of hosting partners, and we’re always looking for more.

Tell Us About Your Partnering Strategy

People are starting to realize the need for private clouds.  People are starting to get it.  Federal Government and Large Enterprise want it.  There are legal restrictions on where data can be put.

For a long time partnering was unique to us.  People in the space all wanted to build their own cloud.  Our customers can work with multiple operators from Day 1.  Our customers do this on a daily basis.  It’s routine.  We have a button for it in the GUI to automate it.  Backing up to multiple points of presence, for example.

The product is maturing and we’re starting to see a change in types of customers coming on board.  Don’t know if it’s the economy or the Cloud industry.  A year ago, most customers were web or SaaS.  Now the vast majority are Enterprises.  It is a profitable and stable business though it puts a different kind of requirements on the product.

Why Enterprise?  I’ve Talked to a Lot of SaaS Companies Having Difficulty With Large Deals.

First I haven’t heard SaaS companies are having any particular problem with Enterprise sales.  There’s stress everywhere, but we don’t see the Enterprise as particularly stressed.  When business is good companies want control over price like SaaS offers.  But when business is bad they want economies of scale.

We love this economy.  Everything requires a bit of luck.  Here’s what’s going to happen.  This is the hardest hitting recession we’ve yet seen in the shortest period of time.  Some companies want quick ROI investment, particularly around saving money.  Others get completely frozen and don’t do anything.  There’ll be companies in both of those camps.

<The frozen camp is where I’m hearing the Enterprise problems.  Larger orgs seem more prone to freezing.>

If you look at things like Siebel or other SaaS having a problem, where customers cut back is in discretionary vertical functionality.  Do I have to do it at all?  We greatly lower the cost of almost everything.  We don’t build apps, we build platforms.  So we replace something non-discretionary with something also non-discretionary but cheaper.  Others are making discretionary spending cheaper.

A datacenter upgrade or tech refresh cycle was poised (last one was dotcom).  Now they lost budget for that, so its, “How do I run my business?”

You can’t run a business without IT infrastructure.  I may get rid of my cable TV, but I still have to buy food.  I just want cheaper food.  That’s what we’re out to do.  We can show them the catalyst for cheaper IT infrastructure.  We can even enhance quality while saving. 

People get the same level or more control as when the hardware was in their datacenter.  In fact, it’s more, because they have better tools to abstract large distributed systems.

How do you get the word out?

We look more like a web company there.  We don’t have a big field sales force.  We don’t have big Enterprise software contracts.  What we’ve done is to simplify and create a small incremental purchasing decision.  Even multinationals can start for a few hundred dollars a month, increasing spend as they see value.  That eliminates long eval cycles and the committee sale.  We’re more efficient and we pass that along to the customer.  We’re more focused on value instead of artificial billings like services and support. 

<This incremental pay-as-you-go cost is what I love about the Clouds.  We’ve seen it at my own company Helpstream when using Amazon.>

So we use telemarketing, or what a lot of people call Sales 2.0.  A lot of sales are Webex.  We only go visit customers who have an established footprint with us.

We minimize the onboarding cost and eliminate the lock in.  We avoid API’s that people have to write code to—that creates lock in which worries customers.  This minimizes the perception of risk.

We have a full blown disruptive product.  It is subscription based.  It’s incremental.  You can try it out slowly and then move quickly when you’re convinced.  That helps a lot in this economy. 

Customers save the capex because they don’t have to own the software.  They save personnel costs because people don’t manage servers, they just manage applications using our platform.  Saving thoses costs together with faster time to market really is a cheaper and better proposition. 

We use a combination of methods to attack the marketing problem.  We are voracious practitioners of PR.  PR offers so much more value than any ad we can place ever would, whether that’s a Google ad or a print ad.  Having some writing and putting their intelligence into it creates value. 

We also do some Google ads, though we have cut back on that a little bit.  It is valuable because it brings new people into the space.  It causes them to go find the PR.  We also do a few conferences.  We don’t go to big trade shows, but there are some decent focused small conferences.  We like conferences with a few hundred people because we can spend time educating someone there.

Often these conferences are vertical or geographic.  For example, there are Cloud Conferences for Government people.

Most of our leads are inbound.  Soon, we want to look at more outbound techniques, but without spending a huge fortune.  For example, we’ll be at the Web 2.0 show in SF.  We’re also doing the Sitcom Cloud Event in NY.  We’re doing Forrester’s Cloud Event.  We actively participate in Cloud Camp.

Tell Us More About Your Partner Strategy

When we started, it wasn’t clear this was the right path.  We got a lot of pushback, but we stayed committed to it.  Cloud is not going to be a one size fits all market.  There’s a lot of different purchasers and a lot of different requirements.  Banks want their systems of record in their data center.  Healthcare likewise.  Europe has a lot of laws about this.  There are many geographical issues, even involving physical limitations of the speed of light.

The level of service customers need and can afford is also all over the map.  One company can’t build a data center that meets all of those requirements.  We see a Federation of Clouds where users can take their workload to where their requirements are met.

It’s very popular to have developer systems in a different area than production.  The latter has geography, redundancy, and other requirements.  We transfer the workload seamlessly from one to the other, which is powerful.

We have a tiny little startup that has facilities and points of presence in three continents.  Startups couldn’t begin to do that in the past.  We have customers on military contracts that have very special security requirements. 

Only by partnering could we meet all of these requirements.  Our job is to build the best possible enabling platform.

We’re very conscious of our partners and want to make sure they make money.  We don’t charge them up front or make them sign up for huge commitments.  Its win-win, customers save money, but partners make even more money with us than on their own.

The real strategic value is there will be an evolution over the next couple of years.  Many companies are just not in the infrastructure business.  Yes, they spend billions, but at some point they’re going to stop building that infrastructure and start using the Cloud.  It’ll start slow, they’ll move bits and pieces, but at some point, they won’t need to own datacenters.  There is a whole industry growing up to service this.

What About Amazon, Google, Microsoft, et al?

Cloud computing will be a federation of many many clouds.  There are thousands of telcos in the world.  We see cloud computing playing out the same way.  Of course we see Amazon, Google, and the others playing in that game.

There should be standards to increase the interoperability and make it better for all.  Networking is a very successful example of this today.  Telephones with rotary dials still work today.  Other industries struggle to get to that point.

Why Not Amazon Today?

What does that mean? 

<Bob laughing, “I want your graphical management tool working for me in the Amazon Cloud!”>

We set out to do a particular thing.  Amazon didn’t exist back then.  We set out to make it easy to deal with large systems.  We built an underlying infrastructure to support the user interface that you see.  AppLogic’s Cloudware infrastructure identifies pieces that can be broken out as services.  We are starting to see how to do that.

There’s the UI, there’s a grid OS, we look at heartbeats, failures, etc.  We have a catalog system, we have a metering system, and we generate billing information.  Each could’ve been a company.  But we built it all together as a seamless whole.

Now that we understand how this all fits together, we can look and see how to do it on systems that have fewer services.  EC2 is one of those targets.  We’ve been open about that.  It won’t happen in a month or two, but it’s something we’d like to do.  Amazon is one of several.

We don’t want to be seen as a front end for a cloud. 

Thanks Guys, Great Discussion!

<3Tera remains one of the Cloud Leaders that I like to keep an eye on.  They’re enabling the hosting world to build their own Clouds using 3Tera’s platform.  That ensures a lot more Clouds will be available with lots of interesting features and distinctions.  It’s all good for the end users!>

 

Why You Want to Eliminate Middlemen in the Cloud

Hulu’s decision to cut off Boxee from being able to display Hulu content is driving some consternation in the blogosphere.

Fred Wilson, an investor in Boxee, thinks people just don’t understand and that Hulu should come back to the table.  Understandably its a blow for Boxee that is tough to take early on when momentum is everything.  Fred has long been a lover of streaming media and predicts the ultimate demise of owning your own media.  He and I have gone back and forth on this issue in the past, and what’s happening to Boxee is a bit ironic, because it proves my point.

Meanwhile CBS is going to go after Hulu for shutting off TV.com which is ironic given the Boxee situation.

Techcrunch writes an amusing post entitled Free Fred Wilson.  Fred needs “freeing” because he is caught between the rights of a user to view content the way they want to and the rights of the content owner to control how that content will be displayed.

What does all of this have to do with Middlemen in the Cloud?

O’Reilly Radar comes closest to my thinking with this quote:

The real insult, though, is calling the people who made them cut Boxee off “content providers.” They might as well have told the studios they are the moral equivalent of the guy schlepping reels around the projector booth.

Did you catch it?  Hulu and Boxee are the Middlemen.  They have no power, no control.  You can think you’re buying something from them, but the real power is with the Content Providers, and you don’t have a deal with them.  Unless you bought the media.

This applies to other types of virtual goods and service available through the Cloud.  If you go to some organization that’s trying to arbitrage Cloud Computing resources, but doesn’t actually own any computers, they’re just Middlemen.  They are resellers.  Their margins are thin and the value they can add is limited.  Worse, if the owner of the real value add, the guys like Amazon that have the servers, want to change the deal, they can do so.

To be sure, you can make a deal with the Content Providers or original owners of the physical goods such as servers and still get into trouble, but at least you only have to wade through the terms of one deal.  When dealing with Middlemen, you usually have no idea what deal they have with the ones really creating the value.  You have no idea whether they can deliver on the deal you think you have with them.  There is a cutout that allows the Originators of Value to do as they please.  BTW, Hulu is an instrument of the Content Providers.  Read that O’Reilly article to see more detail.

The other problem at work here, and vaguely implied in the O’Reilly article, is that ever since William H. Gates III got the better of IBM, big companies have been afraid the nerds would steal their treasure and make them look foolish.  They work overtime on Draconian Measures to prevent that.  They’re certainly not about to let both a Middleman and a Nerd get hold of an actual Golden Goose, or likely even a whole Golden Egg.  If there is one thing Content Providers can never ever let happen, it’s being made to look foolish.

Hmmm.  I wonder what the content providers think about the idea that the URL for O’Reilly is radar.oreilly?  One of my startups hired Radar O’Reilly one time to help us promote a service called PriceRadar.  He was very clear that he couldn’t even call himself Radar because he was just a Middleman for his own character.

Hate when that happens!