Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Upcoming SlideShare
What to Upload to SlideShare
What to Upload to SlideShare
Loading in …3
1 of 15

Migrating from oracle soa suite to microservices on kubernetes



Download to read offline

Watch presentation recording:

In this session, we’ll explore how Randoli helped a Postal Technology company migrate their payment gateway applications off Oracle SOA Suite to Camel/Springboot on Kubernetes.

The primary drivers for the migration were: move to cloud-native technologies in keeping with the organizational digital transformation mandate; move away from an outdated centralized platform to a decentralized architecture for efficiency, scalability, and manageability; and very high licensing costs of the existing platform.

We’ll discuss:

- The high-level approach we took during the migration including architecture and design decisions.
- How we used Camel/Springboot to implement the services.
- Why and how we used Drools for implementing business rules.
- The test-driven approach using Camel testing framework and how it helped reduce issues.
- CI/CD and build process on Kubernetes.
- How we tackled logging, monitoring, and tracing challenges.

Presenter: Rajith Attapattu, Managing Partner & CTO @ Randoli Inc.

Related Books

Free with a 30 day trial from Scribd

See all

Related Audiobooks

Free with a 30 day trial from Scribd

See all

Migrating from oracle soa suite to microservices on kubernetes

  1. 1. Rajith Attapattu, CTO @ Randoli Inc. Migrating from Oracle SOA Suite to Microservices On Kubernetes 1
  2. 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.
  3. 3. Watch The Presentation
  4. 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. 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. 6 High Level Architecture
  7. 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. 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. 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. 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. 11 Operational View - Kubernetes
  12. 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. 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. 14. Join the Konveyor Community
  15. 15. Thank you! 15 Rajith Attapattu, CTO @ Randoli Inc. If you have questions feel free to contact