The end of PaaS ?

[Patrice B]

It seems most of the services that made AppEngine a proper Platorm as a Service are now scheduled to be shut down, and users are advised to migrate.   Migrate search to ElasticSearch, migrate memcache to Redis, and maybe at some point we'll be asked to migrate Ndb to MongoDB and GCS to whatever.   I'm not complaining about the way the process is handled actually, there is enough time to consider the options and work on a migration scenario, there is no imminent deadline, at least for the moment.   But I'm wondering what went wrong with the PaaS approach, and is it officially dead.

Is this the end of GAE as a PaaS ?   I truly believed PaaS was the future of cloud architectures:  stop thinking in terms of servers, start thinking in terms of services.   When I started working with AppEngine, I dreamed of CPU as a service, with no server granularity, and I was disappointed to find I still had to worry about servers, starting up a new server instance, choosing what type of instance would be best, a scaling strategy, etc.   I was expecting servers as a service, i.e. serving my requests without me ever thinking in terms of servers.   But at least there was Ndb, search, memcache, GCS and a few more.

Now it seems all of these are on their way out, which makes me wonder: was there something wrong with the concept of PaaS itself, or is it just that these products didn't gain traction, and are now too costly to maintain with regards to their user base ?   Actually, the one thing that was wrong with Paas from the very beginning was that it would lock a project into a given cloud.   That was a risk to be reckoned for users, but it could have been seen as a feature for the cloud provider.   Now is it for this reason that the mentionned services didn't make it ?  Because users would have been wary of being locked in, and for that reason would prefer to use leading products deployed on leased servers ?    One thing is for sure: once an application has migrated to more standard services, it will not be tied to GCP anymore.

There was a major benefit to the PaaS concept:  it was very cheap for startups.   Deploying ElasticSearch on a the smallest possible cluster will start at around $200 a month, while the search usage of a small application could cost less than $10.   Same for the shared memcache service offered by AppEngine.   Now you are having to pay for running servers all night with very little transactions to handle.

I'd be happy to hear your thoughts on this matter ?

[George (Cloud Platform Support)]

Hello Patrice, 

Your perception about App Engine as PaaS scheduled to be shut down is unjustified: there are no such plans at the moment, nor are there chances the PaaS offer gets abandoned, not for the foreseeable future. 

Products on this list are migrated: Task Queue to Cloud Tasks, Cron to Cloud Scheduler, Memcache to Memorystore, Datastore to Firestore, and Search to ElasticSearch, to make them available and ready to use outside of GAE. In other words, the intention is to not restrict products on this list to the App Engine SDK.

Now with GKE, Cloud Run, and other Cloud provider computing solutions, it only makes sense to allow for these other platforms to take advantage of the products previously only GAE could.

Worthwhile mentioning that, while the Engineering Team migrated these products outside of GAE, they also took it upon themselves to improve them, which is why there may be some difference in the new flavors of these products. 

As a side note, GCS is not tied to App Engine, and therefore does not require any migration. 

There is still a product that qualifies fully as PaaS: Cloud Functions. It is the true PaaS product: Developers do not need to worry about instance configuration at all.

[Patrice B]

Thank you for your update and insight.    Maybe I was seeing a trend where there is none.  

Actually, there are two separate considerations:  (1) some products are replaced by other products, generally for the better, and developpers should plan for migration, this is life I guess, and it's ok as long as there is enough anticipation and not too profound disruption, it's fine.   (2) in at least two cases (search and memcache) the replacement product is not a pure API, not "as a service", it has to be deployed on a number of server instances, whereas the former product was a simple service.  

Maybe it's not a trend, maybe just two isolated cases.   But it does have adverse consequences in terms of increased cost and of increased complexity.

The Datastore to Firestore migration, on the contrary, seems to be in perfect continuity, both in terms of api (when the Python 3 api comes out of beta) and of billing (I have not looked much into that later point actually).

[Kaan Soral]

As a long time App Engine user and still being a believer, I can't help but feel similar to Patrice's original feelings and confusion

One related issue: https://groups.google.com/forum/#!topic/appengine-ndb-discuss/xOuhDFiYKbU - On this migration path, we were being instructed to use a 3rd party Redis service

When mail was deprecated, again we were instructed to use 3rd party mail services

As most App Engine users, I used App Engine as I wanted an all in one service, where I can just "import" whatever I wanted, and use them, without worrying about a "perfect integration" - I wanted most edge case scenarios, retry scenarios etc. to be handled by App Engine

so TL;DR of my points:

[1] (Major) Everything should be in-house, which includes Google Cloud

[2] (Important but Minor I guess) Even if we use other Google Cloud services, their integration should be native or almost native

If I needed to give one example to [2] - I'd say for the storage, the buckets that App Engine references could be auto created, so a new user wouldn't have to deal with all the permissions, setup etc. - that's usually the tricky part of a cloud service, they could just take an example code, run it, and be "Voila!"

As [3] - Another recent gripe I have is the perceived lack of grip over App Engine, If I needed to give one concrete example, I recently discovered that end users could see 500 errors, yet you would never observe these 500 errors in App Engine logs, it took a considerable amount of effort to track these, prove they existed, after back and forth, turned out they were 500 errors from the network layer, and they "just didn't propagate" - so after all that effort, there was no solution, they still don't propagate, I feel like it's a major breach of trust on all fronts, but no one cares ... Back in the day, the engineers cared, we used to have Google Hangout's, they listened, they responded, now I also feel like App Engine is just becoming an old instance scaling service

With all these said, I still love App Engine, and on day to day usage, no issues lately

[George (Cloud Platform Support)]

Hello Kaan, 

The problems you describe here are most suitable for feature requests in Public Issue Tracker. Developers may assess merit in each case, and decide on proper implementation. 

[Kaan Soral]

At this point linking the public issue tracker in discussions like this always adds insult to injury, for me, as they waste time and personally I haven't seen a solution yet

Example: https://issuetracker.google.com/issues/112668010 (I also believe I dug deeper into the issue after reporting it, there was an email exchange, that's when the issue got reopened but never got anywhere) - The first reply was very frank, the error in this case probably came from the load balancer or another network component, he says it won't be propagated - 99% of requests to an app could fail on another layer, we wouldn't suspect a thing - doesn't make much sense to me - this is the disconnect I'm talking about

[Patrice B]

Hello Kaan,

I wished to start a discussion on a more philosophical, or say strategic question: whether there was a real trend towards replacing true services by software products hosted on leased servers.    I did not want to get this mixed up with some specific grievance at all.  

The first consideration of your initial post was in line with that question, and your mention of the email service was quite to the point.   In fact, pushing users from the original email api towards Sendgrid was one of these significant shifts, which I went through, but it was one where a service is replaced by another service, albeit from another provider, and with a significant free quota so that cost is not too much of an issue.

In the two other shifts that I mention, memcache and search, I would have much preferred that sort of migration, from service to other service.   I would not mind using the ElasticSearch API, which is indeed much more powerful than the GCP search api.   What I do mind, is having to lease 2 servers or more, full time, for that.