Clash Royale CLAN TAG

Using Spring Cloud with Orchestration Tools Like Docker Swarm and Kubernetes

I have a cloud-native application, which is implemented using Spring Cloud Netflix.

Spring Cloud Netflix

So in my application, I'm using Eureka service discovery to manage all instances of different services of the application. When each service instance wants to talk to another, it uses Eureka to fetch the required information about the target service (ip and port for example).

Eureka

Eureka

The service orchestration can also be achieved using tools like Docker Swarm and Kubernetes, and it looks like there are some overlap between what Eureka does and what Docker Swarm and Kubernetes do.

Docker Swarm

Kubernetes

Eureka

Docker Swarm

Kubernetes

For example Imagine I create a service in Docker Swarm with 5 instances, and swarm insures that those 5 instances are always up and running. Additionally, each services of the application is sending a periodic heartbeat to the Eureka internally, to show that it's still living. It seems we have two layers of health check, one for Docker and another inside the Spring Cloud itself.

Docker Swarm

Eureka

Docker

Spring Cloud

Or for example you can expose a port for a service across the entire swarm, which eliminates half of the needs to have a service discovery (the ports are always apparent). Another example could be load balancing performed by the routing mesh inside the docker, and the load balancing happening internally by Ribbon component or Eureka itself. In this case having a hardware load balancer, leads us to a 3 layered load balancing system.

routing mesh

Ribbon

Eureka

So I want to know is it rational to use these tools together? It seems using them together increases the complexity of the application very much.

Thank you for reading!

3 Answers
3

Yes you are correct. We have a similar Spring Cloud Netflix application deployed on Oracle cloud platform and Predix Cloud Foundry. If you use multiple kubernetes clusters then you have to use Ribbon load balancing. Because then you have multiple instance for services.

Spring Cloud Netflix

Predix Cloud Foundry

I cannot tell you witch is better Kubernetes or Docker Swamr. We use Kubernetes for service orchestration as it provides more flexibility.

Kubernetes

Docker Swamr

Kubernetes

You are correct in that it does seem redundant. From personal observations, I think that each layer of that architecture should handle load balancing in its' own specific way. It ends up giving you a lot more flexibility for not much more cost. If you want to take advantage of client side load balancing and any failover features, it makes sense to have Eureka. The major benefit is that if you don't want to take advantage of all of the features, you don't have to.

The container orchestration level load balancing has a place for any applications or services that do not conform to your service discovery piece that resides at the application level (Eureka).

The hardware load balancer provides another level that allows for load balancing outside of your container orchestrator.

The specific use case that I ran into was on AWS for a Kubernetes cluster with Traefik and Eureka with Spring Cloud.

If you already have the application then there's presumably more effort and risk in removing the netflix components than keeping them. There's an argument that if you could remove e.g. eureka then you wouldn't need to maintain it and it would be one less thing to upgrade. But that might not justify the effort and it also depends on whether you are only using it for anything that wouldn't be fulfilled by the orchestration tool.

For example, if you're running services inside kubernetes internal kubernetes services that are not set up as load-balanced then you might want ribbon within your services. (You could do this using tools in the spring cloud kubernetes incubator project or its fabric8 equivalent.) Another situation to be mindful of is when you're connecting to external (non-kubernetes) services - then you might need to implement client-side rate limiting. You'll know how you're currently using spring cloud.

You've asked specifically about netflix but it's worth stating clearly that spring cloud includes other components and not just netflix ones. And that there's other areas of overlap where you would need to make choices.

I've focused on Kubernetes rather than docker swarm partly because that's what I know best and partly because that's what I believe to be the current direction of travel for the industry - on this you should note that kubernetes is available within docker EE. I guess you've read many comparison articles but https://hackernoon.com/a-kubernetes-guide-for-docker-swarm-users-c14c8aa266cc might be particularly interesting to you.

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.