Spring Cloud or Kubernetes both claim that they are the best environments for developing and running microservices, which is better? The answer is both, but they have their own different ways of characterizing them.
Background Story Recently, Lukyanchikov published an article
on building a microservices architecture using Spring Cloud and Docker . It gives a comprehensive overview of how to create a simple microservice based system using Spring Cloud. To build a scalable microservice system that can scale to tens or hundreds of services, it must be centrally managed and managed with a toolset with a broad build-time and run-time capability. Spring Cloud includes implementing functional services (such as statistics service, account service and notification service) and supporting infrastructure services (such as log analysis, configuration server, service discovery, authorization service). These services cover the runtime aspects of the system, but do not cover packaging, continuous integration, scaling, high availability and self-healing, which are also very important in the MSA (Microservice Architecture) world. Assuming that most Java developers are familiar with Spring Cloud, in this article, we will draw a parallel diagram to understand the relationship between Kubernetes and Spring Cloud by addressing these additional concerns. The good thing about MSA is that it has the benefit of an architectural style that is well understood, and microservices enable strong module boundaries with independent deployment and technical diversity. But at the cost of developing a distributed system and significant operational overhead. A key success factor is the use of various tools to address these issues. Microservices focus Microservices focus on: configuration management, service discovery and load balancing, resiliency and failure redundancy, API management, security services, centralized logging, centralized Measurement, distributed tracing, scheduling deployment, and automatic scaling of self Healing. According to these points, two platform mappings of Spring Cloud and Kubernetes are drawn:
1. Configuration Management: Configuration Server, Consul and Netflix Archaius (Spring Cloud); Kubernetes ConfigMap & Secrets;
2. Service Discovery: Netflix Eureka, Hashicorp Consul (Spring Cloud); Kubernetes Service & Ingress Resource;
3. Load Balancing: Netflix Ribbon (Spring Cloud) ; Kubernetes Service
4. API Gateway: Netflix Zuul (SpringCloud); Kubernetes Service & Ingress Resource
5. Security Service: SpringCloud Security
6. Centralized log: ELK Stack (LogStash); EFKstack (Fluentd).
7. Centralized measurement: Netflix Spectator & Atlas; Heapster, Prometheus, Grafana.
8. Distributed tracing: SpringCloud Sleuth, Zipkin; OpenTracing, Zipkin
9. Resilience and failure redundancy: Netflix Hystrix, Turbine&Ribbon; Kubernetes Health Check&resource isolation
10. Automatic scaling self Healing: Spring Cloud none; Kubernetes Health Check, SelfHealing, Autoscaling
11 .Package deployment and scheduling deployment: Spring Boot; Docker/Rkt, Kubernetes Scheduler&
12. Task work management: Spring Batch; Kubernetes Jobs & Scheduled Jobs
13. Single application: Spring Cloud Cluster; Kubernetes Pods
Spring Cloud has a rich set of well-integrated Java libraries that solve all runtime problems as part of the application stack. Thus, the microservice itself acts as a proxy through the library and runtime to perform client-side service discovery, load balancing, configuration updates, metrics tracking, and more. Patterns such as singleton cluster services and batch jobs are also managed in the JVM.
Kubernetes is polyglot, targeting not only the Java platform, but addressing distributed computing challenges in a common way for all languages. It provides platform level features such as configuration management, service discovery, load balancing, tracing, metrics, singletons, platform scheduling jobs, etc. outside the application stack. The application system does not require any libraries or agents for client logic, it can be written in any language.
In some ways, both platforms rely on similar third-party tools. For example, ELK and EFK stacks, tracing libraries and some libraries like Hystrix and Spring Boot are equally useful in both environments.
In some cases the two platforms are complementary and can be combined to create a more powerful solution, for example, Spring Boot provides a Maven plugin for building a single JAR application package. Combining the declarative deployment and scheduling capabilities of Docker and Kubernetes makes running microservices a breeze. Similarly, Spring Cloud has application libraries for creating resilient, fault-tolerant microservices using Hystrix (circuit breaker) and Ribbon (for load balancing). But this alone is not enough, when it is combined with Kubernetes' health checks, process restarts and autoscaling features, microservices become a truly anti-fragile system.
Strengths and Weaknesses
Since the two platforms don't have directly comparable characteristics, here's a point-by-point summary of their strengths and weaknesses.
Spring Cloud provides developers with tools to quickly build some common patterns in distributed systems, such as configuration management, service discovery, circuit breakers, routing, and more. It is for Java developers and is built on top of the Netflix OSS library.
Advantages
1. The unified programming model provided by Spring Platform and the rapid application creation capabilities of Spring Boot provide developers with a huge microservice development experience. For example, with few annotations you can create a config server, and with few more annotations you can get a client library to configure your service.
2. There is a rich library selection, covering most runtime concerns. Since all libraries are written in Java, it offers a variety of features, better control and fine-tuning options.
3. Different Spring Cloud libraries are fully integrated with each other. For example, Feign clients will also use Hystrix for circuit breakers and Ribbon for load balancing requests. Everything is annotation driven, making it easy to develop for Java developers.
Weakness
1. One of the main advantages of Spring Cloud is its disadvantage - it is limited to Java. The power of MSA is the ability to exchange various technology stacks, libraries, and even languages when needed. It's not possible just using Spring Cloud. If you want to use Spring Cloud/Netflix OSS infrastructure services (like configuration management, service discovery or load balancing) then the solution is less elegant. The Prana project at Netflix implements the sidecar pattern by exposing the Java client over HTTP, making it possible to allow non-JVM languages to run in the NetflixOSS ecosystem, but it is not very elegant.
2. Java developers care about Java applications and need to deal with too many things that are not related to development. Each microservice needs to run various clients for configuration retrieval, service discovery and load balancing. While easy to set up, this doesn't reduce build time and runtime dependencies on the environment. For example, developers can use @EnableConfigServer to create a config server, but that's just a happy illusion. Whenever a developer wants to run a single microservice, they need to have the Config Server up and running. For a controlled environment, developers must consider making Config Server highly available, and since it can be backed by Git or Svn, they need a shared filesystem. Similarly, for service discovery, developers need to start the Eureka server first. To create a controlled environment, they need to implement a cluster with multiple instances on each AZ. Like developers, Java developers must build and manage a non-trivial microservices platform in addition to implementing all functional services.
3. Spring Cloud has only a short course in the development process of microservices. Developers also need to consider automated deployment, scheduling, resource management, process isolation, self-healing, building pipelines, etc. to obtain a complete microservice experience. For this, I think this is an unfair comparison, Spring Cloud + Cloud Foundry (or Docker Swarm) and Kubernetes should be compared. But it also means that for a complete end-to-end microservices experience, Spring Cloud must be complemented by an application platform like Kubernetes itself.
Kubernetes is an open source system for automating the deployment, scaling and management of containerized applications. It is multilingual and provides an operating system for provisioning, running, scaling and managing distributed systems.
Advantage
1. Kubernetes is a polyglot and language-agnostic container management platform capable of running cloud-native and traditional containerized applications. Its services such as configuration management, service discovery, load balancing, metrics collection, and log aggregation are available in various languages. This allows to have a single platform in an organization that can be used by multiple teams (including Java developers using Spring) and serves multiple purposes: application development, test environments, build environments (running source control systems) , build servers, artifact repositories), etc.
2. Kubernetes solves a broader MSA problem than Spring Cloud. In addition to providing runtime services, Kubernetes also lets you prescribe the environment, set resource limits, RBAC, manage application lifecycle, enable autoscaling and self-healing (almost behave like an anti-fragile platform).
3. Kubernetes technology is based on Google's 15 years of R&D experience and experience in managing containers. Also, with nearly 1000 committers, it is one of the most active open source communities on Github.
Weakness
1. Kubernetes is polyglot, so its services are generic and not optimized for different platforms (like Spring Cloud for JVM). For example, the configuration is passed to the application as an environment variable or a mounted filesystem. It doesn't have the fancy configuration update capabilities that Spring Cloud Config provides.
2. Kubernetes is not a developer-centric platform. It is intended to be used by DevOps IT staff. Therefore, Java developers need to learn some new concepts and be open to learning new ways of solving problems. Manually installing a highly available Kubernetes cluster has a significant operational overhead.
3. Kubernetes is still a relatively new platform (2 years old) and it is still actively developing and growing. As a result, each release adds so many new features that it can be hard to keep up. The good news is that this has been taken into account and the API will be extensible and backward compatible.
the best of both worlds
As you can see, the two platforms have strengths in some areas and leave room for improvement in others. Spring Cloud is a quick-start developer-friendly platform, while Kubernetes is DevOps-friendly with a steeper learning curve but covers a wider range of microservices concerns.
The two frameworks address a different range of MSA concerns, and they do so in a fundamentally different way. The Spring Cloud approach tries to solve every MSA challenge in the JVM whereas the Kubernetes approach tries to solve the problem for the developer by solving it at the platform level. Spring Cloud is very powerful inside the JVM and Kubernetes is very powerful in managing those JVMs. Combine them and benefit from the best parts of both projects.
With this combination, Spring provides application packaging, while Docker and Kubernetes provide deployment and scheduling. Spring provides application firewall through Hystrix thread pool, Kubernetes provides firewall through resource, process and namespace isolation. Spring provides health endpoints for each microservice, and Kubernetes performs health checks and routes traffic to healthy services. Spring takes care of externalizing and updating the configuration, and Kubernetes distributes the configuration to each microservice.
Spring Cloud for Microservices Compared to Kubernetes
http://www.jdon.com/48605