
Amazon Route 53 Releases Auto Naming API for Service Name Management/Discovery - MayBeColin
https://aws.amazon.com/about-aws/whats-new/2017/12/amazon-route-53-releases-auto-naming-api-name-service-management
======
zimbatm
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 number
of instances quickly.

~~~
mark242
Why would these instances not be behind ELB?

~~~
zimbatm
WebSocket. ELB adds latency and is harder to debug.

~~~
otterley
Have you considered using NLBs instead?

~~~
zimbatm
That was before NLBs. But yeah, NLBs might be a good choice now.

------
djb_hackernews
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.

~~~
zackelan
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_...](https://docs.aws.amazon.com/Route53/latest/APIReference/API_ChangeResourceRecordSets.html)

1:
[https://docs.aws.amazon.com/Route53/latest/APIReference/API_...](https://docs.aws.amazon.com/Route53/latest/APIReference/API_autonaming_CreateService.html)

2:
[https://docs.aws.amazon.com/Route53/latest/APIReference/API_...](https://docs.aws.amazon.com/Route53/latest/APIReference/API_autonaming_RegisterInstance.html)

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

~~~
setra
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.

~~~
jsjohnst
> 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.

~~~
colmmacc
These days EDNS0 allows bigger UDP responses in many cases, which may mean
some fragment re-assembly. Unfortunately there are a staggering number of
networks and firewalls that don't open TCP 53, and also ones that don't permit
UDP fragments. So if you want DNS to work reliably /everywhere/, sadly it's
wise to stay below the 512 limit.

~~~
otterley
We're talking about service discovery here. This is internal DNS traffic in
AWS, where these issues to which you refer are nonexistent.

------
toomuchtodo
For folks who are using Consul or Zookeeper, would you consider replacing
service discovery with this?

~~~
otterley
Not yet. I think this is just the first step towards an AWS-native service
mesh solution. I suspect there will be future announcements over the coming
months that continue to put all the pieces together.

