Spring Cloud is a framework that helps implementing a Microservices architecture (with common patterns and practices, like Runtime Configuration, Tracing, Circuit Breaker, Service Discovery, and so on), but it has nothing to do with "Cloud", right?
Microservices and Cloud are a good match when combined, but Spring Cloud helps with microservices, not with cloud. Am I right?
My question is: wouldn't Spring Microservices be a better name for Spring Cloud?
I don't want to change its name, I just want to be sure that I understand the framework correctly.
For the record, "Spring Cloud Netflix" or "Spring Cloud Amazon" would be well named, because they do help with the integration of those specific Cloud platforms.
Well, probably people from Pivotal responsible for naming can give you the good answer, I can only speculate.
In my understanding, Spring Cloud is set of tools that allow (mainly spring boot driven) application to be written in "Cloud Native" way. When you run in the cloud, it makes sense to protect the application with Circuit breaker, to use service discovery in a way that scaling out the various parts of the system will work seamlessly, and so on and forth.
Now, spring boot application don't necessarily run in the cloud, in fact its possible to run spring boot app on your "personal" (on-premise) server.
Spring boot applications are not restricted to run microservices as well, its possible to run monoliths with spring boot as well. In fact there are many monolith application that use spring under the hood.
Now, can you take tools from spring cloud and use them for applications not running in the cloud? Yes of course you can. Can you benefit from these tools? Probably yes, but not so much if you run one microservice on one on-premise server (I'm exaggerating but still).
Probably (again a speculation) it will be correct to say that the more your environment "resembles" the cloud (public cloud, private or hybrid) - the more benefits you'll see from using these tools. Hence the name :)
The Spring Cloud library is a general-purpose tool for the implementation of distributed systems.
Spring Cloud provides tools for developers to quickly build some of the common patterns in distributed systems (e.g. configuration management, service discovery, circuit breakers, intelligent routing, micro-proxy, control bus, one-time tokens, global locks, leadership election, distributed sessions, cluster state)
The microservice architecture is not necessarily built on cloud technologies, such as Amazon and might be run on the self-hosted servers.
Moreover, it's true that the microservice architecture is based on the "architectural patterns" such as service discovery, API gateway, sidecar-proxies etc., however it doesn't mean that it is the only architecture that can benefit from these characteristics.
I believe the name Spring Cloud was chosen well since it is focused on the implementation of distributed systems.
Related
I am working on PoC of connecting legacy Spring application to Kafka. It is war application to be deployed in Tomcat, Spring version 4.3.12. Is there some library to make communication with Kafka almost as easy as with Spring Boot? I need just fundamental operations: sending message, listening for confirmation, receiving.
I have some experience with Spring Boot support as is provided in org.springframework.kafka:spring-kafka library. I am not sure how to efficiently adopt Kafka for legacy Spring - I'm thinking of using Kafka Java client which looks promising but as I am used to working at Spring Boot abstraction level I don't have clue how much code should I supply myself.
Web search is not much helpful in this case since it tends to show Spring Boot-related solutions. Migration of legacy application is considered too, I just need to have some idea how difficult each way is.
kafka-clients is all you need (from Maven Central, not Confluent). You could go a step further and look into Log4j2 Kafka bridge, then property files for that.
If you want to externalize config into regular Java .properties file, you can, or you can pull values from environment variables, if you follow 12-factor principles.
But if you don't already have Spring Boot dependencies, then I do not think adding them is worth it for only Kafka.
Also, the Spring-Kafka documentation covers how to configure your app without Boot.
I was reading about spring cloud architecture and technologies (like eureka, hystrix circuit breaker) used to prevent your application from downtime because of failure of some of yours microservices. And all in all spring cloud suggests to use Spring Cloud Gateway as an entry point to all the micro services. So I am questioning myself how to provide fault tolerance of spring cloud gateway itself? As I see right now if this entry point will fail then all these technologies like eureka and hystrix circuit breaker will not be available since they are implemented on the level of spring cloud gateway. Now when spring cloud gateway is down - all clients will not be able to reach all services behind spring cloud gateway. So how to deal with such kind of situations?
I don't think this is directly related to Spring Cloud Gateway, to be honest. The question is more "How to deploy highly available Java application?" (SCG is a Spring application).
The answer depends on the platform you use.
Most of IAAS platforms provide their own infrastructure load balancers, like ALB / ELB in AWS.
PAAS platform usually include out of the box LB , e.g. Cloud Foundry or Kubernetes can do that for you.
DNS is probably not the best choice for the reasons you've described - TTL and client caching. Also, DNS doesn't really have a way to do a health check of an upstream service. So using DNS requires client-side load balancing, when the client needs to be smart and invalidate cache / retry if a request failed.
I am using Spring Cloud for Creating Microservice Architecture.
I was using the below feature from the Spring Cloud
Zuul – API gateway service that provides dynamic routing, monitoring, resiliency, security, and more -
Ribbon – Client side load balancer
Feign – Declarative REST client
Eureka – Service registration and discovery
Sleuth – Distributed tracing via logs
Zipkin – Distributed tracing system with request visualization.
Hystrix - Circuit Breaker, Fault Tolerance, Hystrix Dashboard for all API
Now Lets say if I have 100 microservices, then we need 100 servers to maintain each microservices. So I thought of using Kubernetes to solve this issue by deploying each microservices in a separate docker container, so now since Kubernetes takes care of microserivice health check, autoscaling, load-balancing so do I need to again use Ribbon, Eureka and Zuul.
Can anyone please help me on this
Even when you use Spring Cloud, 100 services do NOT mean 100 servers. In Spring Cloud the packaging unit is Spring Boot application and a single server may host many such Spring Boot applications. If you want, you can containerize the Spring Boot applications and other Spring Cloud infrastructure support components. But that is not Kubernetes.
If you move to Kubernetes, you don't need the infrastructure support services like Zuul, Ribbon etc. because Kubernetes has its own components for service discovery, gateway, load balancer etc. In Kubernetes, the packaging unit is Docker images and one or more Docker containers can be put inside one pod which is the minimal scaling unit. So, Kubernetes has a different set of components to manage the Microservices.
Kubernetes is a different platform than Spring cloud. Both have the same objectives. However, Kubernetes has some additional features like self healing, auto-scaling, rolling updates, compute resource management, deployments etc.
Just to add to saptarshi basu's answer, you might want to look at https://dzone.com/articles/deploying-microservices-spring-cloud-vs-kubernetes as it walks through the comparison and asks which responsibilities you might want to be handled by which components when using Spring cloud on kubernetes
spring boot actuator exposes /metrics endpoints. but it produces a value only when combined with monitoring tools, diagrams, alerting etc. so:
does spring-boot provides support for push-based metrics collection? if so, what's the tool?
or maybe there are some production-ready tools (with service registry etc) that work with spring-boot in pull-based manner and actually use the /metrics endpoint? for example prometheus perfectly discovers all EC2 instances but is incompatible with spring boot metrics (counters and format).
so is there any real world, production ready tools that can be used out of the box? or we're not there yet?
I have an application written in Java that performs some straightforward but time consuming calculations analysing some texts, printing results to the terminal. I want to speed up the process by deploying that application on a cloud and letting it be calculated there. Which cloud service allows for such deployment with minimal change of code?
Most cloud computing servers are designed to host web applications (Servlets mostly). I'm guessing your application is not a web application. You could write a simple web application that wraps around your application and uses some kind of messaging layer to distribute the load. You could then deploy on any of the major cloud sites (e.g. GAE, AWS, CloudFoundry).
Alternatively, you can find an existing cloud framework such as Amazon MapReduce (link is to a ppt describing the tool) and fit your application into that framework. This would probably be the fastest approach, especially if you don't have much experience with Servlets.