On Thu, 20 Mar 2025 at 05:21, Jon Lewis via NANOG <nanog@lists.nanog.org> wrote:
Of course, this is why we have APIs. So you can do the once in a while version of a task via an easy to use GUI, but when you need to do it hundreds or thousands of times, you can write code to automate the job.
Not everything on the network has an API, and not everything can easily be done via API even when there is one...so sometimes the CLI is the best way to get the job done.
I wonder if the list is talking about multiple different questions. To me SSH is an API. You could certainly create a REPL CLI loop over GRPC, SOAP, CORBA, REST (which I think is both the newest and worst attempt at RPC, implemented by people who refused to understand why CORBA and SOAP are complex, then implemented very incomplete and poor RPC and started to add complexity once they learned why RPC is more complex than naive idea of REST was). I feel some are reading the question 'should you automate or not' and some are reading the question as 'what UX should data entry/provisioning have' If you can entirely remove humans, that's in my mind a very different question to what kind of tool humans use for provisioning. I understood it as human is needed to provision and we're talking about the UX human has. But I may have misunderstood. Having said that, I also don't believe automation is something that is axiomatically desirable. Humans are really bad at skill retention if skill is not used. CLI jockey things have very many outages that last very little time. Heavily automated things have very few outages that last very long time very. I have some anecdotes for this when a new vendor was introduced with a high degree of automation for it, old vendor issues were quickly solved, even most trivial issues on the new vendor got escalated to design and took a very long time to solve. This lack of routine exposure to the systems also makes it harder to design new solutions well. I don't know what is the right balance, but I do think we are using _too much_ automation, underestimating the cost of trade-offs and outright ending up with a poorer business case. -- ++ytti