Even though the Spring Cloud ecosystem is aimed at building reactive systems using the Spring Framework, the reactive programming paradigm did not pass Spring Cloud by. First of all, such changes have affected an entry point of a distributed system, called gateways. For a long time, the only Spring module that made it possible to run an application as a gateway was the Spring Cloud Netflix Zuul module. As we may know, Netflix Zuul is based on a Servlet API that uses blocking synchronous request routing. The only way to paralyze the process's requests and obtain better performance is through tuning the underlying server thread pool. Unfortunately, such a model does not scale as well as the reactive approach, and the details of why this occurs are covered in Chapter 6, WebFlux Async Non-Blocking Communication.

Fortunately, Spring Cloud introduces the new Spring Cloud Gateway module, which is built on top of Spring WebFlux and offers asynchronous and nonblocking routing with the support of Project Reactor 3.

Apart from the new Gateway module, Spring Cloud Streams obtained the support of Project Reactor and also introduced a more fine-grained streaming model. We are going to cover Spring Cloud Streams in Chapter 8, Scaling Up with Cloud Streams.

Finally, to simplify the development of reactive systems, Spring Cloud introduces a new module called Spring Cloud Function, aimed at providing essential components for building our own function as a service (FaaS) solutions. As we will see in Chapter 8, Scaling Up with Cloud Streams, the Spring Cloud Function module cannot be used in ordinary development without proper additional infrastructure. Fortunately, Spring Cloud Data Flow offers such a possibility, and includes part of the Spring Cloud Function's capabilities. We will not go into the details of Spring Cloud Function and Spring Cloud Data Flow here, as they are covered in Chapter 8, Scaling Up with Cloud Streams.