I don't think that anyone can deny that being in the IT industry at this time is exciting and interesting. It's also exhausting. There is a ton of hyperbole floating about on Twitter and the Blogosphere concerning the need for network engineers to become programmers, and that 'whatever' technology du jour is only minutes away from capturing the market and being the de-facto standard. Oh by the way, all networking gear will be white box gear too - didn't you hear? I've tried to NOT write a post that I fear will be read and dismissed as mere rhetoric, but here I am anyway.

As of late, I've had the awesome opportunity to work with some very cool customers who aretrying to take all of this hyperbole and spin it into a functional next generation network. Not surprisingly, one of the primary drivers is the desire for mobility and flexibility baked into and supported by the network. These customers want flexibility not just in their compute workloads, but also in the rest of their network. This same network needs to adapt to those compute workloads - to allow for security and load balancing policies to 'follow' the workloads wherever they may end up. Furthermore, the network must be able to support seamless migration of public facing services such as e-commerce, streaming, or simple web-mail to and from fluffy white clouds; all while maintaining said network policies.

These are fascinating problems to address in a static environment, but to further complicate things, none of these environments are static - it must all be 'automagical.' Everything must be automated and dynamically adapting to the business requirements without much, or ideally any, human intervention.

These problems are, of course, not new, but they are being driven to the forefront of every CTO/CIO's mind by the industry as a whole. The last several years has seen the advent of 'cloud computing' in mainstream IT, and the 'marketechture' (who needs real words when you can make up cool ones) miracle that is SDN. I see these 'things' as merely an evolutionary, rather than revolutionary, paradigm shift to the industry that some would have you believe. However, these phenomena have captured the collective mind of almost everyone involved in IT in any capacity, as well as many outside of IT, it seems. This form of mind control ('these are not the droids you're looking for') that has captured the attention of so many, is unequivocally more important than the technologies themselves, as it has brought about a new focus and new drive into networking. These new and evolving customer requirements popping up are a product of this new fascination and the realization that we can build a better network, one that more closely maps to adapt to the business needs.

How do we, as engineers, support this next generation network? How do we design it and build it? Clearly there is no simple answer, and no one single tool can do this for us. To build this 'business-centric' network, engineers will need to leverage every tool available to them in new and creative ways. Cisco's ACI is perhaps the tool to begin this journey with for many companies. ACI seems to have taken a sound, holistic approach to tackling the challenges ahead of us - identifying that applications are really the most important piece of the network, and providing flexibility and configurability to make impactful network decisions that can benefit a business.

For others perhaps leveraging the same tools that live within ACI in an a la carte flavor will be sufficient - VxLAN has certainly captured my attention. VxLAN can be implemented to enable seamless virtual machine mobility in a fully routed data center fabric with layer three equal cost multipath, thereby eliminating many of the legacy requirements of the traditional network. Ultimately, this will allow for new and exciting data center designs, and plasticity in service chaining.

These technologies and products are amazing, but likely are not the only pieces to the puzzle. How do we as engineers support growing and contracting the network based upon a company's widget manufacturing levels? In other words, the network will likely need to be able to respond to external stimuli in order to continue to adapt to business needs. As the widget level grows, perhaps a company will need to provide more compute capacity on demand via a service like AWS - the network now must respond to this by extending these security and load balancing policies to the 'Cloud.' Of course, once widget levels return to normal the business doesn't want to, or need to, be paying for cloud services, and the network along with the compute should contract to standard widget quantity levels. Right now, I'm fairly certain that this type of interaction can only be done through custom means via some external programing that can poke the network to respond one way or another (similar things exist, but not to this extent as far as I'm aware). Certainly, however, this type of flexibility is on the horizon in both open-source and commercial products.

All of this is to say that we have a tool belt as network engineers, and it's our job to take those tools and implement them in such a way that makes business sense, and provides a positive impact to our customers. Our tool belts *are* expanding. Yes, it's totally 100% exhausting how much stuff is happening in the industry right now, but it's also totally freaking awesome.

While I constantly say that networks 'should just be plumbing,' that doesn't mean that networking can't be exciting. ACI and VxLAN are but two examples of fantastic new products and technologies that will enable us to build better networks and have a good time while doing it. If we can provide invaluable business impact simultaneously - all the better. I don't think every network engineer needs to become a programmer, I don't think every switch will be white box, but I do think that this is a great time to be a network engineer if you have an appetite for learning.

So go learn a new cool thing and write a blog about it