|
Home > Archive > Apache Directory Project > March 2007 > [OT] VMware ESX + BEA Liquid VM
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
[OT] VMware ESX + BEA Liquid VM
|
|
| Enrique Rodriguez 2007-03-26, 1:12 am |
| Hi, Directory developers,
I've been meaning to ask the list if anyone had been following this
topic; other articles are available if you Google:
"With VMware's help, BEA ditches the operating system" (URL may wrap)
http://searchservervirtualization.t...1234289,00.html
I've worked a decent amount with VMware and Xen running infrastructure
services. If not specifically any of the aforementioned vendors, then
at least this model (VM tight to the hardware) has a lot of merit;
partly for performance but mostly for management.
I also think it has a big role to play in what we're trying to do at
the Directory project. For a long time I thought JNode was the answer
here, but this "operating system-less" model is even tighter. And we
have a story, with IDfusion, for how to separate services to make
realm control even more flexible.
Food for thought.
Enrique
| |
| John E. Conlon 2007-03-26, 7:11 pm |
| Hi Enrique,
Enrique Rodriguez wrote:
> Hi, Directory developers,
>
> I've been meaning to ask the list if anyone had been following this
> topic; other articles are available if you Google:
>
> "With VMware's help, BEA ditches the operating system" (URL may wrap)
> http://searchservervirtualization.t...1234289,00.html
>
>
Sounds good, but will it be Open Source?
> I've worked a decent amount with VMware and Xen running infrastructure
> services. If not specifically any of the aforementioned vendors, then
> at least this model (VM tight to the hardware) has a lot of merit;
> partly for performance but mostly for management.
>
> I also think it has a big role to play in what we're trying to do at
> the Directory project. For a long time I thought JNode was the answer
> here, but this "operating system-less" model is even tighter.
Why is so different between BEAs offering and JNode other than offering
the ability of the running the BEA JVM alongside partitions with full
OSes.
In spite of the BEA offering instead of eliminating the JNODE I could
see why the following three options could all still apply to ADS.
1. for a Dedicated appliance server = JNODE + ADS
2. for a Multipurpose Desktop = Native OS + JVM + ADS
3. for a Dedicated server = VMWare + BEA Liquid JVM + ADS
From our stand point, being Java based do we care which of the 3
alternatives are chosen by our users?
John
| |
| Enrique Rodriguez 2007-03-27, 1:11 am |
| On 3/26/07, John E. Conlon <jconlon-H77XNXO9PA9Wk0Htik3J/w@public.gmane.org> wrote:
> Enrique Rodriguez wrote:
> Sounds good, but will it be Open Source?
I doubt it. These particular vendors have a history of free versions, though.
> Why is so different between BEAs offering and JNode other than offering
> the ability of the running the BEA JVM alongside partitions with full
> OSes.
Besides differences in product maturity and performance, IMO the most
important difference is the promise of their tools for managing large
numbers of hosts/VMs.
> In spite of the BEA offering instead of eliminating the JNODE I could
> see why the following three options could all still apply to ADS.
>
> 1. for a Dedicated appliance server = JNODE + ADS
> 2. for a Multipurpose Desktop = Native OS + JVM + ADS
> 3. for a Dedicated server = VMWare + BEA Liquid JVM + ADS
>
> From our stand point, being Java based do we care which of the 3
> alternatives are chosen by our users?
From our standpoint as developers, we don't care. But, from my
perspective as a former Fortune 200 IT director, our ability to "play
nice" with highly-desirable datacenter infrastructure is an important
differentiator. This will be a selling-point that proprietary and
other non-Java open-source solutions won't have.
Enrique
|
|
|
|
|