[prev in list] [next in list] [prev in thread] [next in thread] 

List:       opensolaris-appliances-discuss
Subject:    [appliances-discuss] Re: What do you want from your appliance?
From:       ccheetham () gmail ! com (Chris Cheetham)
Date:       2006-02-27 10:17:36
Message-ID: 31649361.1141064253606.JavaMail.suncom () oss1
[Download RAW message or body]

Our next generation of product is replacing our current line of servers packaged as \
software components with a functionally similar line of servers packaged as \
appliances.  (Perhaps my definition of appliances differs from yours, but I guess \
that's part of the reason for this post.)

Being a Linux user for about 10 years, I initially targeted Linux as the base OS.  \
However about that time, Solaris 10 had just been released and after some \
re-evaluation decided that Solaris was the better platform.  I'm not averse to using \
OpenSolaris at some point.

To me, it doesn't matter how functionally simple or complex an appliance is.  An \
appliance is all about the packaging of hardware, OS, tools and software that are \
known to function as a whole, and (just as importantly) is pre-installed and to some \
extent pre-configured.  The real benefit of an appliance is that removes many of the \
variables around traditional software daemons.  What OS are running?  What version?  \
Did you install this patch?  What other products are installed?  Blah, blah, blah.  \
It removes some of the traditional "exchanges" between support and customers, and \
between developers and testers.

What I'd find beneficial from an "appliance" project are 2 frameworks:  one for \
manufacturing/install and for platform management.  On other words, I as the \
developer will focus on implementing my business logic, and you as the "appliance" \
toolkit provider can give me the tools to deploy that logic and subsequently manage \
the framework.

Manufacturing/install:  Our first release, in which we're cutting our teeth, is using \
JumpStart/FLARs to image X2100s.  It's largely a process specific to a particular \
appliance.  However there are aspects of the current process, as well as some \
yet-to-be-developed, that would be beneficial to anyone producing appliances.  In our \
case, we'll have between 3-4 appliances, some on Tx000s, some on the Xzz00s, each \
with varying versions of 3rd party tools.  A manufacturing framework (either for \
development or pruductions) would promote best practices, provide imaging tools, and \
support versioning (I want to install this specific rev of this specific appliance).

Platform management:  A simple appliance might run your coffee machine, a more \
complicated one could house multi-tiered J2EE appliance.  The target audiences and \
uses are vastly different, so their UIs will be different in look-n-feel but more \
importantly in access technology (HTTP, RMI, SOAP/HTTP etc).  However both may need \
to expose some management facilities, e.g. networking, logging, access, etc.  There's \
another OpenSolaris project, Visual Panels \
(http://opensolaris.org/os/project/vpanels) that looks promising in this regard.  The \
screenshots show a Java client, but more importantly are the JMX and SMF \
infrastructures than an appliance could leverage.

/clc
--
This messages posted from opensolaris.org


[prev in list] [next in list] [prev in thread] [next in thread]