OutSystems Developer Cloud of OutSystems 11: het verschil voor een nieuw project

Je hebt besloten dat een proces uit Excel en e-mail eindelijk een echte applicatie wordt, en je vraagt een offerte op bij een bouwer die met OutSystems werkt. Dan valt er een term die je nog niet kende: OutSystems Developer Cloud, naast het OutSystems 11 dat je in blogs en cases tegenkomt. Twee namen voor hetzelfde platform, denk je misschien. Dat is het niet. Het zijn twee aparte producten van dezelfde leverancier, met een ander fundament eronder. Voor wie nu een project plant is het verschil geen technisch detail: het bepaalt waar je applicatie draait en hoe je bouwteam werkt.

Twee platforms, geen upgrade van elkaar

OutSystems 11, kortweg O11, is het platform dat al langer bestaat en dat draait op Microsoft-technologie: applicaties worden uitgevoerd op IIS-applicatieservers met Windows Server, en de data staat in Microsoft SQL Server, Azure SQL Database of Oracle. Je kunt O11 laten hosten door OutSystems zelf, of zelf beheren op een eigen datacenter of een publieke cloud zoals AWS of Azure. Dat staat zo in de eigen infrastructuurdocumentatie van OutSystems, inclusief de mogelijkheid om productieomgevingen als een server farm met meerdere front-end servers in te richten voor beschikbaarheid.

OutSystems Developer Cloud, ODC, is een nieuwer platform dat vanaf de grond is gebouwd op cloud-native technologie. Volgens de documentatie over de cloud-native architectuur van ODC draait ODC op Kubernetes, met Amazon Aurora als PostgreSQL-compatibele database en aparte opslag voor configuratie, bestanden en containerimages. Elke platformdienst draait in een eigen container, en het platform schaalt automatisch mee op basis van processor- en geheugengebruik. ODC is dus geen O11 met een nieuw jasje: het is een ander platform, volledig beheerd op AWS-infrastructuur, zonder de keuze om het zelf te hosten die O11 wel biedt.

Wat er anders werkt als je gaat bouwen

Het verschil zit niet alleen onder de motorkap, maar ook in hoe een ontwikkelaar dagelijks werkt. In O11 bouw je in modules die je publiceert en waarvan afhankelijkheden gezamenlijk worden meegenomen in een deploymentplan. Dat concept module bestaat in ODC niet: volgens de documentatie voor O11-ontwikkelaars die overstappen naar ODC is de equivalente term daar een asset, zoals een webapp, mobiele app, agentic app, workflow of library, en elke asset heeft zijn eigen levenscyclus. Een app deploy je in ODC individueel naar de volgende fase van je pijplijn; een library moet je eerst expliciet vrijgeven met een versie en release notes voordat een andere app hem mag gebruiken. Dat is een bewust andere manier van werken dan het gezamenlijke deploymentplan van O11.

Ook de broncode zelf is anders georganiseerd. O11 kent per omgeving een eigen coderepository, waardoor code bij elke stap in de pijplijn opnieuw gecompileerd wordt. ODC werkt met één centrale coderepository: bij het publiceren in ODC Studio gaat de code als containerimage naar een centraal register, en dat image stroomt ongewijzigd door de pijplijn. Voor een ontwikkelaar die van O11 komt, is dat wennen, maar het scheelt herhaalde compilatiestappen bij elke deploy.

Wanneer past welk platform

OutSystems zelf stelt in een eigen blogpost over de keuze tussen O11 en ODC dat er geen verplichte overstap van O11 naar ODC is: beide platforms blijven bestaan naast elkaar, en organisaties hoeven niet te kiezen tussen het een of het ander als ze al op O11 draaien. Dat is een relevant signaal voor een MKB-bedrijf dat vandaag al een O11-applicatie heeft: die hoeft niet gemigreerd te worden om relevant te blijven.

Voor een nieuw project ligt de keuze concreter. O11 is aantrekkelijk als je moet integreren met bestaande on-premises systemen, als regelgeving of een bestaand IT-landschap eigen hosting vereist, of als je organisatie al ervaring en beheer rond SQL Server of Oracle heeft. ODC is aantrekkelijk als je project cloud-first is, automatisch moet meeschalen met gebruikspieken, en je geen behoefte hebt aan eigen beheer van de onderliggende infrastructuur. Omdat ODC volledig op AWS draait via een beheerde Kubernetes-omgeving, val je de discussie over servers, patches en databaseonderhoud grotendeels weg, tegen de prijs van minder eigen regie over waar en hoe de applicatie precies draait.

Een derde overweging is het type applicatie. ODC is uitdrukkelijk ontworpen met agentic apps en directe integratie met grote taalmodellen als onderdeel van het platform, iets wat op O11 meer eigen bouwwerk vraagt. Ga je juist een klassieke bedrijfsapplicatie bouwen die vooral moet koppelen met een bestaand ERP- of CRM-systeem op locatie, dan is dat vaak beter met O11 te doen.

Wat betekent dit voor jouw bedrijf?

Ga je nu een nieuw project starten, laat de platformkeuze dan meewegen in je vooronderzoek in plaats van hem over te laten aan wat een bouwer toevallig gewend is.

• Breng in kaart met welke bestaande systemen de nieuwe applicatie moet koppelen, en of daar on-premises databases of oudere interfaces bij zitten. Dat trekt vaak richting O11.
• Vraag expliciet of hosting bij jou, bij een eigen datacenter of volledig beheerd bij de leverancier moet liggen. Alleen O11 biedt de eerste twee opties.
• Bepaal of AI-functionaliteit, zoals een agent die zelf acties uitvoert, een kernonderdeel van de applicatie is. Dan is ODC het platform waar dat het meest ingebakken zit.
• Vraag je bouwer niet alleen welk platform hij adviseert, maar ook waarom, en welk deel van die keuze bij jouw situatie past en welk deel bij zijn eigen voorkeur.

Wij bouwen bij HubTwo met OutSystems en bepalen per project welk platform bij de situatie past, niet andersom. Twijfel je welk platform bij jouw plan hoort, neem dan contact met ons op, dan denken we vooraf mee in plaats van pas na de eerste sprint.