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
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
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,
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
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
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
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
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
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
Spring Boot application, so that
Spring applications start faster and consume less memory. A
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 -
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
Azul, etc. These are all very good for
Spring, the foundation of
JDK is still very solid.
2. A JVM language with healthy competition
JDK does not only support
Java as a programming language, on the contrary, it can support a variety, such as
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
Kotlin. The integration of
Spring has penetrated into all aspects of the framework, such as
Spring Boot and
Spring Webflux support for
Kotlin Coroutines &
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,
Scala are also languages that are well integrated with
Because the three languages
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
The development of
Java language is still very fast, along with the development of
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),
Pattern Matching for instanceof,
sealed interface, etc.
Kotlin is not exactly for
JVM, it also includes
Kotlin support for
Android is currently the most characteristic and stable among many
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
Kotlin code can be compiled and exported to a variety of target platforms with better programs, such as the
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
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
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.
Scala are very friendly to functional programming, in this point are to make up for the shortcomings of
Java. In addition,
Scala also support
Serverless platforms based on
V8, such as
erverless platform. In addition,
Scala are also actively exploring
WebAssembly support, which are good news for supporting
Of course, there are many more
JVM languages, such as
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.
JVM languages that
Spring relies on out of the way, let’s talk about two very successful projects in
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
So why do
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 Cloud and
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
SpringMVC can support
HTTP REST API very well, and also includes support for
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.
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:
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:
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
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
So most of the current Java project projects will choose
Reactive framework, of course
Spring team developed
Reactor framework, adding
Kafka and other adaptations to ensure that from the bottom is asynchronous, so that is the reason for the name
The next scenario is what we all see,
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.
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
JDBC is a synchronous interface, so
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
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-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
MyBatis, etc. have added adaptations to
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 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
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
CloudEvents and messages in
Spring is much easier.
and enterprise integration-related products, such as
Alpakk based on
Spring Integration, etc., which all provide integration with
Reactive and can be said to work seamlessly with
Going back to the question of the article, why will
Spring remain one of the best platforms in the cloud-native era? To summarize,
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
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.