SDN: Not Just a Technology?

I have been watching the development of SDN with interest over recent months. SDN controllers have been released by some major SDN players recently, cementing its importance in the industry and as a technology with a future. Momentum is building, although most of the discussions have been around the technology itself, its capabilities and its application to the challenges within a business.

However, I wanted to start by looking beyond the technology and consider the impact of SDN on other aspects of the business; including teams, productivity, the network engineer, strategic networking, process automation and adoption.

IT Teams have predominantly been technology focused i.e. Network Teams with Network Engineers, Apps teams with Developers. SDN is an opportunity to change this traditional way of working with the possibility of forming 'hybrid teams'. These teams could be made up of a mixture of Network Engineers and Application Developers, increasing agility and effectiveness within a single high performance team resulting in accelerated deployment of new solutions. It would also allow more innovation as forward thinking teams would have the correct skills locally to deliver ideas without having to rely on resources from across the business and compete with different priorities.

SDN, as the name suggests is a software driven technology, requiring software programming skills to make effective network changes. This has naturally left Network Engineers questioning the value of their skills within an SDN orientated world. Although on reflection the technology still uses the same transport mechanisms, therefore, the engineering skills of today will still be required in the SDN environment of the future. Engineers will still need to have a good understanding of IP transport technologies, which will enable them to troubleshoot within different environments with increased complexity.

SDN does introduce new programming languages to network engineers which may cause some resistance but it is actually a blessing in disguise as it has the benefit of allowing management control across an entire network infrastructure with a common language agnostic of the hardware vendor. This also means skills are more transferable between organisations and platforms.

SDN Programming also has the ability to automate some of the network management tasks, i.e. A custom python script implemented on an SDN controller could potential automate the collection of information across an entire estate. This script could check on a monthly basis for any issues in the network configurations that could cause instability or compromise security including port group configurations or miss configured spanning tree. Implementing this script into an SDN environment would dramatically reduce the time spent on the task, increase the accuracy of finding configurations issues and consistency.

Its worth considering the risks of such technologies, one of which is the automation of inefficient business processes. Although this is not specific to just SDN it's just as noteworthy. Process's need to be reviewed and re-engineered to reflect the new agility and programmability of SDN. Automating inefficient processes often just amplify the problem and ultimately will have negative effects within the workplace. It's worth mentioning that a process should add value to the end user. Automation should allow processes to be re-engineered and made more efficient to the benefit of the end user, whether internal or external to the organisation.

Organisations should begin to prepare for SDN and develop a deployment strategy that considers the individual organisations challenges and goals. This should include when to buy into the technology and how to deploy it.

Deployment in SDN pods is considered the best approach, although it does require a top down approach and alignment with the business strategy to achieve the best possible return and benefit.

It is also worth considering the development curve of SDN in the marketplace and where your organisation sits on the technology adopter curve in relation to SDN. I suspect as with all technologies, the innovation is within the many small niched companies. As the technology develops to become more commercially viable, larger companies consume the smaller companies, or the smaller companies merge creating larger companies. At some point during this technology development we will see what vendors and their differentiators will benefit your organisation.

Taking all this into consideration, SDN has the potential to change the way in which a business functions and interacts with the network. This allows SDN to become a strategic advantage, improving users experience and reducing operational cost, although it does require careful planning and integration to your organisation to get the best out of it.

"Someone's sitting in the shade today because someone planted a tree a long time ago."

By Andy Partridge

Why DevOps and collaboration should be embraced in an automated world

It is increasingly common to find the word DevOps being bandied around in office corridors, but what does it actually mean for your typical System Administrator?

Certainly in the past I've ignored DevOps mainly because of the word Dev and its association with programming. I just didn't want to be a programmer. I've typically seen it as a separate role which fits in between sys admins and devs, but more recently I have seen that this is actually where System Administration is heading.

Most organisations have teams split between a production support function and a project function. This allows projects and development work to be separated from support so that appropriate priority and focus can be given to each activity. With the move towards "automation, automation, automation" across IT in general, sys admins are having to look closely at the manual work they do and how this can be automated and repeated across multiple systems.

As an example, a large global retailer I've worked with utilises Red Hat Satellite features such as Kickstart and Snippets to automate the installation of virtual machines in combination with Cobbler to streamline the build process. Using these technologies reduces the duplication of scripting by parametrising and re-using functions for different configurations. This is a first step on the way down the DevOps path.

Many other technologies exist to continue the journey. Again, the large retailer has begun introducing Red Hat Openshift as a method for reducing the time it takes to spin up environments by offering an on-demand service for developers to deploy to. This avoids having to go through the usual process of provisioning systems at the virtualisation layer and typically being held up by the many steps along the way before a fully functional virtual server is ready and available for use.

This isn't to say that provisioning is dead, not by a long shot, Openshift offers a quick and relatively simple method for giving developers what they want. Beyond provisioning there is configuration management where 'Infrastructure as Code' begins its life. Puppet and Chef are the new tools for sys admins and bridging the gap between development and operations as both developers and sys admins start understanding the opposite sides of the DevOps role.

It puts sys admins in a very good position as the coding practices in which they develop in turn allows them better visibility of the development environment and the associated tools that go along with it. Tools such as Git, Jenkins, Cucumber, Nexus and Artifactory. This all helps to improve communication between developers and sys admins and therefore has benefits in efficiency and the resolution of issues.

Developers can also write their own infrastructure code, giving developers the ability to work on projects without loading sys admins with unnecessary tasks. This all becomes a collaboration activity between Dev and Ops. Those tools, Puppet/Chef, allow the enforcement of configurations across multiple systems, ensuring the on-going maintenance is automated as much as possible. Where teams are split between Projects and Support, cross training of these new technologies has to take place in order for all the sys admins to understand the new methods being used.

In the end, when you combine provisioning technologies such as Red Hat Satellite/Cobbler and configuration management tools such as Puppet/Chef mixed with Git, Jenkins and Cucumber your infrastructure can be automated from build to deployment to on-going support and developed using a continuous integration cycle.

Sys Admins have the ability to understand both the code used in the automation and the commands to best implement them. I for one am looking forward to the challenge posed by DevOps.

By Dan Bateman