Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Moving The New York Times Games Platform to Google App Engine

open.nytimes.com

Post reply on HN
Print view View original

131–140 of 152 posts

Re: Moving The New York Times Games Platform to Google App Engine

#131

Post by vira28 »

ubernetes wrote: post #93
vira28 wrote: post #81

Earlier quoted context omitted.

Looks like Spanner is a relational database. DDB is just a key-value pair. So, is it fair to compare against them or am i missing something?

Why wouldn't it be "fair"?

Apart from the points @dullgiulio mentioned.

DDB -> NoSQL, No Automatic backups, No support for ad-hoc querying, eventual consistency (though you can set to get consistency with few tradeoffs) Spanner DB -> RDBMS, Automatic backups, Enriched SQL, Strong consistency.

Let me if you still think its fair to compare these 2 databases.

Re: Moving The New York Times Games Platform to Google App Engine

#132

Post by rhodysurf »

kennethh wrote: post #110
iamgopal wrote: post #106

Earlier quoted context omitted.

SSL is free. Custom domain also free.

That explains it, would be nice if they could write it down somewhere as a feature:)

Its free for custom but only to use existing certs. You still have to set up the cert and such with your domain as you normally would. You also get the *.appengine.com domain with automatic SSL>

Re: Moving The New York Times Games Platform to Google App Engine

#133

Post by vira28 »

bonesss wrote: post #108
vira28 wrote: post #82

Earlier quoted context omitted.

Agree totally. The solution to overcome those shortcomings in AWS, is to sort of put bandaid's with more services (at least their suggestion). I do understand, its not feasible to provide service which fits for everyone, however it will be good if they solve the fundamental problem. One more to add in the list. In DynamoDB during peak (or rush hour) you can scale which increases the underlying replica's(or partitions…

You can scale DynamoDB down the same way you scale it up. Perhaps you're thinking of some kind of autoscaling that only works in one direction?

Thanks. Not the auto scaling part. I thought even manually if you scale up with new replica's, we can't scale down. I should read the manual and get a clear picture.

Re: Moving The New York Times Games Platform to Google App Engine

#135

Post by tscanausa »

ciguy wrote: post #77

As a DevOps consultant I've actually worked with clients migrating stacks to and from GCE/AWS (Yeah, both ways, not the same client). What I've found in aggregate is that GCE is a bit easier to use at first as AWS has a LOT of features and terminology to learn. When it comes down to it though, many GCE services felt really immature, particularly their CloudSQL offering. One client recently moved from GCE to AWS simpl…

Hi, I am not sure you will read this as it's 10 hours after posting. The cloud sql updating both copies sounds like a bug. If you want to email me your case number I can look into it. I know you don't work with GCP anymore but I like to resolve the issue for other users.

Email: tsg@google.com

Disclosure: I work on gcp support. Not paid to be here.

Re: Moving The New York Times Games Platform to Google App Engine

#136

Post by notyourday »

sidlls wrote: post #88
Jedi72 wrote: post #25

Getting pro GCP articles to the top of HN must no-doubt be a high priority for the Google marketing team. This is the nature of modern advertising, sneakily trying to subvert your thinking by masquerading as something else.

Really why would they care? HN is a tiny, tiny slice of the programming world.

It is over-saturated with people who either make spend decisions or seriously affect spend decisions

Re: Moving The New York Times Games Platform to Google App Engine

#137

Post by funkjunky »

ciguy wrote: post #77

As a DevOps consultant I've actually worked with clients migrating stacks to and from GCE/AWS (Yeah, both ways, not the same client). What I've found in aggregate is that GCE is a bit easier to use at first as AWS has a LOT of features and terminology to learn. When it comes down to it though, many GCE services felt really immature, particularly their CloudSQL offering. One client recently moved from GCE to AWS simpl…

(GCP support here) This is a known bug, I've worked at least a few cases where this happened. There is a feature coming out soon that will allow different maintenance schedules to be set for masters/replicas, which will likely be automatically set for different times. And, once the kinks get worked out, hopefully we'll be able to re-deploy the feature that shifted traffic to failovers while the master is being updated, and eliminating maintenance downtime altogether.

Re: Moving The New York Times Games Platform to Google App Engine

#138

Post by funkjunky »

robotmay wrote: post #100
_wmd wrote: post #97

Earlier quoted context omitted.

Cloud Postgres is also hilariously hard limited to 100 simultaneous connections (the default). Doesn't matter how much RAM you give it. My experience with GCP in the past 4 months has led me to revise my "friends don't let friends use App Engine" motto to "friends don't let friends use Google Cloud", there isn't a single service I touched (except maybe Compute Engine) that didn't have half-baked client libraries, doc…

I was super keen to switch to GCP (for cost saving etc) but this mirrors a lot of my experiences. Deploys to App Engine took 20 minutes, not 2 minutes, and I have absolutely no faith in their firewall settings actually working. I have no idea what the problem is, but it's basically impossible to boot a Rancher master node on Compute Engine. Even with all ports open. In the end I just bailed on the platform as a whole…

App Engine Flex takes a long time to deploy, and always has. App Engine standard is what deploys quickly, and also scales quicker.

Firewall settings work just fine for our platinum clients with complex network architectures, I don't see why it wouldn't in your case unless something was misconfigured.

Re: Moving The New York Times Games Platform to Google App Engine

#139

Post by funkjunky »

bpicolo wrote: post #124
funkjunky wrote: post #94

Earlier quoted context omitted.

(Google cloud support here) The pages you linked to are supposed to serve as client libraries reference only. If you want higher level instructions and examples, always start with the main Google Cloud docs first. On any page that offers instructions, the top of the code windows offers a selection of client library languages/CLI tools/REST API available to do whatever that task is. For cloud storage, start here: http…

Heya, Thanks for the link! You're right that this is what I was looking for. Unfortunately, that hadn't shown up in a convenient place while I was googling around. Would be good to add direct links to those from the client lib references, because those pop up for e.g. "google storage python" first. (Unless they're already there and I didn't see them). Links from the READMEs of the repo might be useful too to help peo…

That's not a bad idea, I'll bring it up with our client library maintainers today.

Re: Moving The New York Times Games Platform to Google App Engine

#140

Post by bastawhiz »

mattbillenstein wrote: post #64
bastawhiz wrote: post #61

Earlier quoted context omitted.

That works great until a machine starts failing health checks and you need to take it out of rotation ASAP. It's also the case that DNS gets cached and not all users create the same load: one user making many requests will burden one server instead of having the load evenly distributed.

Clients will try another ip if they can't connect -- partial failures may be a problem, but in my experience as long as nginx is alive, you can load balance to a different web backend if the app processes on that machine are wedged. I've deployed this solution in 50k req/s environments and not seen a single user be a problem like you mention -- any motivated bad actor could cause problems in either scenario I expect.

Clients might not fail to connect. That's even worse. They connect and the server hangs and returns no response (perhaps due to bad configuration changes). Now you're stuck, and your server is too oversaturated to SSH in and fix it.

It out depends on your application and users. Building a website? Probably not much of an issue. Building a low-latency API? YMMV. Keeping your load evenly balanced across your front end cluster also can keep your cost low, since you are able to distribute load more evenly.

That's another point: if you scale your cluster size up and down frequently to accommodate load, doing that with DNS is a nightmare.

Post reply on HN