In network automation we are constantly comparing different automation methods and tools, specifically speaking languages(i.e python, GO ) and IaaC tools such as Ansible and Terraform.

Back when I was studying at university one of my modules was “Programming and system design life cycle”. One of the first lectures we were presented with in the first year was understanding Domain Specific Languages(DSL) and General Purpose Languages(GPL). I clearly recall the research papers that we were presented with: Comparing General-Purpose and Domain-Specific Languages: An Empirical Study by Kosar et al.
Throughout this blog I will be using this study as a reference for my insights.

DSLs Vs GPLs

It’s crucial for any network engineers who is interested in automation to understand programming paradigms. Specifically speaking
Understanding distinction between General-Purpose Languages (GPLs) and Domain-Specific Languages (DSLs).

Before I begin this blog, I’ll admit I have never been a fan of ansible for network Programmability. Don’t get me wrong Ansible is a fantastic tool for configuration management for servers, and a great asset in a CI/CD pipleine. However for network automation, I always rather found that it doesn’t provide the flexibility of a full blown object oriented procedural programming language(GPL General Purpose Languages)

Ansible is a domain specific language(DSL). by nature DSL are supposed to provide ease of deployment. They are specialised within their own domain. They are more concise and relatively straightforward.

The moment you start creating conditional statements in ansible, such as multiple IF statements and for loops, you are essentially programming in YAML. You see YAML is a serialised data format. A low level binary stream of data. Data serialization is the process of converting an object into a stream of bytes.

Subsequently it’s not ideal to code procedurally in this environment. As that’s not what it was intended to do!

You will eventually find as your playbook(YAML) is further increasing in complexity in order to perform a complex task, one is far better served utilising a full blown programming language. For me personally it’s one that’s capable of object oriented programming paradigm aka Python.

Based on that I fully appreciate the purpose of Ansible for network automation. Ansible provides an easy was to configure networks device and doesn’t require any programming language expertise. After all this is the purpose of Domain Specific Language.

DSLs typically provide higher abstraction compared to general-purpose programming languages.

DSLs abstract away lower-level details and complexities, allowing users to express their intentions in a more natural and domain-specific way.

A quick practical comparison: Ansible(DSL) vs Python(GPL)

conditional statements:
Ansible:
In Ansible, you can use conditional statements within tasks in playbooks. Ansible’s conditional statements are based on Jinja2 templating syntax. Here’s an example of using an if statement in an Ansible playbook:
yaml

• name: Example of using conditional statement in Ansible
  hosts: localhost
  tasks:
  • name: Check if a file exists
    stat:
    path: /path/to/file
    register: file_info
  • name: Print a message based on file existence
    debug:
    msg: “File exists”
    when: file_info.stat.exists
    In this example, the when keyword is used to conditionally execute the task based on the result of the stat module. If the file exists (file_info.stat.exists evaluates to true), the debug task will be executed and print “File exists”.

Example of using conditional statement in Python

file_path = “/path/to/file”

if os.path.exists(file_path):
print(“File exists”)
else:
print(“File does not exist”)
In this example, the if statement checks if the file exists using the os.path.exists() function. If the condition evaluates to True, the code inside the if block is executed; otherwise, the code inside the else block is executed.
Both Ansible and Python support conditional statements, but they are used in different contexts: Ansible for defining conditions within playbooks for infrastructure automation, and Python for writing procedural code for general-purpose programming tasks.

Fundamental Differences

