Spring Cloud and Kubernetes both claim to be the best environments for developing and running microservices, but they are very different in nature and solve different problems. In this article, we will look at how the two platforms can help build Microservice based Architectures (MSA), what they are good at, and how each can achieve success in the Microservice journey.

background

I recently read an excellent article by A. Lukyanchikov on building microservices architectures using Spring Cloud and Docker. If you haven’t read it yet, I recommend you read it. It provides a comprehensive description of how to create a simple microservice system using Spring Cloud. To build a scalable and resilient microservice system that can grow to dozens or even hundreds of services, it must be centrally managed with a multi-functional toolset (build time and run time). Spring Cloud provides functional services (such as statistics services, account services, and notification services) and infrastructure services (such as log analysis, configuration servers, service discovery, authentication services). The following diagram depicts MSA using Spring Cloud:

This diagram covers many aspects of system runtime, but not packaging, continuous integration, scaling, high availability, and self-repair, which are important in the MSA world. We assume that most Java developers are familiar with Spring Cloud, and in this article we’ll examine these additional issues to see how Kubernetes differs and relates to Spring Cloud.

The focus of microservices

Instead of doing a features-by-feature comparison, let’s take a higher level look at how Spring Cloud and Kubernetes address these issues as microservices should be focused on. The advantages and trade-offs of this architectural style of MSA are well known today. Microservices support Strong Module Boundaries, Independent Deployment, Technology Diversity, The trade-off, however, is the development of a Distribution system, Eventual Consistency, and significant Operational Complexity. Therefore, one of the key factors for success is to use off-the-shelf tools as much as possible to help you solve MSA problems as much as possible. It’s important to start development quickly and easily with MSA, but the process from project launch to final release is a long one, and here’s what you need to do to really take advantage of microservices.

  • Basic monitoring, instrumentation, health check
  • Distributed logging and tracing
  • For each service, it is not just the code that is isolated, but the entire build + test + package + roll-out
  • Upstream/downstream/compile time/run time dependencies can be clearly defined for each service
  • Know how to build, publish, and maintain good apis and contracts
  • Respect backward and forward compatibility, even if you are both a service provider and a consumer
  • Good unit testing skills and be ready to do more work (everything becomes more difficult with the addition of microservices, hence the need for more unit/contract/API test drivers and less E2E drivers)
  • Understand microservice VS module VS library, distributed single application, coordinated release, database-driven integration, etc
  • Learn about infrastructure automation (more here)
  • CI/CD infrastructure is available
  • Has or is ready to invest in development tools, shared libraries, internal Artifact registries, and more
  • Have engineering methodologies and process tools to break down functional requirements and implement/track/publish across multiple services (XP, Pivotal, Scrum, etc.)

There’s a lot that’s not currently thought of, but the point is — these are generally good engineering practices. For microservices, the engineering standards must be very high.

The list in the figure above contains the most common technical issues (excluding non-technical issues such as organizational structure, culture, and so on) that must be addressed in MSA. That’s my point, and it varies from organization to organization, but it’s mostly true.

Technology mapping

The two platforms are so different that there is no direct equivalence between them. If we map the concerns of each MSA to the solutions in these two platforms, we get the following table.

The main conclusions of the table above are:

  • Spring Cloud has a rich set of well-integrated Java libraries that solve all run-time problems. As a result, microservices can leverage class libraries and runtime proxies for client service discovery, load balancing, configuration updates, metrics tracking, and more. Singleton cluster services, batch jobs, and other patterns are also managed within the JVM.
  • Kubernetes is multilingual, not just for the Java platform, but for all other languages, providing a common solution to the problem of distributed computing. Outside of the application, it provides services for configuration management, service discovery, load balancing, tracking, measurement, singletons, scheduled jobs, and so on in a platform-based manner. Applications do not require any libraries or agents and can use any language.
  • In some areas, both platforms rely on similar third-party tools. Examples include ELK and EFK stacks, trace libraries, and so on.
  • Libraries such as Hystrix and Spring Boot are also useful in both environments. In some areas, the two platforms are complementary and can be combined to create a more powerful solution (KubeFlix and Spring Cloud Kubernetes are examples of this).

Microservice requirements

To illustrate the scope of each project, here’s a table that contains the (almost) end-to-end MSA requirements, starting with the hardware at the bottom, going to the DevOps and self-service experiences at the top, and how they relate to Spring Cloud and Kubernetes platforms.

In some cases, two projects use different approaches to meet the same requirements, and in some areas, one project may be more powerful than the other. But there is also a sweet spot where the two platforms complement each other and can be combined to achieve a great microservice experience. For example, Spring Boot provides Maven plug-ins for building individual JAR application packages. Combining Docker and Kubernetes declarative deployment and scheduling capabilities makes running microservices a breeze. Similarly, Spring Cloud has in-application libraries for creating resilient, fault-tolerant microservices using Hystrix (with bulkhead and breaker patterns) and Ribbon (for load balancing). But this is not enough, when combined with Kubernetes health check, process restart, and automatic extension capabilities, microservice becomes a truly robust system (antifragile System).

Advantages and disadvantages

Since the two platforms cannot be directly compared one by one, we did not delve into each project, but summarized the strengths and weaknesses of each platform.

Spring Cloud

Spring Cloud provides developers with the tools they need to quickly build common distributed systems such as configuration management, service discovery, circuit breakers, routing, and more. It is built on top of the Netflix OSS library and written in Java for Use by Java developers.

