Spring Cloud
Kubernetes


Background story

The article







MSA with Spring Cloud (by A. Lukyanchikov)








Microservice concept

An architectural style for evaluating strengths and weaknesses
Comes at a cost
Significantly increase operating costs
At this height







Microservices concerns








Technology matching







Spring Cloud and Kubernetes technologies








  • Spring Cloud has a rich collection of fully integrated Java libraries to implement various runtime concepts as part of the application stack. Therefore, these microservices have their own libraries and runtime proxies for client-side service discovery, load balancing, configuration updates, measurement tracking, and so on. Patterns, such as single cluster services and batch tasks, are also managed by the JVM.
  • Kubernetes is compatible with multiple languages, targets more than the Java platform, and implements distributed computing challenges for all languages in a common way. It provides platform-level and off-stack services such as configuration management, service discovery, load balancing, tracking, measurement, singletons, and scheduling tasks. Applications do not require any libraries or proxies to implement client logic and can be written in any language.
  • In some areas, both platforms rely on similar third-party tools. For example, ELK and EFK stacks, trace libraries, etc. Some libraries, such as Hystric and Spring Boot, are useful on both environments. There are areas where the two platforms complement each other and together create a more powerful solution (KubeFlix and Spring Cloud Kubernetes are examples of this).


Microservice requirements







Microservices requirements








Advantages and disadvantages


Spring Cloud






advantage


  • The unified programming model provided by the Spring platform itself, coupled with Spring Boot’s ability to create applications quickly, can give developers a lot of experience in microservices development. For example, with very few tags, you can create a configuration server, and with a few more tags, you can get a client library to configure your service.
  • There are a number of libraries to choose from that cover most runtime concepts. Because all libraries are written in Java, it offers more features, greater control, and better consistency options.
  • Different Spring Cloud libraries work well together. For example, The Feign client can also use Hystrix as a fuse, and the Ribbon as a request load balancer. Each one is tag-driven, making it easy for Java developers to develop.



disadvantages


  • One of the main advantages of Spring Cloud is also its disadvantage, namely that it is java-only. The strong goal of MSA is to be able to interchange technology stacks, libraries, and even languages if necessary. That’s not possible with Spring Cloud. If you want to consume Spring Cloud/Netflix OSS infrastructure services such as configuration management, service discovery, or load balancing, the solution is not very elegant. The Netflix Prana project implements the Sidecar pattern, making Java client libraries HTTP based, allowing applications written in non-JVM languages to exist on NetflixOSS, but it’s not very elegant.
  • Java developers have a lot of things to focus on, Java applications have a lot of things to deal with. Each microservice needs to run various clients for configuration recovery, service discovery, load balancing, and so on. These clients are easy to set up, but they do not hide the build-time and run-time dependencies of the environment. For example, a developer can create a configuration server with the @enableconFigServer tag, but this is the only path. Every time developers want to run a single microservice, they need to get the configuration server up and running. For a controlled environment, developers have to consider making the configuration server highly available, and because it can be supported by Git or Svn, they also need a shared file system. Similarly, for service discovery, the developer first needs to start a Eureka server. For a controlled environment, they need to cluster with multiple instances on each AZ. This is similar to how Java developers need to build and manage a non-trial microservice platform in addition to implementing all the functional services.
  • Spring Cloud alone will not go far on the microservice journey. In a complete microservice experience, developers need to consider automated deployment, scheduling, resource management, process isolation, self-healing, build pipelining, and more. At this point, I don’t think it’s fair to compare Spring Cloud to Kubernetes alone. A more fair comparison would be Between Spring Cloud + Cloud Foundry (or Docker Swarm) and Kubernetes. But that also shows that for a complete end-to-end microservices experience, Spring Cloud needs to complement an application platform, like Kubernetes.


Kubernetes






advantage


  • Kubernetes is a language-insensitive container management platform that can run native cloud applications and traditional container applications. It provides services such as configuration management, service discovery, load balancing, measurement collection, and log aggregation that can be used in a variety of languages. This allows organizations to provide a single platform for multiple project teams (including Java developers using Spring) and for multiple purposes: application development, test environments, build environments (running resource control systems, build servers, human warehouses), and so on.
  • Kubernetes implements a broader set of MSA concepts than Spring Cloud. In addition to providing runtime services, Kubernetes also allows us to provide environment variables, set resource limits, RBAC, manage the application lifecycle, and enable automatic scaling and self-healing (acting like an anti-vulnerability platform).
  • Kubernetes’ technology is based on Google’s 15 years of research and development experience in managing containers. On top of that, there are nearly 1,000 committers, making it almost the most active project in the open source community on GitHub.



disadvantages


  • Kubernetes is multilingual, so its services and primitives are universal, unlike Spring Cloud for JVMS, which are not optimized for different platforms. For example, the configuration is passed to the application through environment variables or a mounted file system. It does not have the sophisticated configuration update capabilities that Spring Cloud configurations provide.
  • Kubernetes is not a platform for developers. IT is intended for devOPs-minded IT people. As a result, Java developers need to learn new concepts and be more open to learning new ways to solve problems. No matter how easy it is to deploy a Kubernetes development instance using MiniKube, there are significant operational costs associated with manually installing a highly available Kubernetes cluster.
  • Kubernetes is still a relatively new platform (2 years old), and it is still under active development and growth. So each release has many new features that make it hard to keep track. The good news is that this problem has been addressed and the API has been made extensible and backward compatible.


Best practices for both platforms







Strengths and weaknesses













Spring Cloud backed by Kubernetes













My favorite microservices stack






Like both






Original link:Deploying Microservices: Spring Cloud vs. Kubernetes(Translation: Chi Jianfeng)