SaaS data loss: The problem you didn’t know you had

The accessing devices don't use Maui software themselves but they access objects or files, or their applications access data, that is stored on the Maui infrastructure.

How do they know it is stored on a Maui-infrastructure? How are the Maui repository's contents made known to these devices? How are the Maui contents in each node made known to the others? How are object imports and deletions handled, indices updated, and their space provisioned/reclaimed? How are object security levels created, maintained and altered?

This is what Maui could be - Maui will be a clustered storage node. A file (object) system with, literally, a global name space; a object ingest and classification system. Maui will be an object placement, management, location and protection system; a search process; a real time data mover across global distances. It will be a global repository content representation system with multi-mode client access and ingest request and completion support; a self-tuning, self-healing and self-correcting management system reacting automatically to surges in demand and immune to any single failure scenario.

Maui will be an object access and tracking system with the ability to automatically move content to access hotspots and load-balance between storage nodes in a cluster and data centre nodes; it will be one of the world's most complex business continuity and disaster recovery systems. It will be running inside a global data centre infrastructure comprising physical and virtual data centres, servers, networking and storage of a complexity that hasn't been built before, and will need this virtualisation at multiple levels to provide the provisioning and scaling flexibility needed.

If the paragraph you have just read is Maui then EMC might consider outsourcing it to Google. It might be delivered quicker.

Is Maui the infrastructure or the clustered (object) filer O/S? A clustered object/filer is deliverable in everyday product terms. A global and self-healing/managing/tuning/correcting object repository infrastructure isn't. That's big - really big.

If Maui is the clustered object (filer) O/S then it needs an infrastructure to do the global stuff. What are the boundaries between that infrastructure and Maui? The more that Maui has to do the longer it is going to take to produce it. The less it has to do the longer it will take to define, devise and implement the infrastructure.

It's possible that there are two projects inside EMC - the Maui clustered storage software and the linked data centre infrastructure behind it.

Maui hasn't appeared yet, 12 months after being first revealed. If it's intertwined with the infrastructure component then that's no surprise at all, is it? It isn't going to appear just like that because nothing like that has ever been built before. This whole thing - Maui plus infrastructure - could be one of the most complex coding projects on the planet. Watching EMC's internal development engineering bandwidth cope with this will be like watching a python swallow a moose - a whole moose herd, in fact.

What might happen is that the clustered object/filer O/S part s delivered first with the marketing spin presenting Maui as a clustered storage building block which can be used by customers directly, but which will also be used by EMC as it builds out its own global repository infrastructure.

In this way Maui might be presented as a clustered object/file system with terrific scalability, positioned as an HP ExDS9100 beater, an Isilon buster, a kick in the IBM Scale Out File System (SOFS) butt.

But if it is only this, with no global repository infrastructure behind it, then EMC will have undershot terribly the expectations it has set. Without the infrastructure Maui will be in danger of becoming another Invista (EMC's SAN director-hosted storage virtualisation and management software): a worthy idea oversold and under-delivered. ®

Steps to Take Before Choosing a Business Continuity Partner