In this third and final article on the information packed 2013 TiECon, we summarize key messages from the second half of the SDI Track on May 17th, including the afternoon keynote and two panel sessions. The first article covered all of the TiECon opening keynotes. The second article summarized the invited SDI presentations from the morning of May 17th (but not the panel sessions covered in this post).
PM Keynote: Software Defined Infrastructure – The Coming Wave of Datacenter Disruption
by Steve Herrod, PhD -General Catalyst Partners
Large Data Center (DC) operators are under great pressure as they attempt to learn how to bring the benefits of public clouds to their DCs. Those benefits of the cloud include: agility, flexibility, scalability, and reduction in total cost of ownership. The DC operators recognize they have to rebuild their DC infrastructure to realize those goals. Compute server virtualization was the first step – it’s been widely deployed and has been hugely successful in improving efficiency and lowering compute system cost.
In the Software Defined Data Center (SD-DC), all infrastructure (compute, storage, network, management) is virtualized and delivered as a service. Control of the DC is then entirely driven by software.
Software Defined Storage is emerging together with a new class of applications. The objectives here include:
- Move compute (servers) closer to storage
- Make use of local disc and flash memory
- Get better utilization of flash memory
- Take advantage of economies of scale (e.g. get good pricing on memory)
- Auto provisioning
- Common automated management across all tiers
Today’s network can be a barrier to effective cloud computing. Network virtualization will help break that barrier. It provides a separate logical view of the network to services and applications, which is independent of how the physical network is laid out (topology) and implemented. Automated management should be an adjunct to Network Virtualization (logically off to the side or on residing top of it).
How to bring efficiency and automation to high level services in the SD-DC? Steve recommended the following:
- Migrate entire DC (and beyond) to SDI.
- Traffic management and security policies should be part of SDI.
- Bring firewall and intrusion detection close to workloads, which results in a tighter security policy.
- Provide “Instant” provisioning of the network (L2-L3) as well as L4-L7 services.
- Provide Disaster Recovery (DR) without the need for pinging.
- Management should wrap all of the software-defined services together.
- Treat SDI management as a “big data problem.”
The figure below is a candidate solution for the SD-DC. It depicts a Software Defined Network with Open Flow protocol used to communicate between the Physical Network (Data Plane) and centralized SDN Controller (Control plane):
Panel Session: Software Defined Networks (SDN) Adoption — Crossing the chasm from Early Adopters to Mainstream: Google, NEC-America, Orange-Silicon Valley
Key points made during this panel session:
There’s a steep growth in number of network users, need for more bandwidth, different types of information (e.g. video) transmitted, and a variety of services delivered over broadband networks. But the network “economies of scale are now terrible.” SDN provides better management, orchestration and control of network resources.
Global knowledge of the network topology facilitates quickly moving functionality from one (Google) DC location to another. Note, Google’s first SDN implementation was in an internal network which interconnects all their DCs.
“The industry needs more clarity in terminology, e.g. SDN, Open Flow, NFV, NV, etc.”
Commonality is needed across all parts of the IT infrastructure (compute, storage, network, management). In particular, for auto-provisioning, service automation, and interactions with the rest of the system. More network interactions with many more devices, appliances, load balancers, etc. calls for a new, software based approach to networking. SDN may be used in Content Delivery Networks (CDNs) (No explanation or justification was provided).
There are still a lot of gaps in SDN before it can become mainstream. These include: QoS control, scalability, details on orchestration/provisioning, and network resiliency (protection and/or path restoration on failure). SDN also needs more business drivers to create a mass market.
How do we innovate while ensuring openness for the Data Plane? At a minimum, the Data Plane needs to access flow tables and semantics (from the Control plane) in a standardized way (ONF is standardizing Open Flow for that very purpose). Standardized communication between Control and Data Plane will lead to reduced CAPEX and (more importantly) OPEX for network operators. It will also facilitate the creation of new revenue generating services for network service providers, like Orange. Telcos should think of the network as a service (NaaS), with greater agility and lower OPEX than current networks offer.
ETSI NFV is adjacent to SDN. There are mobile network use cases for both. How SDN and NFV are related is an open question. Look at the mobile packet core (Evolved Packet Core =EPC for LTE) as a good place to virtualize the network.
We need a full implementation of SDN (not just Open Flow) as well as truly open APIs to have a programmable network. Network as a Service is not quite here yet. We need to personalize the network first, i.e. the user “owns” the network for a particular session.
Panel: Architecting a Scalable Software Defined Networks (SDN) Solution: Juniper, Cisco, Big Switch
Key points made during this panel session:
- Cloud computing, mobile data & connections, and social networking are all putting pressure on the existing network infrastructure (both wireless and wireline).
- Users want more control of the network and more automation.
- Need a level of abstraction that we don’t have today.
- Juniper: SDN can provide more control of the network while being decoupled from network equipment and devices.
- Big Switch: Industry needs to bring good software design into network architecture. This includes: loose coupling, modularity, APIs in between layers.
- Cisco: SDI solutions for network service providers will be different than those for enterprise or Data Center customers.
- Cisco: IT organizations are not set up to take advantage of SDN and this represents a barrier to adoption. There are also perceived risks with any new technology (such as SDN). IT skill sets need to change to take advantage of what SDN can offer.
- Big Switch: Corporate culture and skill set gap is an issue for SDN deployments. “It will take people a while before they can wrap their minds around SDN.”
- Juniper: SDN will simplify the network and lower barriers to adoption. If using SDN makes a company more efficient, it will realize more revenue and be able to do more with less people, e.g. network administrators.
- Juniper: What is the correct abstraction for networks? He doesn’t know if SDN is the answer and doesn’t believe in standardized APIs that enable users to “program the network.”
- Big Switch: Open Daylight consortium (open source software) will permit everyone to leverage a commodity SDN controller.
- Cisco: Industry needs to bring eco-system together to avoid market fragmentation (this author thinks that this is the #1 stumbling block to SDI).
- Big Switch: Customers (users) care about benefits of the application(s). They don’t care about implementation details of SDN.
- Juniper: DC scale is huge. We have an agile compute infrastructure now (through server virtualization), but the neither the DC network or storage is agile or efficient. That’s the big opportunity for SDI. He recommends configuration of the DC network to handle storage information exchanges, as well as packet forwarding for compute tasks. Note, that’s a huge change from the current DC environment where there are separate networks for storage (Fiber channel based SANs) and compute (Ethernet).
- Big Switch: As everyone is working on SDN for DC networks, start-ups should look for less crowded SDN opportunities. Those might include: campus LAN, enterprise networks, or mobile networks (campus and wireless telco). Advice: be focused and nimble (they are opposites of one another), be prepared to go from plan A to plan B, carefully pick the ecosystem to work in and not do anything else.
- Cisco: A great start-up opportunity is SDN professional services and support. Start-ups should “go where no one else is.” He says, “Plexxi stuff is awesome.” Pick something to work on that gives you a sustainable advantage over the competition.
- Juniper: Start-ups should focus on their value add when making the key decision of what to do and not do in the SDI space. “Think about how you are going to make your first dollar and who is on your leadership team.”
- Cisco: SDN is a tool that may solve customers problems. (No explanation or justification provided)
- Juniper: Customers say “I want SDN. What is It?” That indicates potential SDN users are confused by all the hype and vendor claims.
A Service Provider view of SDN– Victa McClelland of Ericsson
Victa talked about Ericcson’s SDN trial with Telstra. Due to time and space limitations, we can not cover it in this article, but refer the reader to this Ericsson presentation from 2013 Open Network Summit: SERVICE PROVIDER SDN MEETS OPERATOR CHALLENGES
Panel: How do you manage the Software Defined Infrastructure (SDI) – Use Cases and Technology : AppDynamics, BMC, VMWare
Again, due to time and space limitations, we can not cover this panel session in this article. However, we emphasize that management will be a crucial component of SDI. There are no standards or open specifications for SDI management at this time, so it will be vendor specific for quite some time.
We hope readers enjoyed this three part series on 2013 TiECon, which highlighted the SDI Track sessions. We will be covering more of that topic in future posts, including the SDN related sessions and discussions at last week’s Global Press & Analyst Summit at the Computer History Museum in Mt View, CA. Bob Metcalfe’s closing keynote is at: