Even though Spring Cloud Streams provide a simplified way of achieving a distributed reactive system, we still have to deal with the list of configurations (for example, the configuration of destinations) to deal with the specifics of the Spring Cloud Streams programming model, and so on. Another significant problem is reasoning about flow. As we may remember from Chapter 2, Reactive Programming in Spring - Basic Concepts, one of the main reasons for inventing reactive extensions (as a concept of asynchronous programming) was to achieve a tool that hides complex asynchronous data flow behind the functional chain of operators. Even though we can develop specific components and we can specify the interaction between components, the digging into the whole picture of the interaction between them might become a puzzle. Similarly, in reactive systems, understanding the flow interactions between microservices is a crucial part that is hard to achieve without specific tools.

Fortunately, Amazon invented its AWS Lambda in 2014. This expanded on new possibilities for reactive system development. This is mentioned on the official web page for that service:

AWS Lambda allows us to build small, independent, and scalable transformations. Moreover, we gained the ability to decouple the development life cycle of business logic from a particular data flow. Finally, a user-friendly interface allows us to use each function for building an entire business flow independently.

Amazon was a pioneer in that area, inspiring many cloud providers to adopt the same technique. Fortunately, Pivotal was one of the adopters of that technique as well.