Fastly also has more "points of presence" than AWS/GCP
Fastly has deployments in 17 north american cities. AWS is in 5.
They're pretty different strategies. For every massive AWS datacenter on a continent, fastly has at least 3 tiny ones -- inevitably closer to your customers, meaning lower RTT.
It seems a bit nit-picky, but AWS has ~18 commercial regions, but far more datacenters. It's availability zone that's a data center (more or less), not a region. So for each region you end up with 3 to 5 data centers or something like that.
- three in the US (1 in Virginia, one in Oregon, one in Northern California)
- two in Europe (Dublin and Frankfurt)
- four in Asia (Singapore, Tokyo, Sydney, Seoul)
- one in South America (São Paolo)
and both Montreal and India announced. So by part way through 2017, the "numbers" would be sort of comparable but the real factors are your latency requirements, data sovereignty (hello Germany!) and the features you need (and not all features are available in all regions!).
Don't forget the availability zones! Each region has 2-4 availability zones, and each of these has 1-6 datacenters. The scale of AWS is at least an order of magnitude more important than OVH's.
It really doesn't though. Sure, it would if the difference is only "16 mega-regions (regional-model) versus 300 mini-regions (edge)". But that's not the difference.
The actual difference, at least how Cloudflare pushes it, is in the software; its a higher layer of abstraction; that customers get to stop thinking about regions and locations. Your software is global; its deployed everywhere; it runs everywhere.
This is ENTIRELY antithetical to everything on AWS except CloudFront, Route53, IAM(ish), maybe a couple other minor services. Every Single Thing Every Single AWS Customer configures beyond those global services forces you into a region. Want to deploy a lambda function? Which region would you like? Pricing and available products is different in every region. Fronting it with an API? Where would you like that API Gateway? We'll put CloudFront in front of it so its a bit faster for ya, its global(ish), don't worry.
In a no-true-scottsman true-edge world, this goes out the window. Cloudflare Workers is like this; D1 is kinda-ish-there-ish; R2 isn't. Here's the code; spider it across the world; automatically route clients to your closest PoP. No regions. No locations.
Its not obvious that AWS will ever make meaningful moves to a world like this, for a ton of reasons, but most meaningfully: it requires customer demand; but AWS's existing customers aren't demanding it, because AWS's customers are old CTOs worried about past quarters too much to think about the next one. The younger, smarter, potential customers who recognize how valuable this is aren't AWS's customers; so AWS never hears from them (which, by the way, should more generally concern Amazon's investors; their "relentless customer driven" approach to their products is great for a few decades, but its absolutely true that most of the time customers just want a faster horse, and you're not hearing from the people who aren't your customers because you've never solved their problems before). So, Amazon has dumped billions upon billions into their couple-dozen giga-regions; you cannot pivot that into hundreds upon hundreds of mini-regions like what Cloudflare (and to a lesser but still awesome degree Fly) has.
Vercel is the best case study on this. They are exploding in popularity. They don't run any of their own infra afaik, to be clear, but they whitelabel products from Cloudflare, Neon, and others; all Edge infra providers. No one on Vercel is cross-shopping AWS, and AWS has nothing that feels competitive to what Vercel offers. They can't compete.
The outcome, in maybe 10-20 years, of this landscape feels really obvious right now, but AWS's size and the insane scale of their investment into "how we did things in 2010" will turn them into the next IBM. Some would say they already are. There's nothing they can do about it. They're not making the right investments. Even if they wanted to, they can't at the necessary scale, because what they're doing is working right now and their existing customers keep forcing them to spend more money building more structures, more racks, more blades, all in Ashburn VA.
While what you say makes perfect sense to _everyone_, sadly it is not true. London and Canada - both very new regions for AWS - each only have two availability zones (making them basically useless for a large class of infrastructure).
I don't think it is so much compute in every region as it is data storage there.
My company stores user data and deploys to most AWS regions. It's a big win for some companies to be able to have their data stay in a given area (esp the EU, but I've also heard Canada mentioned).
Even within a single AWS region you can land in completely different data centers. Perhaps it doesn’t require as many people as some think, but the large cloud businesses run at a larger scale than your mom-and-pop data center.
Yeah, you’re not getting what people are saying. AWS’s AZs are much more separated than GCPs. Your recommendation that one could build across regions isn’t what folks are talking about here since there is a big benefit to having geographically separate AZs in the same region. That’s where GCP is falling short here.
I couldn't tell you technically as I didn't build it, however, I use our app and it's very quick, I know that we keep our regions near each other (east east), front end can fail through nyc locations, we have no customers outside of the east coast either, so that helps as well. As far as back end, we are restricted to AWS GovCloud regardless.
If you are in Asia that’s probably why? It’s very useful having AWS in an Ohio since it reduces the latency a bunch (I am based in Chicago ). Also if you need to have low ping times for global deployments .
AWS actually operates 5 independent data centers (called availability zones) within the same complex that make up the us-east-1 region. This makes them significantly more likely to experience an outage in 1 availability zone, but also makes it much easier to architect around the problem.
There are some significant differences region to region in AWS. Different numbers of availability zones, different latencies based on datacenter location, different types and availabilities of EC2 instances, etc. I think it makes sense to develop in the same region that your production service runs in just so you don't shoot yourself in the foot by deploying something that runs fine in your development region but doesn't run as well in your production region.
It’s highly unlikely that Amazon (or anyone) can reliably find or build datacenter space that is high quality _and_ within a few miles of other such space across all the regions they operate. If they had gone to to such lengths they would clearly state that zones are fully independent from each other. Instead they only say that about regions.[0] So even though I have worked at neither company I’m going to say their concept of a zone is mostly equivalent — independent in terms of power and network domains but in the same building or at most on the same property. This allows them to have the low latency that is touted between zones of a specific region.
Fastly has deployments in 17 north american cities. AWS is in 5.
They're pretty different strategies. For every massive AWS datacenter on a continent, fastly has at least 3 tiny ones -- inevitably closer to your customers, meaning lower RTT.
reply