Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [aperi-dev] Adoption of Aperi...

Hello all,

 

I wanted to respond to this from the point of view of a storage vendor looking to have Aperi work seamlessly with our product line, which may be a different take than the typical end-user, but I thought I’d throw it out there. In particular, I wanted to address the question “What does Aperi need to be in order to add value to your organization?”

 

  1. First off, as a company interested in contributing plug-ins to the Aperi codebase that allow specifically for easier management of our devices without increasing the level of code bloat Aperi users have to deal with, we’re interested in keeping the architecture and implementation of Aperi as cleanly modular as possible. We’d like to be able to write plug-ins that touch as little of the existing codebase as possible, for easy addition or subtraction, and have customers that are interested in using Aperi to manage our devices be able to do so without installing any extraneous elements that they will not be using (for example, utilizing or writing plug-ins for the device managers without needing to install or touch the tape managers) to keep the footprint as small as possible.
  2. Along the same lines, we’d like to be sure Aperi keeps a focus on having the native GUI that comes with Aperi be easily replaceable with another GUI should a vendor choose to write one. If a company, for example, wishes to build on the Aperi codebase and infrastructure while maintaining a look and feel that has a consistency with the rest of their brand, this should be easily accomplished with as little code-hacking as possible. I know Aperi is in theory designed and implemented to accommodate this, but theory often falls by the wayside when things get put in to practice, and we need to be vigilant to ensure that this does not happen.
  3. We’d like to see Aperi possibly move toward a more database-agnostic platform. For example, we know that the underlying technology is SMI-S, and we’d like to be able to wrap that protocol in whatever wrapper we’d like to develop within, not necessarily just a Java platform. Other vendors may as well. If someone is looking at browser-based technology for their products, how does the information currently stored in a DB2 or Derby database translate to a browser DOM, or what if a vendor wishes to use a more lightweight SQL database instead?
  4. The more developer tools we can make available, the better. If we want folks contributing code, we should make it as easy as possible for them to learn about the architecture and structure of Aperi and how to develop for it. Detailed information on how to write plug-ins would be super helpful, as I mentioned in today’s meeting. Good documentation on writing plug-ins, making contributions, etc. would really help us to help make the world of Aperi a better place, at least when it comes to managing our storage.
  5. Continued development of a robust and rich SAN simulator tool will help people looking to contribute to Aperi immensely. Just wanted to highlight the importance of that tool to this community and mention that it should be updated regularly.
  6. Support for additional OSes. As we’ve been discussing on the distribution list, support for Solaris would be great. Just wanted to second the motion.

 

 

On the topic of my experience with Aperi thus far, I’ve already written in detail regarding my installation experience, pre-GUI-installer. I intend to embark on a complete analysis of the interface and interaction models  and will share the results of that with the community once I’ve completed it.

 

Thanks,

 

Jenny

 

Jenny Monesson, Ph.D.

Solutions Architecture

LSI - Engenio Storage Group, Austin TX

jenny.monesson@xxxxxxx

 

Voice: (512) 794-3723

Fax: (512) 794-3702

 


From: aperi-dev-bounces@xxxxxxxxxxx [mailto:aperi-dev-bounces@xxxxxxxxxxx] On Behalf Of Todd Singleton
Sent: Thursday, August 23, 2007 2:31 PM
To: aperi-dev@xxxxxxxxxxx
Subject: [aperi-dev] Adoption of Aperi...

 


Hello All,
This post is intended to stimulate some open, candid discussion about the adoption of Aperi.  This is especially important as we head into 2008 - we need to make sure that, as a community, we are adding value to Aperi in such a way to help drive adoption.  So please chime in with your thoughts and incites.  

What does Aperi need to be in order to add value to your organization?  This is the fundamental question that needs to answered by all members of the community.  Does Aperi need to be a competitive end-user product for IT storage administrators?  Does it need to gain a strong end-user following like Nagios and Apache did (producing demand from customers)?  Does Aperi need to be a collection of easily consumed components?  If so, what does 'easily consumable' mean for you?  Does Aperi need to focus more on SAN simulation (or other support tools) and less on a real-time management application?  Is your organization interested in adopting the entire code base, rebranding it, and selling it as a commercial offering?  
Answering these questions will help us focus our efforts and ensure that Aperi produces value for participating members.    

What has your experience done for your organization so far?  Have you attempted to adopt Aperi?  Have you attempted to use Aperi?  If so, what were your first impressions?  Did your experience help or hurt?  
The download, install, and run process has been painful for many for a number of reasons (many of them legal).  However, this experience continues to improve and should be much less painful with the upcoming builds and releases.  However, do share your thoughts.

What does 'adoption' mean for your organization?

Aperi has several cool features (topology viewer, discovery, reporting, etc.).  However, we know that cool does not equal useful and free does not equal valuable.  So what would be substantially useful and valuable to your organization - enough to drive adoption?  Do share.

Todd Singleton
Software Engineer, Tivoli, IBM
Menlo Park, CA
email: toddsing@xxxxxxxxxx


Back to the top