Devoxx 2017 Presentation: Serverless Architectures (AWS Lambda + Fn Project)

Devoxx 2017 in Casablanca has come to an end. I enjoyed this fabulous conference a lot. Highlights were the the Serverless presentations, the istio presentation by Google, the Spring people live coding, and the Kotlin session that showed that my own Kotlin in the cloud HelloWorld was not so bad after all. Tech content is one important part, but also the great atmosphere and focused but relaxed environment with superb lunches were something to write home about.

And here is my presentation:

Video recording doesn’t seem to be uploaded on Youtube yet. Fun fact: We almost bought a flying carpet after Devoxx in Casablanca!

With the same slideset I gave my Serverless presentation at DOAG 2017 conference. Thanks again folks for the marvellous feedback 🙂

With Kotlin and Spring Boot to the Clouds

0. Overview

This posting is based on a quick customer demo that I did the other week. It demonstrates running Kotlin code in different public clouds. To be more precise: We use Kotlin together with Spring Boot to create a somehow minimalistic REST-like application that is running on multiple, load balanced instances on AWS Beanstalk or Oracle ACCS.

1. Kotlin

Kotlin is one of the upcoming, trendy JVM-based languages. It’s syntax is close to Java, but just sometimes more convenient. The language is backed by two industry giants: Pivotal announced support forSpring and Google officially supports Android development with Kotlin.

The Kotlin language follows the Java coding conventions, but makes the semicolon mostly optional (great!) and adds null-pointer safety (you never had problem with this in Java, did you?) and string interpolation on top of that. Although Kotlin packages are same as in Java in reverse order, in Kotlin package names don’t have to match to folder structure (great!). Interesting enough, most Kotlin control structures are expressions.

2. Spring Boot

We will use Kotlin together with Spring Boot in this posting.

Project Creation

For the purpose of this demo we will create the smallest possible application that is still helpful to learn about the synergy of Kotlin, Spring Boot and cloud. To get started, we create a maven project  for Spring Boot with the spring.io initializer.

The project will contain an empty Spring Boot application and the maven pom file amongst others.

Add a Controller

To get some meaningful output we add another Kotlin class: a controller with three functions. Did you know, the “fun” in Kotlin is for function?

  1. the hello(World) function that simply echoes a name.
  2. a func that shows how to access java.util.Date from Java and returns the time.
  3. a info func that show a bit of load balancing magic when deployed on ACCS.

Build the Project

We can build the project with mvn package from the command-line (or from the IDE, as shown in the web cast).

IDE Support for Kotlin

Being developed by Jetbrains, Intellij offers great support for Kotlin. In this webcast I simply use Netbeans.

 

3 Kotlin in the Clouds

This little demo is more real life than you might think. I will show you to run Kotlin in two different clouds. These days I see multiple clouds at my customers usually. Simply choose the one you like most.

3.a ACCS

ACCS is a Oracle Public Cloud PaaS service that provides several language runtimes. ACCS is based on Docker containers, but don’t worry, you won’t see any of them. With ACCS you can easily deploy Java, Java EE, as well as Python, Ruby, NodeJS and even Go code. Also it supports spinning up multiple instances with load balancing.

Deploying a .jar file on ACCS is as straight forward as it gets:

  1. zip it.
  2. upload it.
  3. run it.

However, there is one more thing: to successfully run the .jar file we need to add a manifest.json file that contains the exact command how the jar file will be started in the Java container. It should be all obvious watching the webcast. Check my other posting to learn about ACCS and Java EE.

3.b Beanstalk

The AWS Beanstalk deployment isn’t more complicated than the ACCS one. Actually even the manifest.json file can be omitted. Beanstalk implicitly understands how to run a .jar file (which of course is easy in most cases: java -jar demo.jar). So all you need to do is upload to Beanstalk. However with Beanstalk we have to make sure to include a SERVER_PORT variable and set its value to 5000. This is required since Beanstalk is internally listening to port 5000 but Spring Boot uses 8080.

5. Web cast

I created a web cast for you with all the details.

6. Ressources

Some additional resources that you might find useful:

  1. Kotlin language
  2. Try Kotlin online
  3. Spring Initalizer
  4. Get started with ACCS
  5. Access the demo code from github. TO DO.
  6. AWS Beanstalk

 

 

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.

Intro

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 12.2.1.2 (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:

    https://<ACCSName>-<IDDomain>.apaas.<REGION>.oraclecloud.com/<DocRoot>

  • 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.

Acknowledgement

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

Application Container Cloud Service (ACCS): Invalid Subscription. Please contact oracle support.

This error messages shows up with the Application Container Cloud Service (ACCS) if you did not set the replication policy for the Oracle Storage Cloud Service. Actually I remember that there was a time when the solution how to fix the issue was not included.

ACC Error. Oracle Cloud

Now we are better off, just read the documentation included in the error message link, or see below:

Should this happen? Here is my take (in progress).

Good news is, that you can fix it easily by setting the replication policy for the Storage Service.

Oracle Storage Service: Geo Replication – you must set this!

Configuring the Oracle Storage replication policy should be step number zero if you start in the Oracle cloud with any service. I cannot stress this often enough. Many services such as DB as a service or Java Cloud service will not work without it. Even ACCS – a much newer and higher level PaaS service – will not work unless you set this storage policy.

  • For now: go and set the policy. I got into all kind of trouble trying without. Trust me, you won’t have the time for this.
  • To make cloud services such as JCS or ACCS work it is not so much important how you set the replication policy, it it just important that you set it. Functionally of course, there is a big difference if you data will be replicated asynchronously to another data center or not.
  • IMHO this could be improved by Oracle to improve the overall OPC customer experience. There is no reason why there could not be a default value, that makes other PaaS services work correctly.

Oracle Cloud: Set Storage Replication Policy

From the official Documentation

Guidelines for Selecting a Replication Policy
Read these guidelines before selecting a replication policy.

Oracle provides several replication policies. Broadly, they belong to one of the following types:

  • Policies that have no georeplication: These policies specify only the primary data center (DC) that hosts your service instance.All read and write requests go to the primary DC, always. If the primary DC is unavailable, then the requests fail. Such a policy may be adequate if you have standard data-durability requirements and if an occasional failure of read requests (when the primary DC is down) is acceptable.
  • Georeplication policies: These policies specify a primary DC that hosts your service instance as well as a geographically distant, georeplication DC.Write requests that you send to the global namespace URL are routed to the primary DC. Data that you write is replicated automatically, but asynchronously, to the georeplication DC. The primary and secondary DCs are eventually consistent. If the primary DC is unavailable, then write requests fail with the 403 — Forbidden error, but read requests are routed to the georeplication DC. When the primary DC is available again, requests to the global namespace URL are routed to the primary DC. You’ll be billed for the sum of the capacities used in both DCs and for the data transfer from the primary to the georeplication DC. A policy that has a georeplication DC is ideal if you have advanced durability requirements for your data or if read requests must succeed always regardless of the state of the primary DC.

For faster data transfer between your other Oracle Cloud services and Oracle Storage Cloud Service, consider selecting a policy with a primary DC that hosts your other services that use Oracle Storage Cloud Service the most. When selecting the replication policy for your service instance, keep in mind any security, legal, and regulatory requirements that may apply to your data.