jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Korbinian Bachl - privat <korbinian.ba...@whiskyworld.de>
Subject Re: Jackrabbit & google AppEngine
Date Mon, 13 Apr 2009 18:00:59 GMT

in aws you pay only for the usage - and its in use by you when amazon 
"cant have it". So in my example you only pay for the time your instance 
is running (if it is killed, its back to entry state and not really 
existing anymore) and while the space on the platform is occupied by you 
- in case you have given it free afterwards its no more existing (your 
data of course will also be erased in that case) - so you only pay for 
the time. However, aws charges the full hour that has already begun, 
meaning you pay same when you use a instance for 1 minute or 59 minutes. 
However, we are talking about cent to low $ prices here.

Well, GAE is in fact "ready-to-run" but forcing you to design the 
application for it (at least a special xml file needed) while aws gives 
you just the foundation. Your still responsible for the components on it 
and to put them together, even many are predefined or can be rent (there 
is for example jboss-license scheme, red hat enterprise as well as 
oracle DB - depends on your personal licensing with the companies and 
how much you "want" to spend).

I personally see aws more useful for real business on long term while 
GAE is especially interesting for fast start.

Flexibility and long-term favours aws. Ease of setup and nearly 
"no-cost" for a low usage (at least during beta time) favours GAE.

However, also take in mind that aws has at least a year advantage and 
all products there seem very mature, while GAE is tagged beta. Finally, 
only aws lets you choose *where* on the world to setup instances and 
store data while google is just a big space in "unknown" territory. This 
sounds very odd at first, however, in legal terms for example its nearly 
impossible for many european companies to store data outside of european 
territory as there are strong regulations for these things.

So, in my case I'm currently in favour for aws technically and forced to 
it legally (in case I have to choose between the two).



