I had performance issues with flexible app engine service that I wrote in Python. So I decided to conduct load tests on different languages and environments and this is what I found.
Somehow autoscaler on flexible app engine won't work on Python! We are considering rewriting our service in another language! Can somebody explain how the performance can be so bad on a guestbook application in Python? I was expecting horizontal autoscaler to just WORK every time!
Related
Sorry, if this is a naive question, but i've watched bunch of talks from google's staff and still don't understand why on earth i would use AE instead of CF?
If i understood it correctly, the whole concept of both of these services is to build "microservice architecture".
both CF and AE are stateless
both suppose to execute during limited period of time
both can interact with dbs and other gcp apis.
Though, AE must be wrapped into own server. Basically it utilizes a lot of complexities on top of the same capabilities as CF. So, when should i use it instead of CF?
Cloud Functions (CFs) and Google App Engine (GAE) are different tools for different jobs. Using the right tool for the job is usually a good idea.
Driving a nail using pliers might be possible, but it won't be as convenient as using a hammer. Similarly building a complex app using CFs might be possible, but building it using GAE would definitely be more convenient.
CFs have several disadvantages compared to GAE (in the context of building more complex applications, of course):
they're limited to Node.js, Python, Go, Java, .NET Core, and Ruby. GAE supports several other popular programming languages
they're really designed for lightweight, standalone pieces of functionality, attempting to build complex applications using such components quickly becomes "awkward". Yes, the inter-relationship context for every individual request must be restored on GAE just as well, only GAE benefits from more convenient means of doing that which aren't available on CFs. For example user session management, as discussed in other comments
GAE apps have an app context that survives across individual requests, CFs don't have that. Such context makes access to certain Google services more efficient/performant (or even plain possible) for GAE apps, but not for CFs. For example memcached.
the availability of the app context for GAE apps can support more efficient/performant client libraries for other services which can't operate on CFs. For example accessing the datastore using the ndb client library (only available for standard env GAE python apps) can be more efficient/performant than using the generic datastore client library.
GAE can be more cost effective as it's "wholesale" priced (based on instance-hours, regardless of how many requests a particular instance serves) compared to "retail" pricing of CFs (where each invocation is charged separately)
response times might be typically shorter for GAE apps than CFs since typically the app instance handling the request is already running, thus:
the GAE app context doesn't need to be loaded/restored, it's already available, CFs need to load/restore it
(most of the time) the handling code is already loaded; CFs' code still needs to be loaded. Not too sure about this one; I guess it depends on the underlying implementation.
App Engine is better suited to applications, which have numerous pieces of functionality behaving in various inter-related (or even unrelated) ways, while cloud functions are more specifically single-purpose functions that respond to some event and perform some specific action.
App Engine offers numerous choices of language, and more management options, while cloud functions are limited in those areas.
You could easily replicate Cloud Functions on App Engine, but replicating a large scale App Engine application using a bunch of discrete Could Functions would be complicated. For example, the backend of Spotify is App Engine based.
Another way to put this is that for a significantly large application, starting with a more complex system like App Engine can lead to a codebase which is less complex, or at least, easier to manage or understand.
Ultimately these both run on similar underlying infrastructure at Google, and it's up to you to decide which one works for the task at hand. Furthermore, There is nothing stopping you from mixing elements of both in a single project.
Google Cloud Functions are simple , single purpose functions which are fired while watching event(s).
These function will remove need to build your own application servers to handle light weight APIs.
Main use cases :
Data processing / ETL : Listen and respond to Cloud Storage events, e.g. File created , changed or removed )
Webhooks : Via a simple HTTP trigger, respond to events originating from 3rd party systems like GitHub)
Lightweight APIs : Compose applications from lightweight, loosely coupled bits of logic
Mobile backend: Listen and respond to events from Firebase Analytics, Realtime Database, Authentication, and Storage
IoT: Thousands of devices streaming events and which in-turn calls google cloud functions to transform and store data
App Engine is meant for building highly scalable applications on a fully managed serverless platform. It will help you to focus more on code. Infrastructure and security will be provided by AE
It will support many popular programming languages. You can bring any framework to app engine by supplying docker container.
Use cases:
Modern web application to quickly reach customers with zero config deployment and zero server management.
Scalable mobile backends : Seamless integration with Firebase provides an easy-to-use frontend mobile platform along with the scalable and reliable back end.
Refer to official documentation pages of Cloud functions and App Engine
As both Cloud Functions and App Engine are serverless services, this is what I feel.
For Microservices - We can go either with CF's or App Engine. I prefer CF's though.
For Monolithic Apps - App engine suits well.
Main differentiator as #Cameron points out, is that cloud functions reliably respond to events. E.g. if you want to execute a script on a change in a cloud storage bucket, there is a dedicated trigger for cloud functions. Replicating this logic would be much more cumbersome in GAE. Same for Firestore collection changes.
Additionally, GAE’s B-machines (backend machines for basic or manual scaling) have conveniently longer run times of up to 24 hours. Cloud functions currently only run for 9 minutes top. Further, GAE allows you to encapsulate cron jobs as yamls next to your application code. This makes developing a server less event driven service much more clean.
Of course, the other answers covered these aspects better than mine. But I wanted to point out the main advantages of Cloud Functions being the trigger options. If you want functions or services to communicate with each other, GAE is probably the better choice.
Google Cloud Functions seems very interesting as it is serverless and zero maintenance solution. But, when is it appropriate to use Google Cloud Functions over Google App Engine?
Update:
As of June 12, 2018, Node.js 8.x is supported in Google App
Engine Standard environment along with the Flexible Environment.
Short answer: It depends upon your need.
Long answer: Here's the checklist
Runtime
Cloud Functions supports only Node.js at the moment and there aren't any plans, as far as I know, to introduce new runtimes there. If you're good with that, you can put Cloud Functions in your options.
App Engine does support Node.js, although it's only available in the Flexible environment. App Engine Standard Environment supports Python 2.7, Java 8, Java 7, PHP 5.5, Go 1.8 and 1.6, while App Engine Flexible Environment supports Python, Java, Node.js, Go, Ruby, PHP, or .NET. You can also provide your own runtime using a dockerfile in Flexible environment. So if you want to develop your application in anything other than Node.js, App Engine is the better option there.
Serverless Architecture
Are you looking for a serverless architecture? Are you frustrated with managing instances and having them scale up or down? Do you want to spend no time to manage your server? Go for Cloud functions if you answer yes to all of these questions.
Are you looking for fine grain control on no. of instances and billing of those. Do you want to have separate versions and want better control of those. Look for App Engine in this case.
Microservice
Can you break your code into smaller independant functions? Go for Cloud Functions.
App Engine do support Microservice architecture using same code base, but different yaml files to split the services, but it's upto you if you want to break them into services or not. We are running all our code into one monolithic application for last few years and it's still working good on App Engine.
Database
Is your app data stored in Firebase? Then Cloud functions can be used easily there. If not, App Engine is the better alternative. App Engine can connect to Firebase too, in case you're wondering.
There're other things to consider too, such as pricing and if you're looking to migrate existing application or if you're writing things from scratch. You can in fact, use both of the options. We are using App Engine (Python) Standard Environment for our application, but we have recently migrated few of our long running tasks on Cloud functions and they are working amazingly.
In my opinion App Engine is the answer to most of the things, where as Cloud Functions are made for specific requirements.
When what you desire is to execute a function (some logic of some sort) in response to an event originated in the cloud and you don't want to build (and be billed for) a full web application for just that.
From Product Overview:
Cloud computing has made possible fully serverless models of computing
where logic can be spun up on-demand in response to events originating
from anywhere. Construct applications from bite-sized business logic
billed to the nearest 100 milliseconds, only while your code is
running. Serve users from zero to planet-scale, all without managing
any infrastructure.
From What are Google Cloud Functions?
Google Cloud Functions is a serverless execution environment for
building and connecting cloud services. With Cloud Functions you write
simple, single-purpose functions that are attached to events emitted
from your cloud infrastructure and services. Your Cloud Function is
triggered when an event being watched is fired. Your code executes in
a fully managed environment. There is no need to provision any
infrastructure or worry about managing any servers.
If you already have a GAE app related to the piece of logic you want to implement it's probably simpler to just do it inside the app :)
We are starting a new project that requires two main components:
Backend for task management, e.g retrieve a task from a queue and according to some specific logic validate it.
Run a real compiler on that specific task and create an executable that an end user should receive.
We love app engine, however the second part will require a concrete instance where an actual compiler will have to be installed, app engine is not capable here. We were thinking to mix both app engine and aws instances to accomplish the task (part 1 will be app engine and part 2 will be aws).
All of our senses say it's a bad idea:
unneeded traffic between the two providers, someone needs to pay for that unfortunately.
We'll have to deal with two systems, two deployments process, each system has its own quirks --> double the work.
But we love app engine.
Does anyone has any experience in combining the two systems? any recommendations ?
There's no reason why what you suggest won't work, especially if you separate your concerns well, by exposing a clean 'compiler' interface on AWS or a similar service. Yes, you will have to pay for traffic between the two services, but this is unlikely to be substantial. If you are serving up the end result to the user, you can link them directly to AWS, rather than fetching it with your app first.
AWS's EC2s are literally just vanilla linux boxes in the sky. I would also throw out the suggestion of just moving to it completely. Porting your system over may be easier than it sounds if you're unix savvy.
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).