Om alle voordelen uit het Managed App Platform te halen zijn er meerdere verbeteringen die kunnen worden doorgevoerd. Aan de hand van meerdere best practices wordt ervoor gezorgd dat de applicatie soepel loopt in een omgeving die continue kan schalen op momenten van piekbezoek. Ook kan de CI/CD workflow worden geoptimaliseerd door zero-downtime releases te doen. In dit artikel behandelen wij de belangrijkste zaken en bronnen welke gebruikt kunnen worden het Managed App Platform maximaal te benutten.
Als de applicatie voldoet aan de volgende optimalisaties, zal deze optimaal draaien op het Managed App Platform. Wordt er geen 100% score behaald, betekent dit niet dat dat de applicatie niet op het Managed App Platform kán draaien. Neem in dat geval contact op met Sales om de opties door te nemen en te bepalen of het logisch is om de applicatie op deze manier te draaien. Onder de best practices zijn al deze punten verder toegelicht.
stdoutApplicaties welke goed passen op het Managed App Platform volgen voor een groot deel het gedachtegoed van The Twelve-Factor App. Wanneer er wordt overwogen of een applicatie geschikt is, kan bij deze 12 punten worden stilgestaan en de vraag worden gesteld, voldoet mijn applicatie hieraan? Wij raden aan het volledige document eens door te lezen om een goed beeld te krijgen van hoe er van een klassieke applicatie kan worden gewerkt naar een web-app of software-as-a-service en welke termen en begrippen hierbij relevant zijn.
In sommige gevallen zullen niet alle factoren van toepassing zijn of voldoen maar kan de applicatie toch een goede kandidaat zijn voor het Managed App Platform. Neem bij twijfel gerust contact op met onze Sales afdeling, dan kunnen wij meedenken over de mogelijkheden en een passende oplossing bieden.
De codebase voor een Managed App wordt altijd bijgehouden een versie controle systeem, bijvoorbeeld Git. Er is altijd één codebase per app, als er meerdere codebases zijn, is er sprake van een gedistribueerd systeem. Elk component in een gedistribueerd systeem is een app en kan individueel voldoen aan de twaalf factoren.
De meeste programmeertalen bieden de mogelijkheid gebruik te maken van een packaging tool om dependencies te bundelen, voor PHP is dit bijvoorbeeld composer. Het Managed App Platform gaat ervan uit dat de dependencies van de opgestuurde code door dit soort tools gebundeld worden aangeleverd met de applicatiecode. Aan de kant van Shock Media definiëren wij expliciete templates met site-packages en configuratiewaarden, denk hierbij aan PHP modules en webserver configuraties. Door de gebundelde applicatiecode en de templates te combineren worden images gebouwd die perfect op de applicatie aansluiten.
De configuratie van een Managed App wordt in de Environment variabelen ingesteld en bevat alle onderdelen welke verschillen tussen verschillende deployments (staging, acceptatie, productie). Hieronder vallen bijvoorbeeld:
Binnen het Managed App Platform kunnen deze gegevens in secrets en environment variabelen worden opgegeven en staan deze los van de code. Een simpele test of deze best practice gevolgd wordt is door jezelf het volgende af te vragen: Als de codebase nu open source gemaakt wordt, worden er dan credentials gelekt?
Het is mogelijk om gevoelige environment variabelen zoals wachtwoorden of API keys als secrets door Shock Media op te laten nemen in de zogeheten 'Vault'. Dit is een Secretmanagement platform dat deze secrets encrypted opslaat en enkel binnen de applicatie op het platform beschikbaar stelt. Mochten de secrets op deze manier geconfigureerd moeten worden, neem hierover dan gerust contact op.
Een backing service is een service die de applicatie over het netwerk gebruikt als onderdeel van de normale werking. Voorbeelden zijn :
Voor een Managed App is er geen onderscheid tussen lokale of third-party services. Voor de applicatie zijn beiden verbonden resources, welke middels een connectiestring en credentials uit de configuratie worden aangeroepen. Een deployment van een Managed App zou een lokale ontwikkeldatabase moeten kunnen uitwisselen met bijvoorbeeld een third-party databaseservice door enkel aanpassingen in de configuratie door te voeren, de codebase zou onveranderd moeten blijven.
Binnen het Managed App Platform biedt Shock Media ondersteuning voor het uitrollen en beheren van verschillende backing services voor Managed Apps, een overzicht van de huidige ondersteunde services is hier te vinden. Mist er een service welke cruciaal is voor jouw app, laat dit ons dan even weten, dan onderzoeken wij de mogelijkheden om dit in ons aanbod op te nemen!
Een codebase wordt een (non-development) deployment door de volgende drie stappen uit te voeren:
Een Managed App hanteert een strikte scheiding tussen de Build-, Release- en Runtimefasen. Het is bijvoorbeeld onwenselijk/onmogelijk om tijdens runtime wijzigingen in de code aan te brengen, omdat er geen manier is om die wijzigingen terug te zetten naar de Buildfase.
Om dit voor de gebruikers van het Managed App Platform zo simpel mogelijk te houden hoeven developers zich alleen bezig te houden met het bundelen en opsturen van de codebase. Stappen 2 en 3 worden automatisch door het platform afgehandeld.
Zelfs wanneer het deployproces zorgvuldig is doorlopen kan het zo zijn dat de nieuwste versie van de applicatie tóch niet goed werkt. Voor deze gevallen is de rollback functionaliteit ingebouwd en beschikbaar in het my.shockmedia.nl control panel, zo kan er in geval van nood eenvoudig zelfstandig een eerdere release worden uitgerold.
De applicatie wordt op het platform uitgevoerd als één of meerdere stateless processen.
In het simpelste geval kan dit een standalone script of taak zijn, complexere applicaties kunnen bestaan uit verschillende processen welke 1 of meerdere instanties draaien en individueel kunnen worden op- of afgeschaald.
In de ideale situatie zijn Managed Apps stateless, dit houdt in dat alle data welke persistent moet zijn wordt opgeslagen in een stateful backing service, meestal een database. Sessies voor bijvoorbeeld webapplicaties passen goed in datastores welke tijdsverloop ondersteunen zoals Redis. Uploads of statische content kunnen worden opgeslagen op S3-compatible storage.
Omdat applicaties niet altijd volledig stateless kunnen opereren zijn er mogelijkheden om een RWX (Read-Write-Many) filesystem te mounten en data op deze manier persistent te maken. Omdat dit impact kan hebben op de schaalbaarheid van de applicatie, is het altijd goed om deze mogelijkheden met onze sales afdeling te bespreken.
Er wordt verwacht dat Managed Apps luisteren op een poort, denk hierbij aan poort 80 voor een webserver of 3000 voor NextJS. Als onderdeel van het Managed App Platform wordt de routering naar deze poort(en) op basis van templates en configuraties van Shock Media ingesteld. In de Supported Frameworks zijn default poorten gespecificeerd, wanneer deze worden aangehouden zorgt het platform dat de verzoeken op de juiste plek aankomen.
Mocht het niet mogelijk zijn de default poort te hanteren, kan hier altijd een uitzondering voor worden geconfigureerd.
Schaal op via het procesmodel. HTTP verzoeken kunnen bijvoorbeeld worden afgehandeld door het web proces terwijl langlopende asynchrone processen door workers worden afgehandeld. Wanneer de eerdere factoren in acht zijn genomen kan er door middel van horizontaal schalen op een eenvoudige en betrouwbare manier resources op en af worden geschaald.
Het Managed App Platform biedt ondersteuning voor het instellen configureren van de zogeheten HorizontalPodAutoscaler, door met elkaar in gesprek te gaan kunnen duidelijke limieten worden ingesteld en kunnen de Managed App of workers bij pieken automatisch opschalen. Zo kan er grip op de kosten worden gehouden en zijn resources beschikbaar wanneer dit écht nodig is.
De processen in een Managed App zouden wegwerpbaar moeten zijn, dit houdt in dat deze elk moment gestart en gestopt moeten kunnen worden. Processen moeten streven naar het minimaliseren van de opstarttijd. Idealiter duurt het opstarten van het hoofdproces in de pod enkele seconden zodat de applicatie snel klaar is om verzoeken of taken te ontvangen. Een korte opstarttijd zorgt voor meer snelheid voor het releaseproces en het opschalen.
Daarnaast is het van belang dat de applicatie bij het afsluiten de verbindingen afrondt en een graceful shutdown uit kan voeren. Dit is vooral van belang bij het stoppen van een versie van de applicatie na een nieuwe deployment, afschalen na pieken of wanneer de applicatie verplaatst moet worden naar een andere node binnen het Platform.
Bij het gebruik van het Managed App Platform is het belangrijk om de ontwikkel en productieomgeving zo gelijk mogelijk te houden. Om hierin vanaf de basis ondersteuning te bieden zijn de Test, Acceptatie en Productie omgeving van de OTAP straat inbegrepen bij elke Managed App. Deze omgevingen zijn gelijk om Continuous Integration en Delivery zonder de complexiteit mogelijk te maken. Bij de lokale ontwikkeling is het van belang om gelijke backing services te gebruiken om op deze manier incompatibiliteit te voorkomen.
Behandel logs als event streams. Stuur de logs van de applicatie naar stdout, schrijf deze niet weg naar een file. Deze logs kunnen tijdens lokale ontwikkeling eenvoudig op de voorgrond worden bekeken door de ontwikkelaar. In Test, Acceptatie en Productie worden deze streams opgepakt en doorgestuurd naar de Observability oplossing, hier zijn logs voor een langere periode inzichtelijk. Ook is het mogelijk om logs in realtime via de Maintenance omgeving te bekijken middels shockctl tail.
Naast de processen welke nodig zijn om de applicatie te serveren is het vaak nodig om eenmalige administratieve taken uit te voeren, denk hierbij aan:
Eenmalige beheerprocessen moeten in dezelfde omgeving worden uitgevoerd als de reguliere, langlopende processen van de app. Beheercode moet samen met de applicatiecode worden meegeleverd om synchronisatieproblemen te voorkomen.
Om deze taken mogelijk te maken kunnen entry-scripts of de Maintenance omgeving gebruikt worden.
Mocht je nog ergens tegen aan lopen, of mocht er informatie missen op deze pagina, laat het ons dan gerust weten! Wij staan dag en nacht klaar om je verder te helpen, en houden er van om feedback van onze trouwe partners/klanten te horen.