iwalz

Since v3 they're using grpc, which means http/2 - since than, long polling is much more efficient!

These failures are the worst case for any technology like that and will always cause a bit pain in production - but since the etcd guys a very open to how they behave in case of failures and how they do quality testing of etcd, I started to trust etcd: https://coreos.com/blog/new-functional-testing-in-etcd/

I have read a blog post about continous testing of consul at high scale too (can't find the link for now), but I can't remember to got this much insights.

I have updated the post to reflect #1 - thanks for pointing that out!

I haven't meant that you need to use atlas, but I have never seen a nice automation implementation for a scalable consul cluster that doesn't use atlas. I've also built something around atlas, mostly using hiera in puppet - but since I used atlas and the etcd discovery, everything else looks like a workaround.

What provisioning do you use to integrate with your cloud providers api?

I personally think the OPs reason to use etcd is mainly about 2 parts: 1.) The ecosystem it integrates in 2.) Only maintaining 1 SR technology

I think that with the upcoming kubernetes trend, many OPs guys are somehow familiar with the CoreOS stack where etcd fits in very great. The hashicorp toolchain is great, but I've seen many OPs guys only using terraform or vault e.g. and don't build an integrated environment with nomad or atlas.

The CoreOS stacks I've seen are more integrated in platforms than the hashicorp ones (can be a good and a bad thing at once).