Although the provided runtimes more tightly and seamlessly integrate with Cloud Datastore, Google's NoSQL database, it is also possible from App Engine to use Cloud SQL, Cloud Spanner, or some other database as a backend.
App Engine supports custom runtimes that allow you to run arbitrary Docker containers and any sort of web framework that you need. This does, however, come with the trade-off of additional cost and less high touch integration.
Google App Engine is very easy to use. All you need to do is install the SDK (which in itself is easy as well, and the documentation is very heplful) and run the command needed depending on the type of project to deploy it.
For example, to deploy a golang application, you run golang deploy inside the project folder and it will be automatically deployed.
App Engine brings with it a number of APIs that can lead to confusing choices; for example, outside of App Engine, there is pretty much one clear choice in terms of how to use the Cloud Datastore API: one uses the proper client library (e.g. in Python, this would be the google-cloud-datastore library in PyPi). On App Engine, however, there are often multiple APIs; for example, in Python, there is both the "db" and "ndb" libraries provided by App Engine (easier to use), as well as the "google-cloud-datastore" library (harder to get working in App Engine).
Some of the App Engine environments have compatibility issues using certain APIs. For example, in App Engine Python Standard, it can be challenging to use many of the Google Cloud Python client libraries due to the 'google.cloud' namespace being used incompatibly between the Google Cloud Python client library code and between the APIs that are provided by the App Engine environment. Likewise, code making socket connections or other HTTP requests without going through the proper App Engine APIs can run into issues.
App Engine is vendor-specific to Google. Some code that works with App Engine may need to be modified or re-written to bring to other providers. Not only that, but even among Google's various App Engine environments, some modification may be necessary to port code between "standard" and "flexible" environments. For maximum portability, you may want to consider using "Cloud Run", instead, which brings many of the benefits of App Engine while, at the same time, providing a much more portable approach to running code.
There is an inline editor in Google Cloud for writing and submitting/deploying cloud functions, so while it is possible to store a Cloud function as code in a repository you can try and experiment without getting to that point.
Only the set of languages explicitly supported by Cloud Functions can be used; for more flexibility, I would highly recommend Google's other serverless environment, namely Cloud Run.
While setup is easy assuming you already have a Kubernetes deployment and are familiar with Kubernetes, for beginning users who don't have a Kubernetes cluster, starting with Knative is likely to be a more complex undertaking than other solutions.
Sigma needs just an AWS account (for deploying your serverless app) and GitHub account (for saving your code and generated configurations). But even if you don't have either or both of them, you can still get started with a free demo account or one of the ready-made samples.
Serverless apps in Sigma are currently confined to NodeJS as the programming language (both v6.10 and v8.10), although more languages like Go and Python may be supported in the future.
Even if you don't have a GitHub account, or are still too skeptical to authorize Sigma to access your account, you can still deploy one from the range of ready-made samples right away without having to log in with GitHub.
Sigma already fully supports NodeJS 8.10, introduced for Lambda functions by AWS very recently (https://aws.amazon.com/blogs/compute/node-js-8-10-runtime-now-available-in-aws-lambda/), in addition to the earlier 6.10.
Sigma fully automates the definition of entities, their associations (such as function triggers) and the related permissions (e.g. AWS IAM), so all you need to do is to drag them in and write your code.
With Sigma, you can define your entities - buckets, databases, queues, APIs, etc. - as and when you encounter them in your code (reusing the previously defined ones when necessary). This ensures a seamless development experience, without any jump-arounds among multiple dashboards, documentation pages and configuration files.
Sigma itself is based on serverless principles; everything runs in your web browser, and all services and application logic are deployed into your own serverless provider account (say AWS). There is no backend, and hence no outages.
Sigma seamlessly integrates with your GitHub account, so you can save and reload your projects from GitHub at any time. Sigma can also load public projects from any GitHub URL or profile, so sharing your latest adventure with your colleagues is just a matter of sharing your GitHub URL.
With Sigma, you can stick to your familiar dev cycle (develop one feature, deploy it, streamline it, redeploy, move on to the next, and so on). Sigma will keep track of all changes and ensure that nothing gets left out, right up to the final deployment.
Sigma already supports a wide range of serverless-friendly AWS services - including S3, DynamoDB, API Gateway, SNS, SQS, and so on - with much more coming up in the near future.
Since Sigma internally handles resource configurations and permissions, it is currently difficult to integrate with services that are not yet listed in the Supported Resources section of the IDE.
Since Sigma handles all resource creation, build and deployment configurations internally, it does not offer much customizability for power users - although this may change in the future.
The system supports arbitrary code and dependencies, since it is based in containers rather than a particular programming language. This makes it far more flexible than most of the other options which require a specific language.
Cloud Run includes Identity & Access Management (IAM) integration, so that it is possible to limit access to specific microservices rather than granting wide access.
Google's pricing for Cloud Run involves only charging when the service is in use, with the ability for the service to scale-down-to-zero, making it economical to use Cloud Run with microservices and websites that receive relatively low or spiky traffic.