NetDevOps is the application of DevOps to network development and management. “DevOps” refers to a philosophy that treats software development and system operations as a continuum.
Really, the concept is a reaction to ITIL, which formalized IT services management (ITSM). While ITSM splits out different IT department functions into separate teams, DevOps merges those functions back into one department.
ITSM is formulated by ITIL but DevOps has no standard definition. Proponents of the discipline refer to “breaking down silos.” This means that the formal division of IT functions just creates more barriers to efficiency and removing those structures makes the IT department more responsive.
The ITSM strategy formalizes the delivery of services but it also creates a lot of paperwork because each responsibility needs to get a formal definition of its responsibilities so that its commitment to each task has boundaries and a measurable goal. Each task needs to be charged so that budgets can be properly allocated and tracked. This is a great advancement for accountants and upper management but it ends up being a nightmare for IT staff. It just creates a lot of administration that diverts effort away from the core purpose of the department, which is to deliver IT services efficiently and quickly.
Lean Thinking
ITSM adherents will see DevOps as a backward step. It sounds chaotic. It seems to be a way for IT department heads that resent being monitored to put a patina of theory over their obstinacy. However, there is a strong argument underpinning DevOps. This lies in “lean thinking.” The lean thinking school derives from lean manufacturing, which was pioneered in Japan and gave the Japanese a lead in the production of goods.
The iconic developer of lean manufacturing was Toyota. Other Japanese manufacturers followed Toyota’s lead and then, noticing that their businesses were under threat, manufacturers in the rest of the developed world followed suit.
While some of the techniques used by Toyota are very specific to manufacturing, many of the concepts can be applied to any field of work. The lean manufacturing ideas of flexible manufacturing systems and quality circles can easily be translated into IT operations. These are the core theories that form the basis of the “breaking down silos.”
ITSM inefficiencies
The problem with dividing IT functions into separate teams is that each team requires a management structure. In order to guide a task through to completion, many managers need to negotiate contracts and budgets among themselves. So, managers get very involved with each other and the proof they need for negotiating budgets and proving fault. The actual job gets suffocated by the administration.
While managers argue over contracts and completion confirmations, the day-to-day workers get frustrated that they are not being listened to. Their jobs are being made harder by unnecessary paperwork. The people who have their hands on the wheel know what works. Being told from above what equipment they have to use and what working practices they have to implement results in workers disassociating themselves from the goals of the business and the purpose of their work. They end up “just doing their jobs” and not contributing to efficiency.
The quality circle concept of lean manufacturing puts the workers in charge of deciding how things are going to be done. In IT, successful service delivery is composed of three factors: hardware, software, and working practices. Operations staff are very good at coming up with workarounds. Shortages in infrastructure can be compensated for with software or changes in procedures.
Network managers can instantly think of many ways to resolve bottlenecks in network traffic without having to buy new equipment. For example, moving administration tasks and batch jobs to out-of-hours periods removes traffic from peak working hours. Another strategy that can help the network perform more efficiently is “traffic shaping,” which prioritizes interactive traffic, such as VoIP and video over less immediate demands from applications such as email.
Scheduling tasks is a procedural solution and traffic shaping requires monitoring tools and switch management systems and so is a software solution. These two methods make up for hardware requirements and deliver acceptable service levels for less money. Managers schooled in budget control and contract negotiations aren’t interested in these costs saving tricks. They are more concerned with their own abilities to accumulate power and win funds for their team.
DevOps efficiency
In ITSM, the management process takes over the actual purpose of the department, and those people who know how to organize tasks efficiently have no power. Eventually, the IT department’s purpose gets hijacked by the many managers who spend all of their time talking to each other and keeping their staff apart. It gets to the point where cooperation between teams becomes a sackable offense.
DevOps starts by getting rid of all of those managers.
In DevOps, the software development team and the systems operation team are merged. That doesn’t mean that the same people perform both tasks – programmers are trained to write software and systems administrators know how to tweak different settings to get efficiency. Each skill set is appropriate for different jobs. However, under DevOps, these two types of workers are allowed to talk to each other.
Operations staff know what the system needs in order to run better and they know how to tell programmers about new requirements. Software developers might think that a new program is ready, but there might be operating conditions that they didn’t foresee when writing the new system. It is only when the program is running in the real world that every eventuality is encountered. This might require adjustments. That doesn’t mean that the programmer made a mistake, so there is no need for blame or elbowing for promotion.
DevOps gets all IT staff working together without the compartmentalization of ITSM.
NetDevOps
NetDevOps is a much easier concept to imagine than DevOps. DevOps is particularly strong in the development of software. In networking, bespoke software creation is very rare. It is more common to bring in system monitoring and management tools.
ITSM doesn’t just keep software development and operations teams apart, it also separates the functions of system management and user support. When the need for new hardware and software is identified by either the systems managers or Help Desk technicians, ITSM dictates that someone else should be tasked with assessing the new systems. To DevOps proponents, this division of labor doesn’t make sense. In NetDevOps, it is even more illogical.
If a network manager knows what needs to be bought in order to make the network work better, that person is the most competent employee to identify what service to buy. In the ITSM system, the network manager needs to impart all requirements to a service manager.
Under ITIL, the network manager needs to submit his requirement to the ITSM Service Desk “change authority,” which then appoints a “change manager,” to whom the network manager then has to explain his requirements in detail. The change manager doesn’t work with the network and so doesn’t have the skills to properly assess the available options. The network manager would need to be consulted repeatedly and then be given a final decision, which might not provide a decent solution.
With the NetDevOps route, the network manager identifies a need and then clears the idea with the IT department manager. The manager will probably have more concern over budget and will place a limit on the amount that can be spent on the acquisition. The network manager then looks for options and decides which one of those to go for – if it is within budget, the IT department head really won’t care and won’t get involved.
ITSM vs NetDevOps
ITIL objects to the idea of the network manager finding a new system because that diverts his attention away from the task he is paid for, which is managing the network. ITIL aims to avoid disruption to normal operations while a change project is underway.
It is true that the involvement of operation staff in change reduces their attention to the day-to-day management of their responsibilities. If running the network doesn’t take up all of the network manager’s time, then, clearly, he is under-occupied and maybe a part-time network manager would be a better fit.
The counter-argument is that, by allowing operations staff to get involved in change management, they are, essentially, reducing their allocation to operation to the level of part-time work and using the rest of their time to replace an entire department: the Change Authority of the Service Desk.
The ITIL system of segmented responsibilities doesn’t save any time and would draw the network manager away from his core task just as much as letting him assess and buy software himself. The meetings needed to help the Change Manager understand the requirements is a time-consuming process and could very well result in an inappropriate purchase due to the Change Manager’s lack of experience in the specialized field.
ITIL expects another section of the IT department to implement the requested change. In the case of buying software to assist in managing the network, that would involve assessing the purchased utility. The people who are best qualified to assess the purchase are the network operations team, not some other department. If the ITIL change implementation team had enough skills to properly test networking software, they would be a shadow network operations team, which is a wasteful duplication of resources.
ITIL takes the decision-making changes out of the hands of the people who requested the change and who will also have to live with the consequences of a bad decision. Rather than improving the allocation of responsibility, ITIL just lets those who repeatedly make bad decisions progress up the career ladder without ever having to suffer the consequences of their poor judgment.
NetDevOps projects
A NetDevOps project is what ITIL calls a “major change.” This is not day-to-day maintenance because those tasks would naturally fall into the purview of the operations section even under ITSM. A typical NetDevOps project will need development work and major changes to the network’s infrastructure.
An example of this would be the selection of a new network monitoring tool or new maintenance procedures that require new software. Another example would be the creation of a new business department, which requires the provisioning of extra endpoints and the laying of new cable as an extension of the network.
The addition of a new subnet might require existing subnets to be reallocated. So, the impact of these changes would need to be assessed – a task that would be handed to a separate team under ITSM. A NetDevOps project will require more hardware acquisition than a typical DevOps project, which is usually almost entirely a software issue.
CI/CD
The concept of CI/CD is a DevOps strategy that can be applied to the creation of new systems under NetDevOps. The “CI” of this term refers to “continuous integration” and the CD can have two meanings: “continuous deployment” or “continuous delivery.” The concept of continuous delivery involves preparing software changes for release but continuous deployment means sending every code change straight to production.
The CI/CD model is closely related to Agile development. It involves putting part of the new system live and using the partial release as a method of testing the product’s suitability to users’ needs. The theory is that errors in the design can be spotted earlier before a large investment is made. This prevents an expensive change from being needed once the entire system is delivered.
As NetDevOps is much more about hardware than software, there are some projects where a partial delivery just wouldn’t be practical. For example, it wouldn’t be much use to anyone if a network is half-built. So, CI/CD practices aren’t as relevant to NetDevOps as they are to DevOps. However, there are some NetDevOps projects that could have a staged delivery, such as a phased transition to cloud services.
Changes to network infrastructure can often be an iterative process because expanding capacity in one area of a network can very easily create a new bottleneck elsewhere. Synthetic modeling software can help to spot these problems before an expansion project starts. However, these tools don’t always predict the future correctly. You will only know exactly what a change to the network will mean once that change is operational.
It is difficult to go to fund holders with an upfront definition of requirements, knowing that estimates of future performance might be wrong. NetDevOps gives network managers an easier way to say that they don’t know whether new problems will arise because of the expansion of infrastructure to alleviate overloaded devices. A NetDevOps framework can be depicted as a continuous delivery model to expand capacity all over the network, starting with remedies for that switch that is already known to be overloaded. This is a more realistic planning approach in the real world where traffic patterns don’t always behave the way they should in theory.
The CI/CD model involves putting out a partial solution quickly, monitoring the results, adjusting the new system accordingly, monitoring the results of those changes, making adjustments if necessary, and so on, until the design is settled into a service that actually works and performs all of the functions that the users want. So, the NetDevOps strategy of CI/CD is an ideal implementation model for network capacity expansion.
Benefits of NetDevOps
The organizational touchstone for DevOps is “breaking down silos.” In this phrase, a “silo” is a compartmentalized function of the IT department that has been frozen into a staffing pattern of permanently dedicated staff.
Under the ITIL model, staff allocated to one IT function is not allowed to pitch in and help when technicians working for a different function are overloaded. The ITSM solution to one section being overworked is to hire extra staff for that team even though staff with similar skills in a different section have little or nothing to do.
The main goal of DevOps is to increase profitability by improved efficiency. One example of how the strategy achieves that goal is through the better utilization of skilled staff. Very few businesses have enough change demand to justify having a separate network development section. The most constant staffing requirement is for operations. Because of this, the IT department will focus its human resources strategy on operations and contract out development to consultancies. This resolves the temporary nature of development but creates its own problems.
Bringing in expertise for development means that the operations staff don’t get involved in the construction of the new system. This means that knowledge exchange has to form a very large part of the beginning of a project. Operations training is an important handover task that occurs at the end of the project. If the people that currently run the IT system are the people who develop the new service, those interviewing and training processes are eradicated, saving both time and money.
The ITSM segmentation of tasks between teams creates unnecessary costs. Controlling the scope of a project is notoriously difficult and defining requirements becomes a very lengthy process that again, creates extra costs and delays. The external consultancy is not going to be bound to performing an open-ended task for a fixed price. That business is going to need to plan its own capacity and it will need to know when it can release staff from one project to start another for a different client.
The strategy of employing an external resource for development can result in contracts that improperly communicate requirements, delivering a system that doesn’t work but needs to be paid for. So, ITSM can provide unsatisfactory systems that need to be extensively reworked in order to get them to meet the original requirements. Those rewrites cost money and, in some cases, budget controllers are not prepared to allocate more funds to correct the system.
Office politics
An ill-fitting and inappropriate solution delivered to a badly-written contract can result in the operations department having to create workarounds to make up for errors and shortfalls. In reality, the development of all new systems in IT is a recursive process. That repeat cycle of release and revamp that is expressed in the Agile development model and CI/CD strategy is always going to occur. In ITSM, adjustments are seen as a failure, which is career-threatening for IT managers and seen as a source of shame.
The ITSM strategy of dividing up responsibilities in the IT department results in a large amount of office politics. Managers become reluctant to start a project, knowing that there is a great risk of failure. Doing nothing, or putting off the launch becomes a survival strategy. Spending time building a case to blame others before things inevitably go wrong ends up absorbing more management time than actually running a development project.
ITSM is de-skilling for operations technicians. Being left to maintain out-of-date systems, while glamorous and highly paid outsiders get all of the cutting-edge experience creates hostility between operators and developers. Both have the same skill sets and probably did the same courses at university, so could just as easily perform the same tasks if their job descriptions didn’t continually force each team down different career paths.
NetDevOps creates a single skills pool that can be applied to either development or operations tasks. This keeps all technicians on an equal footing and removes the possibility of some staff being underworked and underappreciated.
NetDevOps toolchains
Apart from CI/CD, there is no overarching theory underpinning NetDevOps the way that ITSM has ITIL. So, there aren’t single software packages of tools that support the process. Instead, NetDevOps managers and teams use a selection of separate tools, and each manager or department will choose different tools according to their past experience and personal preference. Thus, the software that supports the NetDevOps strategy is collectively known as a “toolchain.”
The topic of software for DevOps, and therefore NetDevOps would cover a whole article. In fact, we have written that guide and you can read it at The 8 Best DevOps Automation Tools.
L’article NetDevOps: Where DevOps and Networking Meet est apparu en premier sur Comparitech.
0 Commentaires