Skip to content

A Catalyst Appliance?

CatalystDojoPerlPostgreSQL We have had some interesting discussions about offering a locally hosted version of a Catalyst Web Application called Flexi Time Manager.

The question was also raised on the Catalyst Mailinglist, with no we raised it on the PerlMonks forums at Offering a locally hosted solution?

A very interesting response about doing an appliance:


I've been pondering these questions in anticipation of some stuff i'm working on. Some corporations prefer to have the stuff in-house for a few reasons. These come up alot:
1. Security - they may feel unconfortable having their data outside the company. it may even be policy
2. Network outages - if its internal, your site or their network connection going down won't affect the in-house application (unless you use the light frontend that goes back to your servers)

Thoughts to consider:
1. How much control do you want to give them in terms of access to the source code and the ability to break things even if well meaning. Will they need to sign an NDA?
2. How is the application maintained? Do you have a tunnel into their environment to fix things? (will they consider this a security risk?)
3. How are updates applied? Onsite cdrom/flash drive? Downloads (like IPCop), automatically downloaded and installed? How do you deal with a failed update.
4. What happens when they want to connect some other system to your database to pull the timesheet data?
5. Security. What liability is involved if the appliance is the mechanism for the breach. And would the appliance provide a method for securiy breach (see #2 and #3).
6. Legality - if you have gpl code, you're ok when its a service, when leasing hardware/software youre approaching a greyer area the RMS wanted to kill with GPLv3 (it didn't make it into the final cut)
7. If your model is based on usage, how do you guarantee you're sending back the appropriate data and a firewall isn't getting in the way.

I'm personally leaning towards the leased appliance model. You "lease" a box with the software installed on it. Providing in that fee is an "update" subscription service, where the software will poll the update server and pull the encrypted & signed updates down. Perhaps with a web interface for the company admin to decide whne to apply the updates. Of course the leasing is noticably more expensive that the web version (for the updates and support).

Applications that do some of that I was talking about:
1. IPCop - downloadable signed updates
2. Tivo - ideal model in my mind (at least for the hardware end result)
3. Google search appliance (to they offer the google office apps as an appliance yet?)
4. Vigilant Minds security appliance - (was originally nessus with a rockin web interface)
5. and SugarCRM i think also have appliance versions as well.

You want the corporate types to think of the box you provide like a Tivo, not like software they purchased. In the latter you end up with the companies wanting you (or themselves) to make customizations to the app. Enough of those and you become a development shop and not a service provider.

Now all that said, the Xen/Vmware image idea might work well. I've dabbled with using a single Xen image on a piece of hardware just to cope with the fact that hardware continually improves and unless you're buying in bulk from Taiwan you're guaranteed to not hav ethe same platform to install on year after year. It will also offer greater flexibility for larger companies who have migrated to a Vmware setup. The downside is that if they stop paying, they can effectively keep the Vmware image and get into it whereas an appliance can be reasonably locked down to make it less likely. (Downloads are something people put little weight WRT to stealing.)

How does this relate to perl? There are dozens of modules out on cpan that can help with accomplishing the task of remote updates, package signing, etc...


Food for thought.....



No Trackbacks


Display comments as Linear | Threaded

No comments

Add Comment

Enclosing asterisks marks text as bold (*word*), underscore are made via _word_.
Standard emoticons like :-) and ;-) are converted to images.
BBCode format allowed
Pavatar, Gravatar, Favatar, MyBlogLog, Pavatar author images supported.
Form options

Warning: Use of undefined constant CHARSET_NATIVE - assumed 'CHARSET_NATIVE' (this will throw an Error in a future version of PHP) in /home/suretecsystems/www/blog/ on line 182