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
Datastore
NoSQL database
Infinitely scalable (really!)
Nice Java ORM framework: Objectify
Memcache
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.
Date de publication : 18 mars 2020
