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 of Java.
+
+Quarkus solves of much of this for us.
+Quarkus offers blindingly fast start up times with 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;
+
+    @GET
+    @Produces(MediaType.TEXT_PLAIN)
+    @Transactional
+    @Path("/cake")
+    public String getCake() {
+        Cake c = em.createQuery("from Cake", Cake.class).getSingleResult();
+        return c.getType();
+    }
+}
+----
+
+Taking this simple GET operation, we can use Quarkus to build a runnable jar or even a 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 executed simply by running `java -jar target/myapplication-runner.jar`.
+The native image can be run with `target/myappliction-runner`.
+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 with what choices make sense so developers don't need to learn a whole new API set to make use of Quarkus.