Tag Archives: architectuur

ArcGIS Content, het nieuwe keukengereedschap

In mijn vorige blog schreef ik over een kijkje in onze keuken. Over hoe we in 5 jaar tijd zijn gegroeid van een Nederlandse topografische basiskaart naar een breed pallet aan content en alle technologische uitdagingen die daarbij komen kijken. Maar we zitten niet stil, het aanbod blijft groeien en het gebruik neemt steeds meer toe. Dat betekent dat ons platform ook moet meegroeien. Als beheerder van de omgeving voor ArcGIS Content deel ik graag met jullie waar we nu en in de nabije toekomst aan werken: zeg maar het nieuwe keukengereedschap.

DevOps is een inkorting van Developers Operators en het houdt de samenwerking in tussen deze twee groepen. Maar belangrijker is de samenwerking tussen verschillende disciplines. Omdat het content-team een relatief klein team is, zijn de taken al multidisciplinair verdeeld tussen de medewerkers. Nu is het beheer daar ook in opgenomen en werk ik nauw samen met de content engineers, zodat we elkaars werk goed begrijpen en elkaars keuzes kunnen begrijpen en afstemmen. Dit heeft mij heel veel geholpen bij het ontwikkelen van scripts en snellere releases van de infrastructuur en content. Dit principe sluit ook heel goed aan bij het agile werken, iets wat we al geruime tijd gewend zijn om te doen.

De architectuur voor ArcGIS Content verandert drastisch. De meest voor ons in het oog springende wijziging is de introductie van een webcaching proxy. In eerste instantie gaan de basiskaarten op specifieke proxyservers geplaatst worden, zodat de achterliggende servers worden ontlast. We hebben namelijk het punt bereikt dat een dedicated cache voor de basiskaarten efficiënter is dan steeds meer servers in te zetten, waar de caches ook gepubliceerd staan. De backend blijft uiteraard nog steeds ArcGIS en de webcaching proxy is niet meer dan een kopie van de cache van de ArcGIS-server. De REST-interface, het opvragen van de offline basiskaart-packages en dynamische mapservices blijven nog steeds het domein van ArcGIS. Echter, doe je als gebruiker een verzoek naar een plaatje van een basiskaart, dan komt dit verzoek nooit bij onze ArcGIS-server terecht, maar wordt direct door de webcache afgehandeld. Voor gebruikers overigens een wijziging waar niets van te merken is, alles blijft werken zoals het werkt en net zo snel als eerst. Wellicht zelfs iets sneller.

Een webcache is overigens pas interessant bij heel veel hits. Wij verwerken per dag meer dan vijf miljoen hits op alleen de basiskaarten. Voor deze basiskaarten zetten we nu al meerdere ArcGIS-servers in. Het inrichten en onderhouden van een webcache vergt veel kennis, tijd en extra computerkracht. Bij minder belasting is een webcache simpelweg niet rendabel en is out-of-the-box ArcGIS beter te gebruiken, of gewoon ArcGIS Online.

Een andere belangrijke verandering in de infrastructuur is het automatisch ‘uitrollen’. We gebruiken hier een zogeheten end-state configuration tool voor. Wij geven in een configuratiebestand aan wat de beoogde configuratie is en deze programmatuur zorgt ervoor dat alle servers afgestemd worden op deze beoogde situatie. Dit heeft voor ons twee belangrijke voordelen. We kunnen zeer eenvoudig een kopie van onze omgeving inrichten voor testdoeleinden en we kunnen extra servers toevoegen als de belasting toeneemt. We weten via een dergelijke end-state configuration in elk geval zeker dat alle servers identiek aan elkaar zijn. Of het nu een loadbalancer, een ArcGIS-server of een webcache is.

Dit zijn mooie ontwikkelingen die technologisch gezien erg interessant zijn. Wie mij een beetje kent, weet dat ik urenlang kan doorpraten over dit werk en hoeveel plezier ik eraan beleef. Gelukkig houdt mijn werk na het inrichten van deze veranderingen niet op: big data komt ook om de hoek kijken.

