I am exploring options to have Netflix Zuul as API Gateway for my Microservices in Cloud Foundry. I am not able to see Zuul option in CF marketplace (I see Apigee integration with CF Service Broker API). I wanted to use Netflix Zuul as API Gateway, If I spin up Zuul as regular application it goes behind HA Proxy/Go Router, I think that is not right thing to do. May be I should implement Service Broker API and create Zuul as a service in CF marketplace. Can someone please through some light on this.I it involved task to make Netfliz Zuul as a Service Broker in CF? I see Eureka in Market place but not Zuul. Dont know why it is like this.. Thank you.
That will be very helpful if you can come up with zuul managed service in PCF.
Currently what we do is we use spring boot + spring cloud application to develop api gateway. We have to use spring-cloud-starter-zuul dependency. Then ahead we need to register gateway app with Netflix Eureka service registry.
Lastly we refer registered Zuul api gateway in all our client api applications.
Good luck with cf marketplace Zuul managed service :)
Related
Currently, I want to introduce istio as our service-mesh framework for our microservices. I have played it sometime (< 1 week), and my understanding is that Istio really provides an easy way to secure service to service communication. Much (or all?) of Istio docs/article provides an example how client and server who have istio-proxy (envoy) installed as a sidecar container, can establish secure communication using mtls method.
However, since our existing client (which I don't have any control) who consume our service (which will be migrated to use istio) doesn't have istio, I still don't understand it well how we should do it better.
Is there any tutorial or example that provides my use case better?
How can the non-istio-based client use mtls for consuming our istio-based service? Think about using basic curl command to simulate such thing.
Also, I am thinking of distributing a specific service account (kubernetes, gcp iam service account, etc) to the client to limit the client's privilege when calling our service. I have many questions on how these things: gcp iam service account, istio, rbac, mtls, jwt token, etc contributes to securing our service API?
Any advice?
You want to add a third party to your Istio mesh outside of your network via SSL over public internet?
I dont think Istio is really meant for federating external services but you could just have an istio ingress gateway proxy sat at the edge of your network for routing into and back out of your application.
https://istio.io/docs/tasks/traffic-management/ingress/
If you're building microservices then surely you have an endpoint or gateway, that seems more sensible to me, try Apigee or something.
Context
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".
To name just a few of the options for service discovery that I've considered:
AWS Route 53 Service Registry
Kubernetes
Hashicorp Consul
Spring Cloud Netflix Eureka
Specifics Of My Stack
I am developing Java Spring Boot applications using Spring Cloud with the target deployment environment being AWS.
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.
Locally, we are using docker compose (not swarm) to deploy services - one of the containers deployed is a single node Eureka service discovery server.
However, when we progress outside of local development and into staging or production environment we are considering options like Kubernetes.
My Own Assessment Of Pros/Cons
AWS Route 53 Service Registry
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).
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.
AWS native, no managing service registries or extra "moving parts".
Spring Cloud Eureka
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.
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.
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.
Questions
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 https://kubernetes.io/docs/concepts/services-networking/service/#discovering-services
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.
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?
Possible Challenges I Anticipate
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.
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...
Final Note
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.
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.
In spring cloud dataflow, as per my understanding each stream is a microservice but the dataflow server is not. Am I right?
Is it possible to have multiple instances of spring cloud dataflow(SCDF) server? How to loadbalance the dataflow server? I am planning to deploy it in AWS.The official documentation didn't mention anything about loadbalancing of dataflow server. If it is possible how do Dashboard, shell works?
The SCDF-server is a regular Spring MVC + Spring Boot application that serves the REST-APIs, DSL commands, UI, and repository access for stream/task metadata persistence.
In platforms like Cloud Foundry, Kubernetes and others, upon scaling the SCDF-server, the platform automatically handles traffic routing and load-balancing.
If you were to orchestrate the deployment on your own and on AWS, you'd have to plug a load-balancer in front of the server instances. The shell, UI, and REST-APIs would hit the load-balancer instead, to interact with the SCDF-server.
I am now using spring cloud to build micro service application, and now I need to create service monitoring solution to dynamically check status for each micro-service.
I am not seeing this supported in spring cloud, but I did see NetFlix is providing Srvo, does anyone ever used it or can anyone give some good suggestions on what will be best solution to monitor status for all the micro-services?
Thanks
Spring Cloud Netflix adds servo metrics to the standard spring boot /metrics actuator endpoint. See Spring Boot Production Ready Metrics to see about a MetricRepository. Here is some documentation on using redis. See this project for an example configuration.
In some applications, I saw people are using #EnableEurekaClient. And some other example applications are using #EnableDiscoveryClient.
Is there any difference between these two?
There are multiple implementations of "Discovery Service" (eureka, consul, zookeeper). #EnableDiscoveryClient lives in spring-cloud-commons and picks the implementation on the classpath. #EnableEurekaClient lives in spring-cloud-netflix and only works for eureka. If eureka is on your classpath, they are effectively the same.
Discovery service concept in spring cloud is implemented in different ways like Eureka, consul, zookeeper etc. If you are using Eureka by Netflix then #EnableEurekaClient is specifically for that. But if you are using any other service discovery including Eureka you can use #EnableDiscoveryClient.
In terms of its practicality and simplicity, if the registered center is eureka, then #EnableEurekaClient is recommended. If it is another registration center, #EnableDiscoveryClient is recommended.
#EnableEurekaCient will initilize the service discovery using eureka server, its like explicitly specifying to use EUREKA
While #EnableDiscovery Client will register dicovery service using the jar available in classpath like consul, Eureka, Kubernetes.
#EnableEurekaClient works only for Eureka if we use #EnableDiscoveryClient we can use any discovery client like Consul other than Eureka