Back in 2015, the keynote at the SpringOne 2015 conference in Washington was Cloud Native Enterprise. The slogan of that conference was also Cloud Native and the posters were all over the place with Cloud Native.

You may wonder how you could call it Cloud Native when containers weren’t popular at that time. Although many people may not have the same understanding of Cloud Native, more and more people believe that “Cloud native is about culture, not containers”. It is a culture of software development, and even if there is a Serverless or WebAssembly FaaS platform based on V8 isolation, it is still in the realm of cloud native.

And in the trend of cloud-native, Spring has done a lot of things, such as supporting the distributed architecture of Spring Cloud, which is basically a necessary framework for Java applications to be distributed and cloud-based. Various cloud vendors have Spring Cloud docking versions, such as Spring Cloud Alibaba, AWS, Azure, GCP, etc. Spring Cloud greatly simplifies the docking of Java applications and cloud services.

It’s safe to say that the Spring ecosystem has been at the forefront of the growing popularity of microservices. Many of you may wonder: we know all these previous achievements of Spring, but there seems to be no development in the last two years, can Spring continue to lead the technology trend?

In fact, the reason for this confusion is that when we talk about cloud-based and cloud-native environments for development, the general focus is more on the choice of technology stack, and the main issue behind this is the cost.

Every developer or small and medium-sized company wants to buy fewer cloud resources to do more things, the most important of which are memory and CPU. memory consumption requirements are small, try to choose some lightweight development framework if it can be compiled into a standalone executable; and consider a framework with efficient and fully asynchronous language, which can ensure full use of CPU and avoid waste caused by threads waiting, etc.

On balance, many people would prefer technology stacks such as Rust, Node.js, and Golang. And Java is slow to start, consumes a lot of memory, seems to be more expensive, and seems to be less suitable for the next cloud-native era.

So as the Spring ecology based on the Java language, can it still adapt to new development methods such as Cloud Native, Serverless, Faas, etc., and will it still be the best choice of platform in the cloud-native era?

Next, I’ll break this down for you from 5 perspectives: the evolution of Java and JDK, a JVM language full of healthy competition, Spring Boot and Spring Cloud for mature service-oriented architectures, and Spring Reactive for making event-driven architectures easier to use.

1. Development of Java and JDK

We know that Spring is based on the Java framework, and that the JDK is the foundation for running Java programs. To explore the question “will Spring be one of the best platforms for cloud-native”, we need to see how the JDK base is and whether it provides a good foundation for Spring to evolve with the times.

The first is version iteration. Now the development speed of OpenJDK is very fast, before it was a major version in three years, now it is a version in half a year. Many users lament that it is almost Java 17 and they are still using Java 1.8. We all say that software development should be small steps, this is a good way to develop: small steps, fast feedback, rapid iterative development. Similarly there is JavaScript a year a version, TypeScript a year three versions, Java a year two versions, can be said to be a very good pace.

The second is the update of JDK features. If you pay attention to the JDK, it is easy to find that more and more features are being incorporated into the JDK, such as the lightweight thread Loom project that resembles a concurrent thread, the Panama project that improves the support for Native calls (SIMD support), the more advanced GC algorithm, and so on.

In response to the Java slow startup and memory consumption problems we mentioned earlier, Oracle has introduced GraalVM based on OpenJDK, which can run JavaScript, Python, Ruby and other languages directly in JVM, a veritable Ployglot JVM. In addition, GraalVM also provides the Native Image feature, which can convert Java code into standalone executable programs. Spring has also introduced the Spring Native project, which makes it very easy to native-image a Spring Boot application, so that Spring applications start faster and consume less memory. A native-imageized Spring application will meet the needs of every developer or small and medium-sized company that wants to be cloud-based and less expensive. Even for Java command line applications, GraalVM has a very good solution - Picocli + GraalVM Native Image + upx, which compiles Java applications into more convenient executables.

The following chart shows the list of GraalVM multilingual and Native Image support, as follows.


In addition, various cloud vendors are also active in JDK development, such as AliJDK, Amazon Corretto, Azul, etc. These are all very good for JDK development.

So, for Spring, the foundation of JDK is still very solid.

2. A JVM language with healthy competition

The JDK does not only support Java as a programming language, on the contrary, it can support a variety, such as Kotlin, Scala, Groovy, etc. Here we call it a JVM language in unison. At present, JVM languages are in a state of healthy competition.

We know that each language has its own usage scenario that it is good at. In the cloud native era, multi-language development support is very important and developers need to choose different development languages based on the actual business scenario. Both the JVM languages and the languages supported by GraalVM can be directly integrated with Spring, making it easy for developers to make full use of the Spring technology stack for development.

