https://kotlinlang.org logo
Join Slack
Powered by
is it really best practice to lookup services and ...
# vertx
a
is it really best practice to lookup services and write all that boiler plate code everytime - is there a way to hide that - so ppk can just 'instantiate' the service and just start calling it?
d
Use your orchestrator's (like Docker Swarm or Kubernetes) load balancing for services... I think there's an adapter in vertx for Kubernetes to auto detect services for SD.... there might be cases where you need to go manual a SD though... when some logic is involved in resolving that service.
a
Right - so lets say we go the kubernetes route - we have two services on two seperate clsuters with two seperate loadba;balancers
how do you detect those?
i can find examples on finding services if they are all behind one LB - but what if they are two separate services?
d
No, k8s round robins the requests to all the service duplicates using Services ClusterIp.. i really recommend DevOps Toolkit 2.3 book on leanpub if you want to learn k8s.. thats what got me going.. but Swarm is simpler, i dont think they have a plugin for it though. They both work that they have a dns entry for each service that makes the service name resolve to the ip of one of the service replicas in round robin way... Sorry for my unorganized writing, im on my way out right now 🙂
a
Right - i know the theory - i m looking for the nitty grotty implementations of registering the service and discovering and using it
If the service a is on instance 1,2 and service b are on instance 3,4 - it becomes a lot more difficult- specially when comparing them too the examples provided - which are all based on one node or one service - not two service in a distributed fashion
I dont think we are talking about the same thing lol
d
In swarm lets say, you create service a and b and attach them both to the same overlay network, swarm will take care of assigning ips wherever the instances are, and overlay network will route the requests to domain a (the name of the service has a dns entry like that) from service b, it doesn't matter where it is. That's one of the beauties of orchestration. I think SD was made before this existed, and is mainly for legacy systems or more complex resolutions. You should look up overlay networking in swarm or Services and ClusterIp for k8s to get a better idea... unless i didn't understand your question...
k
Do you mean vertx's built in clustering? The blueprints on the vertx site has an example of circuit breakers and vertx service calls if that's what you mean, but it was done before the days of spring cloud if you use vertx on top of spring.
a
@dave08 - are both those services in the same swarm (in ur explanation)?
d
Yes
a
@kenkyee those examples are all based on multiple instances of vertx on one node - i m looking for when the service is distributed fashion
@dave08 right so that’s the distinction - i m asking for each service being deployed in its own swarm - and then doing the discovery
d
Why let Vert.x handle that when Swarm/k8s does a better job, and handles other services that are not Vert.x?
Why have two swarms?
a
I’d rather use k8 myself - but i m stuck just at this final thing
k
Don't think so...vertx does auto clustering of verticles
a
Keep it separate - logging, Independent deploys - idk - i was always under the assumption there would always be a ‘new’ completely separate deploy for each new service
d
Right, it's also built for clustering and it does the job good for verticles, but for other services... I don't see what's the big advantage of Vert.x SD
a
Instead of just adding it to the same one each time
Next thing u know u have one swarm of 100 servers
d
You're currently using Swarm or k8s?
a
Instead of keeping each swarm for each service - keeping it in manageable chunks
Neither
I ve been reading about k8s a lot more than swarm
But i m open to options as long as they work lol
d
k8s is more powerful but more complex
☝️ 1
If your needs are simple, Docker Swarm is a nice start
a
Multiple swarms though?
d
No, unless you need one for staging and the other for production
Which is what we currently have
a
So u have one huge swarm?
d
Swarm takes care of smartly spreading your services in the cluster based on the resources of your physical nodes
Production: 10 servers, Staging: 6 servers, and growing
a
And everything is behind this one swarm veil?
d
No, one for staging and other for production..
but in k8s you could use namespaces instead
a
Right - so every production service is behind the huge production swarm?
d
Yes, and Swarm manages placement and communication of services
a
Maybe my initial premise is wrong - maybe orchestration isn’t supposed to be a new swarm per service
d
Right
a
And when u deploy one service - it just goes thru the veil and into the right ‘pods’
Or instances
k
Vertx can replace using zuul or istio or traefik but those are honestly a lot better.
d
You should really try out the DevOps Toolbox 2.1, 2.2 for swarm and 2.3 2.4 for k8s, they also give practical usage and good advice, workflows.. and hands-on step by step learning -- they're very good. Check out the sample chapters on leanpub to see if you like them
If it wouldn't have been for those books, I wouldn't have my clusters running so well today...
And the author is very friendly and helpful and has a slack
a
I m a little iffy about devops books tbh - they all seem a little too beginner and theoretical
How does the client hit the service then? If they are all in one swarm? Usually there would be a public facing load balancer and that would route it to the appropriate server
d
Like I said, check them out -- these are really good! They're very hands on, you run things and see the results - no on going theory - you try things as you learn https://docs.docker.com/network/network-tutorial-overlay/#walk-through
a
Alright - thank you 😊
3 Views
Open in Slack
PreviousNext
Powered by