| App Engine just isn't intended or designed for that kind of interaction with services. Take memcache as an example. On a VPS, you install an OS package and manage memcached as any daemon. You are editing the configs and compiling your own binaries if you want. Set it up on a separate box if you want. Set up a bunch of memcached boxes if you want. Do the wiring how you want. It's up to you and you handle all the details and you are billed by time. Handle it correctly and it's crazy fast. On Heroku, there is a layer of abstraction which makes this more like 'give me 3 instances of memcached'. You are billed by the service-instance, essentially. You get help making things work well out of the box. But at a lower level it isn't too different from running deploy scripts to set up EC2 boxes. They just provide the scripts and sell you the resources and support at the same time. On App Engine, Google runs a clustered memcache service for you. It is always running and there is no service setup. It is already on a scalable distributed configuration, not necessarily the fastest or cheapest but good; micro-optimizing memcache servers is not even intended as a supported use case. There is a ton of Google secret sauce involved, behind the scenes you are connecting to some cluster with RPC, all you know is the simple API interface they give you. You are billed based on how much you use it. I think I can predict confidently that GAE is never going to expose an interface where you allocate individual memcached instances. That kind of interaction with services just isn't the App Engine way. Google has Compute Engine for the cases where you want EC2 style control of what is going on at the per-service level. If you want to run your own App Engine platform you can try AppScale. (I never met anyone who does.) It is a whole prescribed architecture and it is not likely to be changed to become more like Heroku. |