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?
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.
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...)
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.
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.
Now let's talk to the 0 user startups with trivial data with their SOA/microservices, NoSQL databases or sharded data bases...