Hoe zorg je dat je je appontwikkeling en je backlog hand in hand gaan zodat je gebruikers zo snel mogelijk kunnen genieten van de functionaliteit die je wilt aanbieden. Zodat je kunt versnellen naar de markt.
Elke dag maken miljoenen gebruikers wereldwijd gebruik van de meest uiteenlopende applicaties (apps). Op een smartphone, tablet en een gewone (virtuele) desktop. We gebruiken apps zoals Word, Excel, PowerPoint en Outlook. Maar ook SharePoint, Teams en OneNote. Of apps voor de administratie, apps voor logistieke processen en voor klantbeheer. Of denk aan LinkedIn, Facebook en Twitter en echt heel veel andere soorten. Kortom appontwikkeling is een dagelijkse gang van zaken. Een populaire methode voor slimme ontwikkeling is DevOps. Uiteindelijk wil je dat die app ook ergens staat zodat deze beschikbaar is en mee beweegt met de vraag. Kortom je app moet het gewoon (blijven) doen.
Kubernetes is hip. Je eerste reactie is wellicht kuberwat. Wat zorgt er dan voor dat deze technologie plots zo populair is. En wat is het en wat kan jij ermee? Lees meer over dit onderwerp »
Juist vanuit de gedachte dat je app het altijd moet doen is het een mooi moment om eens te kijken hoe dan. Een populaire trend is het plaatsen van apps in containers. Ofwel functionaliteit ophakken en in kleine diensten aanbieden. Bij de appontwikkeling kan je tegenwoordig eigenlijk niet meer om Kubernetes en andere containerorkestratie heen. In bijna elk gesprek met softwarebedrijven komt de naam van deze Griekse stuurman voorbij. Daarom koers ik in deze blog naar wat containers voor je appontwikkeling kan betekenen.
Momentum van containerorkestratie tijdens appontwikkeling
Zeker wanneer je niet meer wilt nadenken over de capaciteit van de onderliggende infrastructuur van je app. En de maximale potentie van de verschillende beschikbare rekenkracht wil benutten. Dan is het niet zo raar dat je voor containerorkestratie kiest. Binnen die familie zie je Kubernetes, Service Fabric, Service Fabric Mesh en OpenShift ontstaan. Zeker ook binnen het Microsoft Azure ecosysteem is deze familie een snelgroeiende service.
Bovenstaande video laat goed zien hoe de game-ontwikkelaar van “The Walking Dead: No Man’s Land”, de maximale potentie uit de publieke cloud haalt door inzet van containterorkestratie en andere beschikbare technologie. Het eindresultaat is dat 16 miljoen gebruikers een stabiele en extreem snelle ervaring hebben.
Helemaal in lijn met de DevOps-cultuur willen we in kleine stappen ontwikkelen. Het liefst per functie. En deze ook in die diezelfde zelfde kleine stappen beschikbaar maken. Deze gedachte is volledig in lijn met containerorkestratie. Het idee is dat je elke functie of service apart laten schalen. Op die manier maak je optimaal gebruik van de rekenkracht. Verder niet onbelangrijk, zo maak je ook het leven van updates, patches en onderhoud een stuk overzichtelijker.
Een voordeel van containers is dus flexibiliteit, wat ontwikkelaars meer keuzevrijheid geeft en wat weer ten goede komt van de ontwikkelingsnelheid. Vanuit beschikbaarheid geredeneerd zijn containers makkelijk te verplaatsen. Dit betekent dat een container in theorie probleemloos op een server, on-premise, op een desktop of op een laptop kan werken. Je kunt dus bijvoorbeeld lokaal de container installeren, configureren, testen etc. en deze daarna overzetten naar een lokale of publieke cloud serviceprovider. Het is hierdoor eenvoudiger om containers uit te rollen waar ze het best tot hun recht komen, maar ook om bijvoorbeeld snel nieuwe capaciteit toe te voegen als het even druk is.
Kubernetes, Swarm, DC / OS vs Service Fabric
Containers winnen dus aan populariteit. Zeker bij het creëren van een microservice-applicatie-architectuur. Deze populariteit danken de containers bijvoorbeeld omdat iedere ontwikkelaar exact dezelfde versies gebruikt. Er zijn geen lokale verschillen meer. Een gelijkheid die je mee wilt nemen naar je productieplatform, zodat alle services identiek zijn van ontwikkelomgeving, tot testomgeving, acceptatie-omgeving en productie-omgeving. Alleen welke container-smaak kies je dan?
Als je appontwikkeling is gebaseerd op een Linux-omgeving en gebruik wilt maken van technieken zoals Swarm, Kubernetes of DC / OS gebruik je kort geschreven Azure Kubernetes Service (AKS). Bijvoorbeeld een typische app bestaande uit drie lagen (een webfront-end, caching-laag, API-laag en een database laag) kan worden gecontaineriseerd met een enkel dockerbestand. Geleidelijk kan je deze lagen transformeren tot kleinere diensten of functies. Het grootste voordeel is dat je onmiddellijk kan genieten van de voordelen van beschikbaarheid en flexibiliteit.
Azure Service Fabric (ASF) daarentegen gaat meer over alleen Azure infrastructuur en orkestratie. ASF is neutraal voor de infrastructuur. Dat is waarom het zowel op locatie als in elke cloud kan werken (zelfs op AWS). Dat is een geweldige optie voor teams die een app willen bouwen met behulp van microservices-architectuur op locatie. Dit helpt ook als de beslissing over het al dan niet overstappen naar de cloud nog niet is gemaakt. Met ASF kan je ook later overstappen, het porteren van je app van onprem naar de cloud is vrij eenvoudig. ASF is overigens ook een logische keuze als je je app in het server-ecosysteem van Windows wilt implementeren (Linux is overigens ook beschikbaar).
Hoort de identiteit bij je appontwikkeling
Je gebruiker zal toegang moeten krijgen tot je app. Waarschijnlijk wil je dat die kan inloggen en op basis van rollen of functies bepaal je wat een gebruiker voor rechten heeft. Alleen wil je gebruiker zo min mogelijk wachtwoorden onthouden. Los van het feit draagt het hebben van verschillende gebruikersaccounts en wachtwoorden niet bij aan de veiligheid. Zo kan ik mij voorstellen dat je tijdens jouw appontwikkeling rekening wilt houden met Multi Factor Authentication (MFA). Oftewel je gebruiker een sms sturen met een extra code. Ik sprak met een ontwikkelaar van een applicatie voor tandartsen. Ze hadden in eerste instantie zelf zoiets gebouwd. Hoe handig zou het zijn als je klant kan inloggen met zijn Office 365 account.
Azure AD is gebouwd op basis van tientallen jaren van identiteitsbeheer voor bedrijven en is een cloud gebaseerde directory en identiteitsbeheerservice. Azure AD is vrij vertaald een adresboek waar alle gebruikers, wachtwoorden en rechten in zijn opgeslagen. Dit zorgt voor een combinatie van directoryservices, toepassingstoegangsbeheer en identiteitsbescherming. Azure AD kan naadloos communiceren met eventuele traditionele on-prem directories.
De bedrijven die gebruik maken van Microsoft-technologie en zeker degene die productiviteitsapps uit de publieke cloud onttrekken hebben een Azure Active Directory (Azure AD). Het is mogelijk om Kubernetes-clusters uit te breiden met Azure AD-integratie. Hierdoor krijg je één waarheid en één identiteit. Bovendien kan je zo gebruik maken van MFA binnen Azure. Hierdoor is er ook een app beschikbaar voor de smartphone. En kan je ook beleid toepassen wanneer een gebruiker zich moet authentiseren met MFA.
Hiermee voorkom je dat je zelf een identiteitsoplossing moet ontwikkelen, onderhouden en tegelijkertijd maak je het makkelijker voor de gebruiker.
Met zonder handen de capaciteit beheren
Het is een van de belangrijkste onderdelen van het succes van de app. Beschikbaar zijn. Het is vreselijk irritant als door drukte je gebruikers niet kunnen inloggen of een bepaald proces niet kunnen opstarten. Dit soort onoverkomelijkheden gebeuren altijd op momenten dat het niet uitkomt. Traditioneel lossen we dat op door meer capaciteit toe te kennen dan nodig.
De meeste webshops zijn in de aanloop naar de feestdagen druk. Bovendien zie je dat Cyber Monday en Black Friday aan populariteit winnen. Volgens Forbes was in Amerika deze twee dagen goed voor 14 miljard dollar. Kortom beschikbaarheid is belangrijk op de momenten dat er vraag naar is. Lees verder »
Dus als we de infrastructuur elastisch kunnen maken en extra capaciteit kunnen toevoegen wanneer nodig, gaat technologie echt voor ons werken en kan jij je blijven focussen op de appontwikkeling. Dit is precies de kracht van werken met containers. De integratie met DevOps is hierbij een wezenlijk onderdeel. Direct vanuit je broncode kan je continu functionaliteit leveren. Op basis daarvan wordt het image voor je container gemaakt. Het container platform zorgt dat het image uiteindelijk aan je gebruiker wordt geleverd met de zogenaamde pods. Hoeveel pods er uiteindelijk beschikbaar zijn heeft met de capaciteitsbehoefte te maken.
In het Kubernetes-platform kan je op basis van gebeurtenissen sturen. Bovenstaande afbeelding illustreert deze werking. We kunnen als het ware triggers instellen. Komen er meer gebruikers binnen dan schalen we het specifieke onderdeel verder op. Keert de rust weer terug, zal de extra capaciteit weer worden opgeruimd. Mocht een bepaalde pod het om welke reden niet meer doen, zorgt het platform zelf dat er een nieuwe beschikbaar komt.
Hiermee vergroot je je nachtrust én bespaar je tegelijkertijd op kosten. Omdat wat je niet gebruikt hoef je ook niet voor te betalen.
Appontwikkeling staat en valt met inzichten
Een andere uitdaging met technologie zijn updates en upgrades. We kennen altijd de uitdaging dat dat in een productieomgeving lastig is. Vanuit de containergedachte pas je als het ware het image aan. Er zijn allerlei hulpprogramma’s beschikbaar om deze updates en upgrades automatisch naar de zogenaamde Azure Pipeline te versturen. Zoals eerder geschreven wordt het image dan gemaakt en komen er pods beschikbaar met je nieuwe versie. De oudere pods verdwijnen in een bepaald ritme. Hierdoor hebben je gebruikers er geen last van. Mocht je update toch niet werken zet kan je ook eenvoudig weer terug. Helemaal volgens de DevOps gedachte: fail fast, fail cheap.
Samenvattend kan je met containers het zogenaamde clusteronderhoud uitvoeren met geautomatiseerd patchen en upgraden.
Gezondheid bewaken met Azure Monitor
Inzicht hebben en houden is net als met autorijden cruciaal. Meten is weten is ook hier het devies. Het bewaken van de gezondheid en prestaties van je containers is belangrijk, zodat je kan zorgen dat de apps volgens verwachting blijven draaien. Net als met de traditionele infrastructuur zoals virtuele machines wil je het gewoon weten. Binnen Azure gebruik je hier bijvoorbeeld Azure Monitor voor. Zo krijg je realtime gedetailleerde gegevens tot je beschikking waarop je kunt sturen. Gaaf dat Azure Monitor nu ook beschikbaar is voor Kubernetes.
Het gebruik van containers zal de nieuwe standaard worden. Overigens is nog niet elke app geschikt voor deze technologie. Goed om eens naar je ontwikkel horizon te kijken en te bepalen of je je appontwikkeling wilt aanpassen aan deze trend :-). Een kleine koerscorrectie nu geeft een ander eindpunt later.
Heb je meerdere Azure omgevingen van bijvoorbeeld klanten die je wilt monitoren en beheren? Dan is het handig als je dat vanuit een dashboard kunt, kijk daarvoor eens naar Azure Lighthouse, dat is met dat doel ontwikkeld.
Referenties
[1] Microsoft (2018). Monitoring Azure Kubernetes Service (AKS) with Azure Monitor container health
[2] Microsoft (2019). Scaling options for applications in Azure Kubernetes Service (AKS)
[3] Microsoft (2018). Monitoring Azure Kubernetes Service (AKS) with Azure Monitor container health
ernstveen.wordpress.com 