revertts

Because it saves them money on transit costs. The Internet Peering Playbook is a good resource if you want to learn about some of the economics behind programs like this one (http://drpeering.net/core/bookOutline.html).

Edit: the flip side of this relationship is also interesting - if Apple or whoever doesn't offload enough of their traffic to the rack, then it isn't cost effective and can really annoy the ISP. I've known some ISPs to boot these caches out of their network when the related company wasn't utilizing it effectively.

Those traffic requirements are fairly steep - perhaps it will come down as the program matures.

If you're interested in similar edge cache programs:

https://openconnect.netflix.com/en/

https://www.facebook.com/peering/ (though I don't see FNA specifically mentioned there)

https://peering.google.com/#/options/google-global-cache

https://www.akamai.com/us/en/products/network-operator/akama...

https://peering.azurewebsites.net/peering/Caching

https://www.cloudflare.com/partners/peering-portal/

Why specifically Exodus?

Very nice! If you're looking for one more variant to add: LD with a limit on the acceptable distance can be done more efficiently, and is nearly always what you want in practice.

I wrote a commented version years back that might be a handy reference; it's since been deprecated because we moved it out of StringUtils, but the original code is here https://github.com/apache/commons-lang/blob/master/src/main/...

I've been running the beta for quite some time and didn't even notice that it had changed. Honestly, I think it's the best possible way that they can roll this out - iOS is much more restricted and has fewer devices to worry about, so is worlds easier than macOS, and internal dogfooding/the beta program gives them good coverage before hitting the whole population. Doing it in a dot release or major version doesn't seem particularly interesting one way or the other.

Messaging in the financial sector has very different requirements from messaging for a general service backend, which I assume is what the OP is referencing. As an example, a certain ecommerce site back in the day was heavily tibco based and migrated off due to inefficiencies at scale, multicast storms, debugability, and the general nature of multicast failures (for the most part you get no graceful degradation - which is fine when you have tight control of the network and do careful capacity planning, but isn't the mode that most tech companies live in).

Anecdotally, non-multicast setups are easier to scale in hardware (because you can push commodity farther) and most critically are easier for the normal type of engineer you'd find in the tech sector to reason about (because many aren't comfortable with networking equipment, so it's much easier moving that state out of the network and into layers they can easily debug).

The benchmarks do not use caliper or jmh. This is _very_ important - microbenchmarks on the JVM rarely do what you think they do without extra work.

"Quietly shifting their strategy" - they've been very public about a partnership with DeNA since at least March of last year. Given their success with micropayments in 3DS and similar titles, I've got high hopes for Miitomo/Go/etc.

I hit the same thing - I think my client just had a stale view of what version the person I was talking to was running. I did a refresh of the Favorites list on iOS and it sorted it out.

Re: latency - be careful how you're testing. Providers often announce only a subset of their IP space from any given datacenter, so you might end up with eg. a nameserver in Virginia, Dallas, and NY. If you run a synthetic round robin test you'll get variable latency. But actual resolvers will hone in on and prefer the fastest from the set, only occasionally checking the others; your real customer latency is generally equal to the fastest of available NSs. This plus the amount of caching that happens in DNS makes the performance implications of the design minimal, and it comes with huge availability advantages.

That being said, you may still get crap latencies if all four of your NSs are getting anycasted to far away places. ;)

I wouldn't read too much into amazon.com not being on R53. That company behaves like a diverse set of companies under one umbrella name, and some of those move at a much slower, much more conservative pace than others (more like "if it ain't broke...")

This. In general, you want to be measuring the latency directly to the resources you're routing to - the Internet's a screwy place, and latency to an AWS datacenter in Virginia might not match latency to your datacenter nearish Virginia. AWS provides a latency dataset for their infrastructure, but I'd probably stick to geo if I'm routing to resources not actually on their infra.

Other providers (eg. NS1) offer more ways to feed data into their system, so you may be able to create your own latency dataset and ship it off to them to use as a routing policy. Most large companies have built similar looking systems for tracking client latency to their DCs (look up Facebook's sonar/cartographer for an example). Synthetic, backbone monitoring like pingdom/gomez/etc. is usually not as useful for latency routing as RUM metrics.

Edit: And to be clear, failover and geo have no ties whatsoever to running on EC2. They're also common features across managed DNS providers, so it'd be very easy to run the same config across multiple providers for redundancy or migrate off of R53 without lockin (check out Netflix's denominator library).

There's read after write consistency for new objects, eventual consistency for overwriting existing objects.

Historically this applied to all regions except US Standard, but now that too supports it if you go through the VA instead of global endpoint.

Yep, I did eventually find that. Having to search for it was frustrating; so much of the copy is devoted to describing what Baker Street isn't (hey, doesn't use consensus!) and not what it is (uses a single node, TODO: master/slaves or chain replication or blah blah blah). And it's kind of an important point, because it changes this from "might give this a go for a less critical service" to "unusable in the short term."

If I'm reading it right, the directory service today is a single host. That was very misleading after these statements (which suggested something closer to netflix eureka):

"Zookeeper provides a strongly consistent model; the directory service focuses on availability."

"Baker Street doesn't use Zookeeper or the other popular service discovery frameworks because we wanted a simple, highly available service, not a strongly consistent one."

Edit: Which is not to say that the project isn't interesting, just that some of the copy felt like a bait and switch. :)

> What is so special about Apple and Seattle that notably that company should open an office in that city?

It's potentially the largest hub of independent mac/iOS developers outside of the valley. Seattle Xcoders is a bit of an institution and has been very active for a long time. Omni Group, Black Pixel, Flying Meat, Aged and Distilled, Q Branch (1/3rd of it) are all here. So there is justification for this specific pairing, though it wasn't explicitly mentioned in the article.

Often that's just because the mic isn't setup to capture audience noise - I've been to a few lectures where the audience was very engaged/entertained, but from the recording you'd think they were all sitting there in complete silence.

You should check out RecordStream. It has a lot of convenient processing built around JSON, and a lot of ways to get data to/from JSON.

https://github.com/benbernard/RecordStream/tree/master/doc

https://github.com/benbernard/RecordStream/blob/master/doc/R...

The resolver's IP is what they see. If you're behind a big, geographically diverse resolver (like public DNS), they'll have a bad time trying to map you to the closest server.

edns fixes this by propagating the original client IP, and while some of the public resolvers support it, support is lacking on the other side (CDNs, netflix, etc.)

Also, the starving hacker price is something like $30 a year. Definitely worth it to support that kind of quality, in depth content. :)

How much of that 15% is driven by ISPs versus misbehaving clients? (eg. set to boxes)

Depending on your use case, you might be able to get away with a TCP check on 443 or a separate, HTTP accessible deep healthcheck.

R53 currently lists 28 locations - "The Amazon Route 53 Global Network" section of http://aws.amazon.com/route53/

recs has this functionality, and _way_ more; worth giving a shot: https://github.com/benbernard/RecordStream

Seattle, WA - Full time

AWS Route 53 and Cloudfront

Our projects include massively scalable distributed systems that provide inexpensive, reliable, global distribution. This is an opportunity to join a world class team that is at the forefront of creating the next major computing platform.

Our service improves the performance, scalability, and reliability of our customer’s services. With tens of thousands of customers and over two-dozen edge locations worldwide, we operate at a global scale. As a member of the AWS team you will help create a system that will set the pattern for a generation to come.

You should be somebody who enjoys working on systems software, is customer-centric, and feels strongly not only about building good software but also about running that software in the real world. You must enjoy a close-knit team environment of shared responsibility.

Ideal candidates will have strong distributed systems and web services design and implementation experience. You should have a thorough understanding of Internet protocols such as HTTP, DNS, and TCP and experience implementing servers using Java in a Linux/Unix environment. This is a great opportunity to not only improve our understanding of Internet topology, but also shape it as well.

If you're interested, you can email route53-jobs@amazon.com

https://news.ycombinator.com/item?id=5304977 ;)

Seattle, WA - Full time

AWS Route 53 and Cloudfront

Our projects include massively scalable distributed systems that provide inexpensive, reliable, global distribution. This is an opportunity to join a world class team that is at the forefront of creating the next major computing platform.

Our service improves the performance, scalability, and reliability of our customer’s services. With tens of thousands of customers and over two-dozen edge locations worldwide, we operate at a truly global scale. As a member of the AWS team you will help create a system that will set the pattern for a generation to come.

You should be somebody who enjoys working on systems software, is customer-centric, and feels strongly not only about building good software but also about running that software in the real world. You must enjoy a close-knit team environment of shared responsibility.

Ideal candidates will have strong distributed systems and web services design and implementation experience. You should have a thorough understanding of Internet protocols such as HTTP, DNS, and TCP and experience implementing servers using Java in a Linux/Unix environment. This is a great opportunity to not only improve our understanding of Internet topology, but also shape it as well.

If you're interested, you can email your resume to route53-jobs@amazon.com

Also feel free to ping me directly (email in profile) if I can answer any questions :)

Depending on your usage, CF reserved pricing and price classes may be useful; linking to these just in case you haven't seen them:

http://aws.amazon.com/cloudfront/faqs/#Can_I_choose_to_only_... expensive_Amazon_CloudFront_regions

http://aws.amazon.com/cloudfront/pricing/ (reserved pricing and price classes at the bottom)

They're signed when you begin employment

Larger images saved as pjpegs tend to be slightly smaller than a standard jpeg.

http://www.yuiblog.com/blog/2008/12/05/imageopt-4/

I'll buy Arq immediately when Glacier gets added