Ben je nieuw in de wereld van Mendix en wil je zelf hands-on met het platform experimenteren? Of werken jullie al met Mendix, maar wil je een kleine applicatie gebruiken om te experimenteren of een idee te valideren? Dan kun je gebruikmaken van de gratis ‘sandbox-omgeving’. Dit is namelijk de ideale plek om te testen of een applicatie-idee toegevoegde waarde kan hebben. Binnen een sandbox kun je uitgebreid experimenteren en testen. Slaat het idee aan en heeft het business-waarde? Dan kun je overstappen naar een omgeving met een licentie en uitgebreidere afspraken.
Wat is een sandbox?
De letterlijke betekenis van sandbox is zandbak. De term gebruikt men vaak in softwareontwikkelprojecten om aan te geven dat de omgeving die je gebruikt tijdelijk, beperkt of kleiner is dan omgevingen die meer eisen stellen aan functionaliteit, beschikbaarheid of performance.
Volgens Wikipedia gebruikt men sandbox-omgevingen vaak ook om in een volledig geïsoleerde IT-omgeving (zonder netwerk of connectie naar buiten) software te testen.
Wat is een Mendix-sandbox?
Elke Mendix-app die je maakt op je eigen lokale machine, draait binnen Mendix Studio Pro, de ontwikkelomgeving van het platform. Maar Studio Pro leent zich niet zo goed voor het beschikbaar maken van apps voor andere gebruikers. En dan komt de sandbox om de hoek kijken. Vanuit Mendix Studio Pro kun je namelijk met een enkele druk op de knop de applicatie naar een sandbox-omgeving overzetten. De applicatie draait nu ‘in de cloud’ en is toegankelijk voor meerdere personen om gebruikt te worden.
Aan een enkel Mendix-project kun je 1 sandbox koppelen. Deze koppeling ontstaat als je een nieuw project aanmaakt voor het bouwen van een Mendix-app. De sandbox is gelimiteerd in functionaliteit, schaalbaarheid, beschikbaarheid en performance. De verschillen met een betaalde omgeving zullen we verderop in dit artikel uitgebreid behandelen.
Vanuit technisch oogpunt draait een sandbox-applicatie in een Docker-container. Die container draait in de Mendix Cloud v4 (free tier) op het cloudplatform van AWS (Amazon Webservices). De specificaties zijn:
- 1 GB aan geheugen
- 1 GB voor de opslag voor bestanden
- 0,5 GB maximale databasegrootte
De applicatie zal bij inactiviteit in slaapmodus gaan en herstarten wanneer deze weer wordt gebruikt. In de praktijk zal een app die regelmatig overdag wordt gebruikt ‘s nachts vaak pas in slaapmodus gaan..
Verschillen tussen een gratis sandbox en betaalde licentie
Een betaalde omgeving waarvoor je jaarlijks een licentie moet betalen, noem je een gelicenseerde cloudnode. Zo’n node wordt standaard geleverd met minimaal een productie- en acceptatie-omgeving, maar vaak wordt er ook nog een testomgeving gebruikt waar je applicaties eenvoudig naar kunt deployen.
Dit zijn de 11 verschillen tussen een sandbox en een gelicenseerde cloudnode:
| Sandbox-node | Gelicenseerde cloudnode |
| Je kunt geen eigen domein inrichten. | Je kunt wel een eigen domein inrichten. |
| Maximaal 50 gebruikers tegelijkertijd. | Aantal gebruikers conform de licentie-afspraken. |
| Via een live-log kun je de voortgang van je deployment volgen. | In de projectomgeving kun je live je deployment volgen. |
| Er zijn geen logbestanden die je kunt downloaden. | Je hebt de beschikking over actuele logbestanden en een logarchief. |
| Er zijn geen uitgebreide monitoring en alerts mogelijk. | Standaard monitoring van je CPU, memory, threads, sessions etc. |
|
Je kunt geen pakket van een applicatieversie maken en deze deployen naar een sandbox. Elke keer als je een nieuwe versie overzet naar de sandbox, wordt de versie die draait overschreven. |
Je hebt meer controle over het maken van pakketten van een versie en het deployen naar verschillende omgevingen (test, acceptatie en productie). |
| Er zijn geen scheduled events.
|
Scheduled events kun je aan- en uitzetten. |
| Constanten moet je instellen in het model. | Constanten stel per omgeving in. |
| Dagelijkse back-ups worden maar 2 weken bewaard. | Back-ups worden dagelijks/doorlopend en, op aanvraag, tot wel 1 jaar bewaard. |
| Client-certificaten en profielen voor toegangsbeperking zijn niet in te stellen. | Client-certificaten en profielen voor toegangsbeperkingen zijn wel in te stellen. |
| De omgeving stopt bij inactiviteit en start opnieuw op bij nieuwe deployments of wanneer je de applicatie start. Dit duurt 10 tot 20 seconden. | Je kunt de omgeving zelf starten en stoppen. |
Kun je de beperkingen die gelden anders oplossen?
Als je bij het gebruiken van sandbox-omgevingen echt tegen problemen aanloopt, moet je een betaalde omgeving met een licentie aanschaffen. Je kunt er dan voor kiezen om in de Mendix Cloud je Mendix-projecten te deployen. Je kunt bovendien ook gebruikmaken van een eigen cloudomgeving als je licentie die optie ondersteunt. Denk bijvoorbeeld aan Azure, Google Cloud, SAP-cloud en Pivotal. Mendix kent daarvoor de Mendix for Private Cloud waarbij gebruik wordt gemaakt van een Kubernetes cluster (zie Mendix for Private Cloud), je hebt dan als ontwikkelaar dezelfde mogelijkheden via het platform portal als die in de publieke Mendix Cloud. Wanneer je hier niet gebruik van maakt houd er dan rekening mee dat je zelf alles moet regelen voor de infrastructuur, inrichting en het beheer van applicaties op deze cloudplatformen.
Een aantal beperkingen die gelden kun je soms met een workaround oplossen, maar deze oplossingen zijn vaak niet ideaal. Denk hierbij aan de onderstaande problemen en oplossingen:
Geen inzicht in de monitoring van grafieken en informatie → Zet de widgets van Google Analytics in je model. Deze laten al wat meer informatie zien over het gebruik van de applicatie. Ze laten bijvoorbeeld zien hoeveel gebruikers er zijn en wanneer deze gebruikers inloggen.
Geen logbestanden beschikbaar van de afgelopen periode dat de applicatie draaide → Zet de logging-module uit de Mendix Appstore in om logberichten weg te schrijven naar de database. Zo bouw je zelf een archief van logging op. Let op dat je maar beperkte ruimte hebt in je database. Je kan deze logberichten ook extern wegschrijven via een REST-interface naar bijvoorbeeld Datadog of een vergelijkbaar platform. Je kunt ook kiezen voor een alternatieve database.
Geen eigen domeinnaam waar de app draait → Om de URL van de sandbox te verbergen, kun je een domein registreren of bij een bestaand domein een pagina gebruiken waarop een iframe zichtbaar is waarin je de URL van de sandbox gebruikt (voorbeeldcode vind je hier). Je kunt dan de applicatie aanroepen via deze eigen domeinnaam. Iframes hebben wel beperkingen, bijvoorbeeld wanneer het scherm van je app van grootte verandert.
Advanced tip: als je deeplinks gebruikt, moet je daar rekening mee houden (deeplink doorgeven aan iframe, bijvoorbeeld middels JavaScript).
Geen geavanceerde back-up-functionaliteit → Stel regelmatig zelf een back-up veilig door hem lokaal te downloaden. Voor een sandbox worden back-ups maar maximaal 2 weken bewaard. Een nog betere optie is het zelf ontwikkelen van een functionaliteit voor de export en import van je data. Je kunt in een sandbox alleen een door Mendix gemaakte back-up opnieuw restoren en deze niet zelf uploaden.
Meer dan 1 GB aan bestanden willen opslaan → Gebruik je een applicatie die veel bestanden wil opslaan? Overweeg dan om externe cloudopslag te gebruiken en deze te integreren middels een REST API. Denk bijvoorbeeld aan AWS S3 of Dropbox, oplossingen die een lage prijs per GB aanbieden.
Geen scheduled events → Om toch processen te triggeren die je dagelijks uit moet voeren, moet je vanuit een andere cloudapplicatie je sandbox-applicatie aanroepen. Zo worden er bijvoorbeeld toch op dagelijkse basis gegevens gesynchroniseerd. Google Scheduler, AWS Cloudwatch of de (CRM-)applicatie waar je al gebruik van maakt kunnen dit probleem voor je oplossen.
Kan ik productie-applicaties draaien in een sandbox?
Ja dat kan. Je moet dan alleen rekening houden met de bovenstaande (technische) beperkingen. Daarnaast geldt dat er een mindere SLA en meer beperkte uptime-garanties van toepassing zijn voor sandbox-omgevingen. Uiteraard staat Mendix Support wel voor je klaar als zich eventuele problemen voordoen in je omgeving. Je kunt hier een ticket voor aanmaken.
Is dit, eventueel in combinatie met de workarounds, voldoende voor de eisen die je stelt aan de omgeving voor jouw applicatie? Dan kun je met een gerust hart een sandbox inzetten voor productie-applicaties!
Mijn ervaring is dat voor kleine, niet missie- of proceskritische applicaties een sandbox prima voldoet, zeker wanneer niet veel gebruikers tegelijk de applicatie gebruiken. Sinds de introductie van sandbox-omgevingen, zijn er nog steeds apps die ik zelf stabiel in een sandbox gebruik.
Hoe deploy ik naar een sandbox?
Als je een nieuwe applicatie in het Mendix-platform aanmaakt, wordt de URL van je applicatie ook bepaald. Let op: die URL is achteraf niet meer aan te passen!
Je app is dan beschikbaar onder de URL: https://<naam-van-je-app-cijferXXX-sandbox.mxapps.io. Deze URL wordt gegenereerd op basis van de naam die je gebruikte bij het aanmaken van je nieuwe app. Na je eerste deployment, zal je app via deze URL benaderbaar zijn.
Om een nieuwe versie te deployen naar een sandbox-omgeving, klik je op ‘Run’ in het menu ‘Run’. Let op: je aanpassingen worden meteen gecommit in de teamserver (SVN) en je versie wordt overschreven op de sandbox-cloud. Let bij lokaal testen dus goed op dat je voor de optie ‘Run locally’ kiest.
Kan ik een productie- en test-sandbox hebben?
In de basis kan dit niet rechtstreeks vanuit 1 Mendix-project. Maar er is wel een workaround om toch een testomgeving te creëren. Dit biedt voordelen als je eerst nieuwe features wilt (laten) testen voordat je ze naar de ‘productie’-sandbox overzet.
Helaas zijn hier wel altijd een aantal handmatige acties voor nodig. Volg het onderstaande stappenplan om naast je applicatie ook een testomgeving aan te maken:
- Maak een nieuw blanco project aan met dezelfde naam van je .mpr bestand als de bestaande applicatie die in de ‘productie’-sandbox draait.
Advanced tip: wil je echt een afwijkende URL hebben voor je testomgeving? Geef dan bij de naam van het project bijvoorbeeld op: “SurveyBuilder-test”. Je hernoemt daarna in dit project de .mpr via TortoiseSVN of SmartSVN naar exact dezelfde naam als je productie app .mpr en commit dit eerst voordat je naar stap 4 gaat.
- Deploy deze naar de sandbox (zie “Hoe deploy ik naar een sandbox”).
- Je hebt nu een blanco Mendix-project met sandbox dat je als testomgeving kunt gebruiken.
Als je de wijzigingen van je applicatie eerst wilt testen op de testomgeving, doe je het volgende:
Copy/paste alle bestanden uit de directory van je productie-applicatie, behalve .svn en .mendix-cache directory (als je die niet ziet, check Beeld->Verborgen items)
- Je hebt nu je blanco testapplicatie overschreven met het Mendix-model van je productie-applicatie.
- Maak nu je gewenste aanpassingen.
- Als je nu in je ‘testapplicatie’ deployt (zie “Hoe deploy ik naar een sandbox”), kun je het een en ander testen.
- Zijn de aanpassingen naar tevredenheid? Dan kun je dezelfde copy/paste stappen herhalen in je productie-applicatie en uiteindelijk deployen naar je ‘productieomgeving’.Zoals ik al zei: het creëren van een testomgeving in sandbox vereist veel handmatig werk. In de betaalde versie is dit uiteraard allemaal netjes geautomatiseerd.
Laatste tips
- Wanneer je met sandboxes werkt, heb je soms het nodige geduld nodig. Het deploymentproces verloopt namelijk niet altijd even snel als in een gelicenseerde omgeving.
- Je kunt gewoon de debugger gebruiken die je ook in je lokale omgeving gebruikt.
- Zorg er ook voor dat je een beheerder en gebruiker aanmaakt in de After Startup van je model als die er nog niet zijn.
- Zorg er, net als bij Mendix-apps die op een gelicenseerde node draaien, voor dat je security en access rules op orde zijn.
Ik wens je veel plezier bij het inzetten van de Mendix-sandbox. Experimenteer en leer! En heb je nog vragen: aarzel dan niet om contact met ons op te nemen.
