Wanneer we hypes zoals kunstmatige intelligentie en het internet of things in perspectief willen plaatsen, helpt het om hypes uit het verleden te bestuderen en onszelf een paar vragen te stellen. Wat werd er precies beloofd? Hoe pakte dit in de praktijk uit? En was het werkelijk van nut? Cloud computing is een goed voorbeeld, omdat het de hypecyclus heeft doorlopen en de ‘helling van de verlichting’ nadert (als we Gartner moeten geloven).
Laten we eens kijken naar de huidige situatie rond de cloud, hoe die de regels van het spel heeft veranderd, hoe die zich ontwikkelt en hoe we de monitoring daarvan het beste kunnen aanpakken.
Bakken met geld
Nu we de hypecyclus hebben doorlopen, blijkt dat de cloud een blijvertje is en dat er een berg geld aan te verdienen is. Volgens Gartner zal er in 2021 voor ruim 23 miljard dollar worden besteed aan cloud-gebaseerde infrastructuurdiensten. En één ding is duidelijk: het maakt niet uit wie de eerste was, hoewel dit wel belangrijk lijkt te zijn voor veel dienstverleners die zich in gehypte technologie specialiseren (ja ik heb het over jou, 5G!). Want inmiddels hebben alle grote spelers zich een flink stuk van de taart toegeëigend. Daar kunnen 5G-spelers nog wat van leren.
Cloud computing heeft ook voor een verandering gezorgd in de manier waarop bedrijven technologie benaderen. Het is niet langer de vraag óf ze naar de cloud moeten overstappen, maar naar wélke cloud. En ze moeten niet alleen een cloud provider kiezen, maar ook beslissen of ze een publieke of private cloud gaan gebruiken. Momenteel wordt circa 5 procent van alle it-diensten van de publieke cloud naar de private cloud verhuisd. De reden hiervoor is waarschijnlijk dat deze diensten nooit in de publieke cloud hadden mogen staan.
Geen sprake van kiezen of delen
Verder is duidelijk geworden dat de cloud geen eindbestemming is, hoewel dit op het toppunt van de hype heel anders leek. Toen ging het nog om de vraag of je alles op locatie wilde houden, of alles in de cloud onder wilde brengen. Inmiddels is duidelijk dat deze tweedeling enigszins misleidend was. Er is absoluut geen sprake van kiezen of delen. De cloud is simpelweg uitgegroeid tot een operationeel instrument.
De vraag die veel bedrijven en organisaties zich nu stellen is niet ‘Hoe stap ik over op de cloud?’, maar ‘Hoe kan de cloud mijn processen ondersteunen?’ Deze belangrijke verschuiving verandert de manier waarop bedrijven oplossingen inrichten. En het betekent dat ze alle eisen goed in kaart moeten brengen; welke it-diensten ze in een publieke cloud kunnen hosten, welke diensten ze in een private cloud moeten onderbrengen en welke diensten beter af zijn in een traditionele architectuur op locatie. Criteria zoals de schaalbaarheid van diensten, middleware voor de informatie-uitwisseling tussen omgevingen en de beveiliging, spelen stuk voor stuk een rol bij de beslissing welke zaken er naar de cloud kunnen.
Hybride omgeving
Wanneer bepaalde diensten en onderdelen van de infrastructuur in de cloud eindigen en andere op locatie worden aangehouden, resulteert dat in een hybride infrastructuur. Dat is de huidige realiteit voor de meeste organisaties. Dit kwam ook naar voren in een discussie met mijn collega Greg Campion in deze video over de toekomst van it-infrastructuren.
Om een lang verhaal kort te maken: omgevingen op locatie zijn een blijvertje. Veel bedrijven die data lokaal nodig hebben voor productiedoeleinden, willen dat die ook lokaal wordt opgeslagen. Daar zijn allerlei redenen voor aan te wijzen, zoals zorgen over de bandbreedte en de simpele wens om geen productiedata aan een publieke cloud toe te vertrouwen. Voor financiële instellingen is data extreem gevoelig. Daarom wordt die uit beveiligingsoverwegingen op locatie aangehouden. Maar de gegevens die lokaal worden verwerkt, belanden deels toch in de cloud voor analysedoeleinden, uiteraard nadat ze zijn geanonimiseerd.
Dit alles resulteert in moderne hybride omgevingen met een steeds complexer karakter. Er is sprake van diensten en data in de publieke cloud en weer andere diensten en data in private clouds. Meestal wordt gebruikgemaakt van orchestration-tools om alles met elkaar te verbinden. Een van de belangrijkste factoren die aan de complexiteit bijdragen is het feit dat het netwerk voortdurend verandert. En als cloud providers bestaande functionaliteit wijzigen of nieuwe diensten introduceren, zullen bedrijven hun eigen infrastructuur moeten herzien om de veranderingen bij te benen.
Deze complexiteit is van invloed op het verhelpen van storingen en problemen: it-beheerders moeten precies weten waar die zich voordoen.
Trendbewaking
Voor hybride infrastructuren zijn de monitoringprincipes die decennialang werden gehanteerd niet langer toereikend. We moeten dus eerst inzicht krijgen in hoe we de monitoring aan de nieuwe situatie kunnen aanpassen.
Ten eerste zijn de traditionele monitoringprincipes nog altijd bruikbaar voor traditionele netwerken en hardware op locatie, van routers tot switches en servers. Wat dat betreft verandert er dus niets. Ten tweede is het nog altijd mogelijk om diensten in publieke clouds te monitoren met behulp van de tools en statistieken die door cloud providers beschikbaar worden gesteld. Tot zover lijkt het allemaal gesneden koek. De realiteit is echter dat omgevingen ongelijksoortige technologieën bevatten en dat diensten waarschijnlijk in verschillende clouds worden gehost. Dat maakt monitoring er een stuk complexer op.
Hoe kunnen we nu tegemoetkomen aan de nieuwe monitoringeisen? Hieronder gaan we in op een paar manieren waarop monitoring zal moeten veranderen om aansluiting te vinden bij de nieuwe situatie.
Omdat cloud providers zelf al voor monitoring zorgen, hoeft software voor netwerkmonitoring zich niet op deze diensten te richten. In plaats daarvan moet je zelf bepalen welke statistieken het meeste nut hebben en een manier vinden om die in de juiste context te plaatsen. De sleutel tot succes: voorkom dat je bij verschillende cloud providers moet inloggen om aan data te komen.
Een centraal dashboard
Als je werkt met metingen en statistieken uit verschillende bronnen, zou je je monitoringstrategie in één overzicht moeten voorzien van alle kernaspecten van de infrastructuur. Verzamel gegevens en voeg ze samen op een centraal dashboard, zodat je de hele infrastructuur in één oogopslag kunt zien. Het doel is niet om te zorgen voor een een-op-een-weergave van de infrastructuur, maar om alleen de belangrijkste data op een centrale locatie te verzamelen.
SNMP was altijd het protocol bij uitstek voor de monitoring van hardware omdat het overal aanwezig was. Tot op de dag van vandaag is vrijwel elk apparaat dat van de lopende band afrolt benaderbaar via SNMP. Maar door de opkomst van clouddiensten en iot-apparatuur is dit protocol straks niet langer de absolute norm.
Het wordt daarom tijd om over te stappen op ‘rest api’. Ten eerste kunnen diensten die in de cloud draaien ermee worden bevraagd. Ten tweede bieden steeds meer fabrikanten een ‘rest api’ aan waarmee data over de status en werking van hun hardware kan worden opgevraagd. Een bijkomend voordeel van het gebruik van rest api voor monitoring van hardware en it-diensten is dat je hiermee data kunt onderbrengen in het centrale overzicht waar ik het eerder over had.
Technologieën, platforms en diensten samenbrengen
Nu de hype rond de cloud begint uit te doven, hebben we wat meer duidelijkheid over wat die wel en niet kan doen, en hoe we de voordelen ervan het beste kunnen benutten. En die helderheid gaat gepaard met een beter begrip van hoe we de cloud kunnen monitoren. Het gebruik van de cloud en de integratie daarvan met de huidige infrastructuur zal de komende jaren alleen maar toenemen. Daardoor wordt het steeds belangrijker om manieren te vinden om informatie over ongelijksoortige technologieën, platforms en diensten samen te brengen binnen een centraal overzicht.
De term cloud-gebaseerde infrastructuurdiensten is nog niet synoniem aan de cloud want het kan namelijk ook een Software-Defined Data Center (SSDC) on-premise betekenen. En daarbij kan de on-premise oplossing uiteindelijk ook een gedeeld datacenter zijn. In het overigens goede verhaal kom ik niks tegen over de kosten wat volgens mij toch één van de business drivers is. Want het hele idee achter de hybrid cloud gaat om de meest voordelige workload plaatsing. Met het opschuiven van de hard- naar software zagen we bij cloud-gebaseerde diensten vooral de kostenverdeling veranderen, onder de streep werd het duurder omdat de service effectieve insteek niet gelijk is aan een resource efficiënte benadering. Providers zullen niet zo snel informatie over de bezettingsgraad van de infrastructuur geven omdat ze vooral de marge per vloertegel willen verhogen.
Ik ben een fan en gebruiker van PRTG (product van bedrijf van schrijver).
Ik ben ook een gebruiker van diensten van diverse cloud providers zoals AWS, Azure en GCP.
Een groot deel van het monitoren gebeurt meer en meer op microservices en serverless wat gewoon lastiger is met een traditionele benadering. Het signaleren van incidenten gebeurt steeds meer op log niveau: Als dit gebeurd, doe dan dat. Nu zijn er wel specifieke oplossing voor, maar deze zijn in mijn ogen onnodig duur. De tools van de cloud provider zelf zijn zeer krachtig, maar het kost ook veel inspanning om deze naar je hand te zetten.
Rest api’s zijn weliswaar de feitelijke standaard, maar zeker niet ideaal. We gebruiken meer en meer GraphQL als de standaard API en leent zich beter om data op een generieke manier te query-en. Toch zie ik nog wel een behoorlijke ruimte voor monitoring ontwikkeling.
Kansen genoeg.
Dan nog puntje van verbetering voor PRTG. De interface heeft nog steeds een hoge leercurve, als ik PAESSLER was zou ik vanaf scratch een nieuwe interface naast de huidige bouwen die in het begin misschien veel functies mist, maar een hogere adoptiegraaf kent. Daarnaast blijft het vervangen van TLS certificaten een moeizaam proces en is het toepassen van Let’s Encrypt onnodig moeilijk.
De cloud bestaat niet. Bedrijven zoals Amazon, Google en Microsoft bieden gewoon een framework aan die software defined computing mogelijk maakt (via Rest API’s en console). Grote onderdelen worden zelfs meer en meer beschikbaar gesteld voor on-premises waarbij je dus dezelfde “taal” gebruikt als op de infrastructuur van de cloud provider zelf.
Maak het makkelijk en bedrijven zullen het omarmen….
@Redactie: Ik druk er ongeluk twee keer op plaatsen… Iedere klik op de knop wordt dus naar de back-end gestuurd en maakt een post…. geen rocket science om dat op te lossen! 1 van de reacties mag verwijderd worden.
Monitoren kent twee componenten: datacollectie en interpretatie/visualisatie van die data.
De meest gebruikte vormen van datacollectie zijn:
• WMI- en SNMP-agenten
• packet sniffing
• REST-API’s
• log/text-bestanden
De complexiteit van datacollectie wordt nog eens versterkt door het feit dat elke device-/applicatie-/cloud-leverancier zo zijn eigen invulling heeft. Dit wil zeggen dat zowel de dataset als de datacollectie-methode voor elke leverancier en daarbinnen voor elk product of dienst er anders uitziet. Met in het verlengde een interpretatie/visualisatie-kant die nogal eens varieert; als die er al is!
Fabrikanten van monitoring tools springen in dat gat. Maar leggen de focus bij het verkrijgen van een zo hoog mogelijk detail niveau aan gegevens (“big-data”); soms aangevuld met een vorm van auto-baselining (“AI en ML”).
Hoewel de meeste monitoring tools een hoog detail niveau kennen ontbreekt het aan een eenvoudige vorm van interpretatie/visualisatie waardoor je te maken krijgt met stijle leercurves: welke gegevens zijn er beschikbaar, waar zitten die en hoe ziet de interpretatie eruit voor een gegeven probleemsituatie. Laat staan de vertaalslag naar mogelijke oplossingen; of dan toch in ieder geval een oplossingsrichting.
De uitdaging rondom de inzet van monitoring tools zit hem dan ook veel meer in het gebruik en de daarmee samenhangende component die “kennis” heet! Want zelfs al hebben de verschillende DevOps en ITops teams alle denkbare gegevens beschikbaar, dan zal er nog steeds onderscheidt gemaakt moeten worden tussen “oorzaak” en “gevolg”. Zelfs als die gegevens verzameld worden middels geavanceerde, op AI-gebaseerde monitoring tools zoals bijvoorbeeld Ideiio (gebruiksrechten), Securonix (gebruikspatronen) of Dynatrace (beschikbaarheid en prestaties).
Met in het verlengde: stel je denkt de “echte” oorzaak gevonden te hebben, hoe ziet de “echte” oplossing er dan uit? En in hoeverre beïnvloedt die “echte” oplossing de goede werking van de rest van de keten/stack? Immers, mij lijkt dat je hoe dan ook wil voorkomen dat het van kwaad naar erger gaat?
Conclusie:
Uiteindelijk draait het om “kennis” en “mensen”. Immers, al is een server/applicatie/cloud-dienst nog zo snel, Microsoft/Amazon/Google/…/VMware/Cisco/PaloAlto achterhaalt hem wel.
Enkel mensen met de juiste kennis en de juiste tools (niet noodzakelijkerwijs in die volgorde!) zijn in staat daar wat aan te doen!
Dus inderdaad… kansen genoeg!
🙂
Deze reactie is verwijderd. Het was pure reclame voor een leverancier.
Bedankt voor jullie reacties en @Henri, bedankt voor de feedback!
Even een korte reactie van mijn kant:
De hoge dynamiek in cloud-omgevingen is inderdaad een uitdaging bij het monitoren van de infrastructuur. De prestatiemetingen van de infrastructuur, zoals we het kennen van hardwaremonitoring, worden eigenlijk minder belangrijk wanneer resources worden geleverd als een clouddienst. Leveranciers geven je vaak niet eens diepgaande prestatiegegevens (denk maar aan een Microsoft Exchange Server op locatie versus de gehoste versie, Exchange Online).
Voor de meerderheid van onze gebruikers is kennis van de beschikbaarheid van cloud-diensten (bijvoorbeeld de genoemde mailserver, maar ook SQL-diensten, etc.) van groot belang voor hun IT-monitoring, evenals kennis van de kosten van deze diensten, vooral wanneer deze dynamisch worden berekend op basis van gebruik. Hiervoor werken we al aan sensoren.
Ook werken we aan een geheel nieuwe webinterface en aan de fundamentele vernieuwing van onze API. Voor degenen die de voorkeur geven aan een installeerbare client, hebben we dit jaar al PRTG Desktop geleverd, die een directe vervanging is van de voormalige Enterprise Console.
Voor meer informatie over wat we van plan zijn, zie onze PRTG roadmap. Die kun je hier vinden: https://www.paessler.com/prtg/roadmap?hsCtaTracking=522d70b7-f750-4ec4-b64e-c876ec4d9dad|21c86036-d10f-4704-a1cb-c15e2e30fdb7 (@redactie, ik realiseer me dat een deel van deze comment product gerelateerd is, maar voor Henri waarschijnlijk wel waardevol)
Dag Wilco,
Thanks, ik bestudeer het. Ik denk niet dat de redactie hierover zou vallen. Het gaat om de inhoud en die wordt besproken. Zover ik weet zijn er geen regels waarin staan dat je het bedrijf waarvoor je werkt niet mag noemen ofzo. Het moet waarde toevoegen aan de lezer en de lezer moet begrijpen voor wie je werkt om daarmee een inschatting te kunnen maken.