Tako Schotanus schrieb:
> Thanks! That is a lot more detail than I hoped for :)
> Seems very interesting, I definitely need to take a look at this.
> Just one thing: is it possible to keep these tests around without having to
> pay maintenance? Or is it test and trow away?
> After reading about the GAE a bit I understand that one of the differences
> is that Amazon gives you full flexibility (which is made easier with the
> templates) while Google restricts you to their platform. The advantages of
> Amazon's flexibility are obvious ofcourse, but it also means that a lot of
> the scalability of your app is your responsibility. The advantage of "the
> Google Way" seems to be that scalability comes "free" (if you can adjust
> your app to the limits imposed by them).
> Interesting stuff.
> Cheers,
>  -Tako
> On Mon, Apr 13, 2009 at 12:45, Korbinian Bachl - privat <
> korbinian.bachl@whiskyworld.de> wrote:
>> Hi Tako,
>> well its somewhat easy.
>> First, you need to get an account - funnywise, you usually have one as you
>> can just login with your amazon.com account. Then you'd register yourself
>> for the services you want - here: EC2 (aws.amazon.com);
>> After that youre "in". To get started you need to understand how aws works.
>> In EC2 you can have "instances" - a dedicated virtual machine with
>> guaranteed cpu time and ram that is available in 5 flavours (power + ram -
>> differs in pricing, going from 0,10 per hour to over a dollar per hour -
>> pricing is shown on aws).
>> BTW, regarding the pricing: is right that aws doesnt let you try it for
>> free, however, my whole testrun did cost under a dollar, namely 0,57 USD.
>> Thats nearly "free" to me.
>> If a instance is shutdown, you'll loose *all* data in it and its reset to
>> pre-start (!) state. So even you have space in an instance, the data there
>> will be lost. To overcome this, you need space that can be mounted - this is
>> called EBS (Elastic Block Store). You can think of these as a real hard
>> drive that can be attached to 1 (only 1!) AMI instance.
>> BTW: all cations like new instance, storage and so on can be easily set up
>> by using the Amazon Management Cosole (webapp under console.aws.amazon.com
>> ).
>> So the overview for a JR testrun is:
>> 1 AMI Instance (small) <---connected-----> 1 ECB Volume
>> AWS offers much more services, but these are *not* necessary now (later it
>> may be useful to use additonal aws sotrage options for lower price/ sharing
>> between instances/ backup etc...)
>> So, after you get the first grip, you just need to start an instance at
>> first. As AMI image I would go with "ami-45997c2c" as this is a public one
>> that has java and tomcat on it (you also can build your own AMI local and
>> upload, but for testrun its waste of time, as over 1800 preconfigured AMIs
>> are available in US region and over 200 in EU region). Also make sure you
>> get a key-pair generated in first time use and download it - this is needed
>> for SSH root access to it later on.
>> After your instance is up and running you need to attach space. So you go
>> to ECB Volumes and add a new one. Make sure you create both (instance and
>> volume) in same (!) places called "availability zone" in aws (can be looked
>> up for the instance in case not configured explicitely in the console by
>> just klicking on the running instance). In case you create one in zone A and
>> the other in B you can't attach them together.
>> After ECB is setup and attached, you can access the instance using SSH and
>> your private key. Then simply create a directory and mount the volume to it
>> (remember: first time you need to format it). In case your instance is shut
>> off, or the ECB detached (do unmount first!),  your data will be still
>> existing on your ECB volume and can be attached to any future instances (for
>> long term however, you should have a look at aws S3).
>> So after instance is running and storage mount, you then can config your
>> repository.xml to use the mount path for file based JCR repo. Then just
>> deploy your application to the tomcate via SFTP and voila, JCR on AWS
>> running. If you want to kill the instance, you can do so and then create a
>> new instance and repeat the app upload and in case storage path is equal all
>> should be working.
>> You'll notice that the URL changes all time - to overcome this you'll need
>> to grab a "aws elastic IP", a fixed IP that can be attached to instances and
>> wont change as long as you "possess" it (costs money depending if in use or
>> not - prices can be looked up under aws.amazon.com).
>> So, that'll should get you up and running. Further AWS and Java dependend
>> info under:
>> http://developer.amazonwebservices.com/connect/kbcategory.jspa?categoryID=130
>> Best,
>> Korbinian
>> Tako Schotanus schrieb:
>>  "In an short attemp I tried to get from 0-AWS knowledge to a running JR
>>> demo
>>> app"
>>> Hi Korbinian,
>>> would you mind detailing a bit more how and what you did? I don't mean an
>>> exact description but just a rundown of the services you used and such.
>>> Is there a way to try what you did for free? Because I have the feeling
>>> from
>>> what I read that you always have to pay with Amazon?
>>> It's one of the reasons I never tried any of the Amazon services and it
>>> might be an advantage that Google has: in lots of places developers make
>>> the
>>> tech decisions and if Google allows you to try things out for free you're
>>> more likely to take a look at it.
>>> Cheers,
>>>  -Tako
>>> On Mon, Apr 13, 2009 at 11:10, Korbinian Bachl - privat <
>>> korbinian.bachl@whiskyworld.de> wrote:
>>>  well, even if one would be able to deploy JR, it would be a real joke, as
>>>> googles hard limitations (maybe they soften these later on) would make
>>>> files
>>>> over 1MB each impossible - this and the maximum 10MB response limit kills
>>>> nearly all java apps that are somewhat file related... Currently, im
>>>> really
>>>> unsure what market they target with GAE Java as the limitations makes
>>>> nearly
>>>> all java apps that might benefit most of such a cloud infrastructure
>>>> impossible, e.g:
>>>> Time per request        30 sec
>>>> -> and no threads + background = no data crunching...
>>>> Files per app   1,000
>>>> -> this one looks odd... I nowhere could find what a "file" by their
>>>> definition is, but a limit to 1000 real classes sounds a showstopper for
>>>> many apps
>>>> HTTP response size      10 MB
>>>> -> I still don't understand how one then could make backups from one owns
>>>> data...
>>>> Datastore item size     1 MB
>>>> -> that makes either fuzzy workarounds for larger data or it just won't
>>>> store anything bigger as 1 MB each
>>>> Application code size   150 MB
>>>> -> this sounds high enough
>>>> In the meantime I think that GAE Java will mostly help AWS or even Azure.
>>>> In an short attemp I tried to get from 0-AWS knowledge to a running JR
>>>> demo
>>>> app. It took me less than 30 minutes of reading and 5 minutes of setup
>>>> till
>>>> my first instance was up, had attached storage and a fix IP on it (used
>>>> some
>>>> sun AMI, had all on it for JEE5)...
>>>> As google will get similar price range for GAE as AWS is today, I dont
>>>> see
>>>> any use in investing more time on GAE just to avoid some of their
>>>> restrictions while there are other solutions on the market already that
>>>>  nearly have no limits at all. Only hazzle from AWS I found out so far is
>>>> the billing + invoices that are not yet compatible with EU (european)
>>>> fiscal
>>>> needs.
>>>> Best,
>>>> Korbinian
>>>> Stefan Guggisberg schrieb:
>>>>  On Sat, Apr 11, 2009 at 4:36 PM, Torgeir Veimo <torgeir@pobox.com>
>>>> wrote:
>>>>> has anyone been able to deploy a Jackrabbit repo within google AppEngine
>>>>>>> for Java? - if yes, I would be interested in how to overcome
the "no
>>>>>>> file
>>>>>>> messing allowed" limitation.
>>>>>>>  You'd have to implement a bundle persistence mechanism that
>>>>>> with
>>>>>> JDO
>>>>>> and a JDO filesystem. Not too hard I think. The challenge probably
>>>>>> in
>>>>>> implementing an index storage implementation for lucene that works
>>>>>> JDO.
>>>>>>  agreed. i have never used jdo, but i would guess it doesn't support
>>>>> RandomAccessFile-like
>>>>> funtionality (which AFAIK is required by lucene).
>>>>> however, the most 'challenging' restriction of the google appengine
>>>>> sandbox is the lack of
>>>>> thread creation support...  this makes it virtually impossible to
>>>>> deploy infrastructure
>>>>> apps (like e.g. jackrabbit :(
>>>>> cheers
>>>>> stefan
>>>>>  --
>>>>>> Torgeir Veimo
>>>>>> torgeir@pobox.com

View raw message