Key features review before choosing Google App Engine for mission critical application
hugues2
Brandon Wirtz
Likely you will go broke on the unnecessary backups. But nothing in your doc would prevent you from using GAE.
--
You received this message because you are subscribed to the Google Groups "Google App Engine" group.
To view this discussion on the web visit https://groups.google.com/d/msg/google-appengine/-/Qt-X6HGwKHMJ.
To post to this group, send email to google-a...@googlegroups.com.
To unsubscribe from this group, send email to google-appengi...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en.
Greg
> - The application should be able to serve +/- 1,000 companies. Each company
> having +/- 10 registered users. The system should be abe to support +/- 3
> transactions / second.
> - The data from one company should not be visible for the other companies.
admin user and several limited users. We often reach 5 requests a
second, and GAE will handle many times this without any action on your
part.
> - It should be possible to perform restore the data from each company from
> daily backups. That is, the system should be able to restore data for one
> company independently from other companies
also unnecessary (unless you need roll-back to handle situations where
customers do something legal but stupid). GAE data is stored on many
machines in many data centres, where "many" is undefined - I guess
this is commercially sensitive to Google. But I have never heard of
anyone losing data on GAE, unless they deleted it themselves. We
decommissioned our backup procedures last year, after switching to the
high-replication datastore.
> - The size of data to be stored should be +/- 1Gb / company ==> +/- 1 Tb of
> data to be stored. The information to be stored is a mixed of standard data
> and images.
I think your scenario depends almost entirely on whether you have to
rule out the datastore. If you do, GAE probably isn't for you, because
the SQL solution isn't here yet and will be hard to trust for several
months when it does arrive. But if you can make the jump from
relational to non-relational mindsets (that is a function of your
developer's skills, not a technical limitation), and if you don't need
backups for roll-back, GAE is likely to be an excellent platform for
your application. It is extremely robust, scales to enormous levels
automatically, and is remarkably cheap if you need those attributes.
Any other system will require you to hire at least one good sysadmin
to design, build and manage it, but with GAE you can put those
resources into developers to make your product better instead.
Finally, if Google don't respond to your request for technical review,
there are many competent people on this group (including myself) who
might be happy to do some consulting for you.
Best regards,
Greg.
Ikai Lan (Google)
--
You received this message because you are subscribed to the Google Groups "Google App Engine" group.
Robert Kluin
> Hi,
>
> Before investing financial resources to develop a mission critical
> application on Google App Engine, I would be very interested to have your
> view on the following :
>
> I. Application requirements
>
>
> - The application should be able to serve +/- 1,000 companies. Each company
> having +/- 10 registered users. The system should be abe to support +/- 3
> transactions / second.
I work on apps well over a thousand transactions per second. WIth
proper design, this will not be an issue. The key point is proper
design.
>
> - The data from one company should not be visible for the other companies.
Check out namespaces. Their implementation is very confused within
the taskqueue API, but otherwise it is a very useful feature.
>
> - It should be possible to perform restore the data from each company from
> daily backups. That is, the system should be able to restore data for one
> company independently from other companies
There are many ways to accomplish this. The smart guys at VendAsta
recently wrote a blog post you might find useful:
http://www.vendasta.com/2011/09/02/incremental-data-backups-on-app-engine-using-fantasm/
>
> - The size of data to be stored should be +/- 1Gb / company ==> +/- 1 Tb of
> data to be stored. The information to be stored is a mixed of standard data
> and images.
I deal with applications that have many terabytes of data. Our
performance has been rock solid. I would say this is one spot where
App Engine truly shines. The only spot this will potentially catch
you is on your backups, but if you do incremental backups it probably
wouldn't be so bad.
>
> II. Questions
> ------------------
>
> - Is there any key restriction which would disqualify Google App Engine for
> this model ?
No.
>
> - Based on available documentation and hands-on experience, the Datastore is
> not an option to the lack of relational modelling and due to the lack of
> fast backup / restore solution
I've actually ported several database schemas to App Engine's
datastore that seemed impossible to model in a non-relational context.
Once you let go of the doubt, stop thinking in terms of tables and
columns, and start thinking in terms of objects and attributes you'll
be amazed at the datastore. I've written several backup solutions for
the datastore for clients, robust solutions can be done without a
great deal of work.
>
> - Is there already a view as if a backup / restore solution will be
> available for Cloud SQL
>
> - Is there a support from Google to review the technical design of the
> solution and to provide assistance during the development ?
I also provide App Engine consulting services.
Robert
>
>
> Thanks a lot for your help !
>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Google App Engine" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/google-appengine/-/Qt-X6HGwKHMJ.