A beginner's guide to scaling to 11 million users on AWS

[Marc Gayle]

http://highscalability.com/blog/2016/1/11/a-beginners-guide-to-scaling-to-11-million-users-on-amazons.html

Very interesting article.

Marc Gayle
www.marcgayle.com
www.twitter.com/marcgayle

[David Bain]

Thanks for link Marc!

--

David Bain, RHCSA

Owner at Alteroo

david...@alteroo.com

www.alteroo.com

(876) 475-5824

--

---
You received this message because you are subscribed to the Google Groups "SlashRoots Caribbean Developer Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email to slashroots+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Carey Mould]

thanks I will need this soon for my app I launch by end of month

--

[Matthew McNaughton]

Thank for the article Marc. Have to switched from deploying on Heroku?

@JJ, I know you were working on Google Cloud (maybe still are). But I was wondering if you have any similar articles/references you'd share for persons looking at choose architecture. We use Heroku, and for the most part are pretty happy with it. We have a open data portal running on a free version of AWS, but outside of that we are have standardized on our stack.

-MMM

Best Regards,
Matthew McNaughton

[Marc Gayle]

Nope. Haven't switched yet. But this article is a good primer if I ever want to switch. 

Marc Gayle
www.marcgayle.com
www.twitter.com/marcgayle

[JJ Geewax]

Yep -- still working on cloudy stuff :)

