I think question is pretty descriptive.
I have read following phrase in app engine documentation as well as books "You can have up to 10 active applications created by a given developer account. You can disable an application to reclaim a slot", RETAIL, 2012, Programming Google App Engine, 2nd Edition, OReilly.
However, they didn't said why or what's the reason(s)?
Does Google cannot count more than 10? :)
If you want more, simply enable billing. You can then have as many as you like.
I believe the reason is to avoid spam or abuse of service. If you can create unlimited number of apps you can basically create a farm of servers that can do unlimited things that can attack other websites or spam emails.
Enabling billing will verify your identity and can easily get caught once you violate their terms of service.
Related
I am starting out with Google Apps Script, but as learning graph is growing exponentially few terms are getting hard to grasp.
Can anyone simply explain me about relationship between GAS and Googles Cloud Platform. How they are related? When there is a need of GCP when working with GAS?
Whats difference between creating project on Developer Console and creating on Cloud console?
Please add comment if need any rectification in question, i'll be happy to do that.
Thank you.
Google Apps Script is part of the G-Suite products, generally not related to the Google Cloud Platform products in ways other than being both Google products.
From the developer/customer prospectve occasionally there may be some marginal interactions between the products, but in a very limited manner - special situations. There might be more interactions on Google's infra side, but they're transparent for developers/customers.
So normally there is no need for GCP when working with GAS (or viceversa) unless it's for one of those very particular interaction situations, specifically documented.
For example
the Cloud Resource Manager is aware of and can deal differently with G-Suite customers. From Acquiring an Organization resource:
G Suite:
The first time a user in your domain creates a project, the Organization resource is automatically created and linked to your
company’s G Suite account. The current project and all future
projects will automatically belong to the organization.
a while ago mapping a Google App Engine application to a custom domain was only possible through G-Suite (known as Google Apps at the time).
It's not uncommon for various documentation/guides, including those G-Suite related (either Google's or from third parties) to reference GCP products, but usually that's because of the convenience of using them, not because they are actually needed.
So you really need to be aware of which family the product/documentation you're using is part of. The GCP products and documentation are a lot better of consistently identifying themselves a being part of GCP.
Finally the Developer Console is just the older, but still widely used name of the Cloud Console, they're the same thing - used for GCP. Unless you're referring to the Admin Console which is used for G-Suite.
I would need to automate the creation of new App Engine projects. Is this possible? I see there is a Google Cloud SQL Admin API which can create new Cloud SQL instances, but what about App Engine? Is there anything similar?
Update:
We have developed an application that runs on GAE and uses Cloud SQL and plenty of API integration with most of Google Apps. We foresee dozens, if not hundreds, of customers in a near future. All of them will be using their own Google domain and Google Apps.
While we could actually just deploy the application in our App Engine and modify the Cloud SQL tables to include the id of the customer who owns the record, we thought it would be better if we deploy an app instance and Cloud SQL for every one of them (on our own account). The main reasons coming to mind are that we can track how much every customer spends in terms of billing, and speed up the database since Cloud SQL is just a MySQL instance.
Steps for the creation would require editing a properties file in the packaged .war file, adding the certificate used to log in as a service account, and probably something that I am missing at this moment :-P
This question is somehow related Create an App Engine Project ID command line
As far as I know this is not possible (and is unlikely to be possible anytime soon).
Update:
I can see why splitting into separate projects for billing purposes would be really nice (multi-tenancy is great, but getting one bill per customer from Google sounds easier), but unfortunately I don't think that it's going to be your best option.
For AppEngine, you may want to look into the multi-tenancy features (or in Python) and how to get stats for billing.
Keep in mind however, CloudSQL is not simply a MySQL instance. It happens to speak MySQL but is not the same as running MySQL on Compute Engine for example. I would recommend that you run some benchmarks to be sure that the "adding the customer ID to the table" idea you had won't work.
Lastly, a possibly relevant read: http://signalvnoise.com/posts/1509-mr-moore-gets-to-punt-on-sharding
I guess the conclusion is that there’s no use in preempting the technological progress of tomorrow. Machines will get faster and cheaper all the time, but you’ll still only have the same limited programming resources that you had yesterday.
If you can spend them on adding stuff that users care about instead of prematurely optimizing for the future, you stand a better chance of being in business when that tomorrow finally rolls around.
I know this has been asked one way or another before, but most of the main issues to do with GAE stability seem to have been asked around the end of 2008, early 2009, or aren't directly related to games at scale (which I'm interested in).
Basically, I have been arguing back and forth with my business partner about whether to use GAE or AWS for the back-end of our social game engine, and now it's crunch time. I love GAE (Java) for so many reasons, and although it used to be unstable, it's pretty good now. The main argument in favour of AWS is the fact that AWS has proven itself with multiple games running tens of millions of active users per day. The obvious pin-up child for AWS is Zynga, with its Farmville peaking at 80+million DAU. And that's just one of the hugely successful games running on the AWS infrastructure. Remarkable achievement.
So, one way or another it's KNOWN to work. GAE on the other hand doesn't have any examples that I could find doing these sorts of numbers. Not even close. So can I trust it? Is there a single example of a large social game with 2 million+ Daily Active Users, using GAE?
The main considerations for our social game back-end are:
Reliable CDN (Amazon CloudFront/S3 is excellent for this, as is Google's obviously excellent DataStore).
Ability to scale without falling over (AWS-EC2 is proven here, GAE doesn't seem to have examples of large game apps which can run into the 1000s of requests per second. GAE used to be quite unstable in this regard and so is my main concern).
Reliable no-SQL database. (AWS-SimpleDB and Google's DataStore are both excellent for this. We really don't need SQL).
Support/someone to call/contact if there is a problem. (This is one of the biggest worries with GAE. I have no idea who I can call, or if it's even possible. AWS has an SLA and support.)
I look forward to your thoughts, but please also note, this is not intended to start any sort of flame war. I love both systems, but both have their positives and negatives, but I'm about to make an architectural decision that likely won't be undone moving forward.
Regards,
Shane
I've never worked with AWS-EC2 so I'm going to share my knowledge just on the Google App Engine side.
Google App Engine is not meant to be a CDN; though it can serve static content through its powerful infrastructure providing caching close to the users, it does not guarantee the same kind of high quality and high availability service of a real CDN because it's not part of its duties.
Further data:
Maximum size of a file using the BlobStore service: 2 Gigabytes
Maximum size of a static file: 10 Megabytes
Currently App Engine always returns 200 status for static files even on Conditional gets (you have to rely on third party caching library like cirruxcache for example).
Recently Google App Engine team has shut down the App Gallery for one simple reason: too many Toy Apps!
Google wants to counteract this tendency showing successful businesses case studies; here are some of them:
BuddyPoke (viral Facebook app with 65 million installs)
WalkScore (serves 3 million request a day to thousands of real estate partner sites)
Webfillings
Snapabug
Optimizely
Ubisoft Facebook TikTok game
Other interesting case studies here
"We are well aware of downtimes and reliability issues, and are working hard to solve them: Improving App Engine reliability is our number one priority" was recently said by a Google Developer Relations Manager here.
App Engine is still in beta and is an evolving platform so you have to be prepared to deal with downtimes and issues.
Google App Engine team has just launched a preview of App Engine for Business providing 99.9% uptime service level agreement and premium developer support available.
Here is my opinion for what it's worth:
I'm aware that it's a tough call; having read a lot of articles about GAE I have mixed feelings about it because you can go from the recent catastrophic Carlos Ble report to the happy experience of Flower Garden or Gri.pe.
App Engine for Business looks promising and I would consider it in the case of a serious business project plan.
The fresh SDK 1.4.0 is huge and it clearly shows that the Team is really pushing hard to fix some annoying issues (Warmup requests) and relaxing some limitations (10 minutes process on TaskQueue).
Last thing to consider: if you are going to have big numbers, the Google App Engine Team will probably take your app as a successfull case study to follow with a boost of free and powerful Hype.
BuddyPoke is one example of a large-scale social app running on GAE. How large I'm not sure. This article says 30m daily page views (not users):
http://googleappengine.blogspot.com/2008/10/app-engine-case-studies.html
Their facebook page says 2.7 million monthly (not daily) users:
http://www.facebook.com/buddypoke
Although, they are also on a heap of other social networks:
http://www.buddypoke.com/
Personally I decided to go with GAE, for a couple of main reasons:
The unit of scalability is a single request, not a whole instance like it is with AWS.
I can work at a higher level, without having to worry about configuring instances.
If your point 4 is a big one for you, then you may be better off with AWS. With GAE there appears to be nothing you can do, and no-one you can contact.
About a week ago I had an issue with my app - it had suddenly started failing in Google's code, in a location which had been working fine for the last 5 days, ie since I had last uploaded my app. The only way to report issues to Google seems to be via their production issue template, here:
http://code.google.com/p/googleappengine/issues/entry?template=Production%20issue
I reported the issue, and didn't hear anything. Since it's running on Google's servers I was unable to resort to any 'usual' emergency tactics like restarting a server. An hour later and the problem resolved itself - I'm not sure if someone at Google saw my message and fixed something, or if it just went away. I updated my bug report to say the problem was fixed, but even now a week later the issue hasn't been closed or even acknowledged. Also since the issue has to be posted publicly, my app is now getting random hits from bots.
Admittedly my app is currently only in beta and so only has a hundred or so users, and so it wasn't a major incident for me. If I was getting thousands / millions of hits, maybe either Google would have noticed the problem themselves earlier, or they would have paid more attention to my bug report.
On your point 3, even my small app with a small amount of traffic throws occasional data store errors (even during times which aren't reported on the availability charts as outages).
Having said this, I still like GAE (I am using the Python version), and plan to stick with it. The promise of GAE is its scalability - although it falls over occasionally now for my small traffic, it shouldn't fall over any more when it scales to much more traffic (ie your point 2), provided I've coded it correctly to avoid contention. I'll see how it goes.
Finally regarding your point 1, the blobstore and/or static files are more like a CDN on GAE, than the datastore. However for very large amounts of traffic, a real CDN may be cheaper. It's also not necessarily a CDN, see Google app engine & CDN.
Hi I roll out some site on google apps engine but I'm not really happy about it for this reason:
django is not fully supported so no administration etc.
using django patch etc. sometimes give me some problem when new release on gae is out
a registering domain (with go daddy) and add it to google apps engine (no redirection)
seems take too times for display page
waste times to avoid some restrictions eg no sql, query number limited etc.
little scare because I've no great traffic but is rising up so I can predict how much
really cost
so my question is for your experience is better a slicehost style server (some dedicated server cost $50 and give you 1,5TB ) or other or google apps engine is economic and pro.
just for getting idea my site is yappiedo.com and sometimes seems slow
other Idea and suggerstions are welcome
thanks
In grab bag format:
As long as you have a model for making money off your visitors, you do not need to be scared about rising costs. See this blog for what happens when this guy was hit with major traffic. The costs are reasonable (for him at least) and any other non-GAE solution would have died a screaming death, costing him many thousands of dollars in lost revenue.
You are not working on a traditional relational system. You need to design your application to work with GAE's strengths, not to fight GAE's weaknesses. If you spend all your time working around datastore limitations, take your data model back to the drawing board and make one that plays well with GAE. De-normalization is usually the key word.
There are significant slowdowns associated with starting an instance of your application the first time. These go away when your app is hit often enough that it stays in memory
The should be no difference between hitting *.appspot.com and a properly setup google apps domain. Check your DNS configuration.
And the answer is: depends.
It's still unclear to me when I should or should not use Google App Engine to deploy a commercial web application.
It appears Google has "business" level support.
http://code.google.com/appengine/
Can someone bullet list when I should use Google App Engine and when I shouldn't use it for a web application
The question is surprisingly simple to answer after I've had a stab at google engine with my project for a few weeks. You should use it when:
you can't be arsed to set up a server
you want instant for-free nearly infinite scalability
your traffic is spikey and rather unpredictable
you don't feel like taking care of your own server monitoring tools
you need pricing that fits your actual usage and isn't time-slot based
you are able to chunk long tasks into 30 second pieces
you have the skill/will/desire to work with noSQL and deal with the consequences thereof
you are able to work without direct filesystem access
So actually, you can use it pretty much for anything, especially websites. The only thing it very quickly becomes too pricey for is running large background processes. If you're doing some hardcore number crunching 24/7 you're better off using your own server somewhere because no cloud service can really live up to that.
But think of it this way, where else are you going to get an architecture that can swallow 10+ requests per second load for ten dollars a month?
Basically it boils down to this: If you want to focus on developing your code, not your server architecture. GAE is for you. (unlike amazon which behaves more like a fancy VPS)
I can't really tell you whether you should use App Engine without knowing anything about what you need your web app to do, but I will tell you what App Engine can and can't (or won't) do.
App Engine is fantastically good at scaling. It is, in fact, designed to scale web apps to ridiculous lengths first and foremost, with ease of use and number of features being secondary goals.
That's not to say that App Engine doesn't have features, or isn't easy to use, just that if there ever becomes a choice between adding a feature and staying scalable, the App Engine team will choose scalability.
For example, App Engine doesn't have some of the features of a relational database, because those features don't scale to the size of an app that App Engine is designed to support. App Engine doesn't support requests taking more than 30 seconds, because App Engine is designed to serve a web app, not process long-running requests.
In general, when App Engine doesn't support something, it's not because it's impossible -- nothing is impossible -- but rather because it would detract from the scalability of App Engine.
There are workarounds that can be (and have been) implemented to get around this, particularly with things like the task queue, and App Engine is constantly getting new features and new frameworks built on top of it.
App Engine for Business adds SLAs and different pricing, but is otherwise pretty much the same App Engine.