Hello, Security, My Old Friend

Back before software-defined networking, I spent time promoting a different “SDN”: “Self-Defending Networks”. That was Cisco’s marketing tagline for their Security portfolio. At the time that I joined, they had just brought together security-related products from different BUs as the Security Technology Group, under Jayshree Ullal.

Now, Self-Defending Networks wasn’t something that held up under even the lightest technical scrutiny. All of the products except for NAC were acquired, so each had its own element manager with its own policy schema, and none of them really talked to each other. And it’s kind of hard to run an effective security team if each member speaks a different language and operates from a different rule book, regardless of how individually skilled they may be. That’s why I find the possibilities of having a common layer of abstraction (a la ODL) so compelling: you can’t have reliable security without holistic, end-to-end management (too many gaps), and if you have good holistic, end-to-end management, you can spend less time and energy on security.

I’m joining Skyport Systems because it resolves a lot of these challenges in a very streamlined way. It also manages to simultaneously address many of the reservations people have about entrusting sensitive data to external cloud providers, while also providing a consumable Security-as-a-Service offering that eliminates a lot of those security tool integration challenges. That’s a pretty good trick, in my opinion.

It also doesn’t hurt that I’ve worked with several members of the team before. (Fun fact: I accepted the Skyport offer during Back to the Future week. I think I’ve identified the team’s Doc, too.) It’s an intense, high-energy crew, but importantly, one that is generally pretty strong in the Sense of Humor department as well. The leadership team members each have both startup experience and successful track records in large companies, meaning that they’re not afraid of getting their hands dirty, but also have the mindset and rolodexes to scale the company.

One other consideration I had, as a marketer: technical realities aside, I liked that Self-Defending Networks was a fundamentally positive, hopeful vision to strive for. Too much of security marketing (in IT and in modern politics) is all about instilling fear–which often skews perceptions of and responses to risk in wasteful and even counterproductive ways. I prefer a more positive message: providing a foundation of trust. I think Skyport has the right bones to support that.

More soon.

Meet the New Software-Defined Network. Almost the Same as the Old Network.

Occasionally when I wake up, I have some utterly obscure question percolating in my brain. Once, it was about the color of the original, undomesticated carrots (white and purple, it turns out–like their cousins the turnip and the parsnip). I have to go look it up so I can go on about my day without further mental interference, which is why I can tell you, for example, that there is an online Carrot Museum that will tell you everything you want to know about carrots. Also, in Afghanistan they make a fermented beverage from wild carrots. (Thanks, brain!)

Today, I simply had to know what “palimpsest” means. Here’s what it means:

A palimpsest (/ˈpælɪmpsɛst/) is a manuscript page, either from a scroll or a book, from which the text has been either scraped or washed off so that the page can be reused, for another document.[1] …In colloquial usage, the term palimpsest is also used in architecture, archaeology, and geomorphology, to denote an object made or worked upon for one purpose and later reused for another, for example a monumental brass the reverse blank side of which has been re-engraved. [Wikipedia]

SDN is an excellent example of a palimpsest. Let’s take the SDN origin story as gospel: why, indeed, shouldn’t you be able to program a switch the way you can a non-purpose-built computing platform? The short answer is because the networking industry, and the devices it continues to produce and sell, evolved in a certain way, and the world is filled with such devices and vast numbers of people trained to interact with them via communication protocols vs higher-level constructs.

So now we’re elaborating an assortment of higher-level constructs under the common banner of SDN. This does not, however, eliminate existing network concepts, protocols–or the actual networks themselves. We are using all of these things as the foundations upon which software-defined networks will be operated, much as the “Troy” excavated (with dynamite!) by Heinrich Schliemann was, in fact, as many as nine different cities, each of which built upon the decaying foundations of the previous one. And why not? It all works moderately well, and we have lots of people who know how to make it work.

The thing about “adopting” SDN is that it’s a little bit of new technology, but a lot of mindset and process shifts. This, I think, is why SDN is starting to enter a winter of discontent (or if you’re more of a Gartnerian than a Shakespearean–a trough of disillusionment). Networking salespeople and users alike are trained to buy/sell boxes that you plug in and that largely ends the transaction until the support contract comes up for renewal or there’s an opportunity to add in more boxes. SDN controllers today, by contrast, are all at the some-assembly-required stage of evolution. And if your SDN use case is BetterFasterCheaper manageability, it’s very reasonable to question why you should go through a whole bunch of new gymnastics moves to do more or less what you’re already doing in a different way.

