Implementing Microservices in OutSystems II

In the previous article, we already talk about what is microservices and what are its advantages and disadvantages. In this article, we will talk about how to implement microservices in OutSystems.

Design Stage and Initiative Planning

Of course before implementing something, we have to do some requirements gathering. We prepared scripts and conducted dozens of interviews. We thought of relevant personas and set up relevant scenarios they would encounter while addressing matters such as refactoring, and factory evolution. We measured the impact of changing reusable public elements with the current OutSystems reuse and composition model in real, large, and mature OutSystems factories.

After all the requirements gathered, we should rethink about the architecture. How to accomodate all requirements into one good architecture. You also have to think about the dependency. To develop low-code microservices, weak dependencies are more preferable to make it more flexible.

Service Modules and Service Applications

Service modules are OutSystems modules that enforce a higher level of functionality segmentation, with a focus on functionality reuse. In these modules, we restricted available elements to those the users’ core services might be composed of. In the case of service applications, they should be used when organizing service modules, which is the only type of module these applications can contain, thus providing guidance on architecture best practices.

Users also needed a way to convert the core services built using the existing module types (web and mobile) into service modules. And, they would also need the ability to turn traditional applications into service applications. This would allow them to fully take advantage of the new features in evolving their architectures.

Breaking Monolith

Breaking monolith is one of the characteristics of Service-Oriented Architecture (SOA). First, there was figuring out how the OutSystems Domain-Specific Language (DSL) would evolve to enable decoupling by introducing the low-code microservice concept. A set of requirements, some brainstorming, and some iterations resulted in these viable options:

• An evolution of the REST API Method: The idea here was to extend the current functionality of the element by adding a property that enables defining whether it could be called only from the application’s environment or from anywhere, like traditional REST API methods. It would also mean making some improvements to REST API methods to have TrueChangeTM and Impact Analysis.
• An evolution of the (Public) Server Action: In this case, adding a toggle property to public server actions would change their behavior to services (loosely coupled) and extend the current server action functionality. The action would keep all the characteristics of a public server action but be loosely coupled, meaning that, in runtime its logic would be executed out-of-process.
• A New Language Element: This would be an entirely new addition to the OutSystems visual DSL and would represent pieces of decoupled and reusable logic. A new element with the flexibility of a REST API method and the productivity of a server action.