I disagree. I would bet money that Putting a Squid in front of your app would make it faster. Page Level Caching and the ability to put your Image assets in cache are going to make things faster.
Also I didn't say "single" there are plenty of solutions that would do PLC from multiple locations. Your budget constraint is a limitation. Not to sound cold, but you knew going in to GAE that HTTPS wasn't supported, and would have to use an external solution work. As such it is hard for me really feel that your complaint about having to use an external solution is founded. GAE zigzags, I chalk up to Politics like I said. I'm sure all the GAE guys know they want HTTPS to work, and I'm sure that they feel silly that it is a feature that doesn't work. From: [email protected] [mailto:[email protected]] On Behalf Of Amir More Sent: Thursday, September 22, 2011 7:20 PM To: [email protected] Subject: Re: [google-appengine] calling out the app engine team on ssl for custom domains Hi Brandon, Regarding your resolution of setting up a squid/proxy that forwards requests to https://*.appspot.com somewhere: Having all your traffic go through a single server on AWS or other VPS to proxy requests for google app engine is equivalent to buying a top of the line super-car, ripping out it's four-digit horse power engine and strapping it to a moped with the goal of using said turbo-charged moped for a road trip from new york to california, all because the super-car is too wide for some of the roads you might encounter. It might work but you're doing it wrong. Let's try to go with the flow: I'll see your "proxy/squid set up somewhere" and raise you a multinational dns provider with name servers on most continents with geolocation rules to forward dns requests to the CNAME of a multi-zone load balancer at the nearest AWS region out of 5 worldwide; each region's ELB configured to forward to auto-scaling health-checked linux instances balanced across all availability zones, each instance running a modified linux kernel optimized for the sole purpose of being a web proxy, running either varnish or nginx as a front end, using a SPDY library for SSL requests to app engine (yeah, the app engine front end has SPDY - GAE team didn't even know about it for a while). It would be best to have the AWS ELB use SSL with SPDY to talk to the instances but we'll let that slide. Yet, still, this solution is sub par considering: 1. There's hardly any point to serving static files from GAE, might as well serve them from your proxy. Yay, more locations to push to :) Or you could have your proxy be a literal cache and time out files but then you'd have to either push a cache flush or use cache busters for your content. IMO both reek of an equally vile stench. 2. It's likely the Channel API won't work with all those middle men. If the GAE team starts using websockets (or regular tcp/ip sockets while we're at it) we'd be back to the drawing board. Also various other APIs might be negatively affected or require some tinkering (blobstore upload, XMPP and task queue API) 3. Consistently added latency in the best case - you have the added latency of initiating an SSL handshake with the proxy. Given a solution with a load balancer you'd have two handshakes, and depending on how they're set up either one or both of them will be full SSL handshakes (not just TCP handshakes) 4. Additional highly varying latency in the worst case - what happens when the GAE or production teams move the instances serving GAE requests to another data center? Your users would see a sudden jump in latency since the proxy they're working with takes longer to reach the GAE domains/ips it's been working with. It'll take a while for new geolocation rules at the dns level meant to counter the effect to kick in due to dns caching. 5. It's expensive. The cheapest single server solution is more expensive than the GAE $9/app/month under the new pricing model. The full-blown AWS solution is somewhere around $1k a month. Not including the labor and maintenance required for the custom linux image. There are probably more issues but those are the best I could think of off the top of my head. I think there is no reason to believe that internal politics at google are holding this issue back. Also I can't find a reason to believe that google is an organization set up such that the GAE team and/or their product/project managers need to give financial incentives to other teams just to get a major feature out the door. I'm not saying there aren't internal politics because there probably are. I'm just saying that a feature of this type seems like something that, at worst, would be arbitrated quickly by a manager high enough on the corporate ladder to see the detrimental effect of not finishing this feature a full year after it was announced at a major company event. Regarding 2014 - I agree.. in that MS and their products will be synonymous with myspace by then to developers. But you can't deny the size of MS and their existing install base. EOL for XP doesn't necessarily mean that bureaucratic organizations like government offices will have upgraded by 2014. IPv6.. the jury's still out on that one. The question remains - are we waiting for 2014 or whichever decade will bring IPv6 / end of IE on XP or is there something in the works? I don't take issue with which decision the GAE team made, but with the fact that they're zigzagging on the availability of the feature. Amir -- You received this message because you are subscribed to the Google Groups "Google App Engine" group. To view this discussion on the web visit https://groups.google.com/d/msg/google-appengine/-/9Rs5wZemfCEJ. 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.
