Interview: De Agent als beheertool

Hij heeft niet de uitstraling van een ondernemer. Mark Sutherland komt, met zijn witte baardje en zijn brilletje, eerder over als een hobby-programmeur, die na jaren in loondienst een eenmanszaakje is begonnen, en daarmee redelijk rond kan komen.

Maar de oprichter van Kaseya kan tevreden zijn. Het bedrijf, dat sinds vijf jaar echt van de grond aan het komen is, groeit als kool met zijn software voor Managed Services. Ten grondslag van de Kaseya-software ligt een agent-architectuur die Sutherland samen met medeoprichter Paul Wong ontwikkeld heeft.

Hoe zijn jullie aan de agent-architectuur gekomen?

We werkten al een tijdje voor een securitybedrijf, en die leverde onder meer aan de Amerikaanse NSA, de National Security Agency. In 2000 ben ik samen met Paul (Wong, red.) Kaseya begonnen, en zijn we gaan werken aan een applicatie voor endpoint security.

Vrij snel kwamen we erachter dat we daarvoor een architectuur nodig hadden die in willekeurig elk netwerk kan opereren. Dat bleek nog best lastig. Een van de problemen die we bijvoorbeeld moesten oplossen was de firewall: hoe wordt de communicatie in stand gehouden, ongeacht hoe de firewalls erin hangen. En dat geldt voor meer zaken.

We konden, vonden we, eigenlijk niet erom heen dat we een architectuur met agents nodig hadden. Ze werken zelfstandig, en zijn minder afhankelijk van de infrastructuur omdat het pure outbound-communicatie betreft. De software hebben we vervolgens van de grond af opgebouwd. Onderhand zijn we voorbij security gegaan, en gebruiken we de architectuur voor beheer op afstand.

Eigenlijk draait het allemaal om de serversoftware, KServer. Het idee is dat de agents gegevens verzamelen op de endpoints en naar de server brengen en om instructies vragen. De server verwerkt de gegevens, en geeft de agent op basis daarvan opdrachten mee die deze uitvoert op het systeem. Agent en server zijn gezamenlijk ontworpen, en vormen een geheel.

Het voordeel van deze aanpak, naast dat het werkt in elke netwerkomgeving, is dat het bijzonder veilig is. Een agent voert alleen instructies uit als hij de instructies bij een specifiek punt heeft opgevraagd. Er wordt dus geen data naar de agent gepushed, de agent trekt het naar zich toe. We nemen beveiliging erg serieus, dus ook de instructies zelf worden gecomprimeerd en in 256 bits versleuteld. Het is zelfs mogelijk om in te stellen dat twee agents elkaar in de gaten houden zonder dat ze gegevens naar elkaar sturen.

Verder scheelt het enorm voor de server, want die hoeft niet constant de client af te luisteren. In plaats daarvan hoeft hij alleen gegevens in ontvangst te nemen, deze te verwerken, en terug te geven. Hoewel hij meer berekeningen moet doen, kan hij zijn middelen daartoe aanwenden. Het netwerk wordt ook ontzien.

Het probleem met de agents zelf is dat ze vaak relatief groot en log zijn. Agents waren altijd een megabyte of 40 a 50 groot, en daarnaast erg aanwezig op het systeem. Dat vreet middelen. Wij hebben geprobeerd om dat het hoofd te bieden door het simpel te houden.

De agent/server is geschreven in C, en het is ons gelukt om de agents terug te brengen naar 300 tot 400 kilobyte. Het lijkt soms alsof er geen midden bestaat hier.

Verder was het een uitdaging om de agent zijn begininstructies mee te geven. Daarvoor moest de agent per omgeving apart worden ingesteld. Onderhand hebben we een scripting engine ontwikkeld waarmee de instructies snel kunnen worden ingesteld.

Dan blijft de uitrol over. We hebben die door de jaren heen versimpeld, maar het installeren van de agents is nog steeds een flink werk.

Hoe volwassen is de technologie?

Het is nu vrij volwassen. Onderhand is het toe te passen op allerlei verschillende applicaties, en eigenlijk kan ik niets bedenken dat niet onder een agent-architectuur zou werken. Voorwaarde is wel dat die architectuur solide is, en ik denk dat dit bij ons redelijk gelukt is.

Kaseya is enorm gegroeid in de vijf jaar dat het bedrijf actief is. Toch lijken jullie de enigen die voor dit concept kiezen. Hoe kan dat?

We hebben meerdere bedrijven gezien die het op deze manier probeerden, maar om eerlijk pakten ze het niet goed aan. Elke keer was de agent te zwaar, te log, of hadden ze meerdere agents. CA bijvoorbeeld heeft een tijd terug een agent-principe op een van hun producten losgelaten, ik weet niet meer precies welke. Maar ook dat was te aanwezig op de gastsystemen, en het kwam na uitrol neer op iets van 36 agents per systeem.

Jullie hebben alleen nog maar agents voor Windows, en sinds kort ook Mac. Hoe zit het met Linux en Unix?

We komen dit jaar nog met een agent voor Linux andere Unix-achtigen. We hebben ooit een Linux-agent gehad, maar daar zijn we om zakelijke redenen mee gestopt. De reden was dat, vooral in de Verenigde Staten, geen vraag was naar beheeragents voor dat besturingsysteem. Maar in Europa is die vraag er wel, en daarom gaan we het alsnog doen.

Dat is gek: Linux wordt in de Verenigde Staten nu nog meer gebruikt dan in Europa.

Dat klopt, maar de manier waarop is heel anders. In de VS is Linux veel meer een 'afvuren en vergeten maar' systeem. Het wordt hier toegepast als een soort appliance: je stelt het in voor een specifiek doel, je rommelt nog wat in de instellingen, je zet het aan en blijft er verder voor altijd van af. Dan is een agent-systeem niet nodig.

In Europa wordt Linux daarentegen veel meer als traditionele server gebruikt, en dan is het interessant om dit soort beheersoftware te maken.

Tot Slot: Waar gaat de agent uiteindelijk naartoe?

Ik kan niet echt spreken over de rest van de markt. Wat wij voor ogen hebben is het gebruik maken van de cloud, gedistribueerde computers dus. Met zoveel verschillende systemen met een agent erop, heb je een enorme rekenkracht. Daarmee zijn veel meer en uitgebreidere taken af te handelen, en dat maakt beheer efficiënter en sneller.

Bron: Techworld