Java dans le Cloud

Java dans le Cloud

Nos Meetups

Accueil > Blog > Nos Meetups > Java dans le Cloud

Voici un récap’ des présentations faites par Clément Denis (CTO AODocs) et Jean-Marc Leoni (CTO Akur8) lors de notre dernier Mobitalks Java !


Clément Denis : Serverless Java with Google Cloud Platform.

What serverless really means?

Clément’s motto : Maintaining servers (including virtualized or containerized) is hard. If you can have someone else take care of servers for you, just do it.


The levels of abstraction of infrastructure services




Serverless everywhere, not only the production environment


Developers should develop in the Cloud

As instances deploy and start almost instantly, no point in developing locally most of the time


Go serverless for EVERYTHING, including dev tools

Code: Github, Gitlab, Bitbucket
CI: Travis, Gitlab CI, Bitbucket Pipelines
Ticketing: Jira Cloud, Gitlab
IDE? ⇒ Gitpod


But beware of customer data location!

You should always be in control of the customer data
RGPD is not a joke, always check third-party services TOS
If possible, try to colocate everything in the same place




Pros and cons of Serverless


No ops means cheaper, faster go to market

A startup going serverless for the launch of its product won’t have to hire a Devops guy / team, and will ship faster


Infinite scalability

Serverless makes you think in a different way: your app MUST scale horizontally, which is usually a good thing


Security and updates are their problem, not yours

Google, Amazon or Microsoft will always know about critical security flaws before you, sorry!


Focus on what’s important: your application

Your application is what matters, not the underlying infrastructure


Performance scales really well, but so does cost

Serverless means trading performance bottlenecks with cost management


Harder to design properly

Your app must scale horizontally, so forget about big batch jobs in a background thread


Less control of runtime environment

You’re not in control of everything, so you might have to wait for this wonderful new Java version


Vendor lock-in

Your application will be harder to move to another Cloud provider



What is AODocs running on?


A Document Management system for Google Drive

5 million users

Can be installed on a G Suite domain
Integrates very well with the G Suite ecosystem
A Chrome Extension for Google Drive


Hundreds of millions of files managed in Google Drive

And growing fast!
To the billion and more …




A Document Management system for Google Drive


A single multitenant SaaS app for thousand of customers

We do “real” cloud: the application was designed from the beginning to run in a Cloud environment


Tens of millions of inbound and outbound requests per day

Scales almost instantly from a few to a few hundreds instances, depending on traffic


Mostly Java 8 (exploring Java 11 and Kotlin)

Main app in Java 8, deploying Java 11 and Kotlin microservices


Servlet 3.1 and App Engine SDK with a few frameworks

ORM ⇒ Objectify (annotation based, Datastore specific)
REST API ⇒ Cloud Endpoints Framework
Google APIs ⇒ google-api-services-* and google-cloud-*
Utils ⇒ Guava, Lombok, Jackson, etc.





Java on GCP: what are my options?




App Engine: the one-stop shop for serverless


Services and versions

Multiple services with multiple versions running simultaneously
One URL for each version, routing based on host or path
Zero downtime when switching between versions


Flexible serving infrastructure

Custom domains with HTTPS (Let’s Encrypt or provided)
Traffic splitting for A/B testing or progressive rollout



NoSQL database
Infinitely scalable (really!)
Nice Java ORM framework: Objectify



Millisecond-range operations
Speeds-up Datastore as a level 2 cache


Full-Text Search

Simple but very reliable and extremely scalable
Zero maintenance ever


Tasks and Crons

Split your heavy jobs in smaller units of work
Schedule recurring operations


App Engine for Java: comes in two flavors




App Engine for Java: differences between 1st and 2ng generation runtimes




App Engine for Java: differences between 1st and 2ng generation runtimes




Java on GCP: what are my options?




How are we monitoring our Java apps?


Stackdriver and BigQuery: the perfect couple




Stackdriver charts and alerts: forget about ELK!




Stackdriver logs and error reporting


Use your preferred logging abstraction

SLF4J, Commons Logging, Lombok, …
Just make sure it writes to java.util.logging


Store and analyze in BigQuery

Logs are only stored for 30 days … but you can export them in BigQuery forever
Analyze long term latency trends
Troubleshoot something that happened 6 months ago


Let Google tell you what’s wrong

Stacktraces are analyzed automatically and grouped
Helped us a LOT to spot subtle mistakes




Stackdriver Tracing


Analyze latency by request path

Easily spot outliers


Automatic metrics for App Engine services

Detailed tracing comes for free (no code)


Add your own spans with some code

Based on OpenCensus


Compare latency distribution between versions

Automatic reports or create your own






Stackdriver Profiling




Stackdriver Debugger


Add “breakpoint” in your production code

From your IDE (supports IntelliJ) or from a web editor
No perf penalty, actually dumps the variable state


Add additional logs at specific code points

Never again: “If I just had thought about adding some logs …”


But let’s be honest: it’s mostly a very nice toy 🙂

Only helped us a couple of times in the last few years





Références :
Martin Fowler on Serverless: https://martinfowler.com/articles/serverless.html
GCP Serverless solutions: https://cloud.google.com/serverless/
App Engine: https://cloud.google.com/appengine/
Serverless Framework: https://serverless.com/




Jean-Marc Leoni : “serverless” chez AWS avec Spring et AWS batch pour traitement asynchrone long dans l’univers Java.


Le serverless pour le batch processing

On peut le faire avec du FaaS (souvent):

  • Processing ligne à ligne (feature engineering, data cleaning)
  • Données peu volumineuses

Mais parfois on ne peut pas (machine learning):

  • Toutes les données doivent résider en RAM
  • On ne peut pas distribuer


AWS Batch

Permet de définir des Job Definitions et de lancer des Jobs

Job Definition : une image docker, une ligne de commande et une quantité de CPU/RAM
Job : une instance d’un job Definition qui est lancée sur un Compute Environement
Queue : un file pour mettre les jobs en attente
Compute Environnement : un ensemble de machines qui sont lancéesà la demande et sur lesquelles les jobs s’executent (évolue en nombre de CPU)




Et spring dans tout ça ?

Spring Batch

  • Pratique pour définir des pipelines de traitement
  • De la connectivié JDBC/JPA

Spring cloud

  • Facilite l’intégration avec les providers de cloud
  • DB managées
  • Microservices


Pour terminer, voici un projet Github d’exemple créé par Jean-Marc Leoni pour le meetup.

Retrouvez toutes nos offres !

Date de publication : 18 mars 2020