Merge pull request #1192 from evanchooly/master

serverless.adoc

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

@@ -0,0 +1,71 @@
+== 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.
+In a FaaS environment, the deployment artifacts are small, single purpose "functions."
+These functions are typically stateless which means they can be scaled up or down to meet current load requirements.
+The magic of FaaS happens at the platform level which manages these functions and their resources without direct administrator interference.
+Because the system can monitor and respond to varying levels of traffic and load congestion, developers are free to disregard the server,
+ in effect, and focus on the business logic implemented by each function.
+Applications become "serverless."
+
+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 platforms offer.
+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]
+----
+@ApplicationScoped
+@Path("/")
+@Produces(MediaType.APPLICATION_JSON)
+public class CRUDResource {
+
+    @Inject
+    EntityManager em;
+
+    @GET
+    @Path("/cakes")
+    public List<Cake> listCakes() {
+        return em.createQuery("from Cake", Cake.class).getResultList();
+    }
+}
+----
+
+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 package 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.