One of the best language support for Spring is Kotlin. The integration of Kotlin and Spring has penetrated into all aspects of the framework, such as Spring Boot and Kotlin integration, Spring Webflux support for Kotlin Coroutines & Flow, Spring Data, SpringIntegration, SpringCloud Function, etc. also include support for Kotlin, these all achieve deep integration of Kotlin, the purpose is to make the language and framework better combined to improve development efficiency. In addition, Kotlin and Scala are also languages that are well integrated with Spring.

Because the three languages Java, Kotlin and Scala are very well integrated in Spring, I will specify them next to help you have a clearer perception of the current development of the JVM language.


The development of Java language is still very fast, along with the development of OpenJDK, Java will launch a version in half a year, and each version will be accompanied by syntax upgrade, standard library upgrade, etc., which greatly facilitates the developers. From Java 9 to 16, many syntax and feature enhancements have been completed, such as the var keyword (local variable type derivation), Text block, Pattern Matching for instanceof, Record, sealed interface, etc.


Although Kotlin is not exactly for JVM, it also includes Native, JavaScript, etc., but Kotlin support for JVM and Android is currently the most characteristic and stable among many Kotlin platforms.

Now Kotlin is growing very fast and has incubated several sub-projects, such as the latest Kotlin Multiplatform Mobile (one set of code to support multiple mobile platforms), Kotlin Compose for Desktop (one set of code to develop desktop applications for multiple operating systems) and so on. Of course, the most notable of these changes is the introduction of Kotlin intermediate representation (IR) in Kotlin 1.5. With the new IR, Kotlin code can be compiled and exported to a variety of target platforms with better programs, such as the Kotlin WebAssembly.


Scala 2 was released in March 2006, which is a very long time ago. The good news is that Scala 3.0 has been released in May, 2021. Scala 3 adds new features while removing some obscure features from Scala 2, with the aim of making Scala better to use. If you are interested, you can keep an eye on the official website of Scala3.

Another core change in Scala 3 is the adjustment of the compiler, named TASTy, which stands for Typed Abstract Syntax Trees, with the following structure:


With the help of TASTy, there is already Scala.js and it is not surprising that Scala WebAssembly will follow.

Kotlin and Scala are very friendly to functional programming, in this point are to make up for the shortcomings of Java. In addition, Kotlin and Scala also support JavaScript compiled output, which is very helpful for Serverless platforms based on V8, such as Cloudflare’s Serverless platform. In addition, Kotlin and Scala are also actively exploring WebAssembly support, which are good news for supporting Web development.

Of course, there are many more JVM languages, such as Groovy, Clojure, etc., which are also actively developing. These JVM languages compete with each other and learn from each other, which is all very good news for developers.

With the JDK and JVM languages that Spring relies on out of the way, let’s talk about two very successful projects in Spring, SpringBoot and Spring Cloud.

Spring Boot and Spring Cloud are two very successful projects that are basically used by Internet companies based on the Java technology stack. In addition, if you have been following Springs top evangelist Josh Long’s talks recently, you will see that he has been talking about Spring Reactive and he has written a book called <<Spring Reactive>>

So why do Spring Boot, Spring Cloud and Spring Reactive get so much attention?

We know that there are two very important architectural solutions for cloud native, one is service-oriented architecture and the other is event-driven architecture. The service-oriented architecture is usually based on a synchronous request/response model, which is the goal of Spring Boot and Spring Cloud to support this feature; the event-driven architecture is based on an asynchronous message model and message routing, which is the core of the Spring Reactive project to support this architecture.

Next, I’ll show you exactly how Spring supports these two important architectural solutions in cloud-native, and with that, you’ll also get a clearer picture of the three important projects in Spring, Spring Boot, Spring Cloud and Spring Reactive.

3. Mature Service-Oriented Architecture for Spring Boot and Spring Cloud

Usually, applications under cloud-native are inclined to microservice design, and the core elements of microservice design are service-oriented architecture design and application programming interface (API) management. Spring Boot and Spring Cloud aim to support this feature, and these two projects have been so successful that Internet companies based on the Java technology stack are basically using them.

We know that the most typical structure of a service-oriented interface is the request/response pattern, especially the Request/Response pattern for the Web. Of course, remote RPC request/response is also in this category, such as HTTP REST, gRPC and Dubbo.

Corresponding to the service oriented architecture design in Spring, SpringMVC can support Web and HTTP REST API very well, and also includes support for OpenAPI. Other RPC classes of communication are also supported by the corresponding Spring Boot starter and there is a corresponding starter component in Spring Boot which makes development very easy. If you want to expose other forms of services, such as Web Service and SOAP traditional services, you can also reach them through the Spring Web Services (spring-ws) project.

Another feature, API management, is mainly related to service governance and service consumer invocation, and the corresponding core technology stack is mainly the Spring Cloud project. The Spring Cloud provides various basic settings for service architecture and API management, such as service registration discovery, complex balancing, API Gateway, break protection, etc. These technology stacks facilitate better management and governance of services, and also allow better invocation of services on the consumer side.

Putting it all together, the typical architecture for service-oriented architecture and API management, corresponding to the Spring Boot and Spring Cloud technology stacks, is as follows:

Spring Cloud

If your architecture is service-oriented, such as involving service orchestration, service governance and API Gateway, then Spring Cloud is a very good choice, with complete features, stable framework, good documentation and hands-on experience such as Alibaba. If your company is based on Java technology stack, then Spring Cloud is the best support and practice to implement microservice architecture.

Alibaba has open sourced Spring Cloud Alibaba since July 2018, and as of today, it has gained over 19,000 STARs, which is already more than all other implementations combined. As we can see from the <<2020 Open Source Digitization in Microservices Report>> published by X-lab Open Labs, Spring Cloud Alibaba has become the most active and popular Spring Cloud implementation with the most complete tool chain. You can consider it in your selection process.

3. Making Event-Driven Architecture Easier to Use with Spring Reactive

While we talked about Spring’s support for service-oriented architecture earlier, there is another architectural pattern, which is event-driven architecture. Event-driven architecture is widely considered to be the preferred architectural solution for cloud natives, so how does Spring support this? This brings us to the Spring Reactive project, the core of which is supporting event-driven architecture.

Spring Reactive is geared towards asynchronous messaging, messaging or events is the premier architectural pattern for the Enterprise Integration Pattern (EIP), you may have heard of the Spring Enterprise Integration (SpringIntegration) project, which is primarily responsible for enterprise integration. The purpose of Spring Reactive is to make event-driven architecture design the preferred application architecture, and to make it simpler.

Here’s an aside: I’ve talked to some senior Spring Boot and Spring Cloud programmers, and they’re all very familiar with various service-oriented interface designs, even down to the code level details, but when it comes to the Enterprise Integration Pattern (EIP), they all say it’s Martin Fowlers famous masterpiece, and when asked if they use things like Apache Camel or Spring Integration in their systems, they all say the service-oriented architecture is now meeting business needs.

So here is a question, so well-known EIP, ESB or EDA why not adopted in the architecture design? Is the threshold too high, or is it just a pure theory, completely out of practice?

In the service-oriented architecture design, it is basically based on the service interface invocation, and the invocation is synchronous, so service orchestration and API management play a very important role. Of course, in the service-oriented architecture design, we will also introduce some message-driven design, with the help of Kafka or other MQ systems, to deal with some asynchronous or data analysis scenarios, such as sending an email after user registration, triggering events for security audit after user login, triggering incremental indexing of search engines after product information or price modification, triggering various notifications after users place orders, etc.

Service-oriented has its benefits, but there are very many problems to solve, such as non-blocking, service registration and discovery, high performance, and easy integration, which is why many experts have proposed that event-driven architecture is the mainstream in cloud-native scenarios.

Event-driven architectures don’t involve service registration and discovery as the responsible mechanisms, message-based routing is easy, asynchronous messaging is higher performance (and of course your bill is smaller), various SaaS services are simpler to integrate (EventBridge products), FaaS triggers are easy, and so on. If you want to learn more, check out the book <<Building Event-Driven Microservices>>. Here is a posting of Redhat’s recommended event-driven architecture design based on microservices thinking, as follows:

Building Event-Driven Microservices

From this diagram we can see that all interactions between systems are communicated through messages. Instead of an interface-oriented request/response design that handles Request/Response requests from different applications, microservices are constantly processing messages from Brokers in an asynchronous manner.

At this point, you may understand that if Cloud Native is centered on event-driven design architecture, then Spring Reactive aims to make event-driven architecture easy to use and convenient to develop, which is the same as Spring Boot and Cloud's support for service-oriented architecture. In addition these two architectures are not contradictory, they can coexist and complement each other.

To achieve a better event-driven architecture, two foundations are missing: asynchronization and messaging. Asynchronization can solve the problem of thread waiting, while the message and its message routing, can be a good way to achieve loose coupling of applications. Currently more and more products use asynchronous messaging solution, a variety of messaging products middleware since needless to say, we are familiar with the HTTP/2 are based on asynchronous message communication.

