Impact Analyse ArcGIS for Kubernetes

Momenteel hebben we grofweg 7 on premise omgevingen, naast de SaaS ArcGIS Online:

1. lab omgeving voor het beheer team zelf
2. ontwikkel omgeving voor de klanten (geostenen, tab-geohub)
3. test omgeving voor de klanten
4. acceptatie omgeving voor de klanten
5. productie omgeving voor de klanten
6. acceptatie extern via DMZ
7. productie extern via DMZ

Op de website van Esri staan 3 architectuur profielen beschreven (enhanced availability, standard availability, dev), met hun bijbehorende minimum requirements.

Op dit moment hebben we nog geen zicht op de prijzen vanuit Esri Nederland, dus we werken even op basis van de prijslijst uit eind 2025 voor de VS die hier gevonden kan worden. Hierin is een onderscheid tussen productie en staging gemaakt. Uit bovenstaande lijst zijn 5 en 7 de enige productie omgevingen.

De volgende vragen zullen we moeten beantwoorden om tot een licentie kosten inschatting te kunnen komen voor de nieuwe situatie:

1. Hebben we raster image analytics op alle clusters nodig? Ik ga er nu vanuit dat dit wel het geval is.
2. Willen we straks wel notebook services op k8s? Hebben we nu niet namelijk omdat dat technisch gezien niet kon. Ik verwacht dat dit wel een functionele wens is, maar om de vergelijking tussen de IST en de SOLL zuiver te houden is het misschien verstandig om dit voor nu buiten beschouwing te laten.
3. Welk architecture profile is nodig voor welke omgeving (OTAP, DMZ acc, DMZ prod)?
4. Wat is de impact van moeten betalen voor viewers op k8s? Hoeveel viewers nodig? Wat ook nog problematisch kan zijn is dat licensed users voor k8s niet uitwisselbaar zijn met ArcGIS enterprise op Linux/Windows.

M.b.t. architecture profiles zou ik het volgende willen voorstellen, al zit hier ook een nadeel aan dat niet alle omgevingen exact gelijk zijn. Als het argument dat alle omgevingen een kopie van elkaar moeten zijn zwaarder weegt, dan zouden alle omgevingen het hoogste profiel, enhanced availability moeten hebben. Deze afweging moet nog gemaakt worden en hierbij spelen de kosten ook een rol.

1. dev profile
2. standard availability
3. standard availability
4. standard availabiliy
5. enhanced availability
6. standard availability
7. enhanced availability

Op het moment van schrijven ondersteunt GeoWeb Modules, gebaseerd op Vertigis Studio, geen deployment op kubernetes, maar zou het wel moeten kunnen werken met ArcGIS for Kubernetes. Dit zou een lastige puzzel kunnen opleveren qua connectivity tussen het huidige datacenter (DC1.5) en de OpenShift omgeving, en bijbehorende latency.

Het is de verwachting dat misschien niet alle clusters altijd in de lucht hoeven te zijn, en ook on demand kunnen worden opgestart, Maar daarnaast zijn de profielen minimum requirements en is er ook kans dat er nodes bijgeschakeld moeten worden op basis van demand.

ArcGIS Server extensies worden (nog) niet ondersteund, dus bijvoorbeeld Martime zal (nog) niet kunnen. En dat zou dan betekenen dat je een hybride oplossing zou moeten hebben wat een complexiteit heeft voor de beheerlast.

Er zijn verschillende scenario's denkbaar, bijvoorbeeld:

1. alleen MKO inrichten met ArcGIS for k8s, MKO is een logische kandidaat omdat je hier hoge eisen hebt qua availability
2. alle omgevingen inrichten met ArcGIS for k8s, maar probleem is dan nu nog dat niet alle functionaliteit die voor RWS benodigd is, beschikbaar is in k8s

Op de blog van geosquare staat ook een mooi overzicht: ArcGIS Enterprise op Kubernetes