Comment by mmastrac | Hacker News Reader

Comment by mmastrac | Hacker News Reader

My experience with AppEngine over the last couple of years shows that what they are likely doing internally is dealing with years and years of technical debt for things like scaling and deployment. As a reasonably important customers, we had meetings with higher-ups where they'd discuss the work that they had been doing on improving the reliability at both high and low scale which was ignored for years on end.

The past model for AppEngine involved some pretty heavy development work modifying the JVM and Python VM to implement multi-tenant sandboxing. This obviously doesn't scale very well from a development perspective, and shows why new platform versions have always lagged far behind release.

If I were to infer what they are doing internally now, it would be replacing "legacy AppEngine" with "container AppEngine". In a few years you'll see them migrate everyone to containers that will scale in unsurprising ways to users of AppEngine today.

The reason they haven't moved everyone over to containers is that the dev experience for containers on AppEngine sucks horribly right now and they want it to be at least as seamless as it is for Python and Java right now. They also need to migrate 100% of the legacy AppEngine console functionality over to the new cloud dashboard before they could consider this complete.

So my guess is that AppEngine as we know it is "dead", but being replaced by a product that is a pure superset of what we have today.

This seems accurate to me. There are thousands of bugs on the platform that nobody ever fixes. They have yet to add Python 3 support, too. I have been waiting for over two months for a fix to a permissions problem in Cloud Storage that makes it difficult to use (if somebody leaves the org, any files they owned are essentially unusable).

It's deeply frustrating at times. They are often unresponsive on many fronts. I certainly hope they are fixing the platform... or fixing something, at least. That'd be refreshing.

> If I were to infer what they are doing internally now, it would be replacing "legacy AppEngine" with "container AppEngine".

The fact that in addition to support for custom runtimes, App Engine Managed VMs has Google-provided VMs corresponding to all of the existing supported sandboxed runtimes except PHP is, I think, a pretty good indication that Google's plan for official runtimes going forward is to move them to official Managed VMs rather than what you seem to be calling (accurately, I think) "legacy App Engine" -- the sandboxed platforms.

But all the signs are, IMO, there that this, while it may take a while, the same kind of transition that the move off the old legacy datastore was, something that's optional while it the new platform matures, but eventually will be the only way.

It is not a pure superset. With the current app engine, Google takes care of security patches for the language. With container engine, the customer is now responsible for security patches for their language.

IBM has begun working on a multi-tenant JVM back in 2013. Cool stuf.

http://www.ibm.com/developerworks/library/j-multitenant-java...

Cool, but arguably a layering violation. It's the job of the operating system.

Define "operating system"? It's not crazy to think that you might have another layer inside your VM, not unlike how a hypervisor was one layer that didn't exist outside of mainframes until adapted for regular computers.

In a world of unikernels and library OSes, that is the job of the runtime.

Not necessarily. One of the ideas behind unikernels is very fast boot time, so that you can start a new instance for every tenant. Another idea is reduced complexity...

In which the OS and language runtime are the same thing, e.g. Mirage OS.

See also Sun's project barcelona from a decade+ ago: http://www.oracle.com/technetwork/articles/javase/mvm-141094...

Very cool. I was still writing assembly at college at the time.

Reply on news.ycombinator.com