Cloud, applicatietransformatie en de blinde vlek in containers

Bedrijven willen naar ‘de cloud’. Zo begint het meestal. Ik begin een workshop dan met de vraag aan de deelnemers om ‘cloud’ te definiëren. Dat leverde een aantal jaren geleden nog een bonte verzameling op aan allerlei beschrijvingen, tegenwoordig hebben de meeste bedrijven wel een aardig beeld van wat cloud voor een onderneming kan betekenen. Ze snappen ook dat de voordelen hoog in de cloudstack zitten: hoe meer applicaties je vanuit Software of Platform as a Service (SaaS en PaaS) kunt afnemen, hoe groter de kostenbesparingen. Anders gezegd: hoe meer je als standaard Lego-blokjes kunt afnemen, des te minder customization er hoeft plaats te vinden, des te groter de schaalvoordelen die zich weer direct laten verlaten in financieel voordeel, bijvoorbeeld door een kleinere beheerinspanning.

Je moet als architect wel goed kijken of en hoe SaaS en PaaS in de enterprise architectuur passen. Niet zelden betekent een cloud strategie dat de enterprise architectuur flink moet worden aangepast: enterprise architectuur wordt dan cloud enterprise architectuur. Het architectuurprincipe – hoe kom ik tot architectuur – blijft hetzelfde, de uitkomst is wezenlijk anders. Met de introductie van cloud introduceer je namelijk ook een ander service management model en andere financiële verrekenmodellen, iets waar je in de (business)architectuur rekening mee moet houden.

Applicatiestrategie

Het opstellen van een cloud strategie betekent een herdefinitie van het applicatielandschap. Een bedrijf heeft nu eenmaal een bestaand applicatielandschap en zal niet vanaf de tekentafel opnieuw beginnen met cloud native apps. De meeste vakliteratuur besteedt daarom veel aandacht aan applicatietransformatie, waarbij enterprise cloud vaak uitgaat van een hybrid cloud met zowel private stacks als public cloud zoals Amazon AWS EC2, Microsoft Azure, Google Cloud Platform en in het verre oosten Aliyun.com van Alibaba.Grosso modo heb je daarmee de grootste spelers in het veld wel te pakken.  Die applicatiestrategie biedt een aantal opties die samengevat kunnen worden met:

  • Retire: applicaties die geen toevoegde waarde meer hebben in het landschap en overbodig zijn geworden. Dit is het type applicaties dat in het mandje ‘sunsetting’ valt: ze kunnen uit. Natuurlijk moet je als architect wel nagaan of er businessfuncties zijn die elders kunnen worden ingevuld – in andere applicaties – of dat er een nieuwe applicatie moet komen. Een vervolgvraag is dan of je zo’n nieuwe applicatie als SaaS kunt afnemen, cloud native. Een vierde R – de R van Replace – is dan gerechtvaardigd. Microsoft voegt deze al toe in de applicatiestrategie naar enterprise cloud.
  • Rehost: applicaties die gemigreerd kunnen worden (physical to virtual of virtual to virtual) naar de cloud. Hier komen de containers in beeld: ik kom hier verderop in deze tekst uitgebreid op terug.
  • Rewrite: Rewrite suggereert dat je bestaande applicaties ‘herschrijft’, maar in feite hebben we het bij ‘rewrite’ over twee verschillende zaken. Rewrite kan betekenen dat een bedrijf een bedrijfsproces ‘herschrijft’ in een nieuwe applicatie die cloud native is (meer replace) of dat een applicatie inderdaad echt opnieuw wordt gescript. Dit gaat al meer naar application fabrics waarbij je applicaties vanuit een herbruikbare fabric schrijft, zoals .Net of Java.

Wat een bedrijf ook doet, de vraag is altijd: hoe blijf ik als bedrijf ‘in control’? Die vraag wordt nog belangrijker op het moment dat er workloads naar public clouddomeinen verschuiven. Het is de centrale vraag van service management. Bij een rewrite ga je vrijwel altijd terug naar een development-fase en heeft een bedrijf vanuit ontwikkeling controle, misschien wel in DevOps-constellatie. (Note: ik ga hier voorbij aan partijen als Apprenda die echt applicatietransformatie bieden door bestaande applicaties in een PaaS-structuur te gieten, waarbij bijvoorbeeld de database-laag naar PaaS-oplossingen worden gemigreerd eerste stap naar verdere modernisering van de bestaande applicaties. In een van de volgende publicaties zal ik hier nader op ingaan).

De ‘stay in control’-vraag speelt vooral bij rehost, helemaal als we gebruik gaan maken van containertechnologie. Containers zijn waanzinnig populair en dat is alleszins verklaarbaar. Containers verkleinen de afhankelijkheid van infrastructuur en maken een applicatie-implementatie ultiem schaalbaar. Het is de volgende stap in het loskoppelen van functies, applicaties en onderliggende hosts, zoals fysieke en zelfs virtuele machines. Je kunt applicaties installeren op een fysieke host, een virtuele host en in een container, waarbij een heel filesysteem wordt ingepakt en onafhankelijk van welke host dan ook gedistribueerd kan worden. Veel cloudarchitecten verwachten een enorme verschuiving naar containerarchitectuur binnen nu en twee jaar. Grote cloudpartijen spelen hier al op in: dat begon met Docker, maar inmiddels is het containerlandschap al verrijkt met containerdistributies zoals Google’s Kubernetes, Microsoft Azure Container Service, Amazon EC2 Container Registry en Quai.io voor CoreOs. Het eind is nog lang niet in zicht.

Extra laag

