guide.yml

# Landscape2 guide
#
# This file allows defining the content of the landscape guide.
#
# Reference documentation: https://github.com/cncf/landscape2/blob/main/docs/config/guide.yml

categories:
  - category: "Introduction"
    content: |
       Welcome to the Network Automation Landscape, a place scared with battles between network engineers and developers, waging war over text files and apis. Join us fellow traveler on the Journey that is Network Automation, and please take care to dodge the land mines.

    subcategories:
      - subcategory: "What is Network Automation"
        content: |
          The debate rages, so a clear definition evades the community. Perhaps a clearer question to ask yourself is: What is Network Automation for me? You are here because you probably meet some of the following criteria:
          * You have some amount of scale/size that justifies the effort required to add tools to avoid manual work
          * You are interested in learning about new tools to get more work done
          * Software development for network engineers doesn't scare you
          * Steinzi harassed you to visit this website

      - subcategory: "Where do I start?"
        content: |
          The Network Automation Landscape is a broad set of tools, and starting can be daunting. One possible starting point is configuration management. Network Engineers are used to editing config and applying changes, and ultimately you need to start with a technology choice that lets you do just that. Many people begin with Ansible if only to demonstrate a layer of abstraction and techniques. Ansible shines for simple task executions, and when the business logic gets's more complicated, an other tool will be a better fit or an additional tool. Do not be afraid to start with something for your proof of concept and update/change your tech stack if needed and you have a better understanding.
          There are also many introductory courses and videos/talks online that you can use.

  - category: "Data Sources"
    content: |2
        > The term "Single Source of Truth" (SSoT) has been so misused by vendors, marketers, and engineers that we should avoid using it, as it leads to confusion.
      

      One of the first things to grasp with automation is understanding what you have. Many tools and solutions are helping to discover the network. Before reaching sophisticated automation, most networks need to clean up their services and add a service abstraction layer.
      Starting in a brownfield environment is possible, as is doing simple tasks. At this point, the actual state of the network configuration and operation is in each box. This approach could be called a bottom-up approach. Data and data quality are critical points for a successful automation journey. Therefore, the best practice is to flip the approach and have a single point of source where the desired state is up to date at any time. 
      The actual operational state is on the physical network box in hardware (for example, Forward Information Based (FIB)). The state itself is driven by the control pane (traditionally the routing protocols on the box, Router Information Based (RIB)). Monitoring and Observability platforms collect these data.

    subcategories:
      - subcategory: "Discovery"
        content: |
          Discovery is the process of reading data or config from the network to populate a data source. This can be used to reconcile, manage, monitor or boast about network devices. Tools can scan devices, use SNMP, SSH, Telemetry or other APIs to gather data and config.

      - subcategory: "SoT - actually kinda a Datasource"
        content: |
          Any organization with a network also has physical locations, or people or names of things, that have outside authoritative sources. For example, sites come from the Facilities Dept, People are in the HR system. This means that inevitably the core database in network automation needs to be useful for automation, but isn't as Truthy as its title might deserve. This is an integration problem, and the various datasources and databases in this Landscape handle this in a variety of ways. The more mature tools recognize that integration is key, and lower the barrier of entry to input and output of data, at a machine level.

  - category: "Monitoring and Observability"
    content: |
      Networks are connections between computers that deliver (mostly important) data. So we need to care if they are working as designed. Monitoring solutions that can integrate into the Landscape tools are more mature here. This includes mapping configuration to monitoring tools, and feeding back status and metrics to close the loop. Operational teams will need monitoring information, metrics, logs and config snapshots to deliver a gold standard of service delivery.

    subcategories:
      - subcategory: "Monitoring"
        content: |
          The tools that run tests against the network and return, alert, graphs those test can be broadly considered monitoring. This also covers tools that actively ask the network questions like SNMP, Ping, SSH and API requests.

      - subcategory: "Observability"
        content: |
           Observability is a slightly different approach where existing or additive metrics are parsed and digested into an easy to understand form. Alerts and graphs can then be applied according to rules that match or collate these metrics.

  - category: "Automation Tooling"
    content: |
      A fast growing category is special purpose tools to managing automation workflows. At a simple level an Automation tool has the ability to take some script or config, run this on our behalf, and return the result. As you can imagine, this could be as simple as a shell script and a cron job, or as complicated as a full end to end solution. More mature tools integrate with source control systems, the SoT, and provide tests and collaboration tools that resemble software development tools. This is the nexus of where a network engineers meets the software development lifecycle and will need to skill up accordingly.