anchor.diff:  mvn quarkus:native-image ## produces a standalone executable
   ----
   
  -The runnable jar can then be executed simply by running `java -jar target/myapplication-runner.jar`.  Either scenario requires minimal work,
  - then, to bundle in to your preferred FaaS platform.
  +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
  
positive.code:     @Inject
      EntityManager em;
  
      @Inject
      UserTransaction transaction;
  
      @GET
      @Produces(MediaType.TEXT_PLAIN)
      @Transactional
  
negative.code: 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.
  
  