Recently, my colleague, Ehud Doron, who has been relentlessly promoting SDN, received recognition from the industry for his efforts. Taking home the “Outstanding Technical Contributor” award, Ehud’s ongoing contributions were recognized in the NBI working group of the Open Networking Foundation Summit.
Whether you are building a private cloud or deploying applications over a public cloud infrastructure, you will be using application delivery functionality such as load balancing to scale out application workloads. The level of required application delivery functionality differs between environments. While cutting edge web applications are often designed using REST oriented architectures which require the load balancer only to distribute traffic evenly, typical applications heavily rely on application delivery functionality such as SSL offloading, L7 policies, and session stickiness to properly operate. Furthermore, due to the strategic placement of ADCs in the application stack – in front of the application – security and performance optimization are natural extensions to effectively optimize application delivery.
Last week, I was able to attend AWS re:Invent, and it was great. Not only was I able to attend one of the largest events for cloud computing, but I also learned about innovative technology powering the AWS eco-system, I met great people such as AWS customers, AWS partners and AWS personnel. Most importantly, I was there to speak about Radware’s Alteon VA for the AWS Marketplace.
As the Software Defined Networking (SDN) hype dust settles, more vendors are offering SDN products that represent their take on the “how the world will be a better place with SDN” strategy. I figured that we should really get a better sense of what matters and what doesn’t when it comes to SDN controllers, as well as recognize the best ways to determine which controllers are a good choice.
Software Defined Networks (SDNs) are intended to help organizations simplify changes, improve multi-tenant support and increase network utilization. These benefits are achieved by separating the network control and data planes and by extending an API to the network controller such that applications can directly program the network.
Let’s recall exactly how server virtualization started and what it’s all about:
In the late 90’s, a company named VMware developed hypervisor technology, and as much as it had immediate appeal, not too many people really understood it and only a select few believed there was a business value associated with the technology.
There are three main factors that impact the reality of data communications: where data is stored, how and from what device data is accessed and the amount of data that’s stored.
In 2012 OpenFlow discussions turned into SDN ones. Related although different in significant ways, both OpenFlow and SDN drove a significant level of attention in the networking industry as Nicira’s Acquisition and Cisco’s moves served to establish the commercial value of SDN. In 2013, we are witnessing serious momentum in terms of discussions and start-ups around SDN. However, the questions remain as to which solutions will be successful and which solutions will become available in the market place first?
As the industry and the media keep feeding the Software-Defined Networking (SDN) hype and vendors introduce SDN products into the market – it is becoming increasingly important to understand the difference between various offerings as well as the ways in which they can help end users.
The majority of the discussion has centered on changes in forwarding functionality – the functionality of forwarding packets between interconnection ports of networking devices. With OpenFlow (which is not SDN, but is what triggered a lot of the SDN discussion) the intelligence making the forwarding decisions, which lies in the control plane, has moved out of the forwarding platforms that connect the external systems into the network and into the controllers. Here we have decoupled OpenFlow switches and controllers.