Pragmatic App Migration to the Cloud: Quarkus, Kotlin, Hazelcast and Graalvm
Total Page:16
File Type:pdf, Size:1020Kb
Pragmatic App Migration to the Cloud: Quarkus, Kotlin, Hazelcast and GraalVM Nicolas Fränkel @nicolas_frankel Me, myself and I § Developer and Developer Advocate § Backend, mainly Java @nicolas_frankel Hazelcast HAZELCAST IMDG is an HAZELCAST JET is the ultra operational, in-memory, fast, application embeddable, distributed computing platform that 3rd generation stream manages data using processing engine for low in-memory storage and performs latency batch and stream parallel execution for breakthrough processing. application speed and scale. @nicolas_frankel The Cloud “Gold” Rush @nicolas_frankel Why the Cloud? 1. Costs visibility (vs. TCO) 2. Flexibility • “You pay for what you use” 3. Pay as you go @nicolas_frankel The way to the Cloud 1. “Lift and shift” 2. “Rewrite all the things” 3. The middle path? @nicolas_frankel Lift and Shift § The Cloud is just somebody else’s computer § Relatively easy • “Just” containerize the app § Run can be (a lot) more expensive than on-premise! • Worst case, all hell breaks loose @nicolas_frankel 12-factors app 1. There should be exactly one codebase for a deployed service with the codebase being used for many deployments. 2. All dependencies should be declared, with no implicit reliance on system tools or libraries. 3. Configuration that varies between deployments should be stored in the environment. 4. All backing services are treated as attached resources and attached and detached by the execution environment. 5. The delivery pipeline should strictly consist of build, release, run. 6. Applications should be deployed as one or more stateless processes with persisted data stored on a backing service. @nicolas_frankel 12-factors app 7. Self-contained services should make themselves available to other services by specified ports. 8. Concurrency is advocated by scaling individual processes. 9. Fast startup and shutdown are advocated for a more robust and resilient system. 10. All environments should be as similar as possible. 11. Applications should produce logs as event streams and leave the execution environment to aggregate. 12. Any needed admin tasks should be kept in source control and packaged with the application. @nicolas_frankel A “standard” JVM web application # Factor Issue 2 Declared deps App server is a dependency that is not provided 3 Configuration Application server dependent 9 Fast startup The JVM takes a long time to startup 10 Streaming logs Write in different files @nicolas_frankel More startup performance hits from frameworks Reflection Classpath scanning @nicolas_frankel Rewrite the app 1. Cost 2. Delay 3. Risks 4. Team organization @nicolas_frankel The middle path § Reuse existing code • e.g. annotations from Spring/Java EE § Change the way they are used @nicolas_frankel GraalVM § JVM platform by Oracle § Polyglot • Java, Python, JavaScript, R, Ruby, C § Truffle • Programming Language implementation framework @nicolas_frankel Substrate VM § Create native executables from bytecode § Ahead-Of-Time compilation § Some limitations • Needs to be configured for traditional reflection • Not cross-platform • etc. @nicolas_frankel JVM vs. native executable JVM Native Memory consumption +++ + Startup time +++ + Write Once Run Everywhere ✓ ✘ Adapt to the workload ✓ ✘ @nicolas_frankel Common approaches 1. GraalVM native-image friendly 2. No use of the standard Java reflection @nicolas_frankel “Cloud-native” frameworks @nicolas_frankel The use-case: a URL shortener Traditional approach § Create a bijection between • Space(URL) • Space(short) § Collisions handling @nicolas_frankel URL shortener: alternative approach § Generate random short links § Re-generate if already existing § Store mappings § Trade-off: CPU time vs. storage @nicolas_frankel Stack § Legacy Java EE application § Written in Kotlin § Using JAX-RS § Storing data in Hazelcast IMDG @nicolas_frankel AS-IS state @nicolas_frankel TO-BE state - Development @nicolas_frankel TO-BE state - Production @nicolas_frankel Talk is cheap, show me the code! @nicolas_frankel Recap Walk the middle path when possible § Use existing code § Use frameworks that know how to leverage other frameworks’ code § ROI 4TW! @nicolas_frankel Thanks for your attention! § https://blog.frankel.ch/ § @nicolas_frankel § https://bit.ly/quarkus-hazelcast § https://bit.ly/url-shrtnr § https://slack.hazelcast.com/ § https://training.hazelcast.com/ @nicolas_frankel.