Re: [Smartfrog-developer] Smartfrog habilities

Steve Loughran <[email protected]> Wed, 07 Mar 2007 14:14:36 +0000
Newsgroups gmane.comp.java.smartfrog.user,gmane.comp.java.smartfrog.devel
Message-ID <[email protected]>
ziuziu wrote:
> Hi all,
> I am new on Smartfrog and i would like some advice if possible. I am about
> to use it as an automated deploy tool for a production enviroment that
> contains around 8 servers at the moment.
> Do you think smartfrog easy to use..... reagarding your experience. Does
> anything to do with opsware.
> If anyone could give me a point of view it would really help.
> 

Hello ziuziu

I think you need to open the question up the smartfrog-support mailing 
list; to get the opinions of people other than the developers -we are 
clearly biased :)

Here are some of my opinions on the topic

-If you've ever used Ant, using SmartFrog for your deployment isnt that 
hard a conceptual leap. Just as you configure and run tasks for building 
things, now you configure and deploy components. Some big differences 
are (1) the components stay deployed until terminated, when they are 
meant to clean up, and (2) you can spread components across multiple 
machines.

-setting up an 8 server cluster can be easy or hard, depending on 
whether the machines are identical, or whether you have  a more complex 
setup of, say, two DB, four app servers, two load balanced front ends 
and some router in front of it all: the more complex your system, the 
harder it is to describe the configuration. Eight identical machines? 
Get the deployment descriptor right for one, then deploy it on eight boxes.

-It has built in components to run native and java programs, and 
manipulate the file system, which, together, can be used for a lot of 
deployments. There is extra support for application servers (especially 
jetty, tomcat and JBoss), and in the next release, databases.

-If you can use the built in components, then building up a deployment 
by gluing them together, possibly in complex workflows, means you can 
deploy without writing any Java code. If you have to resort to java 
coding, you have more work, but you may have a reusable deployment 
component, which is yours to keep, or to share if that is your wish 
(i.e. its your code; SmartFrog being LGPL doesnt mean your components 
need to be open)

-It's not XML. This is good and bad. Good, because the docs are more 
readable, there's no need to understand XML namespaces, full XPath 
syntax or, worst of all, XSD and WSDL. Bad, because you have a new 
syntax to learn. I'm always forgetting semicolons at the end of lines 
-but then I do the same in Java.

-It doesn't have a workflow GUI, one of those drag-and-drop tools that 
look nice but dont scale. We have a standalone GUI tool, and an eclipse 
plugin, and hopefully, soon, one for NetBeans. all of these are text 
based, but make editing the text easier.

I havent used opsware; I have no opinions on it. There are a couple of 
things in Ruby that are possibly similar; Capistrano and Puppet. Puppet 
is good for configuring a system; I don't know if it can applications in 
the detail SmartFrog can with Java code

Capistrano can deploy Ruby applications, though its workflow is somewhat 
hard coded to deploying Rails applications and it uses Linux everywhere. 
Its very much like a make-for-deployment, with some notion of 
transactions, but is still very procedural. You run a sequence of 
operations to cold deploy an application, or migrate a database, instead 
of deploying a set of components whose goal is to keep the system in the 
declared state.

I would certainly encourage you to start using SmartFrog, starting off 
with the problem of configuring one of the machines, a test machine, or 
a single part of the system (the database, the application server), and 
as you get one host working, ask for advice on the mailing list on how 
to do fault-tolerant multi-machine deployments. We have components to do 
Service Location Protocol and Anubis (a distributed 'management' 
tuple-space system) that can be used to let nodes discover each other 
and interact without the need to hard code machine names across the 
different descriptors.

-Steve

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV