4. Issues in existing frameworks
•Relative big memory footprint
•Not optimized for cold starts
•Microservice patterns depend on extra
libraries (eg Spring Cloud)
5. • Read the byte code of every bean it finds
• Syntesizes new annotations for each written annotations on all fields,
methods, classes etc.
• Builds reflective metadata for each bean
• …and this all happens at RUNTIME (using reflection)
• Reflection is slow AND heavy on memory consumption (soft
references)
What Spring and Jakarta EE do
6. Try and convince people that something
never designed for microservices is still
ok?
...or go back to the drawing board….
7. • Designed from the ground up
with Microservices in mind
• Spring-like programming
model
• Ultra light-weight and
reactive (Netty)
• Uses Ahead-Of-Time
compilation
• Support for Java, Kotlin,
Groovy
@graemerocher
8. • All dependency & Configuration information
• Annotation Metadata
• AOP proxies
• Essentially all framework infra
Basically, what Spring / CDI do at runtime
Android community already solved the problem
(Google Dagger)
What Micronaut computes at
compile time
10. Size / Performance
•Hello word JAR is 12MB versus 40MB
SpringBoot
•Starts up fast
•Low memory footprint (runs on as little as 10MB
max heap)
11. Cloud native support
• Service discovery – Consul, Eureka, Kubernetes, AWS
• Configuration – Consul, Amazon, Spring Cloud Config
• Client side load balancing – Integrated or netflix
Ribbon
• Distributed tracing – Zipkin, Jaeger
• Support for serverless computing: AWS Lamba f.e.
12. Service discovery with Consul
micronaut:
application:
name: hello-world
consul:
client:
registration:
enabled: true
defaultZone: "${CONSUL_HOST:localhost}:${CONSUL_PORT:8500}"
@Client(id = "hello-world")
interface HelloClient{
... }
15. Native images
• GraalVM is a polyglot VM capable of running apps written in:
• JVM-based languages (Java, Kotlin, Clojure, Scala
• Javascript, Python, Ruby
• LLVM-based languages (C, C++)
• AOT compiling into native images
• Micronaut supports application conversion into native image (not
production ready)
16. Summary
• Promising alternative to solutions like Spring Framework
• Programming model similair to Spring’s
• Lower memory consumption
• Faster start
• Cloud-native
• Improvements
• Native images are still experimental
• Something like Spring Data would be nice