OutSystems Microservices Architectures — Performance Guidelines

The article presents guidelines of architectures best practices in OutSystems, when using independent and distributed services, to be optimized for scalability and resilience.

Service Actions available in OutSystems P11.

A service action in OutSystems, is somehow similar to a REST API, in it’s way of implementation inside the platform.

OutSystems REST API and Service Actions

An use case of microservices architectures in OutSystems, is available in a previous article (see here).

Importance

When microservices modules can’t scale in an efficient way, they can lead to a decreased availability in the overall system. This reduced availability, can originate outages, making applications not work, which might cost money to a company.

Diagram of a service module consumed by other interface modules.

A proper solution design for the scalability of all the system is needed, having in consideration the different decision criterias (both at hardware and software level).

Decision Criteria

Before applying a solution to improve performance, decisions about what to approach need to follow a criteria prioritization, based on:

• The Hardware resources level; the software level of architecture implementation and configuration;
• Impacts on performance, maintainability, extensibility, project schedule, budget or development resources;

And each one of these decisions has trade-offs, which needs a proper analysis, some pointers are provided in next sections.

Scaling Options

The solution to scale a system using hardware, might help scale until a certain point. Because when scaling vertically or horizontally, we can find some limitations.

Vertical scaling:

This solution focus is to increase the hardware resources capacity (by increasing CPU or memory as example). But is not sustainable for modern abstraction and isolation technologies (as containers).

Horizontal scaling:

This solution focus is to increase the number of hardware resources. Is optimized for concurrency and partitioning of scalable apps. But can lead to extra effort when developing applications. However in long term, can be easier to maintain and modify, because the services are isolated.

In the limit, when scaling systems, there can still exist performance issues largely due to the fact that our services are not optimized. When scaling vertically or horizontally, the level of service optimization can always affect somehow our system performance. If our services are not optimized (meaning at the code level) our applications can be largely impacted. Therefore we need a proper approach to make our services performance optimized.

Network Bottleneck

Any optimization of performance needs to consider that the network can be a bottleneck (think on distributed servers). This has a considerable negative effect in our system because:

A) Requests are sent to services endpoints over a network.

B) Operations read or write sent to a shared or dedicated database over a network (important when databases are not in same server instance).

Diagram of interconnections, having service modules as central component.

The network takes a big effect on these scenarios. And we need to think on the factors that can contribute to that network usage.

Service Degradation Factors

Some examples of performance degradation factors are:

• The number Request per second;
• The number of Queries per second;
• Having responses that containing large data;
• Having simultaneous users access;
• The composition of multiple services;

Performance degradation has impact from core modules to interfaces.

Considering that future changes are not easy to plan in long term, any estimation of future service capacity could be misguided. A proper methodology helps to identify performance impacts from system changes.

Methodology

The approach towards a performative system, is a continuous process of the team, to discover possible improvements:

Approach for system performance improvement.

In each phase, the focus is to track possible optimizations, of service application modules. This article explains the guidelines, leaving for other articles the testing and monitoring topics.

Optimize Service Architecture

The end goal is the service optimization, to minimize the network impact in microservices architectures (or distributed services applications).

Illustration of service actions architecture modules in OutSystems.

The optimization of service modules, must be based on OutSystems performance best practices documentation. Most of the points are covered there, however information regarding services performance is not fully available yet. Therefore here are presented some guidelines, that might help developers understand better service actions, and performance improvement advantages.

Guidelines

Presenting five guidelines to improve service performance:

Service Performance Optimization Guidelines.

1) Define Service Scope

• Design a consistent service — a single responsibility, based on business domain , allows to have less service calls (to outside). This will reduce network calls and improve performance because in memory calls are much faster to complete than sending a message over a network;
• Single operations with simple message format are preferred, over composed services that take more time to process;
• Prioritize requests and handle asynchronous ones later;

2) Optimize Data Queries

• A central database for writes is recommended to avoid synchronization patterns that highly use network;
• Reduce queries processing time for filters containing search expressions “like”, give preference to “=” expressions;
• Query pagination input, to reduce results to manageable sizes;

3) Handle Timeout and Exception

• Avoid fetching large amount of data — use pagination in unbound queries, to return a sub number of results at a time;
• Avoid retrieving a large number of fields — use short transaction data and less calls as possible;
• Define behavior over the scenarios of exception handling and service actions module timeout;

4) Pre-process service requests

• Setup pre-calculations for faster responses over complex data;
• Choose a best time to run scheduled processing, for example when generating reports select period (day/night/weekends);
• Use calculated results caching, updating the values on the go, instead of calculating them each time;

5) Cache Service Results

• Evaluate response caching on application level, or service level, when using external services or database calls;
• Use caching to avoid give same results, when most operations are read type, or data does not change;
• Caching reduces network traffic, reduces queries to database, responses are faster, and provide stale data when an outage occur.

These database actions with thunder symbols are not platform built-in, but they are an examples of an action to represent data caching (perhaps a good suggestion to be built-in, inside the platform).

Guidelines Resume

Additional References

• OutSystems Best Practices (link)
• OutSystems Performance Optimization (link)
• OutSystems Performance Evaluation (link)
• OutSystems Master Class on Performance (link)

The article content was presented at a meetup in The Netherlands, on the 12 February 2019 (link here).