initiele versie

chapters/1 - inleiding.tex

@@ -0,0 +1,3 @@
+\chapter{Inleiding}
+
+Dit document bevat verschillende adviezen over de te ondernemen stappen voor het bevorderen van en/of het implementeren van netwerkautomatisering. Deze adviezen zijn gebaseerd en onderbouwd door het uitgevoerde onderzoek.

chapters/1 - voorbeeld.tex

@@ -1,4 +0,0 @@
-\chapter{Een test}
-Test \cite{dirac}
-
-\lipsum{10}

chapters/2 - adviezen.tex

@@ -0,0 +1,81 @@
+\chapter{Adviezen}
+
+Op basis van het uitgevoerde onderzoek wordt een advies uitgebracht naar de opdrachtgever met betrekking tot de vervolgstappen om netwerkautomatisering te kunnen bevorderen in de dagelijkse werkzaamheden van het Expert Team Networking.
+
+
+\section{Installeren van WSL op de beheerserver}
+
+Installeren van de 'WSL' (Windows Subsystem for Linux) rol op de windows beheerserver maakt het mogelijk om gebruik te maken van Linux op de beheerserver. Dit maakt het mogelijk om Ansible hierop te installeren en te gebruiken. Hierdoor kan de beheerserver gebruikt worden om de dagelijkse werkzaamheden te automatiseren met Ansible.
+
+Er zijn de volgende alternatieven naast het installeren van WSL op de beheerserver:
+
+\begin{itemize}
+    \item Een andere beheerserver in gebruik nemen die gebaseerd is op Linux.
+    \item Het beheermodel aanpassen zodat werknemers de klantomgevingen kunnen benaderen met hun lokale computer.
+\end{itemize}
+
+
+\section{Ontwikkelen van nieuwe playbooks met Ansible CLI}
+
+Wanneer een nieuw playbook gemaakt wordt kan deze beter gemaakt worden met de Ansible CLI op de beheerserver. Op deze manier kan de engineer het playbook snel en relatief eenvoudig ontwikkelen (in vergelijking met het maken van een nieuw playbook met AWX). Dit zorgt ervoor dat er minder tijd benodigd is om het playbook te maken en daardoor toegankelijker is voor de engineer.
+
+AWX past hier alsnog goed bij. De playbooks kunnen namelijk getest en gemaakt worden op de beheerserver. Wanneer deze playbooks zodanig stabiel en vaak getest zijn kunnen deze automatisch worden uitgevoerd door AWX. Dit maakt CI/CD principes mogelijk op de langere termijn.
+
+
+\section{Investeren in developmentkennis}
+
+Bij het toepassen en realiseren van automatisering is niet alleen kennis van het te automatiseren proces nodig maar ook kennis over onder andere versiebeheer, ontwikkelen en testen van code. Deze kennis is belangrijk voor het creëren van betrouwbare, stabiele en functionele software.
+
+Het Expert Team Networking heeft uitgebreide kennis over de processen die potentieel geautomatiseerd kunnen worden. Echter bezit het team minder kennis en ervaring over softwareontwikkeling en hiermee geassocieerde werkwijzes en tools. Dit kan ervoor zorgen dat het zeer lastig is voor het team om deze werkwijzes en tools effectief toe te kunnen passen. Daarnaast bestaat een grotere kans op het introduceren van technical debt door het maken/implementeren van suboptimale ontwerpkeuzes en code die moet worden gecorrigeerd bij het toevoegen van functionaliteit.
+
+Het risico van niet investeren in developmentkennis is dat geen gestructureerd developmentproces wordt nagestreefd bij het ontwikkelen en beheren van systemen en code die de automatisering mogelijk maakt. Dit kan leiden tot onbetrouwbare systemen en/of code.
+
+
+\section{Produceren en onderhouden van integraties en tooling}
+
+KEMBIT heeft als nadeel dat er geen bestaande integraties zijn tussen Ansible en TOPdesk. Dit maakt het niet mogelijk om Ansible volledig geautomatiseerd uit te kunnen voeren en een stuk minder gemakkelijk om Ansible in de dagelijkse werkzaamheden te kunnen gebruiken.
+
+Om dit op te lossen wordt geadviseerd om verder te evalueren welke integraties er nodig zijn, en deze te implementeren waar nodig. Om te garanderen dat deze integraties wordt tevens geadviseerd om hier tests op uit te voeren bijvoorbeeld met Continuous Integration.
+
+
+
+
+\section{Nieuwe inrichting van TOPdesk Asset Management}
+
+Gedurende het onderzoek is vastgesteld dat de inrichting van TOPdesk Asset Management de tool nog niet tot zijn volledige potentie benut. Dit veroorzaakt een verminderde gebruikerservaring en maakt het minder makkelijk om integraties te realiseren met de software.
+
+Door een nieuwe inrichting van TOPdesk Asset Management te maken zal het makkelijker worden om koppelingen te maken en de software te gebruiken.
+
+De software is ingericht met veel verschillende templates voor hetzelfde type apparaat. Onderling is geen verschil, alleen de naam. Het betreft de volgende templates:
+\begin{itemize}
+    \item Switch 8 Poorten
+    \item Switch 12 Poorten
+    \item Switch 24 Poorten
+    \item Switch 48 Poorten
+    \item Switch Core
+    \item Switch Distributie
+    \item Switch Acces
+\end{itemize}
+
+Het enige dat verschilt, is de naam van de templates. In deze naam is informatie opgenomen over het apparaat dat belangrijk is voor het team. Dit zijn de hoeveelheid poorten en de plaats in de hiërarchie van het netwerk. Om dit verder te optimaliseren kunnen al deze templates worden vervangen door slechts één template met de twee eigenschappen toegevoegd als velden. Dit kan er als volgt uitzien (bestaande velden zijn niet mee opgenomen, alleen de voorgestelde wijziging):
+
+\begin{itemize}
+    \item Switch
+    \begin{itemize}
+        \item Aantal poorten (8, 12, 24, 48)
+        \item Hiërarchie (Core, Distributie, Acces)
+    \end{itemize}
+\end{itemize}
+
+
+\section{Rekening houden met de kwaliteiten van Ansible}
+
+Ansible is een zeer effectieve tool voor het automatiseren van configuration management op netwerkapparatuur. Dit komt door de toegankelijke, declaratieve configuratietaal en uitgebreide modules voor netwerkapparatuur.
+
+Echter is de tool niet geschikt voor gebruik als general purpose programmeertaal. Dit komt door (opzettelijke) limitaties in de domain specific language van Ansible. Deze hebben als doel om de taal ze eenvoudig en toegankelijk mogelijk te maken, ook zonder programmeerkennis.
+
+Op het moment dat de DSL gebruikt wordt voor een usecase die op de limieten ligt van de functionaliteiten die hierin worden blootgesteld, kan dit leiden tot een juist zeer complexe implementatie.
+
+Ook is het lastig om playbooks te testen. Het niet uitvoeren van tests kan ervoor zorgen dat er regressies optreden bij het maken van wijzigingen die niet opgemerkt worden. Over het algemeen kan het testen de stabiliteit van de software verbeteren door het voorkomen van onverwacht gedrag.
+
+Het advies is om bij het overwegen van een nieuwe automatisering eerst de voor- en nadelen van Ansible in acht te nemen. Zeker wanneer de usecase niks te maken heeft met configuration management is het wellicht beter om een andere tool te kiezen zoals een PowerShell script.

main.tex

@@ -35,7 +35,7 @@
 \renewcommand{\arraystretch}{1.5}
 
 %% Verander dit {
-\newcommand{\titel}{Titel hier}
+\newcommand{\titel}{Adviesrapport}
 \newcommand{\project}{Applied Network Automation}
 \newcommand{\auteur}{
 Martijn Remmen
@@ -82,7 +82,8 @@ Martijn Remmen
     \tableofcontents
     \pagebreak
 
-    \input{chapters/1 - voorbeeld.tex}
+    \input{chapters/1 - inleiding.tex}
+    \input{chapters/2 - adviezen.tex}
     
     
     \printbibliography