I understand, thanks for the clear explanation! On Mon, Apr 13, 2009 at 20:00, Korbinian Bachl - privat < [email protected]> 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 < >> [email protected]> 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 < >>>> [email protected]> 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 <[email protected]> >>>>> 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 >>>>>>> [email protected] >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>> >> >> -- -Tako
