0% found this document useful (0 votes)
366 views

Spring Cloud For Microservices Compared To Kubernetes

Comparation

Uploaded by

tujthevux
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF or read online on Scribd
0% found this document useful (0 votes)
366 views

Spring Cloud For Microservices Compared To Kubernetes

Comparation

Uploaded by

tujthevux
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF or read online on Scribd
You are on page 1/ 12
= RedHat MENU = Developer Istio Quarkus Kubernetes CI/CD Serverless Java Linux Microservices Di BLOG ARTICLES Spring Cloud for Microservices Compared to Kubernetes By Bilgin Ibryam December 9, 2016 Spring Cloud and Kubernetes both claim to be the best environment for developing and running Microservices, but they are both very different in nature and address different concerns. In this article we will look at how each platform is helping in delivering Microservice based architectures (MSA), in which areas they are good at, and how to take best of both worlds in order to succeed in the Microservices journey. Background Story Recently | read a great article about building Microservice Architectures With Spring Cloud and Docker by A. Lukyanchikov. If you haven't read it, you should, as it gives a comprehensive overview of what it takes to create a simple Microservices based system using Spring Cloud. In order to build a scalable and resilient Microservices system that could grow to tens or hundreds of services, it must be centrally managed and governed with the help of a tool set that has extensive build time and run time capabilities. With Spring Cloud, that involves implementing both functional services (such as statistics service, account service and notification service) and supporting infrastructure services (such as log analysis, configuration server, service discovery, auth service). A diagram describing such a MSA using Spring Cloud is below: ~ 2 e 2 i é MSA with Spring Cloud (by A. Lukyanchikov) This diagram covers the runtime aspects of the system, but doesn’t touch on the packaging, continuous integration, scaling, high availability, self healing side which are also very important in the MSA world, Assuming that the majority of Java developers are familiar with Spring Cloud, in this article we will draw a parallel and see how Kubernetes relates to Spring Cloud by addressing these additional concerns. Develop using Red Hat's most valuable products Your membership unlocks Red Hat products and technical training on enterprise cloud application development. JOIN RED HAT DEVELOPER heed RedHat OpenShift Microservices Concerns Rather than doing a feature by feature comparison, let's take a look at wider Microservices concerns and see how Spring Cloud and Kubernetes approach those. A good thing about MSA today is that it is an architectural style with well understood benefits and trade-offs. Microservices enable strong module boundaries, independent deployment and technology diversity, but they come at the cost of developing distributed systems and significant operational overhead. As such, it is a key success factor to bet on and be surrounded by tools that will help you address as much MSA concern as possible. Quick and easy start is important, but the journey to production is a long one, and you need to be this tall to get there. Microservices Concerns In the diagram above, we can see a list with the most common technical concerns (we are not covering the non-technical concerns such as organisation structure, culture and so on) that has to be addressed in a MSA. That is my opinionated view which will vary for different organizations, but for the most part, it should apply to everybody. Technology Mapping The two platforms are very different and there is no direct feature parity between them. If we map each MSA concern to the technology/project used to address it in both platforms, we come up with the following table. Configuration Management Config server, Consul, Netfa Acai Kuernetes Conan & Secrets ‘Service Discovery Neti Eureka, Hasicorp Cons Kubernetes Service ngs Resources toad Balancing Neti ibbon Kaernetes Serve ‘ricateway Netix Zul Kuberretes Serie & Ingress Resoures Service Seeurty Spring Clow Suri entrazed Loesing Euxstack (Logs) eretack ued) Centraiaed Metis Net Spctator & Alas oops, Prometheus, Gafana Ditrbuted Tracing ‘Spring leu Sleuth, Zpin (pentracng, Zin Aestence & aut Tolerance Nettie sri Turbine Rison Kubernetes Heath Check esourcs lion ‘Ato Sealing & Se Healing - Kubernetes Heath Cheek, Sf MeaingAutscalng Packaging Deployment & Scheduling Spring Boot Docker, Kubeenetes Scheduler & Deployment ob Management Sing atch ‘berets obs 8 Scheduled bs ‘Singleton Applation Sorig loud Caster aberetes Pods Spring Cloud and Kubernetes Technologies The main takeaways from the above table are: * Spring Cloud has a rich set of well integrated Java libraries to address all runtime concerns as part of the application stack. As a result, the Microservices themselves have libraries and runtime agents to do client side service discovery, load balancing, configuration update, metrics tracking, etc. Patterns such as singleton clustered services, batch jobs are managed in the JVM too. Kubernetes is polyglot, doesn’t target only the Java platform, and addresses the distributed computing challenges in a generic for all languages way. It provides services for configuration management, service discovery, load balancing, tracing, metrics, singletons, scheduled jobs on the platform level, outside of the application stack. The application doesn't need any library or agents for client side logic and it can be written in any language. In some areas both platforms rely on similar third party tools. For example the ELK and EFK stacks, tracing libraries, etc. Some libraries such as Hystrix, Spring Boot are useful equally well on both environments. There are areas where both platforms are complementary and can be combined together to create a more powerful solution (KubeFlix and Spring Cloud Kubernetes are such examples). Microservices Requirements In order to demonstrate the scope of each project, here is a table with (almost) end- to-end MSA requirements starting from the hardware in the bottom, up to the DevOps and self service experience at the top and how it relates to Spring Cloud and Kubernetes platforms. DevOps Experience: ‘Auto Scaling & Set Resilen ‘ault Tolerance Distributed Tracing Contra Genvraized Logging API Gateway Job Manage rics soyomsqny ‘Singleton Application 0% neing Service Discovery Configuration Management poly Sulids Application Packaging Deployment & Scheduling Process Isolation Environment Management see} Microservices Requirements In some cases both projects address the same requirements using different approaches and in some areas one project may be stronger than the other. But there is also a sweet spot where both platforms are complementary to each other and can be combined for a superior Microservices experience. For example Spring Boot provides Maven plugins for building single jar application packages. That combined with Docker and Kubernetes declarative Deployments and Scheduling capabilities makes running Microservice a breeze. Similarly, Spring Cloud has in-application libraries for creating resilient, fault tolerant Microservices using Hystrix (with bulkhead and circuit breaker patterns) and Ribbon (for load balancing). But that alone is not enough, and when it is combined with Kubernetes health checks, process restarts and auto-scaling capabilities turns Microservices into a true antifragile system. Strengths and Weaknesses Since both platforms are not directly comparable feature by feature, rather than digging into each item, here are the advantages and disadvantages of each platform summarised Spring Cloud Spring Cloud provides tools for developers to quickly build some of the common patterns in distributed systems such as configuration management, service discovery, circuit breakers, routing, etc. It is build on top of Netflix OSS libraries, written in Java, for Java developers. Strengths * The unified programing model offered by the Spring Platform itself, and rapid application creation abilities of Spring Boot, give developers a great Microservice development experience. For example, with few annotations you can create a Config Server, and few more annotation you can get the client libraries configure your services. There is a rich selection of libraries covering the majority of runtime concerns. And since all libraries are written in Java, it offers a multiple features, greater control and fine tuning options. The different Spring Cloud libraries are well integrated with one another. For example a Feign client will also use Hystrix for Circuit Breaking, and Ribbon for load balancing the requests. Everything is annotation driven, easy to develop and feels like a heaven for Java developers. Weaknesses * One of the major advantages of the Spring Cloud is also its drawback — it is limited to Java only. A strong motivation for the MSA is the ability to change technology stacks, libraries and even languages when required. That is not possible with Spring Cloud. If you want to consume Spring Cloud/Netflix OSS infrastructure services such as configuration management, service discovery, load balancing, the solution is not elegant. The Netflix Prana project implements the sidecar pattern to exposes Java based client libraries over HTTP to make it possible for applications written in Non-JVM languages exist in the NetflixOSS eco-system, but it is not very elegant. In addition, since I have written this article, Pivotal has announced a new cool project called SteelToe , which allows consuming Service Discovery and Config Server services from .Net clients too. * There is too much responsibility for Java developers to care about and the Java applications to handle. Each Microservice needs to run various clients for configuration retrieval, service discovery and load balancing. It is easy to set those up, but that doesn't hide the build time a runtime dependencies to the environment. For example, I can create a Config Server with @EnableConfigServer annotation easily, but that is only the happy path. Every time | want to run a single Microservice, | need to have the Config Server up and running. For a controlled environment | have to think about making the Config Server highly available and since it can be backed by Git or Svn, | need shared file system for it. Similarly for service discovery I need to start Eureka Server first. For a controlled environment, | need to cluster it with multiple instances on each AZ, etc. It feels like as a Java developer I have to build and manage a not trivial Microservices platform in addition to implementing all the functional services. * Spring Cloud alone has a shorter scope in the Microservices journey, and you will also need to consider automated deployments, scheduling, resource management, process isolation, self healing, build pipelines, etc. for a complete Microservices experience. For this point, I think it is not fair to compare Spring Cloud alone to Kubernetes, and a more fair comparison would be between Spring Cloud + Cloud Foundry (or Docker Swarm) and Kubernetes . But that also means that for a complete end-to-end Microservices experience, Spring Cloud must be supplemented with something like Kubernetes itself. Kubernetes Kubernetes is an open-source system for automating deployment, scaling, and management of containerized applications. It is polyglot and provides primitives for provisioning, running, scaling and managing distributed systems. Strengths * Kubernetes is a polyglot and generic container management platform that is capable of running both cloud native and traditional containerised applications. The services it provides such as configuration management, service discovery, load balancing, metrics collection, log aggregation are consumable by variety of languages. This allows having one platform in the organisation that can be used by multiple teams (including Java developers using Spring framework) and serve multiple purposes: application development, testing environments, build environments (to run source control system, build server, artifact repositories), etc. When compared to Spring Cloud, Kubernetes addresses a wider set of MSA. concerns. In addition to providing runtime services, Kubernetes also lets you provision environments, set resource constraints, RBAC, manage application lifecycle, enable autoscaling and self healing (behaving almost like an antifragile platform). I cannot resist myself to mention that Kubernetes technology is based on Google's 15 years of R&D and experience of managing containers. In addition, with close to 1000 committers, it is one of the mast active Open Source communities on Github. Weaknesses * Kubernetes is polyglot and as such its services and primitives are generic and not optimised for different platforms such as Spring Cloud for JVM. For example configurations are passed to applications as environment variables or amounted file system. It doesn’t have the fancy configuration updating capabilities offered by Spring Cloud Config Kubernetes is not a developer focused platform. It is intended to be used by DevOps minded IT personnel. As such, Java developers need to learn some new concepts and be open for learning new ways of solving problems. Despite it being super easy to start a developer instance of Kubernetes using MiniKube,, there is a significant operation overhead to install a highly available Kubernetes cluster manually. Kubernetes is still a relatively new platform (2 years old) and itis still actively developed and growing. Therefore there are many new features added with every release which may be difficult to keep up with. The good news is that, this has been envisaged, and the API is extensible and backward compatible. Best of Bath Worlds As you have seen both platforms have strengths in certain areas, and things to improve upon on other areas. Spring Cloud is a quick to start with, developer friendly platform, whereas Kubernetes is DevOps friendly, with a steep learning curve, but covering a wider range of Microservices concerns. Here is a summary of those points. Strengths Sat Weaknesses Unified programing model with Spring framework Main functionality limited to Java platform Feature rch collection of Java libraries Lot's of responsibilty for Java devs and the application stack ‘Well integrated Java libraries Does not cover full microservices life cycle Strength Kubernetes Weaknes Polyglocand generic platform based on containers A generic platform with coarse grained primitives Covers fall microservces lifecycle Operations focused platform Cutting edge technology and large community _Actively developed and rapidly changing Strengths and Weaknesses Both frameworks address different range of MSA concerns, and they do it ina fundamentally different way. Spring Cloud approach is trying to solve every MSA challenge inside the JVM by making it easy for developers to solve it, whereas Kubernetes approach is trying to make the problem disappear for the developers by solving it at platform level. Spring Cloud is very powerful inside the JVM, and Kubernetes is powerful in managing those JVMs. As such, it feels like a natural progression to combine them and benefit from best parts of both projects Capability Spring Cloud with Kubernetes Devoe per enes Seif service, wulti-envirohwent capabilities TARO Sealing & Self Healing | Pou/eluster Autosealer, Wealthindicator, Scheduler Resilience & Fault Tolerance | Wealthindicator, Hystrix, Healthcheck, Process check Distributed Tracing Zipkin centralized Netrics ieapater, Pronetheus, Grafana Centralized Lopging er Bob wanagenent Soring batch, scheduled Job Toad Balancing Ribbon, service Terviee Discovery service Configuration ranagesent Exterpalized Configurations, configiay, Secret Servie Logie Apache Camel, Spring Fraxenork ‘Application Packaging Spring ook maven plugin Deployment. seneduiang | —Deplaynent etratesy, A/B, canary, scheduler strateay Process Isclation Docker, Pods Evironment Nanegeeest Tiasipaces, Aathorizations nesource Managenent CPU ad onory Linite, namespace resoure Tas SCE, Azure, CenturyLink, Wiware, Open Spring Cloud backed by Kubernetes With such a combination, Spring provides the application packaging, and Docker and Kubernetes provides the deployment and Scheduling. Spring provides in-application bulkheading through Hystrix thread pools, and Kubernetes provides bulkheading through resource, process and namespace isolation. Spring provides health endpoint for every microservice, and Kubernetes performs the healthchecks and traffic routing to healthy services. Spring externalizes and updates configurations, and Kubernetes distributes the configurations to every Microservice. And this list goes on and on. kubernetes My Favourite Microservices Stack What about my favourite Microservices platform? | like them both. I like the developer experience offered by the Spring framework. It is all annotation driven, and there are libraries covering all kind of functional requirements. | also like Apache Camel (rather that Spring Integration in this case) for anything to do with integration, connectors, messaging, routing, resilience and fault tolerance at application level. Then for anything to do with clustering and managing multiple application instances | prefer the magical Kubernetes powers. And whenever there is an overlap of functionality, such as for service discovery, load balancing, configuration management, | try to use the polyglot primitives offered by Kubernetes. About the author: Bilgin Ibryam is an Apache Camel committer, integration architect at Red Hat, a software craftsman and blogger. He is an open source fanatic, passionate about distributed systems, messaging and application integration. He is the author of Camel Design Patterns & instant Apache Camel Message Routing books. Deploying Microservices on OpenShift using Kubernetes You've heard o heard of OpenShift. You've heard of roservices. You've Stop nghenment Kubemetes. Actually, you may al jerable experience with The rise of non-microservices Why Java is so hot right now architectures each of t Categorized In Containers, Java, Kubernetes, Microservices, Spring Boot Tags Recent Posts Get started with Nodejs 14 on Red Hat OpenShift Let's collaborate! Take the 2020 Red Hat OpenShift Developer Survey now Securely connect Quarkus and Red Hat Data Grid on Red Hat OpenShift Checkpointing Java from outside of Java Building modern CI/CD workflows for serverless applications with Red Hat OpenShift Pipelines and Argo CD, Part2 Support for IBM Z and more in CodeReady Workspaces 2.4 Quarked testing: Writing tests for Quarkus Static analysis with KubeAudit for Red Hat OpenShift Migrating C and C++ applications from Red Hat Enterprise Linux version 7 to version 8 Install a signed certificate with Open Liberty 20.0.0.10's Automatic Certificate Management Environment Support 2.0 Top Posts How to install Python 3 on Red Hat Enterprise Linux Top 10 must-know Kubernetes design patterns How to install Java 8 and 1! on Red Hat Enterprise Linux 8 Introduction to Linux interfaces for virtual networking Podman and Buildah for Docker users Feeds RSS ATOM LOGIN TO ADMIN YOUR BLOG \ FEATURED TOPICS RED HAT DEVELOPER 7 Build here. Go anywhere. problem solvers who create Enterprise Java careers with code. Linux Microservices Join us if you're a developer, DevOps software engineer, web designer, front-end designer, UX designer, computer \ BUILD scientist, architect, tester, product manager, project Getting Started Center manager or team lead Developer Tools Hosted Che IDE Interactive Tutorials Sign me up Container Catalog Operators Marketplace Certify Applications Red Hat on Github QUICKLINKS: Whet's new DevNation events Upcoming Events Books Cheat Sheets Videos Products \ COMMUNICATE Site Status Dashboard Report a website issue Report a security problem Helping during COVID-I9 About us Contact Copyright © 2018 Red Hat Inc & Privacy Statement | Terms of Use | Allpolicies and guidelines

You might also like