Blog Posts in December 2018
Wish you a quiet and merry Christmas with your loved ones and all the best in 2019! We’ll be back in early January.
ZTP is about provisioning. Can this include configuration as well?
You could argue that provisioning is a form of configuration and in that sense, provisioning can certainly include configuration. If your ZTP solution is good at configuration management is another question.
Beautiful is better than ugly.
Simple is better than complex.
Complex is better than complicated.
So just because you can, don't.
Two other concurrent buzzwords are big data and artificial intelligence. Can they be helpful for automation?
Big Data can provide a rich pool of event-sourcing information and, as infrastructures get more complex, it’s essential that automation triggers are as accurate as possible.
2018 was our busiest year ever… we created or updated 19 webinars, for a total of 32 live webinar sessions.
We wrapped up the 2018 webinars with Storage December featuring Hyper-Converged Infrastructure with Howard Marks and NVMe-over-Fabrics with J Metz (I never thought I would enjoy storage technology discussions, but Howard and J were brilliant)… and this is what we’ve been doing the rest of the year:
Zero-touch provisioning is always one of the big topics in the Building Network Automation Solutions online course, so we decided to invite Patrick Ogenstad (the author of excellent ZTP tutorial) to be a guest speaker in Spring 2019 course (register here).
In the meantime, enjoy his interview with Christoph Jaggi.
We love to claim that we’re engineers and yet sometimes we have no clue how technology we use really works and what its limitations are… quite often because understanding those limitations would involve diving pretty deep into math (graphs, queuing and system reliability quickly come to mind).
A networking engineer attending the Building Next-Generation Data Centers online course sent me this question:
My client will migrate their data center, so they’re not interested in upgrading existing $vendor load balancers. Would HAProxy be a good alternative?
As you might be facing a similar challenge, here’s what I told him:
Last week we published Matt Oswalt’s thoughts on using virtual labs in training and testing. In the second part of his interview with Christoph Jaggi he talked about building a virtual lab.
One of my readers listened to a podcast where a $vendor described how they found another use case for
source routing IPv6 segment routing (SR): 5G networks… and wondered whether SR made a comeback or is about to.
To figure out what segment routing is, watch the webinar we did with Jeff Tantsura a while ago.
I don’t know nearly enough about mobile networks to have an opinion, however…
One of the fundamentals I always emphasize in introductory parts of my network automation workshops and online courses is the fact that we’re about to develop software that will control the most-mission-critical part of IT infrastructure, and should therefore use software development methodologies like version control, testing…
However, there’s a “small” glitch. While it’s perfectly possible to test most software in some virtual environment you can spin up on-the-fly using Vagrant, Docker, Jenkins, Travis, or some other CI/CD tool, testing a network automation solution requires access to network devices.
That omission has been fixed in late August – SDDC 101 webinar is available as part of free subscription, and as always I started with the seemingly simple question: What problem are we trying to solve?
In the market overview section of the introductory part of data center fabric architectures webinar I made a recommendation to use larger number of fixed-configuration spine switches instead of two chassis-based spines when building a medium-sized leaf-and-spine fabric, and explained the reasoning behind it (increased availability, reduced impact of spine failure).
One of the attendees wondered about the “right” number of spine switches – does it has to be four, or could you have three or five spines. In his words:
My friend Andrea Dainese (of the Route Reflector Labs fame) sent me this observation:
Because of lack of fundamental skills, I see two groups forming: junior guys with low salary (the bigger group), and a few experts (hopefully with higher salary). The middle group is disappearing. Intermediate-level engineers are either moving to the entry level (because the complexity is increasing and they are not keeping up with it) or to the upper level.
I call this phenomenon bifurcation of knowledge (I’m positive it has a formal name – would appreciate a comment with a set of pointers), and it’s a direct result of commoditization and the changing shape of the learning curve.
One of the points David Gee, a guest speaker in Spring 2019 Building Networking Automation Solutions online course, and Christoph Jaggi touched on in their interview was the security of network automation solutions (see also: automated workflows and hygiene of network automation).
What are the security risks for automation?
Security is an approach, not an afterthought.