Live data from Hacker News

Moving The New York Times Games Platform to Google App Engine

open.nytimes.com

111–120 of 152 posts

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

#111
post #85

Hey community, let me share my experience with AppEngine. I work in a small firm, where we've developed a massive Software Application comprising of 12 medium-sized apps. I went with Phoenix 1.3 w/ the new umbrella architecture. With AppEngine, the beauty is that you can have many custom named microservices under one AppEngine project and each microservices can have many versions. You can even decide how much percent…

The way you've delivered this "experience" makes you sound like you either work for Google or were asked to make a sponsored statement - for credits or $.

or a passionate user who had a great experience?! I love finding solutions which require less 'square peg round hole'. Unfortunately, rare these days when piecing together a stack w/ the myriad of platforms/frameworks/etc.

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

#112
post #34
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.

We actually spent the entire day at the Giants game today. ¯\(ツ)/¯ There's no incentive for high ranking HN posts, or any HN posts, actually. If there were, you wouldn't see others continually submit our news here before we do. This was a nice and unprompted post for everyone in GCP to read, as well. (Disclosure: I work on GCP as a product marketer.)

since you are disclosing your affiliation: do GCP actually have any account managers or similar business devs in EMEA?

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

#113
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"?

Because a key-value store is a foundamentally simpler data structure (it's an hash) than a relational database, which tracks the relations between different data types. If you make an advanced use of the key-value store, you have a lot of logic in the application (for example to key management, cascade operations between related data...) which a relational database should do for you. It's not fair because there is a development cost in using the key-value you are ignoring.

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

#114
post #85

Hey community, let me share my experience with AppEngine. I work in a small firm, where we've developed a massive Software Application comprising of 12 medium-sized apps. I went with Phoenix 1.3 w/ the new umbrella architecture. With AppEngine, the beauty is that you can have many custom named microservices under one AppEngine project and each microservices can have many versions. You can even decide how much percent…

The way you've delivered this "experience" makes you sound like you either work for Google or were asked to make a sponsored statement - for credits or $.

The way you've delivered this "comment" makes you sound like you either work for AWS or were asked to make a sponsored reply - for credits or $.

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

#115
post #89
post #6

Earlier quoted context omitted.

The "inelastic" might have been a shot at AWS. When pressed, the AWS people do use phrases like "pre-warming", "over provisioning" and "advance notice" around their ELB/ALB setup and ECS. Google's cloud salespeople pitch that they don't require any of that.

It's funny they'd mention that, and then later in the same article say they had to use a Cron job to scale up their gcp solution for a daily spike.

Using a cron to scale an AE service to 500 instances 5 minutes before 10PM > bugging the infra team to bring up our 19th MySQL replica.

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

#116
post #82

Earlier quoted context omitted.

Yep, same problems with many other services: * Kinesis Streams: Writes limited to 1K/sec and 1 MB / shard, reads limited to 2K/shard. Want a different read/write ratio? Nop, not possible. Proposed solution: use more shards. Does not scale automatically. There is another service called Kinesis Streams that does not offer read access to streaming data. * EFS: Cold start problems. If you have small amount of data in EFS…

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 down, but it is limited.

You start each 24hr period with 4 chances to scale down, and after those are depleted you can scale down once every 4 hrs regardless

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

#117

Earlier quoted context omitted.

The way you've delivered this "experience" makes you sound like you either work for Google or were asked to make a sponsored statement - for credits or $.

or a passionate user who had a great experience?! I love finding solutions which require less 'square peg round hole'. Unfortunately, rare these days when piecing together a stack w/ the myriad of platforms/frameworks/etc.

I'm usually not skeptical of comments but this comment definitely feels "artificial".

I think Google has better things to do than to pay people to comment on HN, but I do think either this person is trying too hard to sell us on Google Cloud because they like it (which isn't a bad thing per say)

Edit: I thought about it and they probably aren't related to it, probably just really enthusiastic about it (good thing) but they want to sell us on it (eh, not sure how I feel about)

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

#118
post #85

Hey community, let me share my experience with AppEngine. I work in a small firm, where we've developed a massive Software Application comprising of 12 medium-sized apps. I went with Phoenix 1.3 w/ the new umbrella architecture. With AppEngine, the beauty is that you can have many custom named microservices under one AppEngine project and each microservices can have many versions. You can even decide how much percent…

The way you've delivered this "experience" makes you sound like you either work for Google or were asked to make a sponsored statement - for credits or $.

I would hope someone on HN would disclose a conflict of interest when presenting their opinion.

Disclosure: Work for one of the cloud providers, but not on cloud itself.

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

#119
post #6
post #2

"Due to the inelastic architecture of our AWS system, we needed to have the systems scaled up to handle our peak traffic at 10PM when the daily puzzle is published." WT... I had to reread this to make sure I didnt misunderstand... why not work on making the current arhictecture elastic?! #cloudPorn

The "inelastic" might have been a shot at AWS. When pressed, the AWS people do use phrases like "pre-warming", "over provisioning" and "advance notice" around their ELB/ALB setup and ECS. Google's cloud salespeople pitch that they don't require any of that.

I think it depends on the nature of your spike.

AppEngine instances can typically start in 30 seconds or so. So if your spike is because your video went viral on facebook and lots of people are looking it it, that's fine.

If your spike is because you have 10 million clients with an app set to do an HTTP request at exactly 10:00:00pm, and they all arrive within a quarter second, thats a problem.

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

#120
post #95

Earlier quoted context omitted.

> * ECS: Two containers can not use same port on same node. Anti pattern to containers. Could you elaborate for this? I'm not sure I understand, are you saying that 2 containers cannot be mapped to the same host port? Because that would seem normal, you can't bind to a port where there's already something listening. But I guess I must be missing something.

I'm not familiar with the details of AWS here, but maybe the OP means mapping two different host ports to the same port on two different containers? That's all I can imagine that would be a container antipattern in the way described.

That is perfectly possible with ECS, so I don't know what OP was referring to. The thing I remember though is that you have to jump through a lot of hoops like making 4 APIs calls (or worse with pagination) for what should have been a single call to make such a system work on ECS.
Post reply on HN