Why Network Engineers Should Learn Go | Hacker News Reader

Why Network Engineers Should Learn Go

darrenparkinson.uk

48 pointsgojiberries6 comments

Enjoyed your talk a lot! Python is definitely the industry leader within network automation, and I agree the ecosystem of modules are a reason for that. I had the talk on “how we provide better customer insights with tenant visualization using ACI”, and I spend most my days writing network automation code in Python. It is extremely rare I actually use tools like nornir or scrapli these days. Most things I need to automate, can be done through a north bound API provided by Cisco software, such as DNAC or ACI. Same goes for IPAM, integrations with Azure etc. I write Ansible modules which AWX takes care off, and I use the AWX APIs to get job data.

In other words, I think we pretty much could write any language and it would solve most use cases.

My opinion is for neteng's to not need to code. Automation/Orchestration languages that let you define state and workflow are better. In security, SOAR platforms are achieving this really well.

In other words, Go is great and implementations should use it, but, neteng's should not need to write new code. Data processing and automation functions can be exposed using an abstraction layer which can be maintained better without requiring new neteng's to learn a programming langauage and make these workflows shareable.

Anyone can learn Go or most languages, learning how to do write good/secure code is much harder. It's much harder to replace a neteng writes good code than it is to replace a neteng good at networking. Layer 8 redundancy is important in networking.

Two thoughts. (1) Wrangling YAML is still coding; you’re using the API for a software system it’s just exposed in declarative YAML. I suspect your definition of coding may be a bit narrower than mine, which is fine.

(2) I can’t help but thank of “no-code” solutions. They work great if you’re using the platform how the developers thought you would. However; beware when you start to improv/hack things around because you’ll find little support and extension points.

All this said I do agree with the sentiment that there are tool builders and tool users, and the tool user shouldn’t always be expected to know how to build tools.

You're thinking of Ansible, I am thinking of Siemplify or XSOAR but for networking. A Graphical/visual playbook/workflow declarative system that exposes flexible building blocks (which in turn are backed by reusable pieces of actual code).

It may not be "real code" but it is essentially a programming language as you alluded, except it allows engineers to focus on engineering networking solutions.

Heard of Powerapps from Microsoft? They've had a ton if impact in the corporate world, similar logic. Instead of office macros and paying devs for scripts, office workers come up with workflow and connect input/output of building block elements/tasks and voila, they made an app!

You never really state why network engineers should not be required to write code, and imply an arbitrary limit of "domain-specific GUI" and YAML/golang.

What's the difference between writing if/else/commit() in golang, vs. writing the commands in a proprietary command language, writing the inputs in Excel, and then pasting the combination into a terminal?

Coding/APIs/etc. should be a required course for any dev/sec/ops person. APIs and glue code are the future.

I state specifically why netengs should not write code. I don't like yaml. I think you haven't seen a good nocode solution.

What's the difference? They are both essentially programming languages except nocode allows abstractions, modularity and building blovks that lets networkers focus on network state and infrastructure. Similar to R helps data scientists focus on data science, matlab allows mathematicians to focus on math, powerapps allows office workers to focus on automating office work.

Your last comment: I agree, except neteng people are not dev/sec/ops. And tbf, asking people to wear 3 hats and be really good at all, and expect those people to be replacable and then whine about lack of talent is bullshit! Have a dev build building blocks sec and ops people can use. If you have people wearing 3 hats then they should be there to enable specialists not to be your developer and network engineer and it admin and cloud architect and operations engineer and SRE and security engineer and compliance auditor and whatever else.

Do things right, try to do them right the first time and learn from others' mistakes!

Reply on news.ycombinator.com