OutSystems customers are at a pivotal moment, contemplating moving from O11 to ODC. This transition mirrors the paradigm shift experienced in embracing microservices architecture. While some have already navigated this journey using different technologies, it is time for the OutSystems community to leap into this new modern architectural landscape.
Understanding the Transition
Moving from a monolithic architecture to microservices entails splitting our applications into services and orchestrating them together. Although this poses challenges, such as architectural restructuring, the long-term benefits are substantial. We gain a more flexible deployment model, improve scalability, and use modern frameworks like AWS Lambda and containers.
The Four Milestones Approach
OutSystems recommends a four-step approach to guide us through this migration journey: portfolio assessment, code preparation, code migration, and data migration. Today, I will focus on the first two milestones, leaving the remaining steps for subsequent discussions.
- Assess Your Portfolio: Before diving into the migration process, it is crucial to assess your application portfolio. OutSystems is developing automated tools to aid in this assessment. Alternatively, leveraging discovery methods or seeking assistance from consulting firms like PhoenixDX can provide insights into the readiness of your architecture for ODC migration.
- Prepare your code: The second milestone involves making structural changes to your code and applications. This phase has seven key steps, and I will provide a brief overview.
- Organise Your Architecture: Begin by organising your architecture into architectural layers. This lets you identify modules that will transition to ODC as distinct services. For instance, segregating UIs, services, and libraries lays the groundwork for future migration.
- Embrace Domain-Driven Architecture (DDA): Isolate domains within your architecture to establish isolated contexts. This prepares your applications for eventual decoupling, ensuring they can function independently. While full decoupling isn’t immediate, laying the groundwork now facilitates smoother transitions later.
- Utilise Architectural Assessment Tools: Automated tools will soon be released that will automatically evaluate your application architecture’s readiness for ODC migration. Address any architectural deficiencies before proceeding to subsequent steps.
- Refine Domain Separation: Further segregate domains into application services and libraries, creating vertical clusters aligned with business units. This paves the way for inter-domain communication through service layers, embracing a domain-driven architecture.
- Transition to Service Actions: Replace server actions with service actions to facilitate loose coupling between applications. This step promotes independent deployment of microservices without impacting others, enhancing scalability and maintainability.
- Adapt to ODC Features: Adjust features like extensions and database entity access to align with ODC’s requirements. Containerisation and domain isolation introduce nuances that will likely require rearchitecting parts of your application to ensure compatibility.
- Address Unsupported Features: Evaluate and modify any features unsupported in ODC, such as BPT and SOAP. Rethink their usage within your applications or find alternative solutions to mitigate migration obstacles.
Conclusion
As we prepare to migrate to ODC, we must approach each milestone methodically. By assessing our portfolios, implementing structural changes, and adapting to ODC’s features, we set the stage for a seamless transition.
I look forward to further discussions exploring the subsequent milestones and the exciting possibilities that lie ahead in our ODC journey.
This content was initially part of an Australia East Coast OutSystems User Group presentation titled Swift Shift: Effective Strategies for O11 to ODC Transition.
