I am stuck in deciding between choosing Google App Engine Standard Vs. Flexible environment for a real world production. I want to use Java definitely. Need to use Firebase(latest version) for Authentication and Push notification; I'm not sure whether new Firebase is compatible with standard or flexible.
per the caution note in the following link, my impression is that recent Firebase is compatible is with Flexible Environment only.
https://cloud.google.com/solutions/mobile/firebase-app-engine-android-studio
All things being equal any standard environment app can also run in a flexible environment with minimal app changes. The reverse is not true - the standard environment restrictions are stricter than those for the flexible environment (hence the flexible in its name).
UPDATE: the above is not correct, the language specific section of the Migrating an Existing App Engine App guide should be checked for which standard env APIs are explicitly listed as compatible or incompatible. In some cases that could clarify the decision right away.
Assuming for the remaining of the answer that the choice between environments remains open after this check.
So - to get unstuck - I'd initially shoot for the standard environment (simpler to setup/manage and also potentially free, depending on the app's usage) and only decide to switch to flexible-only env if/when I hit an unavoidable issue caused by one of a standard environment restrictions and which is not an issue in the flex environment. If no such issue is hit you practically maintain the option to switch between the 2 deployment options as you desire.
As for your impression from the tutorial doc - I think it's unfounded, based on the Costs section...
Both Firebase and App Engine have free levels of usage. If your usage
of these services is less than the limits specified in the Firebase
free plan and the App Engine free quota, there is no charge for doing
this tutorial.
... in combination with the Pricing row Comparing environments table...
... as the standard env has a free daily Instance hours quota but the Compute Engine Pricing uses the Machine type billing model and doesn't have a free quota except for the initial limited free trial.
Which overall tells me that the standard environment is used in the tutorial :)
Confirmed in the Configuring the App Engine backend to use manual scaling section as the app's config doesn't have the <vm>true</vm> setting used to select the flexible environment.
Your preference should be app engine standard environment for the time being, unless you specifically need a feature only offered in flexible. Currently, there is very little documentation to go with Flexible app engine, and converting nearly any app from one to the other is NOT a simple task.
Anything you read that says "its easy to convert from standard to flexible" or vice versa is from BEFORE december 6'th, when vm:true was deprecated (along with all of the compat runtimes which let you use standard code on flexible app engine). Flexible now has it's own libraries for most things, and it's different enough to require nearly a complete re-write of many of your methods.
For example, when I converted my cloud storage controller to flexible, not a single line of code was useful beyond method names as the new library primarily utilizes Blobs instead of StorageObjects. (java)
If I for some reason wanted to use my own private server to run my GAE app instead of deploying it to Google servers, could I simply use AppEngine SDK to do that? Are there any technical or legal limitations or problems that I should know about? I know that the SDK isn't designed to run heavy pages but for small websites it should work right?
The dev_appserver is not built to serve public-facing traffic. It's single-threaded, not built for performance, the backends are likewise limited, and it exposes administrative endpoints (such as /_ah/admin/) which users should not be able to access.
Alternatives exist for hosting your app yourself, such as TyphoonAE and AppScale.
Well, you could try. I'm not aware of any legal issues (with the caveat that I Am Not A Lawyer, and can't offer to interpret the license agreement for you), but I doubt you'd be happy with performance.
For one, the dev_appserver Datastore emulation (in both the Python and Java SDKs) doesn't scale all that well once you're past small amounts of data. It's not designed for performance; it's designed to accurately mimic the semantics of the real Datastore.
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.
We are using GAE to host our web services, as far as I know GAE only support Java and python at the moment, however most of our engineers here are more comfortable with C/C++, so i was wondering if there is a way to integrate gsoap with GAE at all. Thanks for your help!
Though I am not an expert at Google App Engine, it is unlikely you'd be able to use native C++ code in the app engine. Based on experience with an app engine like Tomcat, the purpose of application engines is to make your application run on a shared service in its own little sandbox so that it can't affect the other shared services. With C++, you can get a pointer to the beginning of the process memory and start writing zeros if you so desired. This doesn't turn out to work too well in a shared computing environment.
The app engine pages indicate Java and Python runtime environments are available. I've been using C++ for many years and am a big fan of gSoap, but I think these are tools best used in limited cases these days. Web services for Java aren't that much different from gSoap in terms of ramp-up time anyway.
I've used Axis2 for Java web services and it isn't that difficult to use. However, I think it suffers from being overly complex and under documented. I have used WSO2 under PHP and was impressed with how easy it was to use. WSO2 is built on top of Axis and has a Java port too (though I have not used it). If your engineers want to dig in, WSO2 is probably going to be the easiest route.
Motivating them might be hard, but my take is that if they are real software engineers then they won't have a problem adapting.
This might be helpful too: http://code.google.com/appengine/docs/java/overview.html
The short answer is No, Google-App engine is very limited with what you can do (you can't even dynamically create new files).
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 6 years ago.
Improve this question
What alternatives are there to GAE, given that I already have a good bit of code working that I would like to keep. In other words, I'm digging python. However, my use case is more of a low number of requests, higher CPU usage type use case, and I'm worried that I may not be able to stay with App Engine forever. I have heard a lot of people talking about Amazon Web Services and other sorts of cloud providers, but I am having a hard time seeing where most of these other offerings provide the range of services (data querying, user authentication, automatic scaling) that App Engine provides. What are my options here?
AppScale
AppScale is a platform that allows users to deploy and host their own Google App Engine applications. It executes automatically over Amazon EC2 and Eucalyptus as well as Xen and KVM. It has been developed and is maintained by AppScale Systems. It supports the Python, Go, PHP, and Java Google App Engine platforms.
http://github.com/AppScale/appscale
In the mean time...
...it is amost 2015 and it seems that containers are the way to go forward. Alternatives to GAE are emerging:
Google has released Kubernetes, container scheduling software developed by them to manage GCE containers, but can be used on other clusters as well.
There are some upcoming PaaS on Docker such as
http://deis.io/
http://www.tsuru.io/
even Appscale themselves are supporting Docker
Interesting stuff to keep an eye on.
I don't think there is another alternative (with regards to code portability) to GAE right now since GAE is in a class of its own. Sure GAE is cloud computing, but I see GAE as a subset of cloud computing. Amazon's EC2 is also cloud computing (as well as Joyent Accelerators, Slicehost Slices), but obviously they are two different beasts as well. So right now you're in a situation that requires rethinking your architecture depending on your needs.
The immediate benefits of GAE is that its essentially maintenance free as it relates to infrastructure (scalable web server and database administration). GAE is more tailored to those developers that only want to focus on their applications and not the underlying system.In a way you can consider that developer friendly. Now it should also be said that these other cloud computing solutions also try to allow you to only worry about your application as much as you like by providing VM images/templates. Ultimately your needs will dictate the approach you should take.
Now with all this in mind we can also construct hybrid solutions and workarounds that might fulfill our needs as well. For example, GAE doesn't seem directly suited to this specific app needs you describe. In other words, GAE offers relatively high number of requests, low number of cpu cycles (not sure if paid version will be any different).
However, one way to tackle this challenge is by building a customized solution involving GAE as the front end and Amazon AWS (EC2, S3, and SQS) as the backend. Some will say you might as well build your entire stack on AWS, but that may involve rewriting lots of existing code as well. Furthermore, as a workaround a previous stackoverflow post describes a method of simulating background tasks in GAE. Furthermore, you can look into HTTP Map/Reduce to distribute workload as well.
As of 2016, if you're willing to lump PaaS (platform as a service) and FaaS (function as a service) in the same serverless computing category, then you have a few FaaS options.
Proprietary
AWS Lambda
AWS Lambda lets you run code without provisioning or managing servers. You pay only for the compute time you consume - there is no charge when your code is not running. With Lambda, you can run code for virtually any type of application or backend service - all with zero administration. Just upload your code and Lambda takes care of everything required to run and scale your code with high availability. You can set up your code to automatically trigger from other AWS services or call it directly from any web or mobile app.
AWS Step Functions complements AWS Lambda.
AWS Step Functions makes it easy to coordinate the components of distributed applications and microservices using visual workflows. Building applications from individual components that each perform a discrete function lets you scale and change applications quickly. Step Functions is a reliable way to coordinate components and step through the functions of your application. Step Functions provides a graphical console to arrange and visualize the components of your application as a series of steps. This makes it simple to build and run multi-step applications. Step Functions automatically triggers and tracks each step, and retries when there are errors, so your application executes in order and as expected. Step Functions logs the state of each step, so when things do go wrong, you can diagnose and debug problems quickly. You can change and add steps without even writing code
Google Cloud Functions
As of 2016 it is in alpha.
Google Cloud Functions is a lightweight, event-based, asynchronous compute solution that allows you to create small, single-purpose functions that respond to cloud events without the need to manage a server or a runtime environment. Events from Google Cloud Storage and Google Cloud Pub/Sub can trigger Cloud Functions asynchronously, or you can use HTTP invocation for synchronous execution.
Azure Functions
An event-based serverless compute experience to accelerate your development. It can scale based on demand and you pay only for the resources you consume.
Open
Serverless
The Serverless Framework allows you to deploy auto-scaling, pay-per-execution, event-driven functions to any cloud. We currently support Amazon Web Service's Lambda, and are expanding to support other cloud providers.
IronFunctions
IronFunctions is an open source serverless computing platform for any cloud - private, public, or hybrid.
It remains to seen how well FaaS competes with CaaS (container as a service). The former seems more lightweight. Both seem suited to microservices architectures.
I anticipate that functions (as in FaaS) are not the end of the line, and that many years forward we'll see further service abstractions, e.g. test-only development, followed by plain-language scenarios.
Alternatives:
1. AppScale
2. Heroku.
Ref: Alternative for Google AppEngine?
Amazon's Elastic Compute Cloud or EC2 is a good option. You basically run Linux VMs on their servers that you can control via a web interface (for powering up and down) and of course access via SSH or whatever you normally set up...
And as it's a linux install that you control, you can of course run python if you wish.
Microsoft Windows Azure might be worth consideration. I'm afraid I haven't used it so can't say if it's any good and you should bear in mind that it's a CTP at the moment.
Check it out here.
A bit late, but I would give Heroku a go:
Heroku is a polyglot cloud application platform. With Heroku, you
don’t need to think about servers at all. You can write apps using
modern development practices in the programming language of your
choice, back it with add-on resources such as SQL and NoSQL databases,
Memcached, and many others. You manage your app using the Heroku
command-line tool and you deploy code using the Git revision control
system, all running on the Heroku infrastructure.
https://www.heroku.com/about
You may also want to take a look at AWS Elastic Beanstalk - it has a closer equivalence to GAE functionality, in that it is designed to be PaaS, rather than an IaaS (i.e. EC2)
If you're interested in the cloud, and maybe want to create your own for production and/or testing you have to look at Eucalyptus. It's allegedly code compatible with EC2 but open source.
I'd be more interested in seeing how App Engine can be easily coupled with another server used for CPU intensive requests.
TyphoonAE is trying to do this. I haven't tested it, but while it is still in beta, it looks like it's atleast in active development.
The shift to cloud computing is happening so rapidly that you have no time to waste for testing different platforms.
I suggest you trying out Jelastic if you are interested in Java as well.
One of the greatest things about Jelastic is that you do not need to make any changes in the code of your application, except the changes for your application functionality, but not for the reason the chosen platform demands this. With reference to this you do not actually waste your time.The deployment process is just flawless, and you can deploy your .war file anywhere further.Using GAE requires you to modify the app around their system needs. In case if you happen to get working with Java and start looking for a more flexible platform, Jelastic is a compatible alternative.
You can also use Red Hat's Cape Dwarf project, to run GAE apps on top of the Wildfly appserver (previously JBoss) without modification.
You can check it out here:
http://capedwarf.org/