So. . ., we just heard about scale-to-zero capabilities and how they support new serverless apps from Sebastien… let’s look at one of the approaches you can take to implement these serverless apps - using java functions (Supplier, Function, Consumer) and Spring Cloud Function framework.
But before I get all techy and functional on you let’s talk about something important, something that will help us to better understand the value of functions - ice-cream!
Why is ice-cream so important? Well I for one have never met a person who doesn’t like some kind of ice cream. It is something that easily connects people and it is something that happened to be very relevant to Spring’s overarching message . . . a message that hasn’t really changed since its first release in June 2003 - user concentrates on functional requirements and Spring helps with the non-functional and boilerplate concerns.
How so??? What is the relevance?
So here is the story of two strawberry ice-creams. . . well actually it is the same ice-cream captured in two stages of serving and it helps illustrate the core Spring message in a kind of a tasty way.
The pic on the left shows a scoop of ice cream simply thrown on the plate The pic on the right shows the same scoop nicely decorated, plated and served to trigger additional senses or to add flavors.. or to simply charge you more.
Whatever the reason may be, the contents of the ice cream never changed. What has changed is how it was decorated, plated and served.
Now we have a simple implementation of java function that does something (uppercasing string in this case), but knows nothing about how it is going to be decorated, plated and served to ensure proper activation and invocation _within_ the given context. What’s even more important is that it doesn’t really _have_ to know it.
Functions are just like that scoop of ice-cream—a raw material. It represents functional aspects of your requirement such as Add User, Access account balance, Uppercase the string etc. . .
But now you can decorate and serve its functionality over HTTP effectively turning this function into a REST endpoint. . .
. . . or may be you want to turn it into an RSocket consumer or producer
. . . which supports many RSocket operations (providing those operations are compatible with the type of java function). There is actually a whole breakout session on Functions and RSocket
. . . or deployed to one of the popular serverless platforms. . .
. . . or maybe you’re considering a full blown Messaging app where the same function acts as a message handler with its input and output corresponding to different broker destinations which in itself opens up an interesting opportunity to create distributed pipelines and data-flows (more on that later).
Whatever the nature of your application may be, the function is still uppercase, the ice-cream remains strawberry, and the only thing we’re changing is the non-functional/boilerplate world around it.
And we can accomplish it with the magic of Spring Cloud Function framework. So let’s see how it works
So what is Spring Cloud Function?
It’s one of the frameworks from the Spring Cloud portfolio which promotes implementation of functional requirements via Java functions, providing a uniformed programming model that supports Transparent Type Conversion Function Composition POJO functions (if it looks/smells like a function it must be a function) Reactive support Deployment of packaged functions Etc It also provides adapters in a form of Spring Boot auto-configurations for variety of serverless platforms.
So let’s see it in action
In these quick set of demos I’ll be using the same function but changing dependencies between each start of the demo. Those dependencies are Spring Boot auto-configurations that will ensure the same function acts as expected within the context of given application type (e.g., REST, Messaging etc)
As you can see the concept of handling non-functional requirements is handled by opinionated Spring boot auto-configurations typically requiring very limited or no involvement from the user. These auto-configurations not only satisfy the dependencies required by the application, but they also decorate the function with the execution context specific behavior.
So. . .
Functions are simple, expressive, extensible and portable Most if not all requirements could be expressed with functions. In fact think about a requirement past, current or future that can NOT be expressed using java functions? See if your can think of one. . . Testing your functional application becomes very simple - you only need to test the function itself and delegate the actual activation and invocation model to Spring via Spring Cloud Function. The list of benefits goes on, but no matter how long it is the result is still the same - any functionality expressed as java functions can now be exposed as variety of applications by simply providing the relevant auto-configuration during the application assembly.