OutSystems AOs: Keeping costs under control with automation

It isn't controversial to start this one by saying - times are hard out there. In our personal lives, we're all watching our budgets like we all watched this year's 20th anniversary theatrical re-release of Pride and Prejudice; the one starring Keira Knightley, Rosamund Pike, and Donald Sutherland. Did you know the weird fella who tried to win Elizabeth Bennet's heart in that movie but failed because he was weird also played Quentin in season 2 of The White Lotus? Could this be a thinly-veiled reprisal of Tom Hollander's performance in Pride and Prejudice? I don't know, I haven't seen it.

Now that I've made a contemporary pop culture reference to capture your attention, let's segue smoothly into the main topic of this article: saving money through monitoring efficient use of resources. Just like Mr. Collins.

Anyone who has used OutSystems understands the concept of an Application Object, or AO. If you would like to know the current definition of what constitutes an application object, OutSystems publishes that information on their support website here. In short, AOs are a fundamental licensing unit for an OutSystems subscription and therefore are subject to limits much like other licensed features of the platform. When you need to increase those limits, it can lead to increased cost of your subscription.

First of all, let me be clear about what this article will not be: I have no intention of offering convoluted tips for gaming the licensing model of OutSystems (not that I know of any). I also will not be encouraging anti-patterns that compromise the architecture and maintainability of your applications to save on AO usage. There's plenty of that in other parts of the internet, but I don't endorse those.

Instead, I want to propose a multi-part system you could implement at your own organization to monitor for sudden increases in AO usage in your applications, allowing you to take appropriate action before the anomaly makes its way into an environment that matters. That is, this will not necessarily reduce your AO usage (which will always be steadily increasing so long as you're developing on the platform) but will instead act as an early alert system for things you would otherwise hear about from your OutSystems account rep when you finally eclipse your subscription AO limit.

Where do we begin? This solution foundationally depends on using a CI/CD platform for deployments in your factory. Why? Deployment-time is the only time you will generally be actively cleaning up code, smoothing out and removing dependencies, and tagging new application versions. If you map the development lifecycle to the UX research model of Diverge-and-Converge, this is the point where your app, which has been diverging for weeks, converges on a version that you are willing to tag and say, "this could potentially go into production." This is the inflection point in the application lifecycle where we start to do all of our checks to make sure we're good to do just that:

• We run our application through whatever battery of tests we have to make sure it's not broken.
• We do code review to look for obvious and perilous things like security flaws.
• We check AI Mentor Studio and check the things it flags to make sure there's nothing serious working its way up the environment chain.
• Sometimes, we even run our app through a static code scanner to look for problems.

If you are using a CI/CD platform that integrates with the Lifetime API instead of using Lifetime directly, you will actually find that the world opens up quite a bit in terms of what you can automate during this process. That's because instead of trying to change how Lifetime works, you can instead decorate the Lifetime paradigm with your own constructs using whatever scripting language your chosen CI/CD platform agents will run. That's precisely what I'm proposing.

Above you will see Fig. 1, an overview of the system I am proposing. Let me walk through the labeled arrows and describe this process at a high level:

1. The CI/CD Tool reaches out to Lifetime to tag applications and slate them for deployment.
2. Once the deployment is scheduled, the CI/CD Tool will call an exposed API at the source environment (every deployment has a source and a target) which will report the total AO impact of app (or apps) that are slated for deployment.
3. It will then do this again against the target environment to get the current total AO impact of the app(s) in the deployment.
4. The CI/CD Platform will then compare the delta to a specified value, which we'll call the AO Growth Tolerance, and then either proceed with the deployment if growth remains below that tolerance level or take some other action.

"Some other action" could be a number of things, including actually proceeding with the deployment anyways if the target environment is not prod. Most likely, though, it means halting the deployment and alerting a tech lead there has been an anomaly detected, and they need to take a look at the report output and approve the deployment before proceeding. You know or do whatever you want with this information - it's your factory!

If you've made it this far in the article, it likely means you're a technical resource at your company. It also probably means someone who is not a technical resource emailed a link to this article to you with the brief directive to "take a look at this." If that's you, it also means you've likely noticed that all of this can be done with out-of-the-box tooling from OutSystems and your CI/CD platform except for one thing: the APIs that magically report AO usage.

That is correct, and while I don't have good news like, "I am going to spell out step-by-step how to build it" or, "there's a Forge component waiting for you," I do have some good news:

It is completely possible.

I promise it's going to be ok. There may indeed be a Forge component or something that I publish one day, but since I do this in my spare time and since I am planning a wedding and since I am producing a podcast and since I am on a kickball team, I simply do not have the time to write out an entire solution here. But I am not a monster, so here are some design considerations to get you started:

• The API needs to maintain a secure connection between your CI/CD Platform and your OutSystems environments.
  • If your CI/CD platform can talk to Lifetime, it can probably talk to your farms.
  • Consider using some kind of token-based authentication. Look into OAuth 2.0 and the client_credentials flow.
• The API really only needs to maintain 1 endpoint which should reduce the AO burden that your AO alert system has.
  • For ease of implementation, just take the application version GUIDs that your CI/CD scripts used to create the deployment package in Lifetime.
  • Don't just output the raw AO counts - including a readout of what categories of AO are contributing to the load will help alerted tech leads identify where to check first.
• The AO Growth Tolerance needs to be a configurable value in the CI/CD platform, not in your API.
  • Resist the temptation to make the OutSystems environments talk to each other to figure out the deployment impact.
  • You will have more flexibility and lifecycle independence if you allow the CI/CD platform to orchestrate the communication and decide what to do.
• Now the entrée of the article: this data all exists within the OutSystems metamodel. Here are the tables you'll need to come up with the query for (it will be a complicated query, I'm sorry):
  • ossys_App_Version
  • ossys_App_Version_Module_Versi
  • ossys_Espace_Version
  • ossys_Extension_Version (extensions can have AOs as well)
  • ossys_Espace
  • ossys_Extension
  • ossys_espace_object_count

And now, a strong word of caution: several of the entities mentioned above are undocumented and are not recommended for use by OutSystems. You will need to use the Extended Metamodel component from the forge to access some of them and the last one (ossys_espace_object_count) cannot even be found there - you will need to be creative in order to read from it. Finally, NEVER WRITE to these tables - only read. I have no shortage of confidence in your ability to brick your installation by trying to make changes to these entities.

On that scary note - go forth! Sign up and leave a comment below if I got something wrong or you want to berate me for some other reason; it's free! Also, I am still gauging interest in a Greater Twin Cities tech meetup group and hoping to get input on what you think would make a GREAT meetup.