The document outlines the migration from Oracle SOA Suite to a microservices architecture on Kubernetes led by Rajith Attapattu of Randoli Inc. It discusses the motivation behind the migration, including high licensing costs and the need for cloud-native technologies, and provides insights into the architecture design, implementation challenges, and lessons learned. Key highlights include a test-driven approach, operational concerns, and a focus on comprehensive logging and metrics to address issues during migration.

1. Rajith Attapattu, CTO @ Randoli Inc.
www.randoli.ca
Migrating from Oracle SOA
Suite to Microservices On
Kubernetes
1

2. 2
Accelerate your journey to Kubernetes
with the Konveyor Community
A community of people passionate about
helping others modernize and migrate
their applications to the hybrid cloud by
building tools and best practices on
how to break down monoliths, adopt
containers, and embrace Kubernetes.
www.konveyor.io

3. Watch The Presentation
https://youtu.be/cxH6WjDZc2c

4. 4
What we’ll
discuss
today...
▸ The primary drivers for
migrating off SOA Suite
▸ The high-level approach,
architecture & design
decisions
▸ Implementation details
and challenges faced
▸ Test driven development
and how it reduced our
risks.
▸ Operational concerns
and how we addressed
them
▸ Lessons learned & key
takeaways.

5. 5
The primary drivers for migrating
off SOA Suite
● Move to cloud-native technologies in keeping with the
organizational digital transformation mandate.
● Very high licensing costs of the existing platform.
● Move away from an outdated monolith platform to a
Microservices architecture for efficiency, scalability &
manageability.

6. 6
High Level Architecture

7. 7
Proposed Solution
● Lightweight and
works great on
Springboot
● Rich library with
support for EIP &
Transports, Data
formats
● Error handling
support and
testing support
Camel
● Declarative
approach- What to
do vs how to do
● Helps to
externalize,
centralize and
structure in a self
documenting way
● Visibility on which
rules were
executed
Drools
● Cloud-native was
a goal
● Internal team
with good skills
● Good CI/CD
offering built
around OCP
Kubernetes

8. 8
Camel On Springboot
● SOAP interface to support legacy applications but built a parallel
REST interface using REST DSL
● Used an internal object model that got mapped from SOAP
interface
● Micrometer component for getting metrics
● onException with retry policies for error handling
● Resilience4j with Circuit Breaker EIP to handle downstream
communication
● Camel-Zipkin for tracing
● Custom Camel Springboot Starter

9. 9
Drools Engine
For implementing business rules
● We grouped rules into a package like structure with a naming
convention for easy identification
● For each stage where rules were applied, we built a kie-base with
rules only relevant to that stage.
● These kie-bases were wrapped by a POJO and called as a step in
the camel route.
● This allowed us to write targeted test cases via JUnit
● For each stage, we logged the facts supplied, the rules that got
fired and the decisions (outcome).

10. 10
Test Driven Approach
● Camel has awesome support for writing test cases (Weaveby,
Mock ..etc)
● For each business workflow we wrote test routes that exercised
the various cases as unit tests.
● External integration endpoints were easily mocked by Weaveby
allowing us to write multiple test cases by varying the responses.
● Each sub route was unit tested.
● At least two test cases per business rule.

11. 11
Operational View - Kubernetes

12. 12
Operational Challenges
● Operations need to see all the logs relating to a particular
transaction in ELK
○ Used cxf interceptors to inject gtxid to the mdc
○ Strategically placed logs at key points in the route provided
a detailed picture.
● Used AgendaEventListener to log all the rules fired
● Micrometer exposed metrics via prometheus
● Logging via Camel Zipkin provided timing around endpoints
● JVM metrics collected via prometheus - helped pin point netty
buffer leak.

13. 13
Lessons Learned & Key Takeaways
● With any migration project you need expect that you will not know all the
requirements or the corner cases. You have to peel the onion.
● Distributed logging is a must if you are using containers.
● Understand how JVM memory is allocated and how to tune it in a containerized
application.
● Metrics around external endpoints help understand where the latency is coming
from. Metrics around key points in your route provides further insight.
● When combining Camel EIPs and components investigate further to see what
goes underneath the covers.

14. Join the Konveyor Community
www.konveyor.io

15. Thank you!
15
Rajith Attapattu,
CTO @ Randoli Inc.
If you have questions feel free to contact
rajith@randoli.ca
https://www.linkedin.com/in/rajith-muditha-attapattu/