The Google App Engine Standard Environment and the ecosystem around it has provided a comfortable and solid software stack in the past.
There is a general move towards standalone services, such is the case with Tasks and Scheduler.
- New ones were introduced (Firestore, Memorystore),
- some of them were deprecated (mail, Channel API),
- while the fate of a few are unknown (memcache, search).
There were a mix of changes on the (Standard) platform:
- Version 2 runtimes, auto-scaling containers (gVisor)
- Move to REST API-s, away from the proprietary Google API.
These are generally welcoming changes, and while the platform is in a state of flux currently, some of these changes have removed the comfort and ease of building software for the platform.
The search begins
Writing infrastructure code has eaten into IT projects for a long time. It causes all sorts of project slippages, budget overruns, and enormous technical debt.
Developing your own server – web, messaging, socket, even database – or building a new web application framework, or client library are all “writing infrastructure code”.
Therefore it is imperative that coding focuses on business capabilities and value with the new stack.
It also means we can do away with the server infrastructure – servers, VMs, containers. While we are at it, it should remove the associated scalability and availability concerns too.
Costs should align with business value, and include effective use only, for example: computing time (no idle), messages sent, users registered, data stored, files transferred, jobs scheduled, and so on.
The stack has to sit on a platform with a rich ecosystem – a good range of core services for example:
- database,
- object storage,
- messaging,
- identity management.
Some of the best in class capabilities could live outside of the platform, for example:
- payments,
- bulk and transactional emails.
The stack must have the facilities to gain insight into its inner workings. Support for variable levels of centralised logging from hosted services and from logging API in bespoke code.
Support for monitoring of platform and application services, alerting on specified issues and metrics.
There must adequate tooling support for the entire application lifecycle extended to
- environments, including local development,
- programming languages, including relevant tool-chains.
A worthy candidate
The emerging paradigm, Function as a Service (FaaS) together with Serverless, promises to meet my expectations. It would have to be part of a comprehensive cloud offering that delivers the rest of the stack.
FaaS/Serverless reinforces cloud native concepts, and that leaves a lot of questions open for this new stack.
There is still the Google App Engine Standard 2nd Generation with the rest of the services from the Google Cloud Platform. If it wasn’t for the challenges that prompted the search for a new stack, it would be one of the best options available. Perhaps it will be again some day. In the meantime, is there something better?
Is it going to deliver on the benefits? What are the trade-offs going to be? Let’s see.