Geen enkele architectuur kan zonder goed fundament

Een goed fundament is onmisbaar voor elk project dat veiligheid en betrouwbaarheid als uitgangspunt heeft. Dus ook voor het soort projecten waar wij aan werken; niet met bouwstenen in de traditionele zin, maar met digitale bouwstenen.

Wij werken bij Sentia al vanaf het prille begin volgens het principe dat ‘we’re in it for the long haul’. Wij zijn er voor de lange termijn, en zorgen dan ook dat de bedrijfskritische IT-projecten die we voor onze klanten uitvoeren stabiel, veilig, duurzaam en efficiënt zijn. En dat laatste zowel qua gebruik en prestaties als qua kosten. Vandaar ook onze nauwe band met Amazon Web Services, die heeft geresulteerd in het AWS MSP (Managed Service Program) partnership. Want feitelijk streven we hetzelfde na: een oerdegelijke architectuur voor onze klanten.

AWS heeft dat streven handen en voeten gegeven via zijn Well Architected Framework. En dat framework zetten wij weer in voor onze klanten. Hieronder worden de voordelen van het Well Architected Framework toegelicht.

Well Architected Framework
Voor een simpele applicatie is het ontwerpen van een architectuur niet zo complex of kostbaar. Dat is natuurlijk anders bij een grote SaaS-oplossing, of bij een applicatie met duizenden of zelfs miljoenen gebruikers. Dan is een stevig en goed doordacht fundament, oftewel een goed ontworpen architectuur, cruciaal. Dat stevige fundament is van grote invloed op de rest van het digitale ecosysteem, en speelt een belangrijke rol in zowel de gebruiksvriendelijkheid en de snelheid van de applicatie als in de kosten om de applicatie te draaien.

Het fundament dat organisaties leggen door het Well Architected Framework te gebruiken, bestaat uit vijf pijlers:

• Operational Excellence: de mogelijkheid om systemen uit te voeren en te monitoren zodat ze waarde toevoegen, en om structureel processen en procedures te verbeteren
• Security: de mogelijkheid om informatie en systemen te beveiligen en tegelijk inschattingen te maken van de risico’s en mogelijke verbeteringen in de beveiligingsstrategie
• Reliability: de mogelijkheid om te zorgen dat een systeem te allen tijde goed functioneert en dat het zich herstelt bij storingen, onder andere door te voorzien in oplossingen bij fouten in de configuratie of netwerkproblemen en door resources op en af te schalen bij drukke en minder drukke periodes;
• Performance Efficiency: de mogelijkheid om computing resources efficiënt in te zetten, en flexibel in te spelen op een wisselende vraag ernaar;
• Cost optimization: de mogelijkheid om kosten te minimaliseren door goede analyses en optimale schaalbaarheid te garanderen.

Binnen het framework zullen echter wel keuzes gemaakt moeten worden. ‘Operational Excellence’ en ‘Security’ zijn altijd belangrijk, maar het belang van de andere drie pijlers kan per organisatie of situatie verschillen. Er zijn bijvoorbeeld bedrijven die ervoor kiezen de betrouwbaarheid van de applicatie uit kostenoverwegingen niet op de volle 100% te zetten, maar hun applicatie in eerste instantie in één regio uit te rollen met daarnaast wat offsite-backups in plaats van meteen over te gaan tot een uitrol in meerdere regio’s.

Een belangrijk afweging daarbij is natuurlijk hoe kritiek de workloads zijn. Een overheidsdienst, een bank of een ziekenhuis zal waarschijnlijk kiezen voor uitrol meerdere regio’s omdat de desbetreffende applicatie altijd beschikbaar moet zijn, terwijl er bij een kleine retailer geen man overboord is als hij heel even eruit ligt door een storing.

Ontwerpregel 1: zorg voor een schaalbare omgeving
AWS heeft ook een aantal belangrijke ontwerpregels geformuleerd voor het bouwen van cloudapplicaties. De eerste, cruciale regel is dat je niet inschat hoeveel capaciteit je mogelijk nodig hebt om de applicatie goed te draaien, maar dat je gewoon zorgt dat de cloud door middel van autoscaling extra resources kan aanspreken als de vraagt stijgt. Als een applicatie eenmaal draait en je weet wat de basisload is, dan pas kun je kan je gaan kijken hoe je je efficiency en kosten kunt optimaliseren.

Ontwerpregel 2: test en los op
‘Meten is weten’ geldt net zozeer in de bouw als in de IT. Test je systeem, en wel op productieschaal. Alleen op die manier kun je zien hoe je architectuur reageert bij zwaardere workloads en kun je mogelijke bottlenecks lokaliseren en voorkomen. Meer dan 15 minuten heb je niet nodig voor een dergelijke zware simulatie. En die is bovendien heel kostenefficiënt, omdat je in de cloud kunt betalen voor workloads per minuut. De investeringen zijn zeer beperkt, de inzichten die je vergaart enorm waardevol.

Ontwerpregel 3: automatiseer
Laat de tools het werk doen; pas zo veel mogelijk automatisering toe om de architectuur op of uit te bouwen. Hierdoor kun je gemakkelijker monitoren en sneller inspelen veranderde omstandigheden dan wanneer je je toevlucht moet nemen tot handwerk.  

Ontwerpregel 4: innoveer!
Er staat een enorm arsenaal aan tools tot je beschikking, en dat wordt alleen maar groter. Gebruik die tools en experimenteer ermee! Blijf openstaan voor innovaties, en beoordeel elk onderdeel in de architectuur ook op zijn eigen merites. Als je de onderdelen los ziet van het geheel en je ze - net als de traditionele architect - als separate bouwblokken behandelt, kun je ze ook gemakkelijker vervangen door modernere alternatieven die efficiënter, sneller of goedkoper zijn.

Een huis wordt niet in een namiddag ontworpen. Een applicatie net zo min. Neem je tijd. Analyseer en test en besluit op basis van de data wat het beste model is voor een bepaalde situatie. En je zult zien dat je een constructie neerzet ‘for the long haul’ als je maar begint met een goed fundament. 

Nieuwsgierig hoe u uw AWS-fundament zo goed mogelijk kunt ontwerpen om innovatie en ontwikkeling te versnellen?