<h1>Context</h1>

<p>I am deploying a set of services that are containerised using Docker into AWS. No matter which deployment solution is chosen (e.g. raw EC2/ECS/Elastic Beanstalk/Fargate) we will face the issue of "service discovery".</p>

<p>To name just a few of the options for service discovery that I've considered:</p>

<ul>
<li>AWS Route 53 Service Registry</li>
<li>Kubernetes</li>
<li>Hashicorp Consul</li>
<li>Spring Cloud Netflix Eureka </li>
</ul>

<h1>Specifics Of My Stack</h1>

<p>I am developing Java Spring Boot applications using Spring Cloud with the target deployment environment being AWS.</p>

<p>Given that my stack is Spring based, spring cloud eureka made sense to me while developing locally. It was easy to set up a single node, integrates well with the stack and ecosystem of choice and required very little set up.</p>

<p>Locally, we are using docker compose (not swarm) to deploy services - one of the containers deployed is a single node Eureka service discovery server.</p>

<p>However, when we progress outside of local development and into staging or production environment we are considering options like Kubernetes.</p>

<h1>My Own Assessment Of Pros/Cons</h1>

<h2>AWS Route 53 Service Registry</h2>

<p>Requires us to couple code specifically to AWS services. Not a problem per se, we are quite tied in anyway on other parts of the stack (SNS/SQS).</p>

<p>Makes running the stack locally slightly more difficult as it relies on Route 53, I suppose we could open up a certain hosted zone for local development.</p>

<p>AWS native, no managing service registries or extra "moving parts".</p>

<h2>Spring Cloud Eureka</h2>

<p>Downside is that thus requires us to deploy and manage a high availability service registry cluster and requires more resources. Another "moving part" to manage. </p>

<p>Advantages are that it fits into our stack well (spring ecosystem, spring boot, spring cloud, feign and zuul work well with this). Also can be run locally trivially.</p>

<p>I presume we need to configure the networks and registry zone to ensure that that clients publish their host address rather and docker container internal IP address. e.g. if service A is on host A and wants to talk to service B on host B, service B needs to advertise its EC2 address rather than some internal docker IP.</p>

<h1>Questions</h1>

<p>If we use Kubernetes for orchestration, are there any disadvantages to using something like Spring Cloud Eureka over the built in service discovery options described here <a href="https://kubernetes.io/docs/concepts/services-networking/service/#discovering-services" rel="noreferrer">https://kubernetes.io/docs/concepts/services-networking/service/#discovering-services</a></p>

<p>Given Kube provides this, it seems suboptimal to then use eureka deployed using kube to perform discovery. I presume kube can make some optimisations that impact avaialbility and stability that might nit be possible using eureka. e.g kube would know when deploying a new service - eureka will have to rely on heartbeats/health checks and depending on how that is configured (e.g. frequency) this could result in stale records whereas i presume kube might not suffer from this for planned service shutdown/restarts. I guess it still does for unplanned failures such as a host failure or network partition.</p>

<p>Does anyone have any advice on this, do people use services like Kubernetes but use other mechanisms for service discovery rather than those provided by kube. Is there a good reason to do one or the other?</p>

<h2>Possible Challenges I Anticipate</h2>

<p>We could replace eureka, but relying on Kube to perform discovery will mean that we need to run kube locally to deploy whereas currently we have a simple tiny docker-compose file. Also, I'll have to look at how easy it'll be to ensure that ribbon, zuul and feign play nicely with this.</p>

<p>Currently we have ribbon configured with a eureka client so that service A can server to service B just as "service-b" for example and have ribbon resolve a healthy host via a eureka client. I guess we can configure ribbon to not use eureka and use an external Kube service name which will be resolved by Kube DNS at runtime...</p>

<h3>Final Note</h3>

<p>Thanks in advance for any contribution or advice. I know this might elicit a primarily opinion focused response. But I am hoping someone can provide objective guidance on when one solution might be preferable to another.</p>

<p>Service discovery is something you get out-of-the-box with Kubernetes. So having another external service in your platform will be another application to maintain, deploy and can be a point of failure. So I would stick with the the service discovery provided by Kubernetes.</p>
