We found in the State of Network Automation survey that this "lack of integration" was the second most cited challenge to automation with 47% of NetOps agreeing. The unfortunate reality of NetOps and network automation is that it's a heterogeneous ecosystem with very little pre-packaged integration available. Many NetOps organizations already find themselves behind the eight ball when it comes to satisfying DevOps and business demands to get continuous. NetOps should take their cues from development and DevOps standards as this will expand the talent pool even further. It is rare that an organization standardizes on a single language, but they do tend to standardize on just a few. If other organizations and nearby universities are teaching Python and you choose to go with PowerShell, you're going to have a hard time finding folks who have the skills you need to work on that system. It is similarly a bad idea to choose languages and toolsets for which you have no local source of talent. Given that the number one challenge facing NetOps as reported in the State of Network Automation 2018 was a lack of skills (as reported by 49%) it would seem foolish to create additional friction by introducing multiple languages and/or toolsets. If you (or your team) chooses Python while another chooses PowerShell, you are effectively building an operational silo that prevents sharing of skills. Over the course of that software or system lifespan, then, it’s a certain bet that multiple sets of operators and developers will be responsible for updating, maintaining, operating, and deploying changes to that software or system.Īnd this is exactly what gets at the heart of the push for standardization - especially for NetOps as they take the plunge into developing and maintaining systems to automate and orchestrate deployment and operation of network and application service infrastructure. If you're going to treat your production pipeline as code, then you've got to accept that a significant percentage of that automated pipeline is going to be code. They need the same care, feeding, and maintenance as software coming out of your development organization. While you may dismiss this as irrelevant, it's important to realize that at the end of the day, network automation systems are software and systems. Systems and software with over a million LOC appear to have lifespans over a decade, lasting 12 to 14 years. Interestingly, longevity tends to increase for larger programs as measured by lines of code (LOC). Studies have shown the average software lifespan over the past twenty years is around 6 to 8 years. What drives standardization in the enterprise is more practical considerations such as availability of talent, sustainability, and total cost of ownership over the (often considerable) lifetime of software and systems. The reality is that there are very few standards (in fact none that I can think of) governing the choice of languages and protocols and frameworks by enterprise organizations. That may be because often standardization is associated with regulatory compliance standards that have official sounding names like ISO 8076.905E and carry with them checklists and auditors and oversight committees. Being forced to abandon a polyglot buffet and adopt a more limited menu sounds stifling, for sure. Standardization is sometimes viewed as an assault on innovation.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |