“Write once, run anywhere”. Containers, de kortste klap voor ISVs naar een multi-platform, Hybride oplossing.

Het is een van de containerbegrippen die veel organisaties bekend voor zal komen “digitale transformatie”. Om als ISVs deze transformatie voort te zetten, wil je als ISV gebruik maken van een Multi-platform, ofwel een hybride oplossing.

 

Wesley Haakman, Intercept

Het is een van de containerbegrippen die veel organisaties bekend voor zal komen: “digitale transformatie”. Om als ISV deze transformatie voort te zetten, wil je als ISV gebruikmaken van een Multi-platform, ofwel een hybride oplossing. Maar wat houdt dit voor Independent Software Vendoren daadwerkelijk in? Hoe begin je? En als je containers gebruikt hoe beheer je het? Wesley Haakman, Lead Azure Architect bij Intercept: “herschrijf je software of lever een deel van je infrastructuur mee in je applicatie. Of als je nog flexibeler wilt zijn, gebruik een combinatie van beide”.

In een ideale wereld heb je één oplossing die voor al je klanten werkt, maar voor ISVs gaat dit niet op. Een deel van de klanten kan bijvoorbeeld een on-premises installatie of hosting op een ander platform vereisen. Wat doe je dan als ISV? Een van je opties is het aanbieden en ondersteunen van meerdere platformen, oftewel meerdere software versies parallel ontwikkelen. Een andere optie is op de traditionele manier doorontwikkelen, waarbij je NEE moet verkopen en je klanten gaat teleurstellen. In onze optiek is geen van beide een realistische keuze, maar wat dan wel?

Eigenlijk hebben we het over een andere, veel concretere vraag: “Hoe zorg ik er voor dat mijn software en service platform onafhankelijk zijn? Oftewel write once, run anywhere. Dit kan doorgaans op twee verschillende manieren:

  • Standaardisatie in code (bijvoorbeeld het gebruik van .NET Core);
  • een deel van de infrastructuur meeleveren met de applicatie (containers).

De ideale situatie bestaat uit een combinatie van beide. Echter is het herschrijven van de software naar een taal als .NET Core best een ingrijpende verandering en kan dit een behoorlijke impact hebben op je development afdeling.

Containers

Hoe begin je? Een verstandige en eenvoudige keuze is te starten met containers. Met containers maken we gebruik van een concept wat we al langer kennen: virtualisatie. Waar traditioneel het operating system op een gevirtualiseerd platform werd geplaatst en er min of meer een onafhankelijk van hardware ontstond, kan datzelfde worden gedaan met applicaties.

Als je containers toepast heeft iedere container een eigen set aan afhankelijkheden welke worden meegeleverd in de desbetreffende container. De afhankelijkheid van het operating system verdwijnt hiermee en de container engine neemt deze rol over. Het lijkt hiermee of een nieuwe afhankelijkheid wordt gecreëerd, namelijk: de container engine. Echter zijn container engines breed verkrijgbaar en worden multi-platform opgeleverd. Met andere woorden: er is altijd een container engine welke beschikbaar is voor het gewenste platform.

 

 

Containers maken veel efficiënter gebruik van de resources binnen een systeem, meerdere containers kunnen hierdoor op één systeem draaien. Dit in tegenstelling tot een configuratie zonder containers, waarbij je per applicatie een virtuele machine beschikbaar moet stellen. Een ander, niet onbelangrijk voordeel, is dat de inhoud van een container altijd hetzelfde is. Het bekende probleem “mijn test, acceptatie en productie omgeving zijn allen verschillend, wordt hiermee opgelost. Dit is bij containers niet meer van toepassing, of de container nu op systeem A of B draait, de inhoudt blijft hetzelfde en de afhankelijkheden worden meegeleverd. De zorgen wanneer je van acceptatie naar productie released gaat, worden hierdoor direct weggenomen.

Multi-platform

De container is een opzichzelfstaande entiteit en is hierdoor beperkt afhankelijk van het onderliggende besturingssysteem. Hierdoor ontstaat de situatie waarbij we een container op verschillende platformen kunnen uitrollen, zolang er maar een container engine beschikbaar is. Daarnaast zijn containers ook nog eens gestandaardiseerd waarbij het doorgaans niet uitmaakt op welke engine de container wordt uitgerold.

Enkele engines/platformen welke veel door ISVs worden gebruikt:

  • Docker;
  • Kubernetes;
  • Azure WebApps (App Service);
  • Azure Container Services;
  • Azure Kubernetes Services.

Voor de populaire engines is ook een cloud variant beschikbaar. Je kunt dan een enkele container zowel binnen Microsoft Azure als On-Premise bij je klant draaien. Een tweede, derde of een vierde versie van de applicatie is niet langer een vereiste.

Micro services

Containers zijn daarnaast uitermate geschikt voor het gebruik van Micro services. Binnen een Micro Service architectuur wil je juist kleine onderdelen van de totale applicatie kunnen wijzigen of uitbreiden, zonder dat er een totale “overhaul” of update van de applicatie nodig is. Deze modulaire opbouw is uitermate geschikt voor het gebruik van containers.

Het gebruik van een Micro Service architectuur brengt nog meer voordelen (en uitdagingen) met zich mee. Dit zullen wij binnenkort in een ander artikel toelichten. Interessant? Meld je gerust aan voor onze cloudrecources.

Management, Orchestration en DevOps

Ook containers dienen te worden beheerd. Het is vanzelfsprekend niet de bedoeling om iedere container handmatig te onderhouden. Wij adviseren je daarom dit onder te brengen binnen de DevOps processen van je organisatie.

Microsoft biedt je verschillende tools om het beheer van containers en de deployment naar een omgeving te vergemakkelijken. Zo kun je gebruikmaken van container registry. Op de images die hier worden opgeslagen, is eenvoudig versiebeheer toe te passen. Ook kunnen de containers vanuit de portal (of command line) gemakkelijker worden beheerd.

Met name als we kijken naar Azure Container Service en Azure Kubernetes Service, dan wordt het schalen, de hoge beschikbaarheid en het patchen van de omgeving automatisch voor je geregeld.

 

Bron: microsoft.com

DevOps

Uiteraard is het ook met containers mogelijk om DevOps practices als Continuous Integration(CI) en Continuous Deployment (CD) toe te passen. De bekende tooling als Visual Studio Team Services, Jenkins, Octopus Deploy en Chef bieden allen uitstekende plugins voor het zogenaamde builden en deployen van containers. Zo kun je de container builden binnen Visual Studio Team Services en kan de release automatisch plaatsvinden naar een vooraf gedefinieerde omgeving (bijvoorbeeld: Test, Acceptatie of Productie).

Conclusie

Containers zijn op vele gebieden toepasbaar en wij zien het gebruik van container principes snel groeien. Naast de technologische voordelen dwingt het gebruik van containers ook standaardisatie af en zijn er verschillende use cases en producten beschikbaar als het gaat om beheer. Door de multi platform gedachte kun je als ISV je dienst bij een grotere markt aanbieden en is de onderliggende infrastructuur niet langer een afhankelijkheid.

Bent u ook geïnteresseerd in wat containers in combinatie met Microsoft Azure voor u als organisatie kunnen betekenen? Neem gerust contact op en stel je vraag.