Fn Project in Public Clouds (aka Serverless on IaaS ?)

Fn in Public Clouds (IaaS)

Fn project is a cloud agnostic FaaS platform and a common question is how to use Fn in public clouds. Similar to the local installation that we used in the Oracle blog posting (link soon), it can also be installed on any public cloud IaaS. For most IaaS it is enough to pass the installation command directly to the creation of a compute instance as so called user-data. User data is commands that are acted upon when the instance is provisioned. Also when running Fn in a public cloud, don’t forget to enable access rules for Fn server allowing port 8080 – depending on requirements – either from your own IP or all public IP addresses.

Once Fn server is running on your favourite cloud provider, you could deploy the recommendation engine mock example mentioned in the posting above in two different ways.

Deploy Your Fn Function in the Cloud

# example 1 (for teaching purpose only, in production use approach below)
# note: run these commands on the cloud instance

$ fn apps create advtravel
$ fn routes create advtravel /fn-recommend DOCKER_ID/recommend:0.0.2


Another, probably even more useful way to deploy the function is to set the FN_API_URL environment variable locally, point it to the remote cloud instance, and run the local Fn deploy command against the remote cloud instance.

# example 2 (easier, what you'd do in real life)
$ export FN_API_URL=URLofRemoteCloudInstance
$ fn deploy --app advtravel 

Note, that with the commands above you never had copy over the function or the container image to the cloud instance. When the function will be invoked the first time, Fn will pull the Docker container from the registry, store it locally, and then simply run the function.

Test Fn in the Cloud

Once the Fn is running in the cloud and your application is deployed you can access the application from a local machine using the command-line or Postman. The invocation is the same as in the local example, just replace localhost with the public IP address of your cloud instance:

$ curl -X POST --data @testdata/syd.json PUBLIC_IP:8080/r/advtravel/fn-recommend 

Real FaaS?

Obviously, when running Fn project on an IaaS you do not get the true pay per invocation benefit as for a FaaS implemented by the cloud provider as PaaS. You will get automated scalability to some degree, since it is built into the load balancer Fn LB. At the end running Fn on IaaS is only serverless from a user perspective.

It will be interesting to see if a cloud platform (most likely Oracle, since Fn Project is driven a lot by Oracle) will provide a proper FaaS service with pay per invocation and automated scalability that is compatible with open source Fn Project.

Fn Cloud Demo

A recorded live demo from Devoxx conference about deploying Fn on IaaS can be seen here.

Get the demo app used in webcast from here.

Application Container Cloud (ACCS) supports Java EE

This is my personal entry for the ODC appreciation day that was initiated once more by Tim Hall.


Oracle’s Application Container Cloud Service (ACCS) is a cloud native, container based runtime for applications and microservices implemented with Java, Node.js, Ruby, Python and PHP. It’s simplicity makes it most attractive. All you need to do is bundle and upload your code, and add a .json file to let ACCS know how to start your application.

Since a couple of days ACCS is now supporting Java EE as well – this is great news! Note, that there is still Java Cloud Service JCS, which gives you a fully fledged WebLogic domain. However, JCS is more complex to set up and to deploy to, so ACCS is a good option for those that only want to deploy and run a Java EE module.

ACCS with Java EE

The provisioning, as shown in the following screenshot, is PaaS-worthy, easy enough as with any other ACCS deployment type.

ACCS: Application Container Cloud Service with Java EE


ACCS with Java EE, Some Details

Here are some more facts as they are currently known:

  • You can simply upload a .war file. The .json manifest that is required to tell ACCS how to start a Java application is not mandatory for Java EE since the module is running in WebLogic.
  • The current versions used in ACCS when deploying a Java EE module are: WebLogic (which supports Java EE 7), running on Java 8.
  • ACCS with Java EE currently does not support clustering.
  • ACCS does not let you access the WebLogic admin console. This is fine. It’s PaaS!
  • ACCS with Java EE can make use of Java Flight Recorder. In continuous mode, all profiling and event data is captured. If Java Flight Recorder is not in continuous more, then 60 seconds of data is captured. You can download the files and use Java Mission Control to analyze the recordings.
  • The URL syntax to invoke a deployed web module is as follows:


  • Typically the URL to call a deployed application is shown in the ACCS service console. Note, that the DocRoot -even if required to call the deployment – is not shown.
  • A Java EE deployment is running across 2 instances as default which requires a load balancer to be provisioned by ACCS. Currently OTD is used.
  • If you feel brave enough, just give it a go and deploy the sample app.
  • If you are lost working with ACCS by yourself, then follow this tutorial, explaining how to deploy a Java EE module to ACCS. The instruction mentioned in the tutorial worked OOTB for me.

Possible Improvements

As you know, I usually write about features and showstoppers. A few minor things that should be improved in my opinion:

  • A few minor details are not visible in the console. E.g. the used Java version is not fully displayed.
  • Not sure if it is documented somewhere, but I would love to read more precisely about current restrictions for Java EE in ACCS. Actually I dropped the hint for some colleagues at Oracle to blog about it.

Is it Java EE or EE4J now?

You may have heard that Java EE went to the Eclipse foundation. The new name will be EE4J. Do you have to change all your slide decks and articles? Actually no. For some more details have a look at this article.


Many thanks to the team of Abhishek and Sriram for helping to clarify some questions and providing quick and precise feedback!