I posit that for most of the use cases where backends would apply, they really are like-for-like with IaaS. Both backends and Compute Instances are accessed by URLFetch and neither autoscale. They probably have similar latency numbers. Thanks to the remote api, you can even access services in the same way.
Really, the only difference seems to be that the Compute Instance deploy script is likely to be a little more complicated. Let's look at some example applications: * An in-memory index. The index keeps updated with a mirror of some data stored in the datastore and services queries against the index. Ikai's original description of the value proposal for backends described some sort of free text search engine. Here you want RAM and compute power. Massive win for compute instances. * A cache (aka the Brandon service). Here you want RAM, RAM, RAM. Even more massive win for compute instances. Brandon, do you expect to migrate? Why or why not? * In-memory game state for a realtime online game. Here RAM is probably not as critical ad CPU power, although it's still significant. The biggest thing you need is stability and reliability. Here compute instances are unknown... but backends are not reputed to be that reliable. Anyone have an average uptime statistic? It's never ok for a gameserver to be rebooted arbitrarily. I'm having a very hard time figuring out a use case where backends are cost effective. Is it convenient to push the build out with the same deploy script that I deploy my app with? Sure. Is it worth hundreds or thousands of dollars a month just to use a different script? Hell no. Ok, there's one case: Backends let you run heavy data-churning tasks with unlimited deadlines. The remote api is somewhat slower than local access - although how much slower when running inside google infrastructure is hard to say. However, there's a high likelihood that most applications like this are better off doing map/reduce with task queues. Jeff On Fri, Jun 29, 2012 at 5:52 AM, Barry Hunter <[email protected]> wrote: > You are not comparing like for like. > > An app-engine 'instance' is not just a generic VM instance. > > Its 'managed' for you - you dont need to install a OS, manage patches etc. > Even a backed has an effective load balancer in front of it, a firewall. > Access to other 'free' services, memcache, task queues, etc. > > The classic IaaS vs. PaaS difference. > > > > On Fri, Jun 29, 2012 at 5:18 AM, pdknsk <[email protected]> wrote: >> >> Riddle me this. >> >> B2 256MB RAM $0.16/h >> >> http://developers.google.com/appengine/docs/python/backends/overview/ >> >> n1-standard-1-d 3.75GB RAM $0.145/h >> >> http://cloud.google.com/pricing/compute-engine.html >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Google App Engine" group. >> To post to this group, send email to [email protected]. >> To unsubscribe from this group, send email to >> [email protected]. >> For more options, visit this group at >> http://groups.google.com/group/google-appengine?hl=en. >> > > -- > You received this message because you are subscribed to the Google Groups > "Google App Engine" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/google-appengine?hl=en. -- You received this message because you are subscribed to the Google Groups "Google App Engine" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en.
