Eucalyptus
tluk...@exnihilum.com
"Open source cloud platform is commercialized by its creators" @
TL
Diego Parrilla Santamaría
So the current version of Eucalyptus is not enterprise-grade???
Sorry, but I'm a bit confused about the roadmap of Eucalyptus Systems... Are they going to sell Support Services or Premium Products?
Diego Parrilla Santamaría
Business Development Manager & Product Technology Strategist at Abiquo.
+34 620 57 81 46
mailto:dpar...@abiquo.com
skype:diegoparrilla
www.abiquo.com
Boris Quiroz
> Eucalyptus..."
>
> So the current version of Eucalyptus is not enterprise-grade???
>
> Sorry, but I'm a bit confused about the roadmap of Eucalyptus Systems... Are
> they going to sell Support Services or Premium Products?
>
http://www.eucalyptus.com/enterprise/
> Diego Parrilla Santamaría
> Business Development Manager & Product Technology Strategist at Abiquo.
> +34 620 57 81 46
> mailto:dpar...@abiquo.com
> skype:diegoparrilla
> www.abiquo.com
>
>
>
> On Mon, May 4, 2009 at 4:10 AM, tluk...@exnihilum.com
> <tluk...@exnihilum.com> wrote:
>>
>> In case not everyone has seen this, I thought I'd pass it along:
>>
>> "Open source cloud platform is commercialized by its creators" @
>>
>>
>> http://www.infoworld.com/d/cloud-computing/open-source-cloud-platform-commercialized-its-creators-064
>>
>> TL
>>
>>
>
>
> >
>
http://boris.insert-coin.org
AADB 52A9 8C6B 1C73 D0C4 570E 952C 2DC1 D1D0 A4E7
gpg --keyserver pgp.mit.edu --recv-key D1D0A4E7
Xen Community Member
Chris Marino
I think its great they got financing. It was pretty clear that's the direction they were headed for a while now and this confirms it. As for their future, IMHO, they run the risk of pursuing a 'boil the ocean' strategy. If they've shooting for AWS cloud-bursting kinds of opportunities, they've got got flesh out their offering with S3, EBS, SQS, etc. etc. etc.
In the meanwhile, what good is that stuff going to be inside an enterprise? So are they going to work with existing enterprise storage, messaging and visualization? What about the other PaaS folks?
I read some of their documents and inside, in addition to their code, there's a great big seaming pile of software: Virtual Ethernet, DBs, ESBs, Hibernate, Axis, etc. And it all runs in user space, which is a double edge sword, for sure.
There's some competition as well....
Haven't really got an opinion on this yet, but it sure is one of the more interesting developments we've seen in a while and has the potential for high impact.
CM
tluk...@exnihilum.com
Another, maybe simpler way of looking at the situation is that they're just taking advantage of a $5.5 M opportunity and will figure out the answers to all those questions as they go.
TL
-----Original Message-----
From: "Chris Marino" [christophe...@gmail.com]
Date: 05/04/2009 08:06 PM
To: cloud...@googlegroups.com
Subject: Re: Eucalyptus
Considering the interest in EC2 on this forum, I expected a lot more interest in Eucalyptus.....
In the meanwhile, what good is that stuff going to be inside an enterprise? So are they going to work with existing enterprise storage, messaging and visualization? What about the other PaaS folks?
Theres some competition as well....
Havent really got an opinion on this yet, but it sure is one of the more interesting developments weve seen in a while and has the potential for high impact.
CM
On Mon, May 4, 2009 at 5:53 AM, Boris Quiroz <bo...@insert-coin.org> wrote:
2009/5/4 Diego Parrilla Santamaría <diego.parril...@gmail.com>:
> "Eucalyptus Systems promises to sell enterprise-grade products based on
> Eucalyptus..."
>
> So the current version of Eucalyptus is not enterprise-grade???
>
>
Yes, they are.
http://www.eucalyptus.com/enterprise/
> Diego Parrilla Santamaría
> Business Development Manager & Product Technology Strategist at Abiquo.
> +34 620 57 81 46
> mailto:dpar...@abiquo.com
> skype:diegoparrilla
> www.abiquo.com
>
>
>
> On Mon, May 4, 2009 at 4:10 AM, tluk...@exnihilum.com
> <tluk...@exnihilum.com> wrote:
>>
Reuven Cohen
My other issue with basing our API on EC2 without a public roadmap is we're going to be always a few steps behind scrambling everytime there is a new feature released. Working against our own roadmap is hard enough.
r/c
Sam Johnston
I'm impressed a pre-revenue company managed to raise $5.5m basically implementing others software & API's. One of the reasons we haven't implemented the EC2 API for our Enomaly ECP isn't because it's difficult but because we have no assurances from Amazon that they won't sue us for our implementation. Now that Eucalyptus has gone legit, what's stopping Amazon from sending a cease and desist? If amazon publicly said "you are free to implement the EC2 API within your platform" with a clear picture of their related patents, we'd have it ready in a few weeks. Problem is most of my conversations with Amazon have indicated otherwise.
My other issue with basing our API on EC2 without a public roadmap is we're going to be always a few steps behind scrambling everytime there is a new feature released. Working against our own roadmap is hard enough.
Actually the intellectual property issues are potentially worse than that:
- Copyrights (specifically section 3.3 of the Amazon Software License) prevent the use of Amazon's "open source" clients with anything other than Amazon's own services.
- Patents pending like #20070156842 cover the Amazon Web Services APIs and we know that Amazon have been known to use patents offensively against competitors.
- Trademarks like #3346899 prevent us from even referring to the Amazon APIs by name.
Hi Harald,
Your question is a good and very important one. We have spent some time with the UCSB legal department trying to make sure we aren't violating anyone's IP. More importantly, it is definitely not our intention to harm Amazon's interests in any way. In fact, our intention is quite the opposite. We hope that EC2 will become even more popular based on experience with Eucalyptus. With that said, Universities are extremely resource constrained in this regard (and Amazon is not) so we may get squashed in the end.
However, here is our (perhaps imperfect) understanding. There are three areas if IP in play: copyright, trademark, and patent. In terms of copyright, we have not directly incorporated anything from Amazon into Eucalyptus (not even the WSDL). Amazon makes its WSDL publicly available and it does not appear to be copyrighted (at least, we couldn't find anything even hinting that it was copyrighted) but even so, we do not include it -- not even for the purpose of generating the code for the web services front end. However it is absolutely true that the hand-written code for the front-end was written with an understanding of the WSDL. Turns out that the internals of the Eucalyptus front end are set up to support more than just the EC2-generated messages so there is not a completely direct mapping but if it does turn out that the WSDL is copyrighted, there may be an issue here with Eucalyptus as a derivative.
As far as trademark goes, we can't find anything that indicates trademarks associated with the function names or message names. We didn't spend a lot of time trying to obfuscate the internals so there may some overlap. If that is a sticking point, we will certainly rename everything.
Finally -- patents. Again, we did some due diligence and we couldn't find anything to indicate that what EC2 is doing is patented. There are parts of S3 that are patented (notice that we don't have S3 support in Eucalyptus) but it may also be that the patents are pending so our search didn't pick them up. If they are, Eucalyptus (and pretty much every other cloud computing infrastructure, I suspect) will need a license from Amazon.
Cheers,
Rich
Chris Marino
As for the API issues, I think that's FUD. Sure, they could copyright the WSDL, but this is no different than dozens of 'fair use' and reverse engineering efforts that have been successful in mimic observed behavior. Samba, Open Office leap to mind. Many others for sure.
As for this 'patent', not sure I'd run scared of a application that's likely to get rejected, or at least narrowed in scope before anything is granted. [If anyone wants to buy me a beer some time, I can tell them about the millions I spent on patent litigation. The system is totally F'd']
They've got to have more than EC2 compatibility since, as Ruv says, thats not rocket science.
Regardless, I think EC2 compatability is simply a tactic (or it ought to be). Their sights are proabably someplace else, like VMware. And that, I'm afraid, is a lot more like rocket science and $5.5M is only going to get them part of the way there.
CM
Sam Johnston
@TL Agreed. $5.5M can solve a lot of probs, for sure....but as Ruv says, they're dancing with the elephant and they could easily get squished....
As for the API issues, I think that's FUD. Sure, they could copyright the WSDL, but this is no different than dozens of 'fair use' and reverse engineering efforts that have been successful in mimic observed behavior. Samba, Open Office leap to mind. Many others for sure.
FUD or not it's just not worth the effort - the innovation is in the stuff behind the API, not the API itself. Writing some press releases about supporting one API or another in the name of appearing "interoperable" is one thing - actually doing it strategically is another altogether.
As for this 'patent', not sure I'd run scared of a application that's likely to get rejected, or at least narrowed in scope before anything is granted. [If anyone wants to buy me a beer some time, I can tell them about the millions I spent on patent litigation. The system is totally F'd']
Surely that's all the more reason to steer well clear of a known money sink...
They've got to have more than EC2 compatibility since, as Ruv says, thats not rocket science.
Regardless, I think EC2 compatability is simply a tactic (or it ought to be). Their sights are proabably someplace else, like VMware. And that, I'm afraid, is a lot more like rocket science and $5.5M is only going to get them part of the way there.
Agreed. Good luck to them (seriously) - VMware need all the competition they can get and I reckon it's a lot more likely to come from an upstart startup than any of their other billion dollar "competitors".
Sam
Alex Esterkin
If anyone wants to fork the Eucalyptus source code, the time is now, until it is still BSD. Chances are, future releases of Eucalyptus may have a different license such as GPL3.
Regards,
Alex Esterkin
Eric Windisch
> If anyone wants to fork the Eucalyptus source code, the time is now,
> until it is still BSD. Chances are, future releases of Eucalyptus
> may have a different license such as GPL3.
The Eucalyptus license also makes mention of patents in a relatively
non-standard way (I.E. it is yet another BSD variant of its own). I
wouldn't immediately jump to believing it compatible with other
licenses so easily.
As far as the GPLv3 is concerned, I know that not everyone likes the
GPL, but there are many that would see this as a plus. Personally,
I'd prefer the AGPL.
Regards,
Eric Windisch
Diego Parrilla Santamaría
I am not surprised with the $5.5m. They have an incredible traction in the community and the Cloud hype is helping a lot. I have some experience looking for funds from VCs in the past, and I can tell you that even with the really bad economic times the label 'Cloud' helps to gain attention. Obviously, 99% of the companies doing 'Cloud Computing' today are really not Cloud Computing, so most of them are dropped after the first screening process... Eucalyptus has a product, a vision (AWS compatible) and cash. They lack of a Business Model...yet. So, as a competitor, we are taking them very seriously.
I agree with @Reuven that implementing the Amazon APIs is a dangerous game. Today Eucalyptus is a nice company, but if they grow they won't be so nice. If Amazon feels that they can be a threat, then Eucalyptus could have not only legal problems, but product roadmap problems. So sooner or later Eucalyptus will not use the AWS compatibility as a key feature, to avoid 'AWS API lock-in'.
In Abiquo, we did consider following the Eucalyptus approach and implement a EC2 compatible API. But we changed our mind because:
1) You cannot define your own product roadmap. Can sound it's not important, but it really is.
2) The AWS API semantics constrains our own Cloud computing model. AbiCloud model is more complete than the EC2 model: Virtual Datacenters, Virtual Aplications, Enterprises...
3) Because we are an opensource project, somebody else could develop a AWS API for Abicloud as a subset of our API
4) Believe it or not, enterprises don't consider AWS API as something relevant. They do consider relevant an API, but even for them, there are a few key features at the top of the list, more important than an API.
Diego Parrilla Santamaría
Business Development Manager & Product Technology Strategist at Abiquo.
+34 620 57 81 46
mailto:dpar...@abiquo.com
skype:diegoparrilla
www.abiquo.com
Sam Johnston
I agree with @Reuven that implementing the Amazon APIs is a dangerous game. Today Eucalyptus is a nice company, but if they grow they won't be so nice. If Amazon feels that they can be a threat, then Eucalyptus could have not only legal problems, but product roadmap problems. So sooner or later Eucalyptus will not use the AWS compatibility as a key feature, to avoid 'AWS API lock-in'.
It's worth noting that a good deal of the publicity Eucalyptus received in the lead up to the funding was due to their support of the EC2 APIs so it may well be that this was nothing more than a (clever) marketing ploy...In our view, Eucalyptus respects Amazon's IP in two important ways. First, it is not a "reverse engineered" version of AWS as it is not designed to operate on the same scale that AWS is. Put another way, we designed Eucalyptus to run in a typical academic cluster environment and not across several massively provisioned, geographically distributed data centers (as is AWS). If that scale were a feature of the target setting for Eucalyptus, we would have architected it very differently. Because it is not, we did not consider or try to deduce how AWS might be engineered as it must certainly take into account contingencies at frequencies that simply do not occur at the cluster scale.
Secondly, it has always been the intention of the project to provide a vehicle for stimulating cloud usage and experimentation in general, and AWS usage and experimentation in particular.
For example, we have encountered scientists and academics who would like to use AWS, but who must justify the expense (however paltry) to their funding agencies using local resources. These research groups have application code bases in which hundreds of person-years have been invested (read: several generations of graduate students and postdocs have authored the code). Eucalyptus can be used to demonstrate that these codes will work "well" (or least, will work at all) once transitioned to AWS.
Thus we have proceeded under the assumption that we have not infringed on Amazon's IP with respect to AWS internal functionality and that we have designed a "tool" that facilitates greater AWS usage. It has never been our intention to harm Amazon's interests in doing so.
Sam
Diego Parrilla Santamaría
2009/5/5 Diego Parrilla Santamaría <diego.parril...@gmail.com>I would not consider this a reason to avoid Eucalyptus - they have been well aware of the risk since the outset and claim to have designed their system to cater for multiple APIs... I'd obviously love to see them implement OCCI (which could well become the HTTP of Cloud Computing) when it's available later this month but whatever happens I'm expecting to see one or more new APIs on their roadmap before long if they're not already. This more recent response is insightful too:I agree with @Reuven that implementing the Amazon APIs is a dangerous game. Today Eucalyptus is a nice company, but if they grow they won't be so nice. If Amazon feels that they can be a threat, then Eucalyptus could have not only legal problems, but product roadmap problems. So sooner or later Eucalyptus will not use the AWS compatibility as a key feature, to avoid 'AWS API lock-in'.
The change to OCCI is exactly the scenario that I envision for Eucalyptus. They got the attention implementing the AWS API, now they can drop it.