OutSystems Microservices Architecture — Use Case
This article presents a possible use case of microservices architecture in OutSystems technology. This example is based on a retail company and their challenges to comply with GDPR.
1. Basics Before Starting
Having the following concepts in mind will make your reading much easier.
a) The 4 Layer Canvas
When starting an application, OutSystems recomends defining the architecture based on The 4 layers canvas. This model helps to abstract concepts and isolate functional module’s implementation (see more).
This article will focus on blue (user interfaces) and orange (business services) modules, because these modules are the main target of a microservices architecture in OutSystems.
b) The 4 Microservices Principles
A set of principles is generally adopted when defining microservices. There are four important principles, which will be explained below.
- Reusing components generates dependencies, a copy is sometimes preferred
- Synchronous calls should be avoided, due to a real time dependencies
- Duplication of data should be embraced, when decoupled modules share data
- Service discovery helps to discover, at runtime, modified and new services
There are more principles, but they do not fit in the scope of this article.
c) The Mono vs. Micro Architecture
In a monolithic architecture strongly coupled connections exist between modules, whereas microservices architecture modules are loosely coupled.
Most applications have a monolithic architecture due to diverse factors. And in some cases, OutSystems architects need different approaches, like a microservices strategy, to build solutions suitable for large scale enterprises.
2. Practical Use Case
Our use case is from a real case scenario. Here we focus on a subset of a broader problem. This subset contains enough concepts to demonstrate an implementation of microservices, using some new features of OutSystems Platform version eleven (see here).
The use case is from a large retail company, with several virtual and physical stores, consisted of many departments. From those departments, we’ll select to model the Sales, Finance and Marketing departments.
a) Challenge
The company challenge was to comply with the GDPR — Global Data Protection Regulation. This is a set of rules, which companies need to comply, with respect to personal data privacy. We’ve selected one aspect of GDPR, to demonstrate our use case, which can be resumed to maintain user data only when needed.
In particular, this company decided not to keep records of user sensitive data, which was not used, as the birth year. They only needed the customer’s date and month of birth, to offer them annual gifts (the birth years were not necessary).
b) Problem
To ensure this compliance (avoid using and storing user’s birth year), developers had to change part of their systems. However applying this change to some systems, impacted most of the other systems, and all systems needed to be deployed simultaneously to production.
Following diagram represents the scope of this use case. Here our focus is on applications from Sales, Finance and Marketing departments, which are part of a monolithic architecture. The arrows represent strongly typed relations between department and customer application. An architecture like this is hard to change, due to the strong connections that exist between the modules.
The consequence of changing the customer-application-actions content, results in a direct impact on department applications. As we can see below, consumers applications have outdated references.
c) Solution
In this context, a microservice architecture approach solves the problem. Because without strong dependencies in all application, it allows future changes to some modules without changing the whole application.
Since this architecture is not in place, initially we need a transition to microservices architecture and then implement the rules. It consequently simplifies future changes.
The following approach can be taken:
c.1) Design to adapt applications for loosely coupled modules
c.2) Build transitions towards a microservices architecture
c.3) Implement further changes increments on modules
Other approaches can exist, this is just one example. To have a better understanding of each step, let’s look at the details of this approach:
c.1) When thinking on the size and scope of a microservice, follow these rules:
- There is no such think as a “one size fits all”
- Should be aligned with business domains
- Depends on team’s size and their capacity
c.2) On most cases, we need to have a transition architecture. That is essential for everyone to understand the goals of this change. Only then, teams can be autonomous and build their microservices independently, knowing when and how to collaborate for this change.
The following diagram shows an example of the architecture transition, from a monolithic to a microservice application, applied to our use case.
A transition architecture is mostly used in an enterprise system, due to a large number of changes in several systems. But any enterprise size project would benefit from having this transition architecture.
c.3) The final goal is to have a modular architecture. Because then future changes can take place as increments of functionality, without having too many dependencies between modules.
On this use case scenario, the old core application customer needs to be replaced with the new customer application. Where each department user interface application contains a loosely coupled relation with core application Customer. This losely coupled connection is done with services actions in OutSystems.
To implement this architecture, OutSystems made available inside Platform 11, new elements named as service actions, with these characteristics:
- Loosely coupled action element
- Runs in a separate transaction
- Immediately available on publish
3. Demonstration
We’re going to use OutSystems platform (version eleven) to demonstrate our case and implement a microservices architecture. The demonstration’s goal is not to be extensive, but rather a reference to the features this platform provides.
a) Implementation
To implement this architecture, several steps are needed. But some of them are described below, to demonstrate how to use microservices in OutSytems Service Studio:
a.1) Create a new module of Customer application and choose module type “Service” (can also duplicate the existing one).
a.2) Rename old module Customer to add a suffix “_Deprecated”.
a.3) Inside Customer module, below separator “Logic” and in server actions folder, create service actions based on the service actions. There are three options available: to create a new service actions, to copy existing server actions, or to move server actions (from folder server actions to folder service actions).
a.4) Add necessary functionality to new server actions and publish the module Customer.
a.5) Then in the user interfaces modules, refresh and update dependencies.
a.6) Inside each user interface module, replace the old server actions by the new service actions.
a.7) And adapt existing screens logic to use new service actions.
a.8) Publish the modules and validate/test implementation changes.
These steps were an example of what can be done in OutSystems to implement a microservices architecture.
b) Curiosities
Some useful features for developers, when migrating applications towards microservices:
- Moving actions between server/services
- Converting eSpace into Service
- Disabling elements in code
- Impacts of Service change signature/content
c) Dependencies
After modifying a core module customer, to change the content of a service action, the impact analysis did not return any warnings. This is because nothing relevant was changed, and no impacts were expected.
The advantage of using loosely coupled relations is that when we change the content of a core module action (as service behaviour), consumer applications of that action, will not have reference impacts (because nothing critical was changed). The signature maintains, what was changed was the behaviour.
However, notice that when changing a service signature, services might no longer be compatible. True Change will provide a warning of that. Then we need to validate, that the signature changes had no impacts on the service actions used in consumers. Even when a signature changes and we decide not to republish consumers modules, the application can still be deployed without republishing consumer modules.
Any change to a service action content (behaviour) is immediately reflected in the consumer (at run time). This gives the advantage of not needing to publish all the consumers, for a change in just one part of the system. But can also bring some risks, which developers need to take into consideration.
4. Additional Topics
Besides the topics mentioned above, many other topics need to be approached for a complete reference to a microservice architecture in OutSystems.
Those topics were left out of this article, because the goal here is only to have a simple example, and not to approach the typical problems associated with distributed systems, such as:
- Scalability (*)
- Transactions
- Networking
- Infrastructure
(*) Read more in another article (here), about microservices guidelines.
5. Summary
This article demonstrated an implementation of microservices architecture in OutSystems, to explain their advantages in a real case scenario.
The most interesting feature of OutSystems Platform 11, is the native service discovery tool to easily discover new or modified services in run time. It allows microservices to scale in large enterprise application’s portfolios.
To wrap-up, advantages of microservices architectures are:
- Microservices enables rapid development
- Microservices can be modified independently
- Microservices can scale independently
6. References
The article content was presented at a meetup in The Netherlands, on the 16 October 2018 (link here).
Additional reference documentation:
