Re: [Xen-users] Announcing XenMaster

[Wannes De Smet <wannes321@xxxxxxxxx>]

On 12 Feb 2012, at 12:07, Niels Dettenbach (Syndicat IT&Internet) wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> 
> 
> 
> Wannes De Smet <wannes321@xxxxxxxxx> schrieb:
> 
>> To elaborate choosing Java for our back-end:
>> - Java applications can be deployed on a wide variety of operating
>> systems, if not all.
> 
> This was and still is the theory or marketing hint behind the concept of java 
> which - as a goal - was not nearly reached until today as even java is not 
> java on different implementations.

I think I'm missing something here, at the moment you can get a proper -- as in 
properly working, not certified -- JDK 7 build on Mac OSX, Debian, Fedora and 
even Windows, which lead me to believe Java's availability is rather good. 
> 
> I addition there still are versioning and licensing barriers for many users 
> on different distros.
> 
> 
>> - Eventually the back-end will also be orchestrating pools or clusters.
> Ok,
> but this did not leads to java...
> 
>> - The back-end parses responses and shrinks updates down to only the
>> bare minimum, limiting bandwidth use by the front-end.
> 
> As typical daemons in such scenarios usually do...
> 
>> - The back-end allows access to your servers over a single TCP/IP port,
>> the Xen-API will not be publicly exposed.
> Ok,
> sounds nice too, but has nothing to do with java.
> 
>> - Again we’re not running a whole Java EE stack, the front-end is a
> This would be completely overkill... ß)
> 
>> webapp that lives on its own and communicates with the backend over a
>> WebSocket connection.
> 
> Ok, so a typical software stack on such a machine would be:
> C
> (shell)
> Python
> Java VM
> any (other) Webframework/language?
> (Webserver)
> 
> Why do you did not use any of the languages/scripting software still 
> required/coming with a xen environment or any of the many faster plus smaller 
> plus (until today) typically easier to handle/administer solutions for back- 
> and frontend too (i.e. Python, Perl or C)? Writing a deamon in such languages 
> is not a big job (see i.e. man perl-ipc) and there are many small to large 
> module collections / web frameworks available on any levels and rfc.

Full disclosure: I chose Java because I know Java, I know what it is capable of 
and it is something I'll happily defend. C is a tough nut to crack, if I were 
to rewrite the whole thing in C, the chance of me getting killed by an ice bear 
would be bigger than the backend working properly in about 5 months. Regarding 
Python and Perl: I don't know them well enough to make a good argument, but 
until proven otherwise, I will maintain that Java is the most stable and 
easiest platform for our backend. (I am stating my opinion here, if you'd like 
to take this discussion further we should get ourselves a room :).
> 
>> - Coupled with Cassandra, the back-end is the only thing that needs to
>> be run (one single instance), for any number of hosts.
> 
> 
> Sorry, but until today and propably / at least within the next future in wont 
> rely on any Java stuff within our productive xen / cloud systems. This may 
> change at anytime within the future if Java would be able to clean out alle 
> the steps it was/is behind other solutions.

I'm hoping Oracle plays nicely for the years to come, it seems like using Java 
in a FOSS environment today is like cursing on American television.

To conclude: Java works (for us). One can only hope its reputation gets better 
in the years to come.
> 
> just my two cents here...
> 
> Best regards and sorry for the noise,

Thanks for your opinion!

Have a nice Sunday,
W
> 
> 
> Niels.
> - --
> Niels Dettenbach
> Syndicat IT&Internet
> http://www.syndicat.com
> -----BEGIN PGP SIGNATURE-----
> Version: APG v1.0.8
> 
> iIEEAREIAEEFAk83nYM6HE5pZWxzIERldHRlbmJhY2ggKFN5bmRpY2F0IElUJklu
> dGVybmV0KSA8bmRAc3luZGljYXQuY29tPgAKCRBU3ERlZRyiDbhOAJ97XYi1uZOS
> AwDNWh2Js+KqgaiscgCfbYm6L9kvp/71iH9jFhjteY+B2Po=
> =wZb8
> -----END PGP SIGNATURE-----
> 


_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users