- Microservices originated as an evolution from monolithic applications and technologies like EJBs and SOAP/REST, promoting principles like independent deployability and team ownership. - While microservices are useful, adopting them fully comes with difficulties around domain-driven design, operations, and converting monoliths. - Rather than debate microservices vs. monoliths, the focus should be on cloud native applications, which may incorporate properties of both along with containerization, APIs, and serverless architectures. The future lies in approaches like GraalVM native images and InstantOn that enhance applications for the cloud.

1. Are Microservices Going To Die?
—
Emily Jiang
5th December 2022
Java Champion
Cloud Native Architect, IBM
@emilyfhjiang
Mastodon: @emilyjiang@mastodon.social

2. 2
The History of Microservices

3. Enterprise Java Beans
3

4. 4

5. 5
SOAP

6. 6
Representational State Transfer
REST

7. 7

8. 8
● Maintainable and testable
● Independently deployable
● Loosely coupled
● Organized around business capabilities
● Owned by a small team
What is Microservice?
https://microservices.io/

9. 9
● DDD and/or EDD not Resume Driven Design (RDD)
● Day2 Operation ever so important
● Standard programming model to interact with other microservices
● Corresponding team culture
● Be mindful on refactoring monolith to microservices
Microservice Architecture
Checkout IBM Mono2Micro – uses AI to refactor monolith to microservices
https://www.ibm.com/cloud/mono2micro

10. 10
● DDD is hard
● Team culture is difficult to change
● Convert Monolith to microservices is hard if done manually
● No resources to convert Monolith to microservices
Microservices difficulties

11. 11
Monolith -> Microservice -> Monolith
https://www.infoq.com/news/2020/04/microservices-back-again/

12. 12
● Are Microservices the destiny?
● Will Monolith have to be migrated to Microservices
Microservice vs. Monolith

13. 13
Microservices won’t take over Monolith

14. 14
Monolith and Microservice will coexist

15. 15
The boundary between Microservices
and Monolith blends and evolves to
Cloud Native applications

16. 16
What you need is Cloud Native
Applications!

17. 17
What are Cloud Native
Applications?

18. Cloud Native applications
1. RESTful – like cattle not pet, communicative
2. Configurable
3. Fault tolerance
4. Can be discovered
5. Secure
6. Traceable, monitorable
7. Able to communicate with the cloud infrastructure

19. 19
Cloud Native API Standards
Popular runtimes
WebSphere
Liberty

20. Jakarta EE 10 Platform
Updated
Not Updated
New
Authorization 2.1
Activation 2.1
Batch 2.1
Connectors 2.1
Mail 2.1
Messaging 3.1
Enterprise Beans 4.0
RESTful Web Services 3.1
JSON Processing 2.1
JSON Binding 3.0
Annotations 2.1
Interceptors 2.1
Dependency Injection 2.0
Servlet 6.0
Server Pages 3.1
Expression Language 5.0
Debugging Support 2.0
Standard Tag Libraries 3.0
Faces 4.0
WebSocket 2.1
Enterprise Beans Lite 4.0
Persistence 3.1
Transactions 2.0
Managed Beans 2.0
CDI 4.0
Authentication 3.0
Concurrency 3.0
Security 3.0
Bean Validation 3.0

21. Health Metrics
Fault
Tolerance
OpenAPI
Config
JWT
Rest Client
Jakarta EE
Core Profile
Core
Reactive
Messaging
Integrate
Observe
GraphQL
Telemetry
https://microprofile.io/
Cloud Native Java APIs
https://jakarta.ee/

22. 22
Containerization

23. 23

24. 24
Cloud Native Application Deployment

25. 25
Microservice seen as best practices for
developing Cloud Native Applications!

26. 26
Here comes Serverless!!!

27. 27
● It often has servers – too minor to be noticed
● Pay as you Go pattern: applicable to public cloud
● Occasionally running; fast operations
● scaling to zero
What is Serverless?

28. Cloud Native Runtimes
28
The JVM was designed with portability and flexibility
in mind. This meant that bytecodes were loaded
lazily and optimized while the application was
running. The result was slower startup times but
high peak throughput. The cloud demands a shift in
the performance characteristics of JVMs.
Solutions:
- Dynamic AOT compilation and class metadata
persistence
- Static compilation – native image
Native Image JDK
Positives
1. Extremely fast startup time (less than 50 ms)
2. Small memory footprint (less than 30mb) on
startup
3. Small on-disk footprint (no bytecodes, no
interpreter, no JIT etc.)
4. Very small container image size
5. Native OS executable image
Negatives
1. Only runs a subset of existing Java workloads
and tooling
• Developer experience mismatch
2. Not designed for intensive / long running
applications
3. Peak throughput is much lower than that of JVM
mode
4. GC technology is not as good as in JVM mode
5. Requires work to keep up with new Java
versions
6. Different technology = different bugs and
behavior
Positives
1. Full Java capabilities available
• Dynamic class loading,
Reflection,
Serialization
• Monitoring agents, JNI
• ….
2. Runs full suite of applications and
tooling
3. Dynamically adapts to program
behavior
•AOT, Interpreter, JIT
compiler
Negatives
1. Runtime memory use typically
higher
2. Slower startup
3. Larger on-disk footprint

29. 29
Is Cloud Native Application obsolete
when Serverless dominates?

30. 30
Fast startup
Graalvm: build time compilation
Linux CRIU technology
OpenJ9 and Open Liberty InstantOn
Public Cloud Serverless
IBM Cloud Code engine
Amazon Lambda
Google Function
Azure Function
Cloud Native Application Serverless Enabled
https://openliberty.io/blog/2022/09/29/instant-on-beta.html
InstantOn

31. 31
Microservice won’t die but its
name will be less impactable!

32. 32
● https://microprofile.io
● https://jakarta.ee/
● https://openliberty.io/guides
● https://microservices.io/
● https://criu.org/Main_Page
● https://www.graalvm.org/
● https://www.ibm.com/cloud/mono2micro
● https://ibm.biz/MicroProfileBook
Useful resources

33. 33
MicroProfile Book featured Open Liberty
https://ibm.biz/MicroProfileBook
@emilyfhjiang

34. Twitter/LinkedIn: @emilyfhjiang
Mastodon: @emilyjiang@mastodon.social