Bij Royal FloraHolland was er sprake van een aantal directe aanleidingen:

• Royal FloraHolland stond op het punt om upfront te gaan investeren in een on-premises datacenter, inclusief bijbehorende beheer. De vraag ontstond of het dan niet beter was om naar de cloud te transformeren;
• Royal FloraHolland was in een deel van het bedrijf volop aan het werken aan de digitale nieuwe wereld en dat deden ze in de AWS-cloud;
• Er was een grote investering nodig om de applicaties qua software versies weer up-to-date te brengen. De vraag ontstond of dat niet beter meteen kon worden geïmplementeerd in de cloud.

Daarnaast waren er een aantal doelstellingen die met een transformatie naar de cloud bereikt zouden kunnen worden:

• Pay-per-use realiseren: Royal FloraHolland is een bedrijf met veel pieken en dalen in de processen. Denk aan bijvoorbeeld Valentijnsdag of Moederdag waarop de vraag naar bloemen significant hoger is dan op bijvoorbeeld een dag in januari. De Infra was op dat moment nog traditioneel ‘gesized’ op de pieken en was op de overige dagen ruimschoots ‘oversized’;
• Time-to-market versnellen: De infrastructuur uitrollen en applicatie voortbrenging waren voornamelijk handmatige activiteiten welke sneller konden worden uitgevoerd;
• Kwaliteit verhogen: Er waren veel zogenaamde ‘P1’s’;
• Complexiteit verminderen: Er was sprake van veel gedeelde infrastructuur, hetgeen tot gevolg had dat applicaties ‘last’ van elkaar hadden bij incidenten en updates. Ook was er sprake van veel applicaties die mogelijk niet meer gebruikt werden.

De oplossing voor Royal FloraHolland

In onze applicatie gerichte aanpak waren de solution architecten de spin in het web. Wat zij in hun domein deden was:

1. In kaart brengen huidige situatie;
2. Het ontwerpen van de toekomstige situatie binnen de kaders van de principes, zoveel mogelijk gebruik makend van de cloud mogelijkheden, binnen aanvaarbare kosten en met het oog op toekomstig beheer;
3. Het begeleiden van de teams door ze mee te nemen in de cloud: Het maken van cloud scripts, een ci/cd pipeline, code aanpassen, migratie aanpak, in productie name plan en uiteindelijk een ‘zero risk’ in productie name.
   
   

Parallel hieraan werkten we aan het uitbreiden van de AWS landingzone op basis van de vereisten van de ontworpen workloads, zodat we de vraag nét voor bleven. Dit deden we door aan de ene kant een enabler team in te richten die zich focuste op het maken van herbruikbare bouwblokken, en aan de andere kant een dagelijkse stand-up te organiseren om kort de impedimenten te bespreken die uit de teams kwamen.

Het resultaat voor Royal FloraHolland

Bij de afronding van een project kijk ik altijd naar de kwantitatieve en kwalitatieve resultaten. De kwantitatieve resultaten laten zien dat we:

• Meer dan 125 applicaties hebben uit gezet, inclusief de onderliggende infrastructuur. In veel voorkomende gevallen hebben we eerst de data gearchiveerd in AWS;
• Meer dan 100 applicaties naar AWS hebben getransformeerd. Dat klinkt misschien als niet echt veel, maar bedenk dat het hier ging om meer dan 450 applicatiecomponenten die we naar N-1 hebben gebracht en geschikt hebben gemaakt naar de cloud, voor elke applicatie AWS-scripts en een CI/CD pipeline hebben gemaakt én de applicaties (soms gefaseerd) met zero risk naar productie hebben gebracht. Elke storing is er natuurlijk één te veel, maar het maakt me wel heel trots dat we gedurende die periode slechts één storing hebben veroorzaakt;
• Verder bleek een aantal met name logistieke applicaties niet naar de cloud te kunnen, vanwege latency problemen. Dat bleken er overigens veel minder te zijn dan vooraf verwacht, dus die hebben we wel naar N-1 gebracht maar dan op een nieuw on-premises omgeving. Wat opviel was dat een behoorlijk aantal pakket leveranciers nog niet aan de cloud toe is. Zij konden geen garanties geven dat hun pakket op de cloud zou kunnen draaien. Noodgedwongen hebben we ook die op de nieuwe on-premises geïmplementeerd. Uiteindelijk ging het in totaal om 13 applicaties en pakketten.

Kwalitatief

• Alle Hardware en Software producten zijn op N-1 gebracht, waardoor ze dus weer jaren door de leveranciers ondersteund worden;
• Een aantal incourante technologieën is uitgefaseerd, zoals Powerbuilder en CA:Gen, Progress;
• Alle Source code is centraal geconsolideerd;
• Voor alle applicaties is een ci/cd proces ingericht, gebaseerd op dezelfde template, zodanig dat voor beheer niet meer op de machines ingelogd wordt en dat nieuwe versies eenvoudig in productie te brengen zijn;
• Logging, monitoring, back-up en archivering is uniform ingericht, hetgeen de beheer werkzaamheden eenvoudiger maakt. Deze zijn allemaal geïmplementeerd in herbruikbare enabler bouwblokken, gemaakt voor generieke (beheer)processen;
• In het kader van security is een strikte Sandbox-staging-live(OTAP)-scheiding toegepast, zijn de AWS resources ge-encrypt en zoals al eerder gezegd is de toegang tot de machines tot het uiterste minimum beperkt;
• Veel AWS resources staan/gaan uit, indien niet nodig. Bijvoorbeeld de testomgevingen in de avond en het weekend;
• Tot slot, de medewerkers in de teams hebben een grote stap richting de toekomst gemaakt.
  
  

Terugkijkend naar de doelstellingen betekent dit dat de gewenste Pay-Per-Use is geïmplementeerd, de beoogde Time-To-Market is versneld, de overall kwaliteit is verhoogd en de lockin met de infra is verdwenen. Ook is het landschap veiliger, wendbaarder en sneller geworden. Kortom, een succesvol project.