When comparing domain-specific languages (DSLs) with general-purpose languages (GPLs), several key differences emerge:
• Scope and Flexibility:
• DSLs are designed to address specific problem domains, offering specialized features and abstractions tailored to those domains. They are typically less flexible but more focused.
• GPLs, on the other hand, are designed to be general-purpose and adaptable to a wide range of problem domains. They offer a broader set of features and can handle diverse tasks but may require more effort to achieve domain-specific goals.
• Abstraction Level:
• DSLs provide a higher level of abstraction, allowing users to express concepts and operations in a more domain-specific and intuitive manner. This can lead to increased productivity and improved code readability within the targeted domain.
• GPLs offer a lower level of abstraction, providing a more generic set of constructs and requiring developers to handle lower-level implementation details. While they offer greater flexibility, they may result in more verbose and complex code, especially in specialized domains.
• Learning Curve:
• DSLs are often easier to learn and use for individuals familiar with the domain they are designed for. They abstract away irrelevant details and provide a more focused set of constructs, reducing the cognitive overhead associated with learning and using the language. However this isn’t necessarily true when performing complex tasks which require multiple for loops and multiple conditional statements this has a learning curve too and I’m not entirely convinced this is time well invested.
• GPLs have a steeper learning curve due to their general-purpose nature and broader feature set. Developers may need to learn a larger set of language constructs and programming paradigms, which can require more time and effort.
• Expressiveness and Conciseness:
• DSLs prioritize expressiveness and conciseness within their target domain, allowing users to accomplish tasks with minimal code and cognitive effort. This can lead to more readable and maintainable code within the domain.
• GPLs offer greater expressiveness and flexibility but may require more code to achieve the same level of functionality, especially in specialized domains where DSLs provide tailored abstractions.
In summary, DSLs and GPLs serve different purposes and have distinct trade-offs. DSLs excel in providing focused abstractions and higher productivity within specific problem domains, while GPLs offer broader applicability and flexibility but may require more effort to achieve domain-specific goals. The choice between DSLs and GPLs depends on the specific requirements, complexity, and domain expertise of the problem being addressed.

Evaluating Trade-offs

When comparing tools for network automation, such as Python, Go, Ansible, Terraform, and others, it’s essential to consider both the general-purpose language (GPL) versus domain-specific language (DSL) aspect and the specific features and capabilities of each tool.
• General-Purpose Language (GPL) vs. Domain-Specific Language (DSL):
• Comparing GPLs (like Python) with DSLs (like Ansible or Terraform) involves evaluating the trade-offs between flexibility and specificity.
• GPLs like Python offer broad applicability and flexibility, allowing developers to implement custom solutions tailored to their specific needs. However, they may require more effort to build and maintain automation workflows.
• DSLs like Ansible and Terraform provide higher-level abstractions and pre-defined modules tailored to specific use cases (e.g., infrastructure provisioning or configuration management). They offer faster development and simpler syntax but may be less flexible for highly custom requirements.
• Tool-Specific Considerations:
• When comparing specific tools, it’s crucial to evaluate their features, ease of use, community support, integration capabilities, performance, and alignment with organizational requirements and workflows.
• Python, as a GPL, offers extensive libraries and frameworks for network automation, providing maximum flexibility but requiring more development effort.
• Ansible, as a DSL, specializes in configuration management, automation, and orchestration tasks, offering simplicity and ease of use for network automation tasks but with some limitations compared to Python.
• Terraform focuses on infrastructure as code (IaC) and provisioning, providing declarative syntax and multi-cloud support for automating network infrastructure deployment but with less flexibility for complex automation workflows compared to Python.
In conclusion, the choice between GPLs and DSLs for network automation depends on factors such as the complexity of the automation tasks, the level of customization required, the skillset of the team, and the specific goals and constraints of the organization. It’s essential to weigh the trade-offs between flexibility and simplicity and choose the tool or combination of tools that best align with the organization’s needs and objectives. Additionally, evaluating tool-specific features and capabilities is crucial for making an informed decision about which tool or tools to use for network automation.

Next time you undertake an automation project, think beyond just choosing between Ansible or Python, and instead, focus on selecting the programming approach, whether it’s GPL or DSL, that best aligns with the project’s long-term needs.

Just as there are distinctions between network engineers and network architects in infrastructure provision, I firmly believe that network automation demands both a network automation architect and a network automation engineer mindset.

References:

[1]Comparing General-Purpose and Domain-Specific Languages: An Empirical Study by Kosar et al.