Use Case: Enterprise applications op de Cloud

Probleemstelling

Tot nu toe heeft dit handboek de vele voordelen besproken van het gebruik van cloud: automatisch schalen, healthchecks, load balancers, on-demand resources en het pay-as-you-go-model. Nieuwe applicaties kunnen gemakkelijk ontworpen worden om gebruik te maken van deze voordelen. Het is echter moeilijker voor (legacy) enterprise applicaties die niet cloud native gebouwd zijn. Dit document focust zich op de oplossingen die geïmplementeerd kunnen worden op niet cloud-native applicaties, om zo (legacy) enterprise applicaties in de cloud te gebruiken.

Het probleem duikt vaak op in de applicatielaag, want het beste is om deze laag horizontaal te schalen (scale-out en scale-in ipv scale-up en scale-down). De database laag is minder problematisch. Deze kan vaak gemakkelijk overgezet worden naar een DBaaS oplossing zonder aanpassingen te maken aan de architectuur.

De aanpassingen die vaak gemaakt moeten worden aan de applicatie laag gaan over het stateless maken van de applicatie:

• Er dient een lijst van dependencies beschikbaar te zijn
• De app moet gemakkelijk deploybaar zijn (met een VM image/container, een jar/war file, of een installatiebestand)
• De app mag lokaal niets wegschrijven. Data dient ofwel naar een object storage te gaan of naar een caching/database layer
• User sessions (gebruikersessies) kunnen niet lokaal opgeslagen worden
• De omgeving moet afgesloten kunnen worden zonder dataverlies

Deployment

Deployment van een server inclusief de applicatie is bij veel organisaties vaak nog manueel werk. Om de applicatielaag automatisch te laten schalen of om self-healing te laten werken, dient dit geautomatiseerd te worden. Er moet nagegaan worden wat de exacte dependencies zijn van de applicatie. Het is best om dependencies te beheren via een dependency management tool. Enkele voorbeelden van zo’n tools zijn:

• Maven / Ant / gradle voor Java
• NodeJS: packages.json
• PHP composer
• Ruby Gems
• .NET NuGet, NPanday

Eenmaal alle dependencies beheert worden door een dependency tool, is het vaak niet meer moeilijk om de applicatie automatisch te laten deployen. De volgende stap is om nog enkele scripts te schrijven om de deployment taken automatisch uit te voeren.

Ten laatste, om de hele applicatie te deployen, dient ook het besturingssysteem gekoppeld te worden aan de applicatie. Dit kan gebeuren door de hele VM image te shippen, of door kleinere container packages (bvb. Docker) te gebruiken.

Stateless app: Sessiebeheer

De applicatielaag bestaat uit verschillende applicatieservers die naast elkaar draaien en die dataverkeer ontvangen van de loadbalancer. Om deze architectuur te laten werken moet de applicatie zelf stateless zijn. Dit betekent dat de applicatie lokaal niets mag wegschrijven. Alle data en nieuwe bestanden dienen ofwel naar de database layer te gaan, ofwel ergens anders opgeslaan te worden.

Een eerste horde is sessiebeheer. Applicaties schrijven vaak informatie weg over de informatie van een gebruiker van de applicatie. Deze sessies zijn heel vaak ontworpen door middel van het sessiebeheersysteem van de programmeertaal of het framework. Het is dan vaak ook niet zo moeilijk om de omzetting te maken van lokale bestanden naar een andere snelle laag, vaak een caching layer. Als caching layer wordt vaak memcache of redis gebruikt. Enkele voorbeelden van sessiebeheer die externe caching layers ondersteunen:

• Java Spring heeft een eigen HttpSession, dat de ingebouwde java HttpSession kan vervangen. Spring ondersteunt HttpSessions met redis
• ASP.NET heeft Session state provider, dat RedisSessionStateProvider kan gebruiken voor session state
• In PHP kan de php.ini aangepast worden om sessies weg te schrijven in memcache of redis
• Ruby heeft redis-rails, dat een volledige set van “stores” aanbiedt voor Cache en Sessies

Bovenstaande voorbeelden lossen het http sessie probleem op. Applicaties die niet als webapp zijn ontworpen, gebruiken andere technieken. De principes zijn echter vaak zeer gelijklopend.

Stateless app: bestanden

Applicaties maken ook nieuwe bestanden aan. Denk maar aan afbeeldingen of PDFs. Deze bestanden kunnen ook niet meer lokaal opgeslaan worden. Er zijn 2 mogelijkheden:

• De applicatiecode kan aangepast worden om extern storage te gebruiken
• De applicatiecode kan niet aangepast worden

In het geval dat de applicatiecode aangepast kan worden, dan zijn er veel mogelijkheden. Eén oplossing is om de Cloud SDK te gebruiken en deze te integreren in de applicatie. Wanneer er een bestand weggeschreven of terug ingelezen moet worden, dan kan de SDK gebruikt worden om externe storage aan te spreken. Voor AWS is dit bijvoorbeeld S3. Een voorbeeld:

Wanneer de applicatiecode niet aangepast kan worden, dan dient er op het besturingssysteemniveau een oplossing gevonden te worden. Het is mogelijk om een shared storage volume te koppelen aan elke applicatieserver en daar de bestanden naartoe weg te schrijven. Deze bestanden zullen dan onmiddellijk leesbaar zijn door alle andere applicatieservers. De oplossing is minder flexibel dan de code aan te passen, maar is zeker interessant voor legacy enterprise applicaties waar het vaak te duur of onmogelijk is om de code aan te passen. Een voorbeeld van deze oplossing op architectuurniveau: