AWS: Scaling Up to 10M Users | Hacker News Reader

AWS: Scaling Up to 10M Users

slideshare.net

81 pointsmariuz18 comments

Great resource.

Now let's talk to the 0 user startups with trivial data with their SOA/microservices, NoSQL databases or sharded data bases...

AWS Scaling beyond 1 Million would mean that you have a global audience - AWS does not have any Global LoadBalancer for customers who do not want to use Route53 - has anyone worked on Global Loadbalancer on AWS infrastructure without Route53 ?

using route 53 has always been worth it for me, and it's not that hard to only use it for the bits you need rather than using it to manage an entire domain.

e.g. my company hosts our own legacy BIND servers, so our main root domains live there, but I wanted to be able to use Route53 for easy DNS updates within Cloudformation. So, we just set up sub-zones in BIND that forward to a route 53 hosted zone (*.prod-aws.whatever.com), and our user facing domain names (foo.whatever.com) just cname to something in the sub-zones (Foo.prod-aws.whatever.com) that route53 manages.

That's just one example that's not 100% applicable here, but the point is you can get creative and only use it for what you need, which I've found makes it much easier to accept.

A "global load balancer" is not that simple. You can run multiple servers with a single anycast IP, but that will cause problems for 99% of non-UDP traffic.

Anycast DNS is one way of pushing local traffic to local servers, but the only thing "load-balanced" is the DNS server itself, not your app. Your app is just geographically routed.

If you want true global load balancing, you're beginning to talk about something like WAN optimization and running your own network fabric. If you get to that point, you're probably better off rolling your own than using AWS anyway.

We do also have CloudFront - which can front dynamic content, and even integrate with Lambda@Edge to serve responses. But at that point it's not really acting as a load balancer.

R53 + Geo DNS | Latency Based DNS | Traffic Manager + Application Load Balancer | Network Balancer is definitely our go-to recommendation and it's used by a variety of customers to handle traffic globally.

Route53 supports ALIAS records, so everything still works at the root of your domain (e.g. mydomain.com). Failover is handled with DNS health checks that propagate more quickly than the cascading BGP routing updates that power alternatives such as anycast, as well as avoiding breakage of other in-flight connections due to route table disruption. R53 + Health Checks is what we use for www.amazon.com.

I'm curious - what would you prefer to see in an alternative?

What do you mean by global load balancer? You can use AWS loadbalancer without Route53.

I think he means Anycast routing. Technically, one could run their own nameservers which direct to their own load balancers.

Or you could use one of the other DNS providers who provide Anycast support. I think DynDNS does it.

Anycast is easy to setup. Scaling it is another story: https://www.linkedin.com/pulse/build-your-own-anycast-networ...

Though most people that are convinced they need anycast would be better served with 53's GeoDNS

Great slides. The only thing I disagree with is that I think you should put your instances into an autoscaling group from day one. You don't even need to autoscale, but just by having your instance(s) in an autoscaling group, you'll be able to deal with instances dying without having to take manual action. Just an autoscaling group with a desired capacity of 2 will take you a long, long way without significant complexity.

Is there a similar resource / slide deck for scaling on GCP?

Same concepts apply, you just have to map the AWS services to the GCP alternatives. Autoscaling Groups = Managed Instance Groups, ELB/ALB = Cloud Load Balancing, RDS = Cloud SQL, etc.

For sure, makes sense! I'm not familiar with the GCP alternatives, and you seem to be on a roll: care to keep the equivalency mapping going? :) (We may end up crowdsourcing generation of a GCP version of these slides...)

Off the top of my head, what I remember mentioned in the slides:

* Elasticache = Managed Redis and Memcache isn't available on GCP. (I really wish it was.)

* S3 = Cloud Storage

* CloudFront = Cloud CDN

* SQS = Cloud PubSub

* Elastic Beanstalk/CodeDeploy — No GCP alternative.

* Lambda = Cloud Functions (Beta)

Nice thing about GCP is that they don't get creative with naming, so it's pretty easy to infer what their services do.

Resource at [0] comes to mind. There are differences, biggest one within the context of this discussion is that Google cloud carries a multi-regional and global philosophy, whereas aws tends to be zonal. This is expressed in things like global vpc (no need to tie regions or zones together), multiregional gcs, regional or global services, etc.

(Work at g)

[0] https://cloud.google.com/docs/compare/aws/

Which is the point when you decide to go server less?

As early as possible. Things like AWS Lambda require you to really architecture for them in order to get the full benefit of it.

Lambda is also nearly costless if you have little traffic so it's not like you would pay extra for it. But serverless architecture isn't always the right decision.

Serverless shines when you have an unpredictable amount of async tasks to run, and those tasks can take a long time to run. Thumbnailing images for example.

Lambda has a 5 minute execution limit. It's not that great for background tasks unless you can divide them up to keep them comfortably under that limit. It shouldn't be that hard, but it's not effortless either.

Never is also a valid option.

Reply on news.ycombinator.com