This document discusses strategies for moving applications to the cloud, including "lift and shift" and full rewrites. It advocates for a middle path of reusing existing code but changing how frameworks are used. Specific frameworks and technologies mentioned include Quarkus, Kotlin, Hazelcast, and GraalVM. The document also provides an example application of a URL shortener and how it could be implemented using these strategies and technologies.

1. @nicolas_frankel
Shorten all URLs:
Quarkus, Kotlin,
Hazelcast and GraalVM
Nicolas Fränkel

2. @nicolas_frankel
Me, myself and I
§ Former developer, team lead, architect,
blah-blah
§ Backend, mainly Java
§ Developer Advocate

3. @nicolas_frankel
Hazelcast
HAZELCAST IMDG is an operational,
in-memory, distributed computing
platform that manages data using
in-memory storage and performs
parallel execution for breakthrough
application speed and scale.
HAZELCAST JET is the ultra fast,
application embeddable, 3rd
generation stream processing
engine for low latency batch and
stream processing.

4. @nicolas_frankel
The Cloud “Gold” Rush

5. @nicolas_frankel
Why the Cloud?
1. Costs visibility (vs. TCO)
2. Flexibility
• “You pay for what you use”
3. Pay as you go

6. @nicolas_frankel
The way to the Cloud
1. “Lift and shift”
2. “Rewrite all the things”
3. The middle path?

7. @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

8. @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.

9. @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.

10. @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

11. @nicolas_frankel
More startup performance hits from frameworks
Reflection Classpath scanning

12. @nicolas_frankel
Rewrite the app
1. Cost
2. Delay
3. Risks
4. Team organization

13. @nicolas_frankel
The middle path
§ Reuse existing code
• e.g. annotations from Spring/Java EE
§ Change the way they are used

14. @nicolas_frankel
GraalVM
§ JVM platform by Oracle
§ Polyglot
• Java, Python, JavaScript, R, Ruby, C
§ Truffle
• Programming Language
implementation framework

15. @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.

16. @nicolas_frankel
JVM vs. native executable
JVM Native
Memory consumption +++ +
Startup time +++ +
Write Once Run Everywhere ✓ ✘
Adapt to the workload ✓ ✘

17. @nicolas_frankel
Common approaches
1. GraalVM native-image friendly
2. Build-time reflection generation

18. @nicolas_frankel
“Cloud-native” frameworks

19. @nicolas_frankel
The use-case: a URL shortener
Traditional approach
§ Create a bijection between
• Space(URL)
• Space(short)
§ Collisions handling

20. @nicolas_frankel
URL shortener: alternative approach
§ Generate random short links
§ Re-generate if already existing
§ Store mappings
§ Trade-off: CPU time vs. storage

21. @nicolas_frankel
Stack
§ Legacy Java EE application
§ Written in Kotlin
§ Using JAX-RS
§ Storing data in Hazelcast IMDG

22. @nicolas_frankel
AS-IS state

23. @nicolas_frankel
TO-BE state - Development

24. @nicolas_frankel
TO-BE state - Production

25. @nicolas_frankel
Talk is cheap, show me the code!

26. @nicolas_frankel
Recap
§ Use existing code
§ Use frameworks that know how to
leverage other frameworks’ code
§ ROI 4TW!
Walk the middle path when possible

27. @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/