Mit AWS Lambda hat alles begonnen, Google Cloud Functions, IBM OpenWhisk (jetzt Apache OpenWhisk) und Azure Functions haben nachgezogen: Mit dem Paradigma des Function-as-a-Service (FaaS) können Programmteile als Funktionen in der Cloud ausgeführt werden – ganz auf der Infrastruktur des Cloud-Anbieters, ohne eigene Server betreiben zu müssen (deshalb „serverless“).

Um auch im Spring-Boot-Kontext von diesem Konzept profitieren zu können, wurde das neue Projekt Spring Cloud Function ins Leben gerufen. Ziel ist es, ein einheitliches Programmiermodell für die Implementirung von Business-Logik mittels Funktionen bereit zu stellen, mit dem verschiedene Serverless-Anbieter angesprochen werden können.

CI/CD for Serverless Applications on AWS

Marcia Villalba (AWS)

Performing Chaos in a Serverless World

Gunnar Grosch (Opsio AB)

Service Mess to Service Mesh

Rob Richardson (MemSQL)

Web Pentesting – Offensive Java Exploitation

mit Christian Schneider

Zero Trust – why are we having this conversation?

mit Victoria Almazova

Spring Cloud Function – Hintergrund

Spring Cloud Function verfolgt mehrere Ziele: Zum einen geht es darum, die Entwicklung der Geschäftslogik einer Anwendung von einer spezifischen Runtime-Infrastruktur zu abstrahieren. Der identische Programmcode soll somit etwa als Web-Endpunkt, Stream-Prozessor oder als Task ausführbar werden.

Zum anderen sollen typische Spring-Boot-Funktionalitäten wie automatische Konfigurierung, Dependency Injection oder Metriken für Serverless-Anwendungen verfügbar werden.

Mark Fisher von Pivotal stellt die Ausrichtung des Spring-Cloud-Function-Projektes genauer in einem Blogpost vor. Analog zum in Spring üblichen POJO-Programmiermodell wird ein Konzept namens Plain Old Functions eingeführt. Gemeint sind damit grundlegende Interfaces des Package java.util.function: Function, Consumer und Supplier.

Implementierungen dieser Typen können via Classpath Scanning als @Beans registriert werden. Spring Cloud Function stellt also eine Art Wrapper für @Beans des Typs Function, Consumer und Supplier bereit, mit dem diese als HTTP-Endpunkte oder, im Kontext von Messaging-Lösungen wie RabbitMQ oder Kafka, als Message Stream Listeners/Publishers ausgestellt werden können. Zudem können String-basierte Lambda-Ausdrücke dynamisch in @Beans-Funktionsinstanzen kompiliert werden.

Spring Cloud Function – ein Beispiel

Auf GitHub steht das folgende Code-Beispiel bereit, das von Google Cloud Function Gebrauch macht:

@SpringBootApplication
public class Application {

  @Bean
  public Function<Flux<String>, Flux<String>> uppercase() {
    return flux -> flux.map(value -> value.toUpperCase());
  }

  public static void main(String[] args) {
    SpringApplication.run(Application.class, args);
  }
}

Es handelt sich hier um eine einfache Spring-Boot-Anwendung, die wie üblich lokal oder via CI-Build gebaut, getestet und gestartet werden kann. Das Interface Function stammt aus java.util. Flux ist ein Reactive Streams Publisher aus dem Projekt Reactor (die Basis des neuen, reaktiven Programmiermodells aus Spring 5). Die Funktion kann nun via HTTP oder einer Messaging-Lösung angesprochen werden.

AWS Lambda, OpenWhisk & More

Ein erste Version des Spring-Cloud-Function-Projekts steht auf GitHub bereit. Enthalten sind Adapter für AWS Lambda und Apache OpenWhisk. Die Serverless-Anbieter Azure Functions und Goolge Cloud Functions sollen folgen, sobald diese Unterstützung für Java anbieten.

Zur weiteren Vertiefung empfiehlt sich der Blogpost Introducing Spring Cloud Function von Mark Fisher.