#SDN #SDAS How does Synthesis impact and interact with SDN architectures?
With SDN top of mind (or at least top of news feeds) of late, it's natural to wonder how F5's architecture, Synthesis, relates to SDN.
You may recall that SDN -or something like it - was inevitable due to increasing pressure on IT to improve service velocity in the network to match that of development (agile) and operations (devops). The "network" really had no equivalent, until SDN came along.
But SDN did not - and still does not - address service velocity at layers 4-7. The application layers where application services like load balancing, acceleration, access and identity (you know, all the services F5 platforms are known for providing) live. This is not because SDN architectures don't want to provide those services, it's because technically they can't. They're impeded from doing so because the network is naturally bifurcated. There's actually two networks in the data center - the layer 2-3 switching and routing fabric and the layer 4-7 services fabric.
One of the solutions for incorporating application (layer 4-7) services into SDN architectures is service chaining. Now, this works well as a solution to extending the data path to application services but it does very little in terms of addressing the operational aspects which, of course, are where service velocity is either improved or not. It's the operational side - the deployment, the provisioning, the monitoring and management - that directly impacts service velocity. Service chaining is focused on how the network makes sure application data traversing the data path flows to and from application services appropriately.
All that operational stuff is not necessarily addressed by service chaining. There are good reasons for that but we'll save enumerating them for another day in the interests of getting to an answer quickly. Suffice to say that service chaining is about execution, not operation.
So something had to fill the gap and make sure that while SDN is improving service velocity for network (layer 2-3) services, the velocity of application services (layer 4-7) were also being improved.
That's where F5 Synthesis comes in. We're not replacing SDN; we're not an alternative architecture. Synthesis is completely complementary to SDN and in fact interoperates with a variety of architectures falling under the "SDN" moniker as well as traditional network fabrics.
Ultimately, F5's vision is to provide application-protocol aware data path elements (BIG-IP, LineRate, etc..) that can execute programmatic rules that are pushed by a centralized control plane (BIG-IQ). A centralized control-decentralized execution model implementing a programmatic application control plane and application-aware data plane architecture.
Bringing the two together offers a comprehensive, dynamic software-defined architecture for the data center that addresses service velocity challenges across the entire network stack (layer 2-7). SDN automates and orchestrates the network and passes the right traffic to Synthesis High-Performance Services Fabric, which then does what it does best - apply the application services critical to ensuring apps are fast, secure and reliable. In addition to service chaining scenarios there are orchestration integrations (such as that with VMware's NSX) as well as network integrations such as a cooperative effort between F5, Arista and VMware.
We see SDN as validating what We (and that's the corporate we) have always believed - networks need to be dynamic, services need to be extensible and programmable, and all the layers of the network stack need to be as agile as the business it supports.
We're fans, in other words, and our approach is to support and integrate with SDN architectures to enable customers to deploy a fully software-defined stack of network and application services.