It would be a mistake, though, to imagine that the current state of affairs is the de-facto nature of SDN. As controllers mature, they will of course become more plug-and-play. Now that the industry has begun to consolidate around a few leading platforms, we will start to see more packaged SDN applications to run on said controllers. Meanwhile, the bleeding-edge organizations moving towards active deployments now are investing heavily in training NetDevs to build their own applications for proprietary use cases. At Open Networking Summit this spring, and in subsequent media interviews, AT&T indicated that they’re putting tens of thousands of network engineers through specialized coding classes. Some portion of those engineers will eventually go on to jobs at other companies, spreading their new expertise into new soil.

And as I wrote in 2013,

…Today’s discrete controllers will wind up going one of two ways:

  • Down, coupled ever more tightly into existing network operating systems, until eventually they will simply be part of OSes with better northbound APIs than before. This will be especially true of “house” controllers from existing networking vendors.
  • Up, as platforms for emerging ecosystems of network applications. There’s nothing to prevent house controllers from moving in this direction, and for major vendors to develop their own developer ecosystems (well, nothing but mindset and institutional support for such)…

There are those, in fact, who expect that controllers will eventually be packaged with applications such that the (micro)controllers are transparent to the user, as opposed to an independent piece of software to be set up and then integrated with a parade of disparate applications. This scenario will necessitate a truly de facto industry controller platform (we’re far from that yet…) as well as a standardized architecture for peer-to-peer controller communications, and mechanisms for defining order of precedence for operations stemming from different applications.

None of this, however, will change what lies beneath in the foreseeable future. We’ll still have some mix of physical and virtual forwarding devices, managed via some set of protocols–some older, some derivations or extensions of existing ones, some genuinely new ones–because SDN doesn’t necessarily change anything about forwarding architecture, and because of refresh cycles and human operator inertia. It will still be valuable for quite some time to understand how those protocols operate on the devices, even as the preferred method for doing so shifts with controller advances and the general state of administrator skillsets. It’s entirely conceivable that 15-20 years down the road, the idea of monkeying around with networking protocols themselves will seem as arcane to most as being fluent in the inner workings of the systems bus in your PC. But we’ve got a long way to go as an industry before that state of affairs appears on the horizon, and most of that shift will come well after we have some semblance of controller maturity and an SDN application ecosystem in place.

Meanwhile, I’ll apparently be mulling over things like the origins of carrots. Stupid brain.

Stop Hiding. Just Ask.

I came across an exchange on Twitter the other day that made me sad. In part:

Opensource newbie

It made me sad because I spent longer than I should have in a similar place: curious, interested, wanting to know more and also to have input, but being surrounded by people who’d been doing “this stuff’ for 20+ years. I was at a loss as to how I’d ever “catch up”, never mind be in a position to provide value.

Here’s the thing: I wound up in that place because I’d invested a good 20-25 years of my life by that point in making sure I was really competent. Competence and knowing what you’re talking about are things that are valued very highly in my family. Moreover, I grew up surrounded by engineers, who tend to enjoy arguing and sometimes pounce with delight on logical lapses or other types of weak arguments. So from an early age, I shied away from spending a lot of time on things that didn’t come naturally. Early in my career, I did the same: I carefully stayed in roles that didn’t require me to have any specialized knowledge. By my mid-30s, I was in a rather small box–one entirely of my own making.

Now, had anyone else told me I just didn’t have what it takes to do any particular kind of job, I most likely would have furiously plunged into proving them wrong. Instead, I took great care to avoid fulfilling the stereotype of the clueless (female) marketeer: I asked no questions that could be “dumb” questions. I’d quietly go read up on things on my own, but a lot of the time I didn’t have enough context to make total sense of what I read. Still, I avoided asking questions.

What finally did it was screaming boredom. I just didn’t want to keep doing what I’d been doing any more. I decided I’d rather be dumb than bored.

It was terrifying.

Eventually I found a colleague who was working in a similar area, but was coming into marketing after a long time as a engineer. We’ll call him Fred. Every so often I’d walk over to Fred’s cube and announce (pre-emptively, in my mind), “Hi, I have another stupid question,” to which he would helpfully reply, “There are no stupid questions, only stupid people.” And then proceed to explain both the theory and the depressing reality of whatever I was asking about. I have since learned to spot Freds fairly quickly, and over the last few years I’ve built up a wonderful network of Freds. Thanks to social media, most of them are not in a nearby cube, but several states or even a continent away–but that means I get a much broader perspective on whatever I’m curious about than if I just asked the person in the next cube whose vantage point on the world likely only differs from mine by a few degrees.

This brings me to a wonderful talk I unexpectedly attended a few months back. My daughter had been taking a Scratch class through Coder Dojo, and the last night of the session, the parents were all asked to gather in a different room for a pitch from one of the Coder Dojo cofounders, Bill Liao (@liaonet).

Liao opened by stating that coding is poetry, which won me over right there. To be good at poetry, he said, you have to be deeply fluent in a language, in a way you can be only if you speak it from a very young age. It goes without saying, perhaps, that when you learn to speak a language in a fluent, natural way, you do it by interacting with other people. Or as Liao put it,  “I learned to code in my bedroom, and I think working alone in your bedroom is a terrible way to learn to code. I think working with others on a project is a great way to learn to code.”  You can watch an abbreviated version of his talk below.

And this, in turn, brings me to a lesson taught to me by my friend Brent Salisbury (@networkstatic), who became active in OpenDaylight in its very early days. He was trying to convince me to get involved. “But Brent,” I protested, “I haven’t coded in 20 years, and I never got good at it even then.” He told me it didn’t matter. ODL desperately needed documentation. QA. “Play around with Python,” he said. “Hell, I’m dyslexic–if I can code anyone can.” The point being that any project in which people are doing things mostly on their own time–which is most open source projects–desperately needs help of all kinds, and will usually gladly welcome a range of skills, not just narrow technical ones. “I’m just learning how to code, but this is really interesting to me–how can I help?” is as good a door-opener as any.

And of course the way to make book-learning–or any learning–really stick is to try to use it. At Brocade, we have a couple of SEs who have spent most of their careers as network engineers, but are really excited about SDN. They’ve been delving into the documentation–both on the ODL site as well as the materials for my company’s distribution–and making notes about how it works in ways that make more sense to someone accustomed to running a network. I myself had learned about SDN and ODL from a more classical software perspective, so reading what they’ve written was really helpful to me, as they naturally point out very practical nits and concerns that hadn’t occurred to me. Now we’re in the process of converting their work into papers the bigger world can access, which should be helpful to a lot of other network engineers trying to get their heads around this stuff. Note: none of us is writing Java code. All of us are contributing to the growth of an open source effort. It takes a village.

Becoming an expert also takes a village. It’s why throughout history, you find innovation happens in clusters, where talented people gather, get to know each other, and exchange ideas. The lone genius is a myth. Mozart was mentored by Haydn, among others.

Ask for help, and ask how you can help.

Why Open SDN – In 6 Words

In Maslowian terms:

Open SDN by Maslow

Maslow’s SDN – by Lisa Caywood

Interoperability of different device types from different vendors.

Optimization of device selection–for price and performance independently of services features.

Continuous visibility of flows from source to destination.

Informed, centralized manageability for all devices.

Programmability to shape network and network tools according to users’ needs.

Automation of and by policy.

ONUG Spring 2015 & the Cancer of Vendor Sponsorship

Based on feedback from attendees of earlier ONUG events, I was looking forward to this conference. Right now, most of my customer conversations are at the “1a” level (“What is SDN? What does my company mean when we say SDN?”). There are certainly some that are more sophisticated (we have paying customers for our controller, after all), but I was looking forward to a concentrated gathering of users to hear what’s on their minds.

Here are my observations from Day 1:

Speaking of vendors–most of the vendor attendees were small startups, many in the SD-WAN space. Of the established players, Juniper was notably absent. And despite the clear interest in white-box with this group, Cumulus opted not to invest in this event.

