Imagine that you are a data packet. You have information to deliver, and you’re anxious to get started. Here you are at your source network device, and you look out on the vast network of switches, routers, and other machines. But where do you go? You look down and see that you’ve been given a destination IP address. Good. But now the question is: How do you get there? You either need someone to direct you along the path, or you need some clear instructions.
Through the years, we’ve gotten pretty good at sending data across networks. Yet despite our best efforts, the growth of data has far outpaced the speed of development in the arena of traditional networks. Just to remind you of how it works, let’s look at the flow of data that we have been used to over the past couple of decades.
Packets cross the physical layer of the networks constantly. Along the way, they pick up bits of information from higher layers. The data link and network layers of the OSI model tell the packets which way to travel to get to their destination. They are guided along their path by a built-in set of rules called protocols. These three lower layers of the OSI model carry conversations between devices throughout the network.
The problem with this traditional approach is that the coding of these devices is pretty much set, at least for a while. Think of each device as a traffic cop who has been given instructions on how to direct the traffic flow. The kindly officer will continue to send traffic in the same way until he is given further instructions. You see the real issue when you realize that path changes need to be communicated to every one of our traffic cops, and this takes a bit of work. The reconfiguration of switches, routers, and other network devices could take weeks or months – especially back when all this was a manual process.
Software-defined networking (SDN) changes everything. No more the tedious individual configuration of individual devices. With SDN, that can all be done from a central location. Our thinking packet analogy falls apart when we consider that the packets are not very smart at all. In a traditional network, the brains were in each network device. But SDN uses something called a controller.
Now just imagine that a packet that needs instructions to get to its destination can be directed by the SDN controller no matter where it starts its journey in a vast network infrastructure. The way that packets – all the packets – are handled by the network can be instantly altered at the SDN controller with the press of a button. Or it can be automatically redirected depending on changing network conditions, automation or programming.
The congested networks of the past are superseded by these dynamic new networks that are defined by software – not hardware. This state-of-the-art technology requires new tools and skill sets. But thankfully, it doesn’t require a wholesale refresh of network equipment. Network engineers who have been around for a while remember all the talk about “end of life” and “lifecycle” as it applies to network equipment. The finance department will be happy to know that transitioning to SDN doesn’t require a huge investment in capitalized equipment.
One thing that SDN does require is a new way of doing things. We’ve always thought of the maintenance and operations (M&O) functions of a network to be far removed from the laboratories of research and development (R&D). Not anymore. Developers have picked up their chairs and moved all the way to the network operations center – or at least close by.
Actually, the job of looking after the network is becoming something of a hybrid. A network operator may not need to know everything about coding, but she should know what it is. And the more that she can do on the development side, the more valuable she will be to the company.
Network engineers once said, “Don’t touch a live network.” But that seems to be what’s happening these days as technology developers take their place beside operators. The new model is called DevOps . What exactly is DevOps? Rather than offering our own definition, we’ll just borrow one from Amazon Web Services:
“DevOps is the combination of cultural philosophies, practices, and tools that increases an organization’s ability to deliver applications and services at high velocity: evolving and improving products at a faster pace than organizations using traditional software development and infrastructure management processes. This speed enables organizations to better serve their customers and compete more effectively in the market.”
Along with this new approach to development, SDN also comes with a new model – a new stack, if you will. You may have studied protocol stacks in the past. These are basically logical ways to visualize and understand how various parts of a technology interact. With the SDN model, there are three layers, and the controller is at the center. (To learn more, you may want to watch this video introduction to SDN.)
You might think of the controller as a sort of network operating system. Just as the operating system of a standard computer serves internal devices such as the CPU, storage, and memory, the SDN controller serves the various devices of the network. In this model, the smart routers and switches are not so smart anymore. They leave most of the decision-making up to the controller.
This illustration from the Open Networking Foundation (ONF) will give you a better idea of how SDN works. The controller communicates with elements through what is commonly called the “southbound interface”. At the same time, applications are connected to the controller through the “northbound interface”. All this interaction is facilitated by a protocol, usually OpenFlow (but it could be NETCOMF, OpFlex, SNMP, or others).
All this may seem unfamiliar, but you can’t stop progress. Centralized control of the network with SDN offers many advantages. Among them is the reduced time to market. What might have taken weeks or months before with traditional networking might only take hours or minutes with networks defined by software. Developers are happy because they can release faster, and they can make quick changes as needed.
SDN follows a whole new paradigm. The network is no longer constricted by the many hardware devices that inhabit it. There is so much more flexibility, agility, and power in this new application-centric approach. Network innovation now travels at the speed of software, and it is the essence of the Total Uptime cloud platform.
Network administrators may pine for the days of Frame Relay, ATM, and leased lines – but are those days are gone. Back then, we were more concerned about keeping the bit-error rates low on the customer’s data connections than catering to their latest applications. Anyone who wants to work in today’s high-tech networking environments had better keep up. And let’s face the facts: It’s not just about the latest equipment any more. Networks are now being defined software, and that’s actually quite a good change.
One of Total Uptime’s largest assets is our global cloud platform, deployed in dozens of datacenters around the world with incredible cloud based routing capacity. This platform gives our customers the ability to control and route traffic between the client and the datacenter, in the middle of the Internet. As you can imagine, this provides a […]
Companies across the globe are rapidly undergoing a digital transformation covering every aspect of their respected organizations, especially the enterprise. This macro process has pushed IT leaders to migrate applications and data to the cloud as well as software defining their own on premise infrastructures. This is being accomplished by incorporating the technology triad of […]
Roughly, a decade ago, VMware released their ESX virtual hosting platform that literally changed the datacenter, as we know it. It came at a time when datacenters were inundated with server sprawl as every new application request resulted in the purchase, racking and configuration of a new server. The arduous hardware purchasing process for servers […]
After unabashedly extolling the virtues of redundancy in a recent article , you may be wondering why we would follow up with another post questioning whether sometimes too much (redundancy) was just too much. Credit fellow staffers for the suggestion that we revisit the issue. The problem was clearly a part of our initial research, and it deserves […]