Filling the Development Skills Gap
| Chapter 3, "The Network Management Problem," described a solution mindset as a way of approaching NMS development. This involves a mix of perspectives that combine to cross the boundaries of pure development, such as GUI, backend/server, middleware, database, and so on. Instead, the central focus is on the overall solution rather than on the increasingly diverse component technologies. This is of increasing relevance because of the growing number of technologies being packed into NEs. Managing any given technology resolves down to the associated:
Arriving at these requires a broad range of skills. Linked overviews can help to identify the key elements of a managed technology (such as MPLS). A comprehensive understanding of all aspects of the technology, while useful, is rarely needed for providing management solutions. In spite of this, solution engineers will tend to acquire a deep understanding of the managed technology as they work with it. The key elements of the managed technology can be used to determine the associated managed objects. If a MIB has been supplied for the technology, then the main challenge lies in incorporating the relevant objects into the NMS. In solution engineering, the overall focus is not on a single item of work, such as producing:
Each of these is important, but it is the combination of all the NMS components that forms the overall solution seen and experienced by the end user . For this reason, solution engineering considers the end-to-end solution even beyond the needs of the current software release. Project work on a specific feature, such as adding Gigabit Ethernet management, is continuously viewed with questions such as the following:
The second-to-last point is essential for maintaining continuity of existing function in the NMS. Adding new features always risks breaking existing code and, for this reason, solution engineering encourages broader vision and attention to risk so that unnecessary breakages are minimized. This is a persuasive reason for minimizing changes to existing code (as mentioned in Chapter 3). It is perhaps the last point that most clearly characterizes solution engineering: trying to incrementally and safely exceed the requirements within an agreed timescale . This is particularly important as development cycles become shorter because it allows for the grouped releases (starting with the foundation release as described in Chapter 3) to dovetail into each other. If requirements A, B, and C are needed in the full release, then add A and B in the first release. In the second release add part of C, and finish it in the final release along with enhancements that have emerged during development. The test cycle required for foundation releases should be short ”a truncated version of that required for a major release. This pushes responsibility for testing the foundation releases onto the developers, but it helps to streamline the process. If possible, a skeleton QA team can assist in testing the foundation releases. The emphasis should be on successful, short work cycles achieved using a combination of careful software engineering and lightweight development processes. Major releases, on the other hand, should use the full test cycle and heavyweight development and test processes. As an example of solution engineering, let's look at adding third-party support to an existing NMS feature, such as MPLS. This consists of adding software to manage not only the vendor's MPLS NEs but also those of other vendors . This is a contentious and interesting issue because adding support for any device tends to add value to it as well as to the NMS. So, many vendors may be a little unenthusiastic about supporting and effectively enhancing competitors ' NEs. While this is an important issue, we note in passing that enterprise networks tend to be multivendor environments, so third-party support may be mandatory. An important point about the MPLS standard MIBs is that NMS support for compliant third-party NEs may be relatively easy to implement. MPLS equipment vendors recognize the need for compatibility and interoperability because trials take place regularly in various independent test sites, such as Isocore and the University of New Hampshire. [1] In these trials, vendors get a chance to competitively test their MPLS implementations . The reasoning is that if all the NEs are demonstrably compatible, then there is little reason for network operators to fear deployment of MPLS devices from different vendors. A consequence of this is the need for NMS to support more than just one vendor's hardware. So, if vendor X decides to add support for its own MPLS devices to its proprietary NMS, then a good solution would also add at least limited third-party support at the same time. This can take the form of allowing the user to create LSPs/tunnels that:
This means that while the network hosts multiple vendors' NEs, the MPLS content is driven by vendor X devices. However, the limited third-party support should enable the vendor X NMS to auto-learn (discover) NEs from other vendors. It should also be able to process traps from these devices. We mention in passing a further objection that may be raised to adding third-party device support: It competes with standard NMS such as HP OpenView Network Node Manager. Considerations like these show why adding this type of support is contentious. Existing development resources may already be stretched in providing support for the vendor's own NEs. So, why use precious development time in supporting other vendors' NEs? One reason is that third-party support can greatly assist end users in running their networks. Similar considerations apply to processing traps from third-party NEs because such facilities help users to manage their networks more effectively. Adding special-purpose NMS software infrastructure for in-field use, such as tracing facilities that can be turned on and off by the end user, can also be beneficial. This is particularly useful when software problems occur on user sites. The user can generate trace files and email them back to the developers for analysis. Alternatively, the developers can dial into the site and generate the trace files themselves . This helps avoid the need for developers to travel and can result in fast problem identification and accurate resolution. If the developers have taken ownership and inserted meaningful trace messages, then most problems can be quickly resolved. Developer Note: Training for a Solution Mindset ”Key AbstractionsThere are many ways of adopting a solution engineering mindset apart from the ones already mentioned. (Experience is perhaps the best teacher, but this section describes some additional approaches). Another way of becoming used to solutions in general is to gain expertise in as many as possible of the excellent general-purpose, desktop software packages available, such as those for:
These are powerful, increasingly GUI-based applications that are applicable across a wide variety of uses, including network management. Identifying and learning the constituent components usefully leverage the intellectual property freely available with these applications. This is beneficial because many of the components have become standard desktop objects, such as:
The more standard the look and feel is for an NMS, the easier it is to use. Ease of use translates into time, effort, and money saved in managing networks. Most standard applications do not provide source code, so they can be used only to learn the visual and processing paradigms . But even this can help to ensure that the NMS developer adheres to known usability guidelines. The Open Source community [OpenSourceWeb], however, does provide access to source code, which potentially opens up a treasure trove of standard components for developers. Interestingly, some NMS products [NMSOpen] are now open sourced. [Linux continues to pose a significant threat to the big commercial software vendors (i.e., Microsoft and Oracle, among others) and server vendors (such as Sun Microsystems)]. Many organizations now deploy Linux on cheap PC-based platforms. It remains to be seen whether Open Source will have a large impact on enterprise and SP network management products. It certainly can't be ignored. Apart from the visual aspect, just about every application supports some type of document-view architecture [MicrosoftWeb]. A document in this context is the application data stored in some persistent format, such as disk files or a database. The view is the application infrastructure (GUI, command consoles, etc.) provided for looking at, creating, and modifying the data. This is a useful abstraction for NMS development in which the persistent data is distributed between databases, disk files, and SNMP agent MIBs. Another important aspect of solution engineering is the ability to think in chunks . We saw this earlier in our ongoing discussion on MPLS, but it can be extended to other areas of development. It represents a form of abstraction similar to the way strong chess players think during chess games ”in certain positions specific patterns of pieces need not be considered individually because they are seen as interrelated chunks. In a similar fashion, rather than looking at the overall NMS and trying to think about it in its entirety, it is better to break it up into chunks. The chunk of interest at any given time is then selected out of the set of possibilities, while the others are temporarily left out of consideration. The different layers of an NMS (mentioned earlier) are a good example of these types of chunks. We mentioned that it is a good idea to (as far as possible) decouple technology-specific code (for provisioning, auto-learning, and trap handling) from other components. This modularization is not only good practice, it also illustrates what might be called chunk orientation . Technology-specific code can be organized into a backend block. This can take the form of (among others):
The form taken is not so important; the key is the functional demarcation . This backend code can then present a simple interface to the rest of the software and also to standalone test programs. These simple test programs can then be used to exercise all of the backend code well in advance of full database and system integration. The backend chunk then assumes an identity of its own. It can be modified and independently tested , and as long as the interface does not change, the rest of the system need not change. Modifications to the backend can then be assigned to different developers, and if it is reasonably well-structured , it should be easy to learn. Chunks like this serve to de-mystify the NMS software codebase and impose a known structural pattern on it. ComponentsThe industry has embraced object orientation as a healthy move away from monolithic (procedural) systems development. Component development is a further refinement of this concept in which software products are made up of reusable objects. An important aspect of components is that they should model real-world objects as closely as possible, including relationships to other objects. To illustrate this concept, we now look at a multisite VLAN implemented using an intermediate SP ATM/MPLS cloud. Figure 4-1 illustrates an Ethernet service provided by a central site joining two branch offices of an enterprise. The two branch offices could be in the same VLAN or in two different VLANs. However, the WAN link (provided by the SP) allows for traffic to pass between the two sites as required. The links between these two sites are transparent to the end users. This type of arrangement is called Virtual Private LAN Service (VPLS). Figure 4-1. Multisite Ethernet-to-MPLS interworking. The bidirectional transfer of Ethernet through an SP core is sometimes call Transparent LAN Service (TLS) and allows for multisite, single broadcast domains. The central site would typically be an SP network but it could also be an enterprise headquarters. The connections between the enterprise sites in Figure 4-1 can be Ethernet encapsulated over ATM. We have created an LSP (called LSP A) in the SP cloud that connects the ingress and egress interfaces X and Y. The label that corresponds to this LSP is Label2. So, traffic at interface X that is MPLS-encapsulated with Label2 can then get to interface Y. However, we have a problem because interface Y may be shared by more than one client (i.e., sites other than the New York VLAN might also use interface Y). So, some means has to be found to determine where to send the traffic at interface Y. The TLS solution is to use a second label (Label1) for this purpose. This means that traffic landing on interface X pushes both Label1 and Label2 during MPLS encapsulation. This gives us a label stack depth of two with the outermost label being Label2. The value of Label2 is then used to forward the traffic from interface X to interface Y, at which point Label2 is popped off the stack. We now have a label stack depth of one with Label1 as the outermost (and the only) label. The LER at interface Y pops Label1 and uses it to forward the traffic on to the New York VLAN site. One merit of using two labels like this is that it reduces the number of LSPs. The VLAN traffic must be mapped to Label1, for example, by mapping the associated IEEE 802.1Q VLAN ID to Label1. The following components are needed for this model:
Figure 4-1 illustrates only half of the story ”that is, getting traffic from Dallas to New York. To get traffic sent in the opposite direction, we would need two more interfaces, another LSP with a VLAN ID mapping. To manage this type of Ethernet interworking it is necessary to combine all of the above elements using an NMS. The overall managed object set is four ports, two outer labels, and two label-to-VLAN ID mappings. The components should be easy to combine, provision, and monitor so that the appropriate relationships are maintained between the two enterprise sites. NMS also have other components that add value by being as loosely coupled as possible, such as:
Network operators often perform certain actions at specific times. If the NMS scheduling facilities are freestanding and not tied to one particular application feature (such as connection management or backup), then the user does not have to use external software (such as running UNIX cron jobs to schedule NE configuration database backups ). Instead, the NMS can provide a scheduling function for all such operations. In other words, the user benefits because scheduling is implemented as a loosely coupled NMS component. This allows for executing the scheduled operations in a secure and controlled fashion (rather than using telnet). For operations that are repeated regularly and for which a permanent record is required, it is generally better to use the NMS. Crossfunctional CooperationThe complexity of NMS software development is such that many different people are generally involved in its production, including:
The efforts of these groups can assist in improving the quality of the end product. GUI developers can combine their visual controls as early as possible (rather than waiting for the integration phase) in order to call into the backend or middleware layers. QA can also assist in the early stages of development by first testing paper models (based on design documents) and later testing stubbed software builds. These builds provide the skeleton of the end system with much of the function not yet implemented. This is in advance of receiving fully functional builds. An early cycle of tests can provide useful feedback and at the same time helps QA become conversant with the new software. Regular cycles of such releases help all parties (including developers) in a project become accustomed to new features. This is somewhat related to the release early, release often model [OpenSourceWeb] that has been an important part of the development of Linux. Another important partner in the development process is IT. The setup and maintenance of modern NEs increasingly require professional system administration skills. The contribution that IT can make to this is significant, particularly when many users are sharing the NEs. They can quickly resolve issues such as NEs suddenly failing because a signaling protocol has been inadvertently disabled. IT staff are well used to managing complex devices as part of their day-to-day work, and this skill can be leveraged by development. Software developers can also assist crossfunctional cooperation by actively moving around the different areas of development and avoiding excessive specialization. As mentioned earlier, chunk-orientation in software structure helps to achieve this. Ownership and moving around the development environment need to be balanced against the needs of the developers (some will like to move around more than others). These areas include:
The last area mentioned is noteworthy because it is sometimes perceived to be the least glamorous role. Deployment software (such as those based on InstallShield or UNIX scripts) is the first thing the end user sees during installation of a given NMS. Traditionally, the bulk of project development effort goes into feature coding and testing, so a good implementation of deployment infrastructure is essential to the overall solution. Deployment is a very interesting and challenging area because it requires not only intimate knowledge of the product but also an excellent understanding of the host environments. Following are guidelines for successful deployment:
A short stay (of a month or two) in QA can also greatly assist developers in understanding the overall software development business processes. QA test plans can be written based on the content in software design documents ”this is an interesting and useful perspective for developers to acquire. This last point is particularly important, since testing can amount to nearly half the total cost of a complex project. Developers' moving between different areas helps spread knowledge and expertise around a team. This can then improve the accuracy of design and implementation because decisions are informed by broad experience. The cost of a given developer learning a new area in this way can be offset against the acquired expertise. Task-based development is closely allied to solution engineering. It is most clearly explained in the context of either bug fixing or maintenance code changes. A given task is assigned to a developer who applies the necessary changes, tests, and then submits the changes into a configuration management system such as Telelogic CM Synergy. Many code changes can relate to just one item of work (or task), and this is why a task orientation is extremely helpful. Software tools, such as Telelogic CM Synergy, allow for a task to be treated as an object in its own right rather than as a collection of source code file changes. The task can then easily be imported into or quarantined from a given development code stream. This is a very powerful facility and provides a substantial advantage over traditional version control systems.  |
EAN: 2147483647
Pages: 150