There were some bright spots, notably Adrian Cockcroft’s talk about how to DevOps. You can view his slides here. Ted Turner from Intuit (Ananda Rajagopal’s guest) later in the day talked about how Intuit is taking 15-year-old apps and breaking them into microservices, and then leveraging AWS for the non-core portions of the app workflow. The reliance on AWS for a significant portion of one’s IT operations was actually a fairly common theme in both speaker and offline comments.

Unfortunately, the rest of Day 1 was given over to “Working Group test results presentations”, aka the aforementioned vendor panels. Or as Andre Kindness of Forrester put it:

Today the morning sessions were closed to us vendors–fair enough, I suppose…on the one hand, I can appreciate users’ desire for frank discussions without getting aggressive phone calls to their management from certain suppliers. On the other hand, hearing what users are really struggling with (which isn’t always the same thing as engineering’s neat ideas) is always instructive for those of us who might be in a position to help provide solutions. I’d be good with seats in the peanut gallery and a strict behind-the-red-velvet-rope, listen-only policy for vendors for these sessions–especially since there was no bar on media attendees.

The first open session of today featured Najam Ahmad of Facebook. Facebook is doing some very interesting things with their infrastructure, and although it’s certainly not, in its entirety, a blueprint for most other companies, there are always interesting nuggets in their presentations that can be applied in other contexts. For example, when an audience member asked about getting the right skillsets in the networking organization, here’s what he said (slightly paraphrasing):

“We have a free-hacking month once a year. Anyone can go work on any team they’re interested in, and at the end of the month, if they want, they can stay with that team, or go back to their old team. For a while we weren’t getting any of the software engineers. Networking just seemed boring and weird to them. Then we started framing it as a big distributed systems project, and that started drawing them in. Then you have the problem of developers not knowing much about networking and vice versa, so we paired networking people with software devs and had them work together on projects, with the expectation that each would learn from the other. Now everyone on our team codes, to some extent. Some more, some less, but they all have an appreciation for each others’ knowledge and skills.”

There were some luncheon sessions that I couldn’t stay focused on because they mostly had the same problem as Day 1’s panels. This was followed by an investor panel, which mostly focused on two questions:

  1. Will SDN/NFV/whitebox hurt Cisco?
  2. What are the prospects for startups in these areas?

On #1, the view was that if Cisco and other established networking vendors lay down strong strategies now, once we start seeing active deployments a year or so from now, it shouldn’t make a significant difference for them. The hype around SDN of a year or so ago, which appeared to be hurting Cisco’s stock price, has died down as the reality of the length of this transition (10 years, one speaker posited, which seems very likely) has set in, and there’s plenty of time to get the go-to-market execution in place. Interestingly, the institutional investor commented that he didn’t see VMware NSX breaking out beyond the security segmentation use case it’s currently positioning. NSX’s architecture as a vertically integrated software stack anchored to a specific hypervisor probably does limit its use cases more than other, more general-purpose controllers, but given the very long runway the same speaker gave other vendors in the space to work out their strategies, I was left wondering what other knowledge and commentary was behind the comment.

On #2, no one expected any significant moves to IPOs or strong exits in the next year, owing to the expected leadtime on real SDN deployments. One speaker also commented that the bar would likely be higher for IPOs than in past cycles, with an expectation that the company actually be making money before entering into the public markets. That would be refreshing, wouldn’t it?

The final session today was a discussion on DevOps, which was covered very adequately by other bloggers. In fact, here are links to several other live blogs posted by my Networking Field Day friends:

ONUG Spring 2015 Live Blog – Day 1 (Ethan Banks)

ONUG Spring 2015 Live Blog – Day 2 (Ethan Banks)

Tom Hollingsworth/John Herbert – Day 1

Liveblog from ONUG Day 2 (John Herbert)

