Centera and the Centera API have been in the middle of a storage blog smack-up.
I was surprised to read the claim that the Symantec/Centera integration had issues. First of all, they've been an integration partner for years. Secondly, their implementation is top-notch, given that their integration architect is one of the most well-respected Centera-API experts in the industry! Therefore it doesn't make sense that their developers would have a problem with the Centera API.
Symantec has confirmed that there are no data integrity issues with Centera. It was a false alarm.
At the heart of the supposed issue was the need for partners to integrate their applications with Centera's SDK. Hundreds of them have done so.
It's worth exploring the reasons why these partners decided to integrate with Centera in the first place. They chose to integrate with a technology (object-based storage) that was bleeding edge.
Issues arose during the integration. Bugs were found. Bugs were fixed. Workarounds were added. Requests for enhancements were made. Features were added. Best practices were advertised. Quality improved.
Customer adoption of the resulting applications legitimized object-based storage systems as a third category of system (alongside "block" and "file").
Customers. Partners. Storage system vendors. What would they come up with if they had a chance to build a new API from scratch?
They already did. It's called XAM.
Choosing to Integrate
Why did partners choose to invest in an object-based approach to storage? There are differentiable advantages to these types of systems. I've written before about the differences that I see as a software engineer. From a value perspective I see four things:
- Authentic original content. Application vendors wanted a new technology that could open a document or file and be positive that the content had not been modified since its creation.
- Metadata required. Application vendors wanted a new type of storage system that required metadata be sent along with the content.
- Ease-of provisioning: Customers storing HUGE amounts of fixed content did not want to spend their time configuring LUNs and/or file systems for ever growing capacities.
- Application separation: Customers wanted to partition their storage on an "application" basis (as opposed to a file or LUN basis).
Partners (and eventually customers) recognized that these four capabilities (along with many others) would offer differentiation in the market. So they invested in the integration.
Collaborating on a Standard API
The Centera API is being replaced by the XAM API. The original API still fully supports Centera, but any future enhancements will roll into XAM. Customers, partners, and storage system vendors created the XAM API in a collaborative effort. The original Centera partner integration yielded a secondary benefit: the ability to leverage past experiences. The XAM working sessions were attended by participants who knew what to carry forward from the Centera API and what to leave behind.
The XAM API will allow an application to use object-based techniques on any storage system that supports the XAM initiative. It's open to anyone who wants to play.
This openness is opening the door to additional research in object-based storage systems. Academia is much more inclined to research a technology that is not tied to any particular vendor.
Positioned on the Cutting Edge
When a technology moves from proprietary to open, a strong surge in research often results. I'm seeing this research beginning to happen both inside of EMC and outside as well.
Internally, EMC has advanced the following iniatives:
- Established a XAM research team in Shanghai. This team has developed a Centera virtual storage appliance (VSA) that has been used for dozens of internal projects.
- Funded several XAM proof-of-concepts, including projects related to data lineage, data preservation, and file systems.
- Ran a worldwide XAM coding challenge and flew the winners to the EMC October 2008 Innovation Showcase.
Externally, I'm aware of the following research initiatives:
- SNIA has had initial discussions about running a XAM coding challenge of their own.
- A XAM paper was presented at the Digital Curation Conference in Edinburgh, Scotland.
- I've just submitted a data lineage / object-based storage paper to the JCDL.
- I recently met with a research team at the Sloan School at MIT; they are interested in engaging in XAM research, potentially as part of the Data Space proposal.
Quality is the Key
I've mentioned before on my blog that Centera is a 5 9s storage system. Failure rates have been calculated on data interruptions/outages for Centera systems in the field, and the quality metrics are right up their with EMC's big 3: Symmetrix, CLARiiON, and Celerra.
Kudos to Centera's partners, and kudos to anyone who has ever worked in Centera partner engineering. My lasting impression of people that worked in this group is that they knew that they were on the bleeding edge, loved it, and worked hard with the partners. The job of bringing the Centera API into the mainstream is complete, and XAM now becomes a solid, cutting edge technology for object-based systems.
As I mentioned previously, leave me a comment here if you are aware of additional XAM research occuring in your company or university.
Steve
Thanks for this detail, Steve, especially the unequivocal statement that "the Centera API is being replaced by the XAM API". This is news to me!
I've long said that the entrenched file and block concepts would give way to a more structured system with metadata, and XAM will certainly move us in that direction. I'm especially eager to see what Microsoft and the Linux community do with XAM. Keep us informed, eh?
Posted by: Stephen Foskett | February 05, 2009 at 06:31 AM