Why SDN isn't the big story
SDN really isn't what the industry should be most excited for, said the Peering Introvert's Ethan Banks. Instead, Banks likens SDN to an airplane -- it's more so a vehicle taking us to a destination. SDN is a tool that's allowing the industry to move into more exciting things.
For example, SDN is enabling things like automated provisioning, network applications, and the ability to implement business policy up and down the stack. Although many are fascinated and still stuck on focusing on the airplane -- i.e. SDN -- it's more important to keep in mind the big picture, or the things SDN is enabling the industry to do.
Read more of Banks' reasoning behind SDN as the vehicle to exciting things within networking.
Puppet and DevOps: A tool versus a way of life
On his ipSpace blog, network engineer Ivan Pepelnjak took a look at DevOps and Puppet after a conversation at Interop examined whether it's possible to configure devices with Puppet or Chef. Pepelnjak replied that although Puppet and Chef are tools, DevOps is a lifestyle.
He broke down the definition of DevOps, saying it's mainly used to deploy new functionality in a network more quickly than traditional methods. From a networking infrastructure perspective, there are two ways to do this: automating the network device configuration as much as possible while cutting out the need for manual CLI work, and decoupling the hardware infrastructure from the virtualized services using overlay virtual networks.
Puppet, on the other hand, is simply a tool used to deploy new servers, virtual machines or services. Pepelnjak said he would use it during the deployment of Linux-based products, but he may or may not use it to configure a network.
Take a look at Pepelnjak's full post explaining the differences between Puppet and DevOps.
Issues with policy compliance in the data center
On the Network Heresy site, authors Tim Hinrichs and Scott Lowe, along with contributors Martin Casado, Mike Dvorkin, Peter Balland, Pierre Ettori and Dennis Moreau, came together to review issues with policy compliance in the data center. Fully automated IT provisioning and management is considered the end goal for many, but fully automated IT management is tricky to do. The authors break down specific challenges of policy compliance, including competing objectives from the various sources that add to the policy.
The authors included a section on automating policy compliance and the specific issues that exist today with IT policy, like translating concepts into infrastructure configuration and application code. To truly enable policy compliance automation, two things need to happen: communication of the IT policy to the system in a language it can understand, and a policy engine that can not only understand the language, but can also bring IT resources into compliance and interoperate with the ecosystem of software devices.
Check out the post on Network Heresy, which examines issues with policy in the data center.
IT changes to make for a service-oriented business model
On his Keeping It Classless blog, Matt Oswalt took a look at the technical changes engineers can make to move to a more service-oriented business model. He broke down the post into two areas that admins need to examine: server virtualization and compute, and network engineering. He described the changes server virtualization is making to things like CPU, RAM and hardware.
There is also a transition happening within networking to more of an application focus. Oswalt calls for engineers to build processes that allow for less time spent on updating spreadsheets and tagging trunk ports, and more time spent on ensuring consistency across internal customers.
Take a look at Oswalt's post focusing on what network admins need to do to help change over to a more service-oriented model.