So why asynchronization? We know that the model of message processing and synchronous service calls are different, such as the Event Loop and Actor model of message processing, both of which are very efficient ways of processing messages, and if we have to deal with synchronous service calls based on thread pools in the process of message processing, it will inevitably affect the model and performance. Of course it is not completely impossible to have synchronization, just try to avoid too many scenarios of synchronous service calls.

There is a lot of work to be done in Spring around asynchronization and messaging scenarios, and we all know that Java is very lagging behind on asynchronization support. Java 1.8 added the CompletionStage interface, Java 9 added Reactive Stream support intervened with Flow. Everyone has been concerned about the lightweight threaded Loom project is still under development and is expected to be released until Java 17.

So most of the current Java project projects will choose Reactive framework, of course Spring team developed Reactor framework, adding Reactor to Netty, Kafka and other adaptations to ensure that from the bottom is asynchronous, so that is the reason for the name Spring Reactive.

The next scenario is what we all see, Spring Webflux, Spring Integration, Spring Data and many other projects have added support for asynchronization, all these adjustments, is to ensure that from the bottom is fully asynchronous, you can understand the 5G non-independent networking and independent networking two You can think of it as both non-standalone and standalone networking for 5G, but Spring has chosen the Reactive standalone networking, standalone ecological approach, and of course the workload is very large. This involves two very big problems: database and distributed communication.

Currently most NoSQL products provide an asynchronous interface, asynchronous access to NoSQL products without any problems. Although NoSQL is developing rapidly, it still hasn’t shaken the position of database, we all know that the specification of database access in Java is JDBC, but JDBC is a synchronous interface, so Spring started R2DBC project, the purpose is to be able to access the database with Reactive asynchronous interface, at present, the experience of using JDBC and R2DBC in The experience of using JDBC and R2DBC under the Spring framework is almost the same.

Here I synchronize two news with you: Spring 5.3 has built-in R2DBC support, that is spring-r2dbc, and spring-jdbc side by side. We all like to use MySQL database, also launched mariadb-r2dbc 1.0.0 stable version, Oracle also launched R2DBC version of the driver. Of course the DB framework in Java, Spring JPA, MyBatis, etc. have added adaptations to R2DBC. Hibernate also launched hibernate-reactive project (based on Vert.x database), although not based on R2DBC, but is also fully asynchronous.

Another issue is distributed communication, which plays a very important role in the microservices architecture. Spring has always mainly supported HTTP, but the HTTP protocol is mainly designed for browsers and the advantages of communicating between back-end services are not obvious, and there is no performance advantage. Of course gRPC based on HTTP/2 asynchronous messaging is a good choice, but Spring has never had built-in gRPC support, but of course this is not a big problem for most developers, and the third-party grpc-spring-boot-starter does a very good job

If you follow Spring releases you should know that subsequent versions of Spring 5.2 have chosen the RSocket communication protocol and built RSocket into the spring-message project. Why? RSocket is a fully asynchronous binary messaging protocol that provides a complete communication model and is peer-to-peer, which is a good match for event-driven architectures, which is why Spring Reactive has incorporated RSocket into the core of Spring. Spring and Ali team plays a leading role.

There is a CloudEvents specification under CNCF, which mainly addresses event communication in heterogeneous systems. Messages and events are consistent in data structure, both are Headers and Payload(data) structures, and include message header extensions. With the latest cloudevents-java SDK 2.1, Spring messaging adds support for CloudEvents and supports codec support for the CloudEvent interface, unifying and integrating messages and events to be handled in Spring. CloudEvents and messages in Spring is much easier.

and enterprise integration-related products, such as Apache Camel, Alpakk based on Akka, MuleSoft’s Mule 4, Spring Integration, etc., which all provide integration with Reactive and can be said to work seamlessly with Spring Reactive.

5. Summary

Going back to the question of the article, why will Spring remain one of the best platforms in the cloud-native era? To summarize, Java and JDK development is in a very good place, and the JVM language is growing and competitive. Mature Spring Boot and Spring Cloud have made service-oriented architecture design easy to use, and Spring Reactive has made event-driven architecture more accessible while allowing more enterprise systems to complete interfacing with Spring Reacitve, whether it’s an IoT device, ESB products, SaaS or cloud services, etc.

For microservices scenarios, Spring Cloud provides a mature architecture-oriented service foundation, and Spring Reactive is an event-driven architecture for the future, not to say, of course, that service-oriented architecture is obsolete, in fact service-oriented architecture is very successful, but in a cloud-native or new Serverless environment, it may make more sense to have an event-driven architecture, or to use both together, don’t worry, Spring does a great job in both areas.