Introduction

ODC is the latest version of the OutSystems platform that fully leverages the advantages of cloud native technology.  In this version, Outsystems particularly adopts containerised storage along with a Kubernetes cluster to run applications at scale. In the data storage space, Outsystems ODC uses Amazon Aurora, a cloud native PostgreSQL based database to store its app revisions. All of these are running on AWS infrastructure, which we are already familiar with. On top of that, ODC was designed with microservices architecture in mind, thus loose couplings between components of the applications are to be expected.

This is quite a change from O11 in terms of technologies and infrastructure perspective. A migration tool from O11 to ODC is expected to be available in the near future to ease the migration, however it is now still WIP (work in progress) by Outsystems. The migration tool is also not expected to perfect, or to be able to handle all scenarios. Therefore, some steps that can be done to avoid migration issues can be considered now while building apps on O11 to reduce complexity of migration in the future.

ODC App Preparation

Making O11 Applications to be ODC ready would mean taking into account the new cloud native capabilities and differences between cloud native and the non-cloud native technologies, as well as considering the new features and changes which Outsystems brought into the ODC. Outsystems is currently developing a tool for O11 to ODC migration called the ODC Migration Kit, however it is expected to have some limitations in certain areas due to the very high level of complexities of code required to handle all scenarios.

Based on that, there are several suggestions on how to prepare your O11 applications:

• 1. Advanced Database Queries for ODC Migration

  Due to the move from SQL Server to cloud-native Aurora DB, some advanced SQL queries and SQL capabilities that would be available in SQL Server would need to be changed or adjusted to be able to be run in the new Aurora DB, with PostgreSQL flavoured syntax. Therefore, in general, aggregates should be used whenever possible.  If advanced SQL needs to be used, consider keeping the queries minimal or simple, having in mind the potential of minimally reworking the queries in the future.

  

   

• 2. ODC Data Access and Widget Modules

  In ODC, the reusable widgets are organised in a Library type application. Libraries are fully reusable components that naturally aren’t allowed to store or access data / entities which are available on the App type application. Therefore, whenever possible, entities and non-reusable logic, including Data Actions, shouldn’t be included in the core widget modules. Data could be passed onto the core widget module as an input parameter instead, with the exception of any calls to external APIs. The library module can raise an event to pass processed / new data out to the parent module to be stored or processed further.

  

• 3. Extension Modules

  ODC uses only cloud native components and technologies, thus extensions that rely on .Net framework or any other non-AWS cloud native technologies would not work. Therefore, avoid using extensions, unless if it’s completely necessary or if it’s known that the extension does not rely on .Net / non cloud native technologies. It would also be useful to think ahead and design a cloud solution that provides the same functionality as the extension that is being or about to be used and integrate that cloud solution into the O11 applications.

• 4. OutSystems forge components

  The rules around whether to be able to use some OutSystems forge components or not depends on the underlying elements which the components use. For example, a component may contain some core widget elements which weren’t designed with cloud native technologies in mind, as well as ones which contain .Net codes. Looking at whether similar or ported components are available on the ODC Forge site while designing the O11 applications might provide some insights.

• 5. Rest API vs Soap API

  ODC does not support SOAP protocol out of the box, unlike the O11. ODC only supports REST APIs at the time of this writing. Avoid consuming or exposing SOAP APIs directly in the O11 applications, unless if absolutely necessary. When possible, liaise with the integration team to start designing and developing conversion mechanism from SOAP API to REST API within the enterprise service bus.

• 6. OutSystems BPT and Workflow

  Future versions of ODC are expected to support workflows out of the box, but the current ODC version does not support OutSystems BPTs and workflows. Additionally, there may be differences in how workflows can be built and executed in future ODC versions. The Migration Kit may include features to convert OutSystems BPTs from O11 to ODC-flavored workflows, which could facilitate the migration process. However, the effectiveness of this mechanism is yet to be determined.

• 7. Microservices architecture in ODC

  ODC was designed with microservices architecture in mind, allowing each app to function as a reusable service for others. Each app in ODC is deployed in individual containers, maintaining weak dependencies on one another by default. Utilizing microservices architecture when developing applications in O11 can facilitate a smoother transition to ODC in the future, enhancing scalability and flexibility.

  

• 8. Traditional Web Applications

  Traditional web applications are not supported in ODC, which makes their migration more challenging due to their inherent characteristics. By migrating these applications to Reactive Web applications in O11, organizations can reduce the complexities and time required for the transition to ODC. This proactive strategy not only aligns with best practices but also paves the way for a smoother migration process. Insights on transitioning from Traditional to Reactive Web applications can be beneficial.

Conclusion 

Migrating to ODC may seem daunting, but there are steps that can be taken now to simplify the process and reduce the time required for migration when the moment arrives. While Outsystems has yet to release the ODC Migration Kit tool, understanding its potential capabilities can aid in ensuring a smooth transition to ODC. Additionally, adhering to best practices and utilizing the OutSystems solution can significantly help in managing technical debt, easing the complexities associated with migration.