Now, about the “cancer” comment in the title of this post: I had gone all the way over to the other side of the world (Paris, not horrible) in March to the MPLS/SDN/NFV World Congress, having heard good things about it from past attendees. I heard from the same people (vendors) I’ve heard from many times at conferences in the US. I already know my colleagues’ and competitors’ schticks. I don’t need to hear it again. ONUG turned out to be much the same. I said this to an analyst friend at Gartner Data Center a couple of years ago. I’m dreading ONS at this point. I get that events are revenue opportunities (and for Mr. Lippis of ONUG, a primary one), and also that when vendors pony up large chunks of money to help cover the costs of the events, the marketing departments expect something (visibility, since the value of leads is honestly very negligible) in return. But–YUCK. I know I’m not the only one who’s tired of hearing the same thing at every event. There have to be other, better ways to do this.

Update: Some ideas to get the ball rolling here.

Response: Open Networking: The Whale That Swallowed SDN

Art Fewell, whose views I greatly respect, has written a very good post on Network World entitled “Open Networking: The Whale That Swallowed SDN“. It’s a great historical summary of SDN 2011-present, with some noteworthy areas of concern. I agree with the general thrust of Art’s thesis, yet at many points I found myself thinking “Yeah, but…” I started to write a few comments on the Network World page, but the comments turned into a page, so here we are.

Here’s what I really liked in Art’s piece: Continue reading

Thoughts on SDN Consumability

I’ve been using the phrase “SDN consumability” here and there of late, assuming that there was nothing particularly revolutionary in the idea. The response, however, is typically a cocked head, an interested look, and a question: “What do you mean by that?”

So here’s what I mean by that:

In order for SDN to see mainstream adoption, SDN solutions need to be/have

  • Simple to operate – easy to deploy, low-to-moderate learning curve
  • Safe and reliable – tech is stable, nothing blows up, no one gets fired
  • No blue-sky requirements, limited DIY – tech and process migration support available

Continue reading

The Legend of SDN: One Controller to Rule Them All

I originally posted this just over a year ago (Feb 5, 2013) on my corporate blog. I’m reposting here now because the subject of “master controllers” and federation is coming up again more insistently as users begin to think through how to implement a controller-based architecture. I expect to be writing more on this soon.

As we enter the second(ish) Year of SDN, we’ve gone from irrational exuberance to some semblance of reality, with some first-generation products starting to come to market now. That will inevitably drive more reality, on the user side, but an embrace of reality may take a bit longer on the vendor side. I say that because there are still plenty of “whoever wins the controller wars wins all” notions being promulgated in various forums. Continue reading

Notes from ONS 2014 Day 0: SDN Market Opportunities Tutorial

Yes, I’m crazy enough to get up early on a Sunday to go to an SDN conference. I won’t say that there was a lot of “new news” in this session yesterday, but it certainly validated a number of hypotheses. I wound up taking many pages of notes even so, and I’ll summarize the main themes and highlights here.

Open Source and Standards Bodies

While it shouldn’t be a surprise at the Open Networking Summit to hear attendees and speakers beat the open source drum, it was interesting how completely dismissive of traditional vendor implementations most of the speakers were. Prodip Sen of Verizon, also Chair of the ETSI NFV group, commented matter-of-factly,

“Open source is the new standards body. Equipment manufacturers need to build openness, interoperability and modularity into their products. We’re not interested in vertically integrated stacks—that day is gone.”

I could caveat that by noting that even the “enterprise” speakers (from Ebay/Paypal) were rather Web 2.0-flavored and so not completely representative of the broad mass of non-tech enterprises and their needs, but the general direction is pretty unmistakable.

Continue reading

SDN Needs a Charles De Gaulle

There were a pair of stories in the trades last week in which VMware finally took off the gloves and effectively proclaimed themselves the antithesis of Cisco in their approach to—well, not SDN, since both companies say they have gone beyond it. But to the next generation of networking, in any case.

(That’s rather a mouthful, though, so for the rest of this post I’ll refer to their efforts as SDN just as the rest of the industry does; please forgive the shorthand. I’ll get back to the other current discussion about whether SDN 1.0 is dead in another post.)

Any good journalist knows that a good controversy attracts eyeballs, and the best controversy has two—and only two—diametrically opposed antagonists. More than two would complicate the storyline. So we got stories that suggested not only that VMware is now officially at odds with Cisco, but also that SDN architectural options are themselves both binary and comprehensively represented by Cisco and VMware.

Continue reading