So, the theme for the day was “Less Unicorns, More Ponies”
I have to admit, I could not attend some of the afternoon sessions--there is a define downside to going to a conference with your boss.
Anyway, we heard from a number of folks (a lot of SPs and academics) that are doing the hard work of trying to do useful real-world things with OpenFlow and SDN. There were a fair number of successes but also a good number of struggles. Kudos to the ONS folks for trying to present a balanced view as opposed to hosting a two-day OpenFlow pep rally. So, sadly, the shine is starting to come off the SDN unicorn, but in the long run, this what needs to happen for the long term health of SDN.
Hands down, my favorite session was Igor Gashinsky from Yahoo! for a number of reasons: 1) it was darn entertaining, 2) I think hyperscale data centers present some the most interesting and demanding environments right now, 3) the use case was interesting, and 4) frankly, it allows me to make a point.
It seems that much of the conversation around SDN centers on the southbound conversation--the ability to program the hardware. While that is certainly useful and interesting, at least as interesting and important is the northbound conversation--the ability to extract interesting information from the infrastructure and make it available to the controllers, applications, tools, etc. In Igor’s case, he talked about being able to extract info directly out of the switching hardware to facilitate troubleshooting--not an inconsequential task when you have 20K servers and 400K VMs. Its a good use case but I also think its just scratching at the surface.
I believe its an interesting topic and one of the things that David Ward will dig into a bit further during his session this afternoon.
From an IT manager’s perspective, the applications that run the business are important, very important. In fact, many RISC/UNIX migration discussions focus on application support, performance, and availability. With a growing number of customers transforming their IT practices and economics by migrating off RISC/UNIX platforms to Cisco UCS, we have introduced Cisco Validated Designs (CVDs) for business-critical applications which also contain a RISC/UNIX migration element.
The first migration focused CVD is Oracle PeopleSoft on Cisco UCS. The goal of this CVD is to provide sufficient information to run an Oracle ERP application like PeopleSoft on Cisco UCS. ERP applications are the backbone for many organizations to run their business functions and robust performance is a requirement. With that in mind, we measured the online performance of Oracle’s PeopleSoft Enterprise Human Resources Management System (HRMS) 9.1 using Oracle Database 11g on Red Hat Enterprise Linux ( RHEL) 5.6 operating system. The solution was comprised of a standard 3-tier technology stack of web, application and database servers. The web and application servers were run on Cisco UCS B200 M2 blade servers and the database server was run on a Cisco UCS B250 M2 blade. This benchmark measured client response times for up to 2500 concurrent users which represents a small to medium-sized company profile.
SAPPHIRE 2012 is coming very fast, but is still 3 weeks away. So I figured out that I can give you some insights about what’s going on between Cisco and SAP!
The best ways are probably to let a customer share his/her experience, and to invite you this April 18th to a special webinar.
SAP Hana has truly revolutionized data analysis, allowing companies to tap into volumes of their company information in real-time. As one of SAP’s global technology partners and a certified SAP HANA hardware partner, Cisco has teamed with SAP to provide a foundation on which our customers can transform their businesses.
Medical technology leader Medtronics chose Cisco’sUnified Communications Systems (UCS) platform on which to run its SAP HANA in-memory computing appliance, because it was the best startegic fit with Medtronic’s existing infrastructure out of the four certified vendors considered .
To know more , please read this excellent article from InsiderProfiles.
In my last blog I focused on the architectural differences between traditional blade servers and Cisco UCS. Although I touched on the issue of management complexity, let’s take a closer look into how operational costs are affected by the cost of provisioning, monitoring, and managing your infrastructure.
According to many industry studies, roughly 70% of current IT budgets are allocated to maintenance activities with only 30% allocated to innovation. This spending imbalance comes from the fact that maintaining infrastructure is hard. Much of the difficulties are caused by the “accidental architecture” of management systems that have been put in place as an afterthought. For example, a traditional blade server chassis with 16 blades can have anywhere from 13 to 20 management interfaces!
Then you want to add virtualization on top of this environment? It is no wonder IT departments are struggling to meet cost objectives and run day-to-day operations smoothly!
So, I hit the tutorials at the Open Networking Summit, yesterday. Going back over my notes, some of my musings from the day:
There is certainly a lot of energy and passion around SDN--it was cool to see what all the folks were showing in their booths. Granted, half these folks are trying to put me out of a job, but hey, that’s life in Silicon Valley. In general, a fun day.
There certainly seems to be a lot of technical dogma for such a nascent technology. Cloud went through the same sorts of growing pains with arguments around architecture and technology. I think the sooner we can move beyond SDN being solely defined by a particular technology or protocol and start looking at SDN as a set of characteristics and capabilities, the better off we will all be.
SDN will continue the trend of moving the IT decision-making center of gravity outside of IT and towards the lines of businesses (LoBs). Cloud kicked off this trends and I believe SDN will continue it. SDN will allow LOBs to assert more direct control, which is good, but, there is some maturing that needs to happen. I heard a number of folks refer to OpenFlow as the networking equivalent of the x86 instruction set. I don’t completely agree with the analogy, but it is illustrative. I am not sure there are many LoBs out there that want to be directly manipulating flow tables any more than they want to writing in machine code. Most LOB-based developers are using Java or Python or the like, not assembly language. Cloud had its almost vertical adoption curve because the barrier to entry was pretty low--pull out your AmEx and, bam, you are in business. Huge potential with SDN, but still work to be done.
Speaking of which, there are some use cases like hyper-scale DCs and service providers, where SDN lets you do some cool things that are truly move the needle for them. In the enterprise, I still don’t see the killer apps. Talking to enterprise customers, most kinda shrug about SDN and question what it offers that they currently cannot do. For enterprise traction, the conversation really needs to show how it moves the ball forward. Kudos to Rakesh Saha from IBM yesterday for being one of the few folks to show how SDN can potential move the needle.