I just think:if our projects all modules,what ever what languege dev,we all use spring cloud sidecar as a proxy remote call,is it a good idea? or is not? so our business code do not need any micro framework. if course ,we can deploy business code and sidecar on the same server,so business code call sidecar do not need much time.
istio plaform do this job inside docker container, not the same as this advise?
Related
We have load balancing, discovery, etc in the Spring cloud. But the same load balancing, discovery is available in Kubernetes as well. So just wanted to know when we should go with Spring cloud (load balancing or discovery) and when to use Kubernetes
It depends on your use-case. There can be situations where you need to directly use Eureka server registry and Eureka client discovery offered by Spring Cloud Netflix. Ribbon is the client side load balancer provided by Spring Cloud Netflix.
In my experience, it is not impossible to use Eureka in any environment. It can be your local data centre or cloud infrastructure. However when it comes to deployment environment, there are so many alternatives for us to achieve the server registry mechanism. Sometimes those alternatives are the best solutions. I will give you an example below...
If you host your application in your local server (Local data centre)
Now in this scenario you can use Eureka and continue your server registry and discovery mechanism. (That is not the only way. I mentioned Eureka for this scenario because it would be a good use case for it)
If you host your application in AWS infrastructure
The AWS environment gives you lots of benefits and services such that you can forget the burden of maintaining and implementing Eureka. You can achieve simply the same behaviour by AWS load balancers, AWS target groups and even more by adding AWS auto scaling groups. In AWS it self there are so many other ways to achieve this as well.
Long story in short that for your scenario, you can continue using the power of Kubernetes and get the privilege unless you have a specific reason to use Eureka and put a large effort to implement it. You should select what suits the best depending on time, effort, maintainability, performance etc.
Hope this helps for you to get an idea. Happy coding!
I am learning building microservices using spring boot, Spring Cloud(netflix OSS Components). I have used netflix Eureka for service discovery, zuul for api gateway, ribbon, feign while running in my local machine.
Netflix eureka, zuul, ribbon, feign spring cloud config are not useful when we deploy to PCF?(if yes what are the alternatives available in pcf and how to configure them?)
As who are building microservices follows CI/CD approach, how developer verify working of their micro services before pushing code as we don't use eureka, zuul,ribbon,feign in production pcf. (how to simulate pcf environment in developer machine?).
I'd suggest to read below content before implementing if you have any doubt regarding usage of Eureka and Zuul, you will get all answers yourself.
https://github.com/Netflix/eureka/wiki/Eureka-at-a-glance
https://github.com/Netflix/zuul/wiki
As who are building microservices follows CI/CD approach, how developer verify working of their micro services before pushing code as we don't use eureka, zuul,ribbon,feign in production pcf.
Answer to this question is: You must be aware of JUnit test cases, so you can run you test cases using deployment pipelines to make sure all your functionalities are working as expected or you can use Test Automation for the same.
(how to simulate pcf environment in developer machine?).
Answer to this one:
You can use eclipse plugin you are using eclipse/STS IDE. Or you can connect all PCF services from you local machine using CloudFactory
#Bean
public Cloud cloud() {
return new CloudFactory().getCloud();
}
https://docs.pivotal.io/pivotalcf/2-1/buildpacks/java/sts.html
Here are some thoughts:
Eureka Service discovery: in my opinion this is not strictly necessary when running on PCF. When you push an app on PCF usually a route is assigned to your app, and you can use this Route as a poor man's service discovery. Eureka would allow you to use client-side load balancing in the case of container-to-container networking, but usually you wouldn't need this.
Zuul: Can be very useful also on CloudFoundry in case you are doing things like writing frontend-for-backend services, providing frontends for different devices (mobiles, desktops, i-pads) that use the same backend services. Might also be useful for an authentication/authorization layer or rate-limiting. One native CloudFoundry alternative would be to use route-services for tasks such as rate limiting, authentication/authorization.
spring-cloud-config: makes sense if you want your configuration to be under version control for different environments. This is useful no matter if you are running on CloudFoundry or not. I don't know of any alternatives on plain CloudFoundry.
spring-cloud-feign: makes sense if you want use annotations such as #RequestMapping with your Feign client interfaces. This is independent on if you are running on CloudFoundry or not. AFAIK there are no alternatives for this in case you want to use Spring MVC annotations with Feign.
ribbon: makes sense if you want to use client side load balancing as opposed to let the CloudFoundry router to do the load balancing for you.
How developers can check locally if this works for them:
In general, I don't believe developers should need to check locally if their app is working fine together with zuul, cloud-config-service, and eureka.
They could check this in a dev or test space or environment though.
If they really want to check this on their local machine, they could download PCFDev and run these infrastructure components there.
Hope this helps.
I'm confused with cloud/clustering technologies like Docker Swarm and Spring Cloud and how they relates to each other.
Is it correct way to thing, they implement same functionality at different layers? For example docker swarm performs load balancing and service discovery at container or network layer (application is agnostic of this layer), where as framework like Spring Cloud embeds this logic to application, giving more flexibility, but also violating separation of concerns.
Am I mistaken, or is this correct? What is the SWOT of each approach, and is there any reason to use both Docker tooling and Spring Cloud utilities together?
First off, Spring and Docker are two different technologies coming from different points of view. From what I can gather, Spring Cloud is a mechanism for deploying java containers and orchestrating them.
Docker is an application / OS agnostic deployment mechanism.
I don't know much about Spring Cloud, but if you're in an environment that is not all Java, it may make more sense to approach Docker. It would allow you to deploy micro services on just about any platform.
We went through this at the last company I worked for, as they were implementing Springboot, but also looking at Docker at the same time. In the end it just made sense to deploy everything in Docker since it provided a uniform deployment and service management mechanism. That as opposed to hobbling together various deployment and management tools by language.
It seems like that spring cloud sidecar just can be used to discover Eureka instances,but how to register via spring cloud sidecar?
Thanks in advance for the help.
When Sidecar starts up it will ping the health_url that is in the configuration to see if the non-Java application is up. If it is then Sidecar registers that app with Eureka. If you read the Sidecar documentation in detail it gives you specific examples. The non-Java app doesn't try to register itself.
Is Spring cloud config server an example of sidecar application for microservices?
Do you mean if the Spring Cloud Config Server itself is what the Spring Cloud documentation labels as Sidecar? Then no, as far as I know it is just a plain, regular Spring Boot app.
A Sidecar as referred to in Polyglot support with Sidecar is a Spring Boot application that acts as a bridge between your service infrastructure and a service that is not written in a JVM language. Apps written in Python, Go, Ruby, C#, NodeJS, Erlang or really any other language that can bind something to a port come to mind.
The benefits of the Sidecar are, that your Non-JVM apps
service discovery become automatically discoverable through Eureka, which means that JVM services can resolve the host:port/<service-id> of the Non-JVM apps as well as the other way around,
monitoring are monitorable through the same health-endpoints-infrastructure that is available in Spring Boot (Actuator), i.e. by manually providing the health endpoint in the Non-JVM app Eureka knows when the Non-JVM service is down
routing/proxying query the services by either manually looking up their hosts/ports or proxying these requests through Zuul, which in turn resolves their current addresses through Eureka
balancing be load balanced by Ribbon and
configuration may consume configuration properties provided via Spring Cloud Config.
I hope this answer addresses your question, if not (or someone finds it to be inaccurate or misleading) just let me know and I delete it to make room for something more suitable. ;-)