creative soul - Fotolia

News Stay informed about the latest enterprise technology news and product updates.

Network engineering careers: Yes, you should learn to code

From the SDN blogosphere: One network pro says coding will prove critical in the network engineering careers of tomorrow; another shares advice on software-defined security.

In this roundup of SDN-related commentary from around the web, one blogger tackled the ubiquitous network engineering careers question du jour: To code or not to code? Another explained what users should look for in software-defined security technology, and a third networking expert said the overlay network killed TRILL. 

Network engineering careers: Cracking the code

Russ White, a network architect at LinkedIn, based in Mountain View, Calif., recently weighed in on the debate surrounding coding and career development. White argued network engineers should learn to code, even if their jobs don't demand it -- and even if doing so won't necessarily lead to immediate pay increases or promotions.

That's because coding, White wrote, involves processes and tools that differ from those used in traditional network engineering careers. He said he believes learning to work and think like a coder can improve a network engineer's ability to design and manage networks. For example, interacting with document management systems can improve configuration management practices, and understanding how algorithms function can improve network troubleshooting skills.

According to White, the coding mindset also involves unique design and problem-solving approaches that can prove invaluable in network engineering careers.

White also argued that in the age of automation, networking pros will increasingly need to interact with coders directly. Read more of his thoughts here.

What is software-defined security?

Networking expert and prolific blogger Ivan Pepelnjak recently tackled a different question on his site, ipSpace: What is software-defined security (SDS)? In considering whether "this particular blob of hype" is really just marketing nonsense, Pepelnjak noted that software has driven security functionality for decades. In other words, the representation of SDS -- in the term's broadest sense -- as an entirely new concept is misleading.

To avoid falling for empty hype, Pepelnjak advised looking for SDS technology that simplifies network security functions by increasing the level of abstraction. He added that a useful definition of SDS can help users separate the wheat from the chaff, saying SDS technology should:

  • Manage security services through lower-level functionality abstraction;
  • Create security services on-demand and insert them in the forwarded path, as needed; and
  • Have a well-documented API.

Birth of SDN and death of TRILL

Network engineer Tom Hollingsworth wrote on his blog about how software-defined networking and overlay networks are leaving large Layer 2 networks in the dust, along with Transparent Interconnection of Lots of Links (TRILL).

The TRILL specification is an alternative to the Spanning Tree Protocol, designed to allow large Layer 2 networks in the data center to function by enabling multipathing.

According to Hollingsworth, TRILL is a casualty in the battle between software and hardware. The large Layer 2 networks for which TRILL was created experienced too many hardware problems that were cumbersome and time-consuming to fix.

Overlay networks, in contrast, proved much easier to adjust on a dime. When networking pros began moving functionality into software to circumvent hardware's limitations of scale, TRILL was rendered irrelevant. SDN, he wrote, became a real thing when the technology began solving users' problems without requiring the purchase of more hardware.

Check out Hollingsworth's full post here.

What to look for in a software-defined perimeter

On the Enterprise Strategy Group blog, analyst Jon Oltsik shared advice related to software-defined perimeters (SDPs). Also known as a black cloud, the SDP is a framework from the Cloud Security Alliance, based on the Department of Defense's need-to-know network security model. SDPs authenticate and authorize each individual network connection before granting temporary access. Until that point, infrastructure appears black, which means IP addresses are hidden.

Enterprises, Oltsik pointed out, cannot just deploy an off-the-shelf SDP widget. He said they will need to first collect information about their own network. Some factors to consider:

  • Strategic authentication approach. According to Oltsik, attempting to authenticate every transaction and encrypt every network session can quickly mushroom out of control from an operations perspective, while also opening the network to new security vulnerabilities. Enterprises, therefore, need a well-developed strategy before implementing SDPs
  • Data collection and analysis. To adequately manage its software-defined perimeter, an enterprise must prepare to collect and analyze massive amounts of network data in real time.
  • Business policies and enforcement. With the fine-grained access controls that SDPs allow, Oltsik wrote that each organization must decide how strict it wants to be -- weighing what constitutes permissible risk. 

Oltsik said he is a strong advocate of software-defined perimeters and predicted they will gain a significant foothold in the enterprise. He warned, however, the path to deployment will not be easy, likening it to a Lord of the Rings-like journey.

Next Steps

Python for network engineering careers

Will today's network engineers be tomorrow's network programmers?

How to get started with SDN

Dig Deeper on Networking careers and certifications