serverless.adoc

docs/src/main/asciidoc/topic/serverless.adoc

@@ -0,0 +1,65 @@
+== Functions as a Service and Serverless
+
+Functions as a Service and, more broadly, serverless is an emerging trend that is gaining wide adoption with offerings from most of the
+major platform and cloud providers.  Owing much to the simplicity of the development model, more and more workloads are being deployed as
+ serverless functions to take advantage of the automatic scaling and concurrency that serverless offers.  However, to date, Java and the
+ JVM has not been a primary focus for many.  JVM startup time and memory overhead are prohibitive costs for many organizations.  However,
+  it would be a shame to leave behind the wealth of experience and vast ecosystem in order to gain efficiencies in a serverless model.
+
+Quarkus solves of much of this for us.  Quarkus offers blindingly fast start up times memory optimized applications well-suited to
+serverless environments.  With Quarkus, developers can continue to use Java and many of the libraries familiar to them.  Quarkus takes on
+ the work of packaging everything up for deployment.
+
+=== Running a Quarkus app on serverless
+
+One of the challenges when adopting serverless as development paradigm comes down to choice.  There are many choices available to build
+your functions and which one is chosen can have lasting impacts.  Quarkus can help eliminate some of this by allowing you to bring
+along the frameworks you know use and trust.  While many FaaS offerings bring with them their own APIs one needs to implement in order to
+ function properly, many also offer the option to deploy arbitrary containers via Docker or OCI images.
+
+Consider the following basic CRUD example:
+
+[source, java]
+----
+@Path("/")
+@ApplicationScoped
+public class CRUDResource {
+
+    @Inject
+    EntityManager em;
+
+    @Inject
+    UserTransaction transaction;
+
+    @GET
+    @Produces(MediaType.TEXT_PLAIN)
+    @Transactional
+    @Path("/cake")
+    public String getCake() {
+        Cake c = (Cake) em.createQuery("from Cake").getSingleResult();
+        return c.getType();
+    }
+}
+----
+
+Taking this simple GET operation, we can use quarkus to build a runnable jar or even an native image which we can then embed in a Docker
+image or for use in a Knative Build script for deployment on top of kubernetes.
+
+[source, shell]
+----
+mvn package ## produces a runnable jar with dependencies in target/lib
+----
+
+or
+
+[source, bash]
+----
+mvn quarkus:native-image ## produces a standalone executable
+----
+
+The runnable jar can then be execute simply by running `java -jar target/myapplication-runner.jar`.  Either scenario requires minimal work,
+ then, to bundle in to your preferred FaaS platform.
+
+=== FaaS API
+All this begs the question: why doesn't Quarkus simply provide its own opinionated API?  While this may happen eventually, the current
+philosophy is to integrate what choices make sense so developers don't need to learn a whole new API set to make use of Quarkus.