Containers hebben ontegenzeggelijk voordelen, maar het is nog wel een erg jonge technologie met de typische ‘kinderschoenen’-problematiek. Zoals vaak beginnen de uitdagingen in het speelveld van service management, of beter: de koppeling tussen service en service management.  We hebben het dan over monitoring.

Hoe blijf ik in control? Toen de eerste virtualisatieslagen werden gemaakt, was één van de eerste uitdagingen hoe je die virtuele machines moest monitoren. De traditionele monitoringsoftware zag immers alleen de fysieke host en kon alleen uit de voeten met metrics die uit de fysieke cpu en geheugen werden gehaald. Er werd een laag tussen de fysieke host en de applicatie geschoven die niet was voorzien in monitoring. Datzelfde probleem zien we nu weer bij containers: een laag tussen de virtuele hosts en de applicaties die nu in de containers zijn verpakt.

Eerst maar eens een blik werpen op de monitoring referentie architectuur (bron: https://wiki.cac.washington.edu/display/EA/Monitoring+Reference+Architecture ).

Monitoring Capabilities v2.7 (heat mapped)-453-45a8518e-0

Bij de introductie van containers moeten we kijken naar de onderste drie lagen van het model:

  • Design 5 (D5): Indentify development targets. Wat willen we monitoren? De containers of hetgeen zich in de containers bevindt? Het laatste. Je wilt weten hoe applicatie- en applicatiecomponenten zich in die containers gedragen. Vergelijk het met een echte container: de douane vindt die metalen bak op zich niet interessant, wel de inhoud.
  • Vervolgens kijken we naar Collect 6 (C6): discover assets to be monitored. Nogmaals: dat zijn niet primair de containers zelf, maar de objecten in de containers.
  • Integrate 2 (I2): Enrich. Hier wordt CMDB en service catalog nadrukkelijk genoemd, misschien wel de grootste uitdaging met containers. Zijn containers zelfstandige entiteiten in het landschap of slechts een tijdelijk transportmiddel om applicaties snel uit te rollen over virtuele hosts? Soms worden containers neergezet als mini-hosts, maar dat zijn ze niet. Dat maakt monitoring juist zo lastig. Toch zit hier de sleutel: uiteindelijk willen we één beeld van de werkelijkheid, één view op het landschap, één centrale repository waar alle componenten zich bevinden zodat verbanden kunnen worden gelegd tussen die componenten. We zijn tenslotte niet aan het monitoren om het monitoren.

We hebben applicatiemonitoring en we hebben monitoring voor de infrastructuur, ook in de public cloud. Denk aan een specifieke oplossing als CloudWatch voor Amazon, maar ook aan proposities zoals ServiceNow deze met ServiceWatch heeft als integraal platform waarbinnen allerlei monitoringgereedschappen als Microsoft SCOM, Nagios, BMC (Event Manager, Patrol), CA (Spectrum), HP (OneView)  en IBM Tivoli worden “geïntegreerd”. Probleem: we hebben niets voor de containers. Daar zit domweg een gat, tussen de infrastructuurlaag en de applicatielaag. Dat gaan we met traditionele monitoring niet oplossen, dus houden we een blinde vlek in de bewaking van ons totale landschap. We ‘zien’ de containers zelf wel, maar hebben geen zicht op wat zich in de containers afspeelt. Daar gaat het nu juist om.

Microservices (as a Service)

Cloud herdefinieert dus onze infrastructuur, onze applicaties, het service management én de manier waarop we ‘in control’ blijven.  Cloud, microservices en containertechnologie betekenen een herdefinitie van monitoring, waarbij we de containers bij zowel de applicaties als de infra moeten rekenen. We hebben dus behoefte aan monitoring die een gehele stack bewaakt: van boven naar beneden.

Traditioneel:

  1. Applicatie
  2. Operating Systeem
  3. Virtuele machine
  4. Hardware

Binnen de cloud monitoren we niet meer op de hardwarelaag. Dan wordt de monitoring bepaald door:

  1. Applicatie
  2. Container
  3. Hypervisor

De hypervisor (in public cloud) monitoren we met bijvoorbeeld CloudWatch of Azure Diagnostics: cpu, I/O, geheugen, netwerkverkeer. Binnen de container monitoren we filesysteem, geheugengebruik binnen de container, cpu-gebruik binnen de container en vooral queries op componenten in de container. Die queries worden door de applicatie uitgevoerd op de componenten in de container: de applicatie monitoren we daarom vooral op throughput – hoeveel tijd verstrijkt er tussen het stellen van de vraag en het verkrijgen van het antwoord.

Vooralsnog zijn er nog niet veel producten op de markt die een integrale monitoring van containerlandschappen aankunnen. Sysdig is, voor zover bij ondergetekende bekend is, een van de weinige partijen die zichzelf positioneert als een partij voor ‘Monitoring as a Microservice’. Dit bedrijf, opgericht door de mannen die ook Wireshark bedachten,  monitort in de Docker-containers. Om dat te kunnen moet je van alle producten die in die containers worden opgeslagen, weten hoe ze zich gedragen en hoe ze communiceren met andere producten (API’s). Sysdig doet dit inmiddels voor een hoop producten, waaronder webservices (Apache, Tomcat), databases (SQL, Postgre, MongoDB), diverse Linux-distributies (Red Hat,  CentOS, Ubuntu) en scripting platformen (PHP, Python). Natuurlijk ondersteunt het de verschillende containerdistributies, waaronder Kubernetes en Amazon ECR. Let wel: veel van bovenstaande bevindt zich nog in bèta-versie, maar de ontwikkelingen zijn veelbelovend.