advantages

  • The unified programming model provided by Spring Platform and the rapid application creation capabilities of Spring Boot provide developers with an excellent microservices development experience. For example, you can create a configuration server with a few annotations, and add a few more to let the client library configure your service.

  • There are rich class libraries to choose from, covering most run-time issues. All libraries are written in Java and offer multiple features, better control, and optimization options.

  • The different Spring Cloud libraries integrate well with each other. For example, a Feign client will also use Hystrix to disconnect and the Ribbon to load balance requests. Everything is annotation-driven, easy to develop, and feels like a Java developer’s paradise.

disadvantages

  • One of the main advantages of Spring Cloud is also its disadvantage — it is limited to Java. A powerful driver of MSA is the ability to change the technology stack, libraries, and even the language as needed. This is not possible in Spring Cloud. If you want to replace configuration management, service discovery, load balancing, and other basic services of Spring Cloud/Netflix OSS, it’s hard to find an elegant solution. The Netflix Prana project implements the Sidecar pattern, exposing Java client libraries over HTTP, allowing applications written in non-JVM languages to exist in the NetflixOSS ecosystem, but it’s not very elegant. In addition, since I wrote this article, Pivotal has announced a new project called SteelToe, which also allows services to be discovered and configured using services from.NET clients.

  • Java developers have too much responsibility. Each microservice needs to run various clients for configuration retrieval, service discovery, and load balancing. They are easy to set up, but this does not hide the build-time and run-time dependencies on the environment. For example, I could easily create a configuration server using the @enableconFigServer annotation. But every time I want to run a single microservice, I need to start the configuration server. For a controlled environment, I have to make the configuration server highly available, and in order to support Git or Svn, I need to share the file system. Also for service discovery, I need to start Eureka Server first. For a controlled environment, I need to build clusters of multiple instances on each availability zone (AZ), and so on. It felt like as a Java developer, in addition to implementing all the functional services, I had to build and manage an extraordinary microservices platform.

  • Spring Cloud has a smaller footprint on the microservice journey, and you need to consider automated deployment, scheduling, resource management, process isolation, self-healing, building pipelines, and more to get a complete microservice experience. At this point, I don’t think it’s fair to compare Spring Cloud to Kubernetes alone, and it’s more fair to compare Spring Cloud + Cloud Foundry (or Docker Swarm) to Kubernetes. But it also means that for a full end-to-end microservices experience, Spring Cloud must add something like Kubernetes to it.

Kubernetes

Kubernetes is an open source system for automatically deploying, extending, and managing containerized applications. It is multilingual and provides basic functionality for configuring, running, extending, and managing distributed systems.

advantages

  • Kubernetes is a multilingual, general-purpose container management platform capable of running cloud native and traditional containerized applications. It provides services such as configuration management, service discovery, load balancing, metric collection, and log aggregation that can be used in multiple languages. This allows you to have a platform in your organization that can be used by multiple teams (including Java developers using the Spring framework) and serve multiple purposes: application development, test environments, build environments (running source control systems, building servers, Artifact Repositories), and so on.

  • Kubernetes addresses a broader range of MSA issues than Spring Cloud. In addition to providing runtime services, Kubernetes allows you to configure the environment, set resource constraints, RBAC, manage the application life cycle, enable automatic scaling, and self-repair (acting almost like an anti-vulnerability platform).

  • I can’t help but mention that The Kubernetes technology is based on Google’s 15 years of experience developing and managing containers. In addition, with nearly 1,000 contributors, it is one of the most active open source communities on Github.

disadvantages

  • Kubernetes is multilingual, so its services are generic and not optimized for different platforms (such as Spring Cloud for JVM). For example, the configuration is passed to the application as an environment variable or as a large number of file systems. It doesn’t have the fancy configuration updates that Spring Cloud Config provides.

  • Kubernetes is not a developer-centric platform. IT is intended for devOPs-conscious IT people. As a result, Java developers need to learn new concepts and be willing to learn new ways to solve problems. Although it is easy to start a development instance of Kubernetes using MiniKube, manually installing a highly available Kubernetes cluster incurs significant operational overhead.

  • Kubernetes is still a relatively new platform and is still under active development and growth. As a result, many new features are added with each release. The good news is that this problem has long been expected, and the API is extensible and backward compatible.

alliance between giants

As you can see, both platforms have advantages in some areas and need improvement in others. Spring Cloud is a quick-start, developer-friendly platform, while Kubernetes is DevOps-friendly and has a steep learning curve, but covers a wider range of microservices issues. Below is a summary of these points.

The two frameworks address different scopes of MSA problems, and they are implemented in completely different ways. Spring Cloud makes it easier for developers to solve problems, trying to solve each MSA challenge within the JVM, whereas Kubernetes tries to solve problems on the platform so developers don’t have to face them. Spring Cloud is very powerful inside JVMS, and Kubernetes is very powerful in managing those JVMS. So combining them and benefiting from the best parts of both projects feels like a natural process.

Through this combination, Spring provides application packaging, while Docker and Kubernetes provide deployment and scheduling. Spring provides in-application partitions through Hystrix thread pools, and Kubernetes provides partitions through resource, process, and namespace isolation. Spring provides health endpoints for each microservice, and Kubernetes performs health checks and routes access to healthy services. Spring externalizes and updates the configuration, and Kubernetes distributes the configuration to each microservice. The list goes on and on.

Above is my favorite micro service platform, how about it? Kids get multiple choice, adults get all of them, of course. I like the developer experience the Spring framework provides. It is annotation-driven and has libraries covering various functional requirements. I also like Apache Camel (In this case, Spring Integration) because it relates to application-level Integration, connectors, messaging, routing, resilience, and fault tolerance. However, FOR anything related to clustering and managing multiple application instances, I prefer the magic of Kubernetes. Whenever there is overlap, such as service discovery, load balancing, configuration management, I try to use Kubernetes.

The original link: developers.redhat.com/blog/2016/1…