The good news here is that Google Cloud is super similar to AWS (I think we can all agree AWS has done a pretty stellar job designing stuff that solves people's hosting problems). This means that most AWS products have a Google counterpart (S3 -> Cloud Storage, EC2 -> Compute Engine, Beanstalk -> App Engine w Managed VMs, RDS -> Cloud SQL).

Here's a few differences you'll notice using Google vs AWS off the top of my head...

(This is coming from the perspective of a very happy and very large former AWS customer -- we built Invite Media on AWS, and our bill in 2012 was about ~2m USD per month which was a few thousand EC2 machines, a Petabyte of storage on S3, etc.)

- Google VMs will likely be cheaper than AWS

- AWS has way more geographical choices for your VMs to live today

- Both Google and AWS storage is optimized for high scale, throughput, and durability, however Google chooses availability whereas AWS chooses latency. This means that if an AWS region goes down, DynamoDB goes down, whereas if a Google Cloud region goes down, Datastore keeps running just fine. The trade off is that Dynamo is super fast, and Datastore is not.

- AWS has more infra services than Google today (Elasticache, IOT, etc)

- Google has some really nifty unique services today (ie, BigQuery -- which is insanely fast and really cool, and the Vision API which gives you back metrics like "there's a face at position x, with a likelihood of [joy, anger, surprise] of y%" -- to me that's kind of crazy cool)

Anyway -- short version is they're both good. Amazon has been in the external-facing game since ~2007, Google's been in this game internally since ~2004, but externally only since ~2013 (excluding App Engine)...

Some links to read in case you think I'm full of shit:

- http://www.businessinsider.com/snapchat-is-built-on-googles-cloud-2014-1

- http://www.wired.com/2014/01/secret-snapchats-monetization-success-will-surprise/

- http://cloudacademy.com/blog/google-cloud-vs-aws-a-comparison/

- https://cloud.google.com/files/esg-whitepaper.pdf

[Shannon Clarke]

Nice rundown. Thanks JJ

Regards,
Shannon Clarke
www.linkedin.com/in/sajclarke/

[Marc Richards]

I think that one of the biggest things that Google Cloud has going for it is the Kubernetes based Container Management platform[1]. To me "managed/hosted" container orchestration seems like the sweet spot between Elastic Beanstalk style PaaS and EC2 style IaaS. I hear nothing but good things about Kubernetes, and the fact that it is being standardized[2], and that the CNCF is being backed by so many different companies[3] is promising. Amazon is notably absent from that list. While that is very disappointing, it isn't terribly surprising that they didn't want to standardize on a tool made by a competitor. I really hope they change their minds though.

On the other hand, as you said, AWS has been in the game a lot longer and they don't seem to be slowing down. One area where they seem to be ahead (correct me if I am wrong) is the extensive and fine-grained levels of access control that can be created using IAM as well as encryption related tools like their Key Management Service. Policy/Encryption services may be boring to most, however newer services like Lambda[4] and the API Gateway[5] allow for some very interesting server-less approaches. I also really like the concept of RDS for Aurora[6]. The current pricing puts it out of reach for many (hopefully that will come down over time), but I find the prospect of highly *reliable* managed database to be *very* appealing.

At the end of the day, competition is good and I hope Google and AWS bring out the best in each other and continue to innovate and drive down prices. It is an *amazing* time to be a developer.


[1] https://cloud.google.com/container-engine/
[2] https://cncf.io/technologies
[3] https://cncf.io/about/members

[4] https://aws.amazon.com/lambda/
[5] https://aws.amazon.com/api-gateway/
[6] https://aws.amazon.com/rds/aurora/

[JJ Geewax]

So many citations !

Here's the one shitty part of my job... I can't tell you all about ... so many things ....

I'll leave you with a few things:

- GKE (managed k8s -- which is how we write Kubernetes): Yep, it's cool. 

- IAM: some is there, more on the way

- KMS: on the way

- Lambda: https://cloud.google.com/functions/docs

- I forgot to mention Bigtable last time. Yep, you can have it. https://cloud.google.com/bigtable/

And also, have you guys read this really neat paper that is toootally unrelated to this thread? ;)

http://static.googleusercontent.com/media/research.google.com/en//archive/spanner-osdi2012.pdf

I wonder....

[Marc Richards]

Cool, hadn't heard about Cloud Functions. Spanner is quite interesting, especially since it has the ability to replicate across regions. What would be even more interesting would be an SQL interface on top of that...oh wait that already exists[1]. What would be even *more* interesting would be if it were available to the public and I dunno maybe had a MySQL compatible interface...Alas one can only dream of such things.

[1] http://research.google.com/pubs/pub41344.html

[JJ Geewax]

F1 is a slightly different SQL style for a slightly different purpose (we built that specifically for Ads). Spanner speaks SQL natively (you probably saw this in the paper), with some extensions for Protobuf and JSON, and some tweaks to support "large scale" (ie, interleaving).

Compatibility with MySQL (or any external SQL) is actually *really* complicated for a couple of reasons....

The obvious one is that Spanner has hierarchical keys (via interleaving) to express data locality. MySQL's flavor of SQL just doesn't handle that as it's replication model is completely different. PostgreSQL is equally complicated. MSSQL and Oracle.... you get the point. In short, SQL89 and SQL92 were built for... those years.

The bigger problem is bug-level compatibility. Without the same binary, it is nearly impossible to make sure that bugs for MySQL exist in a MySQL clone... A great example... what's "the right thing" to do with your MySQL clone: replicate this buggy behavior? or do the right thing? http://bugs.mysql.com/bug.php?id=11472 (is 10 years enough to switch from "bug" to "feature"?)

The last one is an incomplete feature overlap as there are a few queries that work fine in MySQL but may not work the same in Spanner -- sadly I don't think I can go into any more detail on this one...

The good news for all of this is... you shouldn't be writing raw SQL anyway, so leave the integration with whatever flavor of SQL to your ORM like SQLAlchemy, Active Record, Django, etc.

The bad news is... you can't just lift-and-shift all your code and magically have it "scale to 1m queries per second". You *might* be able to, but it probably won't work exactly as you expect. An airplane cockpit might have a lot of similarity with the space shuttle, but dropping a Delta pilot into the Atlantis space shuttle might not work out so well...

In short, to benefit from all this scaling magic, you have to provide a bit more information about what you're doing (what row is this new row near? is this transaction just reading data? or modifying data too? do you need to immediately read the data you just wrote? or can you wait?). Since you have to share that, it'd mean code changes....