LinkedInFacebookTwitterDeel deze blogpost
Posted in Achter de schermen, Content | Tags: , , , | Plaats een reactie

De locatieparadox

GIS’ers bekijken de hele wereld door een locatiebril. Maar, bij het kijken naar de ICT-architectuur van een GIS-systeem vergeten veel GIS’ers hun locatiebril. Hierdoor ontstaan veel ICT-problemen met GIS-systemen die eenvoudig zouden kunnen worden vermeden.

 

GIS'ers bekijken de hele wereld door een locatiebril,  kan tot verrassende problemen leiden.

GIS’ers bekijken de hele wereld door een locatiebril,
dat kan tot verrassende problemen leiden.

Locatie ook in architectuur

Na mijn overstap van IBM naar Esri ben ik deelgenoot geworden van de wondere wereld die bestaat uit locatie, locatie en nog eens locatie. Voor mij een heel nieuw gezichtspunt: leuk, interessant en verfrissend. Maar gaandeweg valt me op dat er ook wel eens niet aan locatie wordt gedacht, juist op momenten dat ik locatie als ICT-architect belangrijk vind. Ook bij een GIS-systeem moet in de ICT-architectuur rekening worden gehouden met locatie. Locatie gaat namelijk niet alleen over coördinaten en projecties, het gaat ook over de vraag welk deel van het ICT-systeem
waar draait.

 

Het maakt uit

In de hoogtijdagen van het mainframe was de ICT-wereld overzichtelijk: alle code draaide op dat ene mainframe. Maar in een tijd van smartphones, thuiswerken en globalisering kunnen we ook als GIS’er er niet omheen: het maakt uit waar de delen van een GIS draaien.

 

Te grote afstand

Bij een landelijke dienst ondervonden GIS’ers in vestigingen buiten de Randstad grote performanceproblemen, omdat er niet was gelet op het aantal kilometers van hun PC met professionele GIS-client naar de database in het datacentrum in het midden van het land. De grote afstand leverde zoveel netwerkvertraging dat het onaanvaardbare performanceproblemen gaf voor de gebruiker – locatie als verklaring voor een ICT-probleem.

 

Gescheiden servers

Bij een middelgrote gemeente moesten er bij het begin van de implementatie van een GIS-viewer al meteen softwarelicenties worden bijgekocht, omdat was vergeten dat servers in gescheiden netwerksegmenten stonden. De servers stonden fysiek weliswaar in dezelfde ruimte, maar door de gescheiden netwerksegmenten konden de servers elkaar niet bereiken en zou het systeem niet werken – locatie als verklaring voor een ICT-probleem.

 

Bij mobiel werken speelt locatie op  meerdere vlakken een rol.

Bij mobiel werken speelt locatie op
meerdere vlakken een rol.

Geen verbinding

Voor een mobiele toepassing werkten de ontwikkelaars hard aan de code. “Wat maakt het nou uit op welke machine mijn code draait”, zeiden ze. Maar ze begrepen niet dat hun code geen werkend systeem zou opleveren, omdat hun code op een mobiel device draaide en vanuit het veld geen verbinding had met de benodigde COTS-software (Commercial Of The Shelf) in het datacentrum – locatie als verklaring voor een ICT-probleem.

 

Wat draait waar?

Ook bij een GIS-systeem moet in de ICT-architectuur rekening worden gehouden met locatie, met de vraag ‘wat draait waar?’. Als we onze krachtige locatiebril een beetje bijstellen moeten we in staat zijn daar rekening mee te houden en zo onze locatieparadox te vermijden.

 

Meer over architectuur

Tijdens Esri GIS Conferentie geef ik, samen met mijn collega Theo Michielse, op donderdag 26 september een presentatie over ‘Architectuur: Leidraad bij uw veranderende geolandschap’ (van 14:55 tot 15:40 uur).

Lees meer over deze presentatie…

Schrijf u in voor Esri GIS Conferentie…

Posted in ArcGIS | Tags: , , | Plaats een reactie