Skyrocketing Micronaut µ-services in Google Cloud Guillaume Laforge Google Cloud Developer Advocate @glaforge Java Champion Apache Groovy co-founder Member of the Micronaut technical advisory board

Chapter 1 — Micronaut, a microservices & serverless focused framework

Micronaut is... A microservices & serverless focused framework A complete application framework for all kinds of apps An annotation processor that hooks into your compiler to wire everything at compile time The results of lessons learned building Spring and Grails

You can build... ● Microservices ● Serverless applications ● Message-driven applications with Kafka or RabbitMQ ● Command-line tools ● Android mobile applications ● Anything with a static void main ● In Java, Groovy or Kotlin

Features at a glance ● Familiar annotation-driven programming model ● Non-blocking Netty HTTP server ● Declarative reactive compile-time HTTP clients ● Cloud native (service discovery, distributed tracing, cloud support) ● Easy data-access layer ● Instantaneously spin up servers & clients for unit tests ● Open API to expose your APIs

No content

No content

Problem with current frameworks Classical application frameworks offers lots of productivity thanks to annotation-based programming models… But make extensive use of techniques bad for memory consumption and startup performance: ● Reflection ● Runtime bytecode generation ● Runtime generated proxies ● Dynamic class loading

Java’s own problems ● Limited annotation API ● Type erasure ● Slow reflection ● Reflective data caches ● Classpath scanning ● Slow dynamic class loading

Micronaut ❤ GraalVM Increase app throughput by 20-30% and reduce latency Faster startup time (up to 20ms) Lower memory consumption (as low as 18MB) Lightweight self-contained native binaries (great for cloud deployment) Less work to configure native image, as Micronaut eliminates: reflection, runtime proxies, runtime bytecode generation, and dynamic class loading

Chapter 2 — Serverless solutions on Google Cloud Platform

cloud.google.com/ about/locations A Big Global Network of Data Centers

Panorama Machine Learning Vertex AI Platform Vision API Video Intelligence API Speech API Translate API NLP API ... Compute Compute Engine App Engine Kubernetes Engine Container Registry Cloud Run Cloud Functions ... Networking Cloud Virtual Network Cloud Load Balancing Cloud CDN Cloud Interconnect Cloud DNS ... Storage & Databases Cloud Storage Cloud Bigtable Cloud Firestore Cloud SQL Cloud Spanner ... Big Data BigQuery Cloud Dataflow Cloud Dataproc Cloud Dataprep Cloud Datalab Cloud Pub/Sub Genomics ... Management Monitoring Logging Error Reporting Debugger Deployment Manager ... Developer Cloud SDK Cloud Source Repositories Cloud Endpoints IDE plugins Cloud Test Lab Cloud Build ... Identity & Security Cloud IAM Cloud IAP Cloud KMS Cloud Secret Manager Cloud Resource Manager Cloud Security Scanner Cloud Platform Security ...

The compute spectrum FaaS App platform Container Virtual machine Dedicated server Physical hardware Virtual hardware Operation system Application runtime Application Function Virtual hardware Operation system Application runtime Application Function Operation system Application runtime Application Function Application Function Function Serverless Zone

The serverless models and characteristics Operational Model Programming Model No Infra Management Managed Security Pay only for usage Service-based Event-driven Stateless

Serverless compute options on Google Cloud Cloud Functions Serverless functions App Engine Web applications and APIs Cloud Run Containerized HTTP workloads Source-based deployments of event-driven functions Source and compiled deployments of web apps and web API backends Containerized applications serving HTTP requests, fully managed or on GKE clusters

Cloud Functions

Cloud Functions Cloud services “glue” Backend code that reacts to events ● Background events ● HTTP events Use cases ● Integrating with 3rd-party services & APIs ● Webhooks ● IoT backends ● Lightweight real-time data processing ● Virtual assistants & chatbots Available runtimes ● Node.JS ● Python ● Go ● Java ● .Net ● Ruby

The cloud “glue” — Functions event sources Cloud Storage Cloud Pub/Sub HTTPS Firebase Cloud Scheduler Cloud Tasks

✅ Good fit? — ❌ Constraints? ✅ Good fit ● Easy to deploy bits of code ● React to Pub/Sub & Storage events ● Nice for webhooks handlers or other asynchronous operations ● Don’t want to think about runtime env. ● Lightweight data transformation (ETL) ● Cloud-based HTTP glue & webhooks ❌ Constraints ● Limited set of runtime languages ● Function granularity might be too small ● Must interact via events ● No custom domain (not out of the box) ● Concurrency level of 1 (more cold starts) ● Not for user-facing APIs or web fronts

App Engine

App Engine Standard Available language runtimes: ● Python 2.7 / 3.7 / 3.8 / 3.9 ● Java 8 / 11 ● Node.js 10 / 12 / 14 ● PHP 5.5 / 7.2 / 7.3 / 7.4 ● Ruby 2.5 / 2.6 / 2.7 ● Go 1.11 / 1.12 / 1.13 / 1.14 / 1.15 Features: ● Multiple services, multiple versions ● Traffic splitting (A/B testing, blue/green, canary deploym.) ● Concurrency (80 concurrent requests) ● Custom domains ● Built-in CDN for static asset serving ● Batteries included (Memcache, Datastore…)

✅ Good fit? — ❌ Constraints? ✅ Good fit ● For stateless applications ● For HTTP request/response workloads ● Scaling high traffic, down to zero (good enough for Snapchat!) ● Built-in CDN static asset serving ● Traffic splitting (across services & versions) ❌ Constraints ● Must use one of the available runtimes ● No support for WebSockets, HTTP/2 & gRPC streaming, Server-Sent Events

Cloud Run

Containers Any language Rich ecosystem Any library of base images Any binary .js .rb .go .py .sh … 0 1 0 1 0 0 1 1 1 Containers Flexibility Serverless Velocity

Serverless containers with Knative and Cloud Run Cloud Run Fully managed, deploy your workloads and don’t see the cluster. Cloud Run on Anthos Deploy into Anthos, run serverless side-by-side with your existing workloads. Knative everywhere Use the same APIs and tooling anywhere you run Kubernetes with Knative.

Container contract & resources ● Listen on 0.0.0.0 on port $PORT (default 8080) ● HTTP server must start < 4 min (timeout → 504) ● Request time < 15 min (default → 5 min, up to 60 min) ● Stateless (in-memory file system) ● Computation only within request (No background activity) ● 2 vCPU per container instance (configurable to 4 vCPU) ● 256 MiB of memory up to a max of 8 GiB (configurable, soon 16 GiB) ● 250 concurrent requests per container (configurable 1-1000) ● 100 max containers by default (configurable 1-1000, support overridable) ● Access to a Metadata Server ● Sandboxed by gVisor

✅ Good fit? — ❌ Constraints? ✅ Good fit ● For stateless workloads ● For HTTP request / response ● Supports WebSockets, gRPC, Server-Sent events ● Scale up quickly, and down to zero ● Specific runtime needs (language, dependencies, binary…) ● Custom domains ❌ Constraints ● Must use containers, adds complexity ● Decide on build process (Cloud Build, Cloud Native Buildpacks…) ● No built-in CDN, or Memcache

Chapter 3 — Deploy Micronaut on Cloud Functions, App Engine, & Cloud Run

Demonstrations HTTP and background functions with Micronaut Micronaut web application on App Engine (also GraalVM native image) Containerized Micronaut services on Cloud Run (also GraalVM native image)

Thank you and Q & A Thank you Questions & Answers Guillaume Laforge @glaforge