SunGard AS has more than 9000 enterprise customers who count on our cloud services and managed services when disaster strikes. Lately, we’ve seen that the “Internet of Everything” is changing customer expectations. Our customers want new types of cloud services—and they want them sooner. They’re also asking to provision and control the services on their own. To keep delivering new products and services, we need a network that’s more flexible, intelligent, secure, and agile than ever before.
Our strategy for the future is to create a platform for service agility by enabling network programming. This is a radical change for our business and our customers. Not having to wait for engineers to program the network will help us bring new services to market sooner. Network programmability will also make it possible to offer new self-service options our customers are requesting, like bandwidth calendaring and service on demand. Read More »
Tags: Cisco, Fast IT, infrastructure, infrastructure programmability, Internet of Everything, IoE, network, Network programmability, ONE, programmability benefits, SDN, software defined
Now that OpenDaylight has arrived, it’s time to explain why I made the Open Source choices eventually embraced by its Founders and the community at large. One doesn’t often see such leaders as Cisco, IBM, Intel, HP, Juniper, RedHat, VMWare, NEC, Microsoft and others agree, share and collaborate on such key technologies, let alone the latter engaging in a Linux Foundation based community (some thought hell will freeze over before that would ever happen, though it got pretty cold at times last Spring).
For those of you not familiar with OpenDaylight (see “Meet Me On The Equinox”, not a homage to Death Cab for Cutie or my Transylvanian homeland), IBM and Cisco have actually started this with an amazing set of partners, nearly that ephemeral Equinox this year (~11am, March 20th) though we couldn’t quite brag about it until all our partners saw the daylight, which by now, we’re hoping everyone does. It was hard not to talk about all this as we saw those half baked, speculative stories before the Equinox – amazing how information flew, distorted as it were, but it did; I wish source code would be that “rapid”, we’d all be so much better for it…
The Open Source model for OpenDaylight is simple, it has only two parts: the community is hosted in the Linux Foundation and the license is Eclipse. The details are neatly captured in a white paper we wrote and published in the Linux Foundation. Dan Frye, my friend and fellow counterpart at IBM and I came up with the main points after two short meetings. It would have been one, but when you work for such giants as our parent companies and soon to be OpenDaylight partners, one has to spend a little more time getting everyone to see the daylight. It boils down to two things, which I am convinced are the quintessential elements of any successful open source project.
1) Community. Why? Because it trumps everything: code, money and everything else. A poor community with great code equals failure (plenty of examples of that). A great community with poor (or any) code equals success (plenty of examples of that too). Why? Because open source equals collaboration, of the highest kind: I share with you, and you with me, whatever I have, I contribute my time, my energy, my intellectual property, my reputation, etc.. And ultimately it becomes “ours”. And the next generation’s. Open Source is not a technology; it’s a development model. With more than 10 million open source developers world wide, it happens to be based on collaboration on a scale and diversity that humanity has never experienced before. Just think about what made this possible and the role some of the OpenDaylight partners have already played in it since the dawn of the Internet. Dan Frye and I agreed that the Linux Kernel community is the best in the world and so we picked the closest thing to it to model and support ours, the Linux Foundation.
2) Fragmentation, or anti-fragmentation, actually. Why? The biggest challenge of any open source project is how to avoid fragmentation (the opposite of collaboration). Just ask Andy Rubin and the Android guys what they fear the most. Just ask any open source project’s contributors, copyright holders, or high priests, how much they appreciate an open source parasite that won’t give back. Though we would have liked to go deeper, we settled on Eclipse, largely because of the actual language and technology we dealt with in the OpenDaylight Controller: most, if not all the initial code is Java, and though some are worried about that, I’m sure Jim Gosling is proud (btw, I’m not sure the Controller has to stay that way, I actually agree with Amin Vahdat), but we had to start somewhere. Plus having a more friendly language NB (northbound, as in the applications run on top of the Controller) is such a cool thing, we think that the #1 open source (Eclipse) and the #1 commercial (Microsoft) IDE’s are going to be very good to it, so why not? There are more reasons that pointed in the Eclipse direction, and other reasons for such wonderful alternatives (as APL or MPL, perhaps the subject of another post, some day). But when it comes to understanding the virtues of them all, no one understands them better than the amazing founders of these license models, most of them from IBM, of course (I wish they did that when I was there).
What happened between the Equinox and Solstice is a fascinating saga within the OpenDaylight community which I think played its course in the spirit of total and complete openness, inclusion, diversity, respect of the individual and the community, and most of all, that code rules – we do believe in running code and community consensus. I tip my hat to all my fellow colleagues that learned these two things along the way, the enormous talent at the Eclipse and Linux Foundation that helped us launch, and even the analysts who tried (and did incredibly well at times) to speculate the secret reasons why these partners came up with the model we did: there is no secret at all, my friends, we’re simply creating a community that is truly open, diverse, inclusive, and never fragmented. Just like a big, happy family. Welcome to OpenDaylight, we hope you’ll stay!
Tags: Android, apache, Cisco, community, controller, Eclipse, Fragmentation, IDE, java, Linux Foundation, Linux Kernel, ONE, onePK, open source, open source model, opendaylight, SDN
One of the themes of my posts is that the overall ONE strategy, including virtualisation, would create an environment for network systems development that would meet the expectations of systems developers accustomed to the “enterprise” style of software development.
An enterprise systems developer expects the required systems resources for software development to be readily available for development and test purposes. When those resources constitute web application servers and databases, this is trivial with virtualisation, and generally unremarkable in today’s enterprise environments.
When those resources constitute expensive, high-end, routing and switching platforms, though, life is not that straightforward. A major part of a network engineer’s time is spent on obtaining, connecting and configuring network equipment for demonstration and test purposes. You can’t just try an idea out when it occurs to you, as the required network platforms often can’t be available when, and in the configuration, you want.
But imagine what you could do if those network resources were available at a click of a button. What if network engineers had the same capabilities as software engineers to create virtual environments of near perfect fidelity? Well, with the technology of the Virtual Internet Routing Laboratory (VIRL), that we are demonstrating at Cisco Live in Florida, that possibility is getting closer. Read More »
Tags: BGP, cisco live, Cisco ONE, cloud, Intelligent Network, ONE, simuate your design, VIRL
I admit it. I’ve grown weary of the debate about whether SDN includes network programmability or whether or not SDN can only be accomplished through NfV, or the relative merits of control plane / dataplane separation. I will leave those debates to others more focused on the technology itself. Personally, I have been more fascinated with what I see as the new business opportunities emerging around SDN.
Certainly there is a raft of opportunities for start-up companies in the controller space or in the virtualization of various networking functions. Many innovative new companies are re-examining existing network functions within the SDN paradigm; that will lead to some potentially new and useful approaches that may be cheaper/easier/faster than current designs. No doubt many customers will see value in these new ways of doing things, and everybody will benefit.
But that’s not what I find fascinating about SDN. What I am starting to see are ideas that are completely out of the box, and would likely not be thought of by typical network technologists working alone. Let me discuss a few categories of things I have seen possible with the emerging technologies.
The Network as a Compute Resource
It turns out Read More »
Tags: API, cloud, NFV, ONE, onePK, opendaylight, OpenFlow, SDN
For those of you familiar with the movie “This is Spinal Tap” the volume on SDN has been turned up to 11 for some time. However, too much of the sound is around the technology and not on the benefits to network operators. In fact, Cisco views SDN technology and our Open Network Environment (ONE) as an opportunity for service providers to monetize and optimize their existing assets. In other words – leverage existing investments as much as possible and build SDN and programmatic Cisco ONE capabilities on top of them. Read More »
Tags: Cisco, NFV, ONE, onePK, quantum, Sanjeev Mervana, SDN, Service Provider