Use Google App Engine for the deployment of the staging environment

Context

In order to iterative development cycles for acceptance testing and user experience design, it is necessary provide the software in a publicly accessible domain. Since the instance will only be sporadicly used at random times, having an always online instance hosted on a rented virtual machine would be wasteful.

Alternatives

(A) AWS Lambda

Pros

  • AWS offers lots of powerful features to build web applications.
  • The usage based pricing plans lead to fair operational costs.

Cons

  • Requires much learning to get used to the serverless paradigm.
  • Using MySQL from Dart would require a package which is licensed with a copyleft license (GPL).
  • Using AWS' DynamoDB would require much learning to get used to the NoSQL paradigm.
  • Using Spring on AWS is possible to seems like not a good idea because of Java/Spring warm start is required.
  • Using AWS Lambda creates vendor lock-in which makes it difficult to switch to another deployment platform later on.

References

(B) Google Cloud Functions

  • https://github.com/GoogleCloudPlatform/functions-framework-dart

Pros

  • It might be possible to use Dart both in the frontend and backend and thus have a simple system.
  • Serverless computing can provide good performance with little operational effort.

Cons

  • The Dart support is a prototype, at the moment.
  • The maintainers of the project give feedback on pull requests or issues with low priority. E.g. there is no comment on PR#179 after 13 days.

(C) Firebase

Pros

  • Low operational costs.
  • Powerful features, e.g. storage and user authentication.

Cons

  • Vendor lock-in.
  • Business logic in storefront.
  • Since Dart is not supported for Firebase's serverless offerings, it is not possible to create custom APIs without adding a new language in the stack (e.g. Python or JavaScript).
  • Restrictions on the number of projects which can be created.

(D) Heroku

  • Backend can be implemented with Java/Spring.
  • The VM is started when a request is coming in.
  • When there is no request for 30 minutes, the VM goes to sleep.

Pros

  • Simple deployment process.
  • Keeps to door open for an on-premise deployment.
  • No operational cost.

Cons

  • The free plan is limited to 512 MB (this should be sufficient for quite a while, though).
  • Also the next standard plans are limited to 512 MB. And getting more RAM for a production environment would be very expensive.
  • The idea to use Dart for both the backend and the frontend needs to be discarded.
  • Uses Postgres as preferred database while MySQL is already in use in Kirpal Sagar.

(E) Google App Enginge

  • Backend can be implemented with Java/Spring.
  • It is possible to (auto?) scale to the app instances to zero when they are not used.

Pros

  • Simple deployment process.
  • Keeps to door open for an on-premise deployment.
  • Supports MySQL via CloudSQL

Cons

  • The idea to use Dart for both the backend and the frontend needs to be discarded.

References

Decision

  • AWS Lambda requires too much learning and creates too much vendor lock-in.
  • Google Cloud Functions via the Dart functions framework created too much risk because it may never be production ready.
  • Using Firebase creates vendor lock-in and moves all the business logic in the frontend.
  • Heroku is applicable but they don't offer temporary high-performance VMs.
  • Google App Engine offers hosting of Java/Spring applications on high-performance VMs which can scale down to zero instances.

So, it seems like it will be better to use a classic Java/Spring backend instead of a cutting-edge serverless backend. Google App Engine seems like a good fit in terms of features and price.