Live data from Hacker News

Amazon Route 53 Releases Auto Naming API for Service Name Management/Discovery

aws.amazon.com

11–20 of 23 posts

Re: Amazon Route 53 Releases Auto Naming API for Service Name Management/Discovery

#11
post #4

This seems like a useful feature but it would be nice to have a better understanding of how it affects rate-limiting. Historically Route53 has been pretty useless for service discovery because of the heavy rate-limiting. Something around 5 updates per second, on the whole account with a window of 60 seconds. I don't know if it's still the case but it used to be quite painful, especially when you need to scale up the…

Why would these instances not be behind ELB?

Re: Amazon Route 53 Releases Auto Naming API for Service Name Management/Discovery

#12
post #11
post #4

This seems like a useful feature but it would be nice to have a better understanding of how it affects rate-limiting. Historically Route53 has been pretty useless for service discovery because of the heavy rate-limiting. Something around 5 updates per second, on the whole account with a window of 60 seconds. I don't know if it's still the case but it used to be quite painful, especially when you need to scale up the…

Why would these instances not be behind ELB?

There are service architectures where putting them behind an ELB is not an ideal scenario (an example would be RabbitMQ; works great with haproxy in front of it, not so much with ELBs). ELBs aren't always a perfect fit, and depending on what sort of connection lifecycle or scaling velocity you require, direct addressing of service instances might be required.

Re: Amazon Route 53 Releases Auto Naming API for Service Name Management/Discovery

#13

It's not clear how this is different from what is currently possible. I'm not a route53 guru but can't you already a) create a subdomain microservice.mydomain.com b) create instances c) add the instances IP address to an A or AAAA record for the subdomain. Is it that they didn't have APIs for these operations and now they do? I know I'm missing something.

It's not a long article, like three paragraphs. The complexity is handling health checks and the like. If one of your endpoints goes down, you want to update the DNS record to remove it. Which means you have to make or use software that continuously monitors your endpoints and updates DNS accordingly. Now Route 53 will do those health checks for you automatically.

Re: Amazon Route 53 Releases Auto Naming API for Service Name Management/Discovery

#14

It's not clear how this is different from what is currently possible. I'm not a route53 guru but can't you already a) create a subdomain microservice.mydomain.com b) create instances c) add the instances IP address to an A or AAAA record for the subdomain. Is it that they didn't have APIs for these operations and now they do? I know I'm missing something.

If I'm reading the underlying docs correctly, previously you would have called ChangeResourceRecordSets[0] with a quite verbose XML document. It looks like you'd need to first query for the existing RR set, modify it, then update it, and deal with potential race conditions if two service instances are starting concurrently. Technically possible, but quite a bit of complexity.

Now with auto-naming, you create a service[1], then a service instance calls RegisterInstance[2] on start-up with a much simpler JSON payload.

0: https://docs.aws.amazon.com/Route53/latest/APIReference/API_...

1: https://docs.aws.amazon.com/Route53/latest/APIReference/API_...

2: https://docs.aws.amazon.com/Route53/latest/APIReference/API_...

Re: Amazon Route 53 Releases Auto Naming API for Service Name Management/Discovery

#16

It's not clear how this is different from what is currently possible. I'm not a route53 guru but can't you already a) create a subdomain microservice.mydomain.com b) create instances c) add the instances IP address to an A or AAAA record for the subdomain. Is it that they didn't have APIs for these operations and now they do? I know I'm missing something.

There were APIs to do the operations you mentioned. I think for most services an ELB would do the trick; create an ELB, add instances to it, create a CNAME or Alias to the ELB.

The one time I've wanted this is with auto scaling groups for services that don't use ELBs. I haven't found docs on it, but if this could be used to add/remove DNS records based on auto scaling events that would be useful. It would save from using lifecycle hooks to trigger a Lambda function.

Also this seems to be a larger service discovery play, it just doesn't seem very fleshed out yet.

Re: Amazon Route 53 Releases Auto Naming API for Service Name Management/Discovery

#17

It's not clear how this is different from what is currently possible. I'm not a route53 guru but can't you already a) create a subdomain microservice.mydomain.com b) create instances c) add the instances IP address to an A or AAAA record for the subdomain. Is it that they didn't have APIs for these operations and now they do? I know I'm missing something.

When I first read the article I was under the impression that now one would be able to connect a zone with an autoscaling group (and, as you mentioned, avoid allocation internal ELBs), but it looks like it's really just some sugar on top of the existing API.

Am I right?

Re: Amazon Route 53 Releases Auto Naming API for Service Name Management/Discovery

#18
post #6
post #5

Only 8 records per answer? I wonder why. Many of us run services comprising hundreds of endpoints or more.

Considering this is DNS there has been a historical limit of 512 bytes. Despite this not usually being a limitation now you are really pushing the ideal packet size with hundreds of answers each of which are multiple bytes. High chance of packets being dropped.

> Considering this is DNS there has been a historical limit of 512 bytes.

Only with UDP transport, longer responses are told to requery via TCP.

Re: Amazon Route 53 Releases Auto Naming API for Service Name Management/Discovery

#19
post #11
post #4

This seems like a useful feature but it would be nice to have a better understanding of how it affects rate-limiting. Historically Route53 has been pretty useless for service discovery because of the heavy rate-limiting. Something around 5 updates per second, on the whole account with a window of 60 seconds. I don't know if it's still the case but it used to be quite painful, especially when you need to scale up the…

Why would these instances not be behind ELB?

WebSocket. ELB adds latency and is harder to debug.
Post reply on HN