jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tako Schotanus <quinte...@gmail.com>
Subject Re: Jackrabbit & google AppEngine
Date Mon, 13 Apr 2009 20:33:28 GMT
I understand, thanks for the clear explanation!

On Mon, Apr 13, 2009 at 20:00, Korbinian Bachl - privat <
korbinian.bachl@whiskyworld.de> wrote:

> Hi,
>
> 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).
>
>
> Best,
>
> Korbinian
>
>
>
> 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
works
>>>>>>>>
>>>>>>> with
>>>>>>> JDO
>>>>>>> and a JDO filesystem. Not too hard I think. The challenge probably
>>>>>>> lies
>>>>>>> in
>>>>>>> implementing an index storage implementation for lucene that
works
>>>>>>> with
>>>>>>> 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
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>
>>
>>


-- 

-Tako

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message