From OutSystems 11 to OutSystems Cloud

Presented on the OSDC back in November 2022, ODC Studio is the OutSystems Developer Cloud's low-code and visual development environment. This new visual programming tool promises to speed the development because developers will be able to start sharing such things as templates, elements, and themes.                                          
 
ODC is cloud native, this means that the infrastructure of both the development Platform (for building and deploying apps) and the independent runtime (for hosting and running the deployed apps) live in the cloud. 

Besides having access to ODC Studio (development environment where developers build and debug apps) and ODC Portal (which allows to consolidate apps and user management), OutSystems Developer Cloud customer have the possibility to: 

• Access to multi-tenant development platform services. 

• A standard runtime setup of three stages: Development, Test, and Production. 
• A set of isolated, encrypted, and scalable databases and data stores for the platform services data. Secret data such as API keys are stored in a secret manager. 
• An isolated, encrypted, and scalable relational database for each Runtime stage. 

Developing apps in OutSystems Developer Cloud

In the OutSystems Developer Cloud, developers can create both web apps and libraries. Web apps are responsive applications that can run on all devices and browsers, while libraries consist of a collection of reusable UI and logic elements that can be utilized in other apps. 

Within a web app, different types of elements can be defined. Timers can be created to execute background logic, and at the interface level, Screens, Blocks, and other UI-related components can be used to construct user interfaces. For logic, elements such as Client Actions, Server Actions, Service Actions, and Integrations, as well as Roles, can be created. Regarding data, regular Entities and Static Entities can be generated, along with other data-related components such as Client Variables and Settings. 

When dealing with Libraries, their purpose is crucial to consider. A Library is an app that is meant to be reused by other web apps or libraries. Therefore, libraries contain highly reusable elements such as Blocks, Client and Server Actions, REST service consumers, Static Entities, and Settings.

Above, there the image shows how different the architecture is when it is used OutSystems Developer Cloud and OutSystems 11. 

In the OutSystems Developer Cloud, two web apps exist: Directory & Vacations and the Holidays Connector Library. 

However, in OutSystems 11, the same scenario could be approached differently. One possible architecture would involve splitting the Directory app into two Modules: a UI Module and a Core Service Module, where Entities and business logic would be defined. Each of these would reside in their own app in OutSystems 11. Additionally, the Vacations app could be split into three Modules: a UI and Core Module, an Integration Service Module for the sync logic supporting the holidays integration, and a separate Module for the connector itself. In terms of apps in OutSystems 11, there would be one for the Vacations Modules and another for the Integration Service and Connector of the holidays integration.  

New terminology

New platform means new terminology and concepts. The first main difference is the fact that in ODC there aren’t modules, meaning, one application is equal to one module this is due to one of the main goals, promote loosely couple architectures and to promote team autonomy and lifecycle independence.

Moreover, here in ODC we have the Organization concept, which is interpreted as space with all user accounts managed by the company. A collection of apps and libraries (set of elements of UI an logic that can be reused) used by teams in an organization. 
 
One of the goals of ODC is actually promote loosely couple architectures and to promote team autonomy and lifecycle independence. 

But how should teams prepare themselves to make the needed changes, from OutSystems 11 to OutSystems Cloud?

As with everything in life, changing the way of implementing or programming can be challenging due to a combination of technical, social, financial, and other factors. This often involves altering existing processes, systems, or structures that have been in place for some time. 

One of the first suggestions when approaching the best way to transition is to change the code and allow only the use of service actions between applications, leaving necessary server actions set as private. However, it should be required to check whether this is the best approach. 

The task is challenging, as it requires a deep understanding of the implications on database transactions and exception handling. Furthermore, it needs to be taken into consideration that these two complex modifications need to be done carefully, as they do not work with best practices of cloud development. Mere substitution of public server actions with service actions is insufficient and will not suffice to regain operational efficiency. 

Developers should also ensure that static entities do not have their identifier set as auto-number. Using auto-number is not recommended, as it might generate issues in complex scenarios. For example, when deploying applications from one environment to another, data created in different environments might have different identifiers, which can impact logic, especially when it relies on the main identifier of the entity to uniquely identify records across environments. Therefore, it can be stated that setting the auto-number as No should already be the best practice for every OutSystems developer, without the need to change just because of a future migration to ODC. 

Increasing isolation between domains is also advisable. This is not just a rule to follow when talking about ODC, but between domains in OutSystems 11, where we should mainly use Service Actions. In summary, when developing an application in OS11 nowadays, we should weigh the pros and cons of using server actions set as public or service actions. This selection depends entirely on the scope of usage of the module being created. Additionally, note that server actions in ODC cannot be set as public. 

After changes, what exactly is expected as benefit? 

As previously stated, the concept of modules no longer exists in OutSystems Development Cloud (ODC). This raises the question of whether the business logic actions should be merged with the core services in one application, meaning, the Core Services (CS) module should be combined with the Business Module (BL) rather than keeping them separate as in OS11. 

Since the 4-layer-canvas (4LC) is no longer applicable, there is a need to rethink the way applications are created. Developers should start thinking in a native Domain-Driven-Architecture (DDA) way to scale enterprise applications in large factories and prepare for expanding contexts. 

From experience, especially in larger factories, BL modules often consume more than one CS module, depending on the business requirements. As the concept of business logic remains in ODC, we can consider that the previously separate BL module is now an application that consumes services from two CS applications. 

Furthermore, it appears that OutSystems is using the term "tenant" differently in ODC compared to its typical usage in OutSystems 11 (O11). Essentially, customers no longer get their own infrastructure, but rather a tenant within ODC. To support millions of simultaneous users and thousands of tenants in the future, and to simplify migration from O11 multi-tenancy applications to ODC, customers will need to define the concepts themselves in the ODC data model and logic. 

Which actions should be taken into consideration in the future? 

Introducing OutSystems Development Cloud (ODC) can provide a range of benefits for developers and organizations, including better abstraction of concepts, easier maintenance, faster deployments without impacting other applications, clear understanding of the platform for all users, and the promotion of a service-oriented architecture. 

• Better abstraction of the concepts: This allows developers to focus more on the logic and functionality of the application they are building, rather than worrying about the underlying infrastructure. By abstracting these concepts, ODC simplifies the development process and reduces the complexity of managing applications. 
• Easier maintenance: ODC offers a centralized management console for managing applications and infrastructure. This makes it easier to monitor and maintain applications, as developers and administrators can access and manage all the components from a single location.  
• Faster Deploy without messing with other applications: With ODC, developers can deploy their applications faster and with less risk of affecting other applications. This allows developers to release new features and bug fixes more frequently and with greater confidence. Note that, in ODC, each app is deployed independently and that it is possible to execute multiple deployments of different apps at the same time, meaning, it is allowed to different users to deploy their own apps to the desired stage without the need to wait for a deployment to finish, and without impacting other users in the organization. 

• Clear concepts to everyone: ODC uses a consistent terminology and provides a clear separation of concerns between applications and infrastructure. This makes it easier for developers, administrators, and business users to understand the structure and operation of the environment.  
• Promote a Service-Oriented Architecture: ODC promotes a service-oriented architecture (SOA). This enables developers to build applications faster by leveraging pre-built components, and it also makes it easier to maintain and update applications over time.  

WRITTEN BY: Ana Agostinho  | OutSystems Developer