Question 1: It’s my understanding that both Cisco and Brocade’s TRILL implementations are still proprietary. Cisco supports Fabricpath with its NX products (except for the nx4000, I believe) and Brocade doesn’t use IS-IS as the routing protocol in their TRILL implementation.  Is that still the case?

Actually, Brocade and Cisco had no choice but to implement a “pre-standard” TRILL variant. Brocade is compliant in the dataplane but not the control plane; Cisco is compliant in the control plane but not in the dataplane. For the record, Brocade and Cisco have both said they will offer a compatibility mode or feature set to enable FabricPath and VCS to interoperate with openTRILL.

Possibly as soon as this July a TRILL plug fest will be held at UOL; if that happens, we should all start to get a good sense of what we need to get everyone playing well together.

Question 2: It’s my understanding that there isn’t a fully standards-compliant TRILL implementation in the market yet.  The newest Broadcom chipset does support it, but there’s no one that I’m aware of that’s actually implemented this in software yet. Is this true?

IBM/Blade Networks’ RackSwitch G8264 already offers support for the TRILL Standard, and Dell, Extreme, Huawei and HP have all said they will release openTRILL-based switches in 2012.

Question 3: As well, in your list of currently supported, Broadcom, Marvel, and Fulcrum are all ASIC manufacturers. So this list is a little misleading as it gives the impression that there are a lot of vendors who support TRILL which is currently not the case from my understanding.

The number one complaint SPB folks give for their dislike of TRILL is the need for hardware support. The need for new ASICs was stated as a weakness in TRILL. As a result the IETF TRILL WG has taken care to keep track of what merchant silicon vendors offer TRILL support as we know that is the first (and required) step before support is available to produce a productized openTRILL RBridge. This does tend to create some confusion as for example the Juniper 3500 has a chip that supports TRILL, but I think Juniper would sooner bring back ATM than implement TRILL. However since these merchant silicon vendors must support TRILL before any vendors (who rely on merchant silicon) can offer support it’s important to document the progress.

It may be better represented as follows:

Question 4: Broadcom sells to everyone, so by that logic, everyone with a Broadcom ASIC has the potential to argue that they should be in the top left quadrant, right?

I would argue again that having for example a Broadcom chip that supports TRILL and then knowing that a company’s actual product does or does not support TRILL speaks volumes as to their support. Since the HW takes the most time, if they have a chip that supports it, but have chosen not to do the software side and offer full support, this may illustrate intent more than a company that doesn’t even yet have a chip that supports TRILL while also not having software support.

Question 5: If your methods for evaluating vendors on TRILL support are:

a) Is it full standards-based TRILL using IS-IS as the routing protocol?  Both Cisco and Brocade fail on this (as far as I’m aware).

b) Is it fully supported in software as well as hardware? HP has a TRILL-future switch, the 5900, but that doesn’t mean we can claim TRILL support on that platform today. It’s important that customers understand that the hardware does support it, and that we will be turning it on in the near future, but today, it doesn’t support it.

Is that accurate?

FabricPath uses IS-IS for IP traffic, and FSPF for FCoE traffic. Brocade uses FSPF for both.

FSPF has a benefit over IS-IS—it prevents out-of-order delivery, which is needed by FCP, regardless of whether it’s running over FC or DCB.

Within the IETF TRILL WG, many of us are excited to see people using TRILL. Yes, the Cisco implementation may be seen as TRILL-like, or TRILL-ish, but the FabricPath implementation does represent the largest global deployment of TRILL. Between Brocade and Cisco, there are now more than 1,000 sites running a TRILL-based product in production. This clearly indicates that many more people are becoming familiar with RBridges and other TRILL concepts, while also getting comfortable with Ethernet Fabrics and what they have to offer.

Of course, we would all prefer to see everyone be running ‘pure’ TRILL, but let’s remember that both VCS and FabricPath came out long before TRILL had a single RFC. That’s why there should be some leeway given to the two companies that did the most in getting TRILL mainstream recognition. At the same time,  we should expect both companies to adhere to their publicly stated schedules for full openTRILL support and/or interoperability.

However, we should also keep in mind that IS-IS is totally transparent to the TRILL user. There is not one configurable aspect to IS-IS in TRILL, and that’s by design. Since FSPF is based on IS-IS, if you had a version of VCS running IS-IS and a version running FSPF, you would not be able to tell the difference. Add to this the fact that FCoE uses FSPF, and anyone running FCoE on their RBridge must support and run both IS-IS and FSPF if they want to be fully compliant with both FCoE and TRILL. As you can see, there’s the potential here for some confusion among new users.

Again, we’re still very early in the process. TRILL only got its first RFC’s in July of last year, and SPB is not even standardized yet. This is a 10-year project, not an 18-month, single-product release. We’re trying to build a protocol that will, over the next decade, wipe STP from the face of the planet. This kind of evolution takes time—and it’s exciting to see that HP will soon be helping with the change.

This is part two of a series that highlights common questions in Brocade’s “Fabrics 101: Essentials of Ethernet Fabrics” workshops.

In Brocade’s recent Ethernet Fabric 101 workshops in San Diego and Austin, participants’ chatter around standards TRILL (Transparent Interconnection of Lots of Links) and SPB (Shortest Path Bridging) lead us to answer some crucial questions in our latest installment of the Ethernet Fabric 101 Q&A Series. We’ve recapped the discussion and provided answers to their questions that you may be asking yourselves as well.

Question 1: Will TRILL become the standard over SPB?

TRILL is already a standard; SPB will become one as well, some day. They will eventually both be available as IS-IS (Intermediate System To Intermediate System) and OSPF (Open Shortest Path First) are already today.  However TRILL is much further along because it’s a standard with the support of many established companies.  The current vendor landscape is detailed below:

Question 2: Are there any issues when implementing Ethernet Fabrics in a spanning tree environment?

TRILL is designed to interoperate with spanning tree protocol from the beginning.  This is required for the phased removal of STP. For example, if you are deploying Ethernet Fabrics with Brocade VCS Technology in a STP-based architecture, the entire Ethernet Fabric will appear to the rest of the architecture as a simple L2 switch. This capability allows customers to phase in an Ethernet Fabric-based architecture at their own pace and completely eliminates the need for fork-lift upgrades.

Question 3: Could you run spanning tree on either end with TRILL in the middle?

Yes, TRILL is designed to enable this. Now, with that said, each implementation of TRILL may vary a little bit in how the network architects choose to interoperate with STP. As with all things, you should plan carefully and follow best practices for your implementation.

Do you have a question about Ethernet Fabrics you’d like to ask?  Let us know by posting in the comments section below, emailing ethernetfabric@gmail.com or Tweeting @ethernetfabric.

Stay tuned for more insights and answers to your questions in the next installment of this series. For more information about Brocade’s Fabrics 101: Essentials of Ethernet Fabrics workshops, you can visit the registration site here and follow along with #Fabric101 on Twitter.

We got a good hint on the morning of February 3rd when the U.S. Labor Department came out with its newest statistics, and they make for interesting reading.  While government agencies have been cutting jobs, the private sector has been adding them at a remarkable pace. With 243,000 new ones in January alone, up from 203,000 in December, the unemployment rate fell to 8.3%, the lowest since exactly three years ago. Many economists and investors praised the numbers, and the stock market went up accordingly.

But here’s an even more interesting angle: The manufacturing sector, the subject of so much contentious debate, added 50,000 new jobs, while the health and education services can take credit for 36,000 more. But far above them both, with a whopping 70,000 new jobs, was the professional and business sector.

That would be people like us.

We’re seeing this even more in our neck of the woods. First, you may have caught the fact that salaries here in the Silicon Valley recently crossed the six-digit threshold. That’s the first time this region has broken past that very fancy glass ceiling. For the record, tech-job postings in Silicon Valley on Dice Holdings, which released the good news, are up 26% from a year ago (the national equivalent rose 11% over the same period). But looking even more closely, a new report from KGO, a local broadcast outlet,  highlights 12 companies nationwide that need to fill at least 500 positions each, for a total of 38,000 jobs. In other words, with good candidates, these 12 companies alone could account for a good chunk of all the jobs added nationwide in January.

So what are these jobs? While these companies are looking to fill positions across the board, there is a heavy emphasis on engineering and IT positions even at non-technology concerns such as State Farm Insurance. This further illustrates how pervasive information technology is in all parts of our work and lives these days.

Drilling down one level deeper, there’s no question that the real action is going to be on the network. Take YouTube: The Wall Street Journal recently pointed out that the site’s audience actually dwarfs the combined number of consumers watching TV. In fact, there’s been an 80% spike in YouTube television (what’s that?) even if the audience is highly fractured over more than 30,000 channels. To give just a couple of examples, consumers watched 3 billion hours of video each month last year, adding up to more than 1 trillion views.

And then, of course, there’s the 800-lb. gorilla in the room: Facebook, the newest progenitor of young millionaires. ZDNet looked through Facebook’s S-1 and found a number of interesting IT-related disclosures that may indicate that the company may need to hire a lot more staff.

Specifically: Facebook is aware that security could hurt. “Computer malware, viruses, and computer hacking and phishing attacks have become more prevalent in our industry, have occurred on our systems in the past, and may occur on our systems in the future. Because of our prominence, we believe that we are a particularly attractive target for such attacks,” said Facebook. Translation: We have a bull’s eye on us.

Uptime matters—a lot. As the user base and the amount and types of information shared on Facebook continue to grow, we will need an increasing amount of technical infrastructure, including network capacity, and computing power, to continue to satisfy the needs of users everywhere.

Remember how impressive that ‘70,000 professional and business jobs’ number sounded above? Compared to a year from now, it might be minuscule.

Interested in reading more about the IT and networking jobs outlook? Read EthernetFabric.com blogger John Noh’s post on SF Examiner.

What are your thoughts? We’d love to hear your insights. Let us know by tweeting at @EthernetFabric or posting a comment below.

The term “fabric” has become the latest buzzword to hit the networking industry.  The concept is strategically important to any organization serious about maximizing the value of virtualization in their data centers.  Many different vendors offer a data center fabric strategy today.  Most of the network vendors such as Brocade, Cisco, Juniper, Extreme, Alcatel-Lucent, Avaya, Extreme and Enterasys have all rolled out network based fabrics, but one of the more interesting alternatives comes from Xsigo which unveiled its server-based fabric.  Network or server based, its clear the architecture in the data center is changing.  As IT organizations evaluate these varying solutions, it’s important to take a step back and determine why it would make sense for a company to deploy data center fabrics.  I’ve provided eight compelling reasons to make that decision.

Performance problems with the current network. Clearly, if the network or server interconnects are highly saturated and have become the bottleneck in the data center, then it’s time to upgrade.   Changing the architecture to a fabric approach at this time will future proof your data center.

Virtualization mobility.  Some view Virtual machine(VM) mobility as the primary driver for fabric deployments.  If you’re not doing any VM migrations, or you migrate VMs only within a rack, there may not be a reason right now to move to a fabric.  However, if the VMs are moving between racks, then a fabric makes the most sense since it’s optimized for east-west traffic.

Power, space and cooling are in short supply. Fixing the network may not immediately occur to you as the next big opportunity for increasing server efficiency, but it is. A fabric can relieve the east-west traffic bottlenecks, which then lets you increase VM density and hence server efficiency. If your aim is to further reduce your server count, a fabric can help.

Storage convergence.  Converging storage and data networks creates new traffic flows within the data center.  A legacy network is not optimized for the increased volume of traffic and new traffic flows.  Enabling storage convergence should be done in conjunction with a fabric deployment.

A network upgrade is underway.  This could be upgrading to 10, 40 or possibly 100 Gigabit Ethernet, 8 Gigabit Fibre Channel or 10 Gigabit Fibre Channel over Ethernet (FCoE).  If you’re spending the money to upgrade the network, then you can maximize the efficiency of the network by shifting to a fabric.  The fabric could also lower the overall cost of the deployment as the infrastructure is used more efficiently.

A new data center or data center consolidation.  Any new data center that is currently being deployed or consolidated should leverage a fabric architecture.  Deploying a legacy network will most likely limit the useful life of the new gear.  Any new data center will have new servers, storage devices and should have a new network as well.

Over 50% of your tier 1 applications are now virtualized.  Virtualization has definitely evolved from being a technology used for non-mission critical applications to one used to virtualize even the most important tier 1 applications.  If over 50% of your tier 1 applications are now virtualized, network reliability is of the utmost importance.  A fabric will provide greater reliability and performance, making it a better platform for your most critical application.

Operational issues are hampering your ability to support the current environment.  Legacy environments are complex and hard to support.  A fabric will be operationally simpler; that’s a fundamental premise of fabric design.  If supporting the current environment is becoming too burdensome then it may be time to shift to a fabric.

When considering a fabric, don’t just upgrade for the coolness factor (although that’s sometimes a good reason). The above criteria are real problems that can be solved by deploying fabric technologies. Use it as a checklist; if you’re facing one or more of the above, you should be seriously considering a fabric today.  Then you can begin to drill down into the primary architectural options to fully understand the differences.

Have a question about data center fabrics? Contact me on Twitter @zkerravala, reach out to blog via @EthernetFabric or leave a note in the comments section below.

Today, I got a note from a friend of mine, AJ. AJ spends a lot of his time talking with customers all over the world. He has a great vantage point from which to gauge the interest in emerging technologies by customers and their level of deployment. He brought up an interesting observation about converged networks.

Here’s AJ’s note.

Brook,

I was thinking about this morning’s executive briefing with one of our larger customers and figured you would appreciate my train of thought. Of course we talked about technology adoption trends and as we were chatting, I was reminded of another major IT trend not so long ago, datacenter consolidation.

As you know, this was a hot topic for many customers presenting some real challenges for IT architects and operations folks. As you will recall, a few years ago the folks at HP collapsed 84 large regional datacenters into 6 large scale production environments. Those environments are some of the most scalable, hardened operations that I have ever seen; including things like more than 250,000 ports of our SAN Fabric. When HP had those datacenters on line, they made them the showcase to hundreds of key customers along with a basic message, something along the lines of-

“Come and see how HP re-engineered its own IT organizations and see the benefits of what we can re-engineer for you!”

All in all a VERY compelling story.

But here we are at the beginning of 2012, and depending upon your calendar, we are 3-4 years into the Converged Network “revolution”. And I hear from many customers words to the effect:

“Such and such networking company, OEM or storage company says that Converged Networking (specifically FCoE) is standardized, certified for prime time, infinitely scalable, production ready and the cost savings are so amazing that as soon as you deploy it money will be falling from the equipment racks to be swept from the floor.”

Now, I can’t help wondering why we haven’t seen one or more of the networking, storage or server companies complete the reengineering of their own datacenters with converged networks. If they had done that, wouldn’t they heavily market their success using their own datacenters as a showcase? Wouldn’t that be a compelling proof point of being “ready for production”? I’d expect we would hear something like:

“Come and see how we converged our datacenter networks and re-engineered our environments to simplify deployment, ease management, massively scale, provide the base of the private cloud and cut our capital and operational expenses by half. We did it for our datacenters and we can do it for yours.”

Perhaps it’s just that I don’t get invited to such events. But I’m interested in what people have seen. Has anybody seen a completely re-architected, scalable, mission critical production environment showcased by any of these companies as proof that converged networks using FCoE are “the way to go”?

Personally, I suspect that this will be more like the early years of server virtualization where the virtualization platforms actually offered a service where they would audit the application base and tell you what applications you could safely stack for virtualization. But it just seems like this time much of the industry is asking the customer to figure out where the sharp edges and corners are on the new technology; perhaps losing some of their own blood on the datacenter floor in the process.

I don’t think it’s too cynical to believe that if even half of the market hype were true, we would have seen at least one converged networking datacenter being a showcase from one of the major players by now. Does anybody have any “confirmed sightings” like this?

Ciao,

aj

After I got AJ’s note, I saw a summary of internet posts of interest by Greg Ferro with a link to this post by Steve Foskett, Eight Unresolved Questions About FCoE – @SFoskett – Stephen Foskett, Pack Rat. Steve identifies a number of restrictions that maybe the reason AJ isn’t seeing as strong an endorsement of FCoE as one would expect of a mature technology.

So, to borrow a 1980’s marketing campaign slogan from a well know fast food company, “Where’s the beef?”

One category of futuristic-über-champion-from-another-planet envisions OpenFlow/SDN as fully displacing all network-based intelligence. By that perspective, OpenFlow competes with every existing network-based protocol. Sure, and maybe someday I might get you to buy an entirely different kind of bridge from me.

The notion that there might be some competition arises in part because OpenFlow has such large (and fuzzy) scope.  How large depends on whom you ask.  I see OpenFlow as a key enabler to solve many, but not all, interesting problems, and as such I’m something of a fan.  Quite a few champions see OpenFlow as ideal for solving every current networking pain point.  Spanning Tree is a pain point, thus OpenFlow (some claim) is the answer, even though (in contrast to tried-and-true TRILL-based fabrics) no one has deployed a compelling demonstration of such a solution.

Such speculations can be entertaining, but here on present-day Earth it’s generally more productive to solve problems that haven’t already been solved.  There are quite of few of those around, particularly in hyperscale virtualized data centers with workloads in the millions and tenants nearing six figures.  Ultimate profitability will come from automation, super-high utilization rates for capital equipment and vast tracts of data center per administrator.  Because these attributes are strategic differentiators, the operators can (and must) invest in development to solve the myriad of problems they are tackling daily.  They’re not very interested in proprietary solutions that will lock them into a specific hardware vendor for years; nor are they going to wait patiently for traditional plodding standards bodies to address (piecemeal) each problem with a distributed network-based solution, wondering all the while whether the resulting disparate solutions play nicely together.

These and other bleeding-edge network operators are willing take a few risks.  They want to work with forward-looking vendors willing to work within a well-tuned, flexible, highly automated and standards-based architecture that will enable the customer to realistically consider competitive bids over time.  Oh yeah, and they need to transition from their current architecture to this new architecture in smooth-and-steady increments with minimal (zero would be nice) disruption, since it’s remarkably tricky to convince a few thousand customers that occasional brief scheduled downtime is acceptable.  Yep, this is the Wild West, alright.  This is part of Earth where OpenFlow is needed, where investment is worthwhile and risk can be justified.

Meanwhile, even among the SDN faithful, there are folks that recognize that some intelligence belongs in switches. Rapid and robust failover handling of multipathing is frequently listed as an example. So why would OpenFlow developers attempt to re-invent Ethernet Fabrics and then leave most of the intelligence in the switch? Mmm.  What’s the value-add there?  Yeah, not great.  Especially since there are lots of exciting unsolved problems to address instead.

So, am I saying that OpenFlow and Ethernet Fabrics have nothing to do with each other, and never the “tine” shall meet?  Hardly. As I just pointed out, OpenFlow is for solving new problems.  Standardized Ethernet Fabrics are already meeting the large-scale, high-bandwidth, topology-independent, equal-cost-multipath, East-West-plus-North-South need.  That need exists in many places on Earth, from large scale enterprise data centers to the hyperscale DC’s described above.  In parallel, key players in the hyperscale architecture game are deploying hypervisor-based encapsulation (under control of pre-standard OpenFlow) to solve several problems.  These encapsulated “overlay networks” still need a rocket-fast, isotropic transport to connect the boxes.  That’s where Ethernet Fabrics come into the picture.  Meanwhile, your run-of-the-mill large enterprise data center can deploy Ethernet Fabrics without the hypervisor-based overlay.

In summary, I meekly submit that there really is no controversy, and the technologies don’t compete (except in the way that markedly different forks compete).  Instead, there are places for each, places for both, and places for neither.  As an illustration, I’ve built the following complex (not-so-much) and exhaustive (even less) table of use cases for each category:

Again, this is based on today’s challenges and efforts.  No doubt OpenFlow vendors will expand the problems that they address. They’ll focus where there’s ROI, which is highest for as-yet-unsolved problems.  So chances are that I’ll have OpenFlow in my home office soon.

EthernetFabric.com blogger Lisa Caywood also contributed to this post.

In light of the President of the United States (POTUS) delivering his SOTU last week, we thought we’d take a few moments to reflect on the state of things in the networking world. Unlike the POTUS, however, it’s hard to deliver a singular view of the state of things as the networking world is highly fractured by different technologies and customer segments. Let’s just say that we tend to operate more on the principles found in the Articles of Confederation than the Constitution. But here it goes, courtesy of Network World’s coverage of Dell’Oro Group’s market update.

The overall outlook for theEthernet switch market is that it will plod along at a pedestrian pace – 4% growth in 2012 – impacted heavily by macro-economic factors such as the Eurozone debt. We guess you can say that IT buyers consider Ethernet switches a discretionary buy for now. Perhaps these buyers would change their thinking if a vendor offered something really interesting and unique for this market? Maybe we will see something like that soon… On the positive side, 10 Gigabit Ethernet top-of-rack (ToR) switches are going gangbusters, as the chart notes, largely in data center deployments.

Moving onto SAN switching, don’t look now but the market is as healthy as ever. And I’m not referring to Dell’Oro’s decision to lump FCoE “revenues” into the SAN switching category, which artificially inflated the revenue numbers. In terms of where we are with the market today, there are some things we can say.

In the service provider realm, you might have caught Juniper’s recent earnings woes. The company has been blaming its woes on the tepidity of the SP router market, which is still a very important business for it. The Carrier Ethernet router and switch markets also are slowing down some, though certainly not as fast the core router. Indeed, the Carrier Ethernet market is expected to still grow by 8% in 2012.

Looking further out, the market for Layer 2-3 Ethernet switches will approach $28 billion in 2016, but again, the bulk of that will be in deployments at larger data centers. Still, that’s a growth rate of 6% from 2010 on. And because of the continuing need for speed in ports, the expectation is that most of that spike will be the fixed 10G category. However, speaking of speed, sales of 100Mbps Fast Ethernet are definitely slowing down. We still see these enterprise backbones and closets everywhere, of course, but maybe not for much longer.

Moving up the ladder, it’s going to be fun ride for 40G Ethernet and 100G Ethernet—look for this segment to jointly pass $3 billion by 2016. And it won’t be going alone: With servers moving from Gigabit Ethernet to 10G Ethernet LAN-on-Motherboard, most large enterprises will turn to SFP+ and 10G Base-T connectivity next year, while the SMB space migrates to 10G the year after that.

It’s a similar story on the Ethernet port side. Gigabit Ethernet ports will surely see a drop—Dell’Oro says from 11.9 million to 10.9 million—and the 100M variety will fall off a cliff in the next few years. At the same time, 10G Ethernet ports will see a virtually unprecedented spike, quadrupling sales from 8.5 million to 62.2 million.  Buyers have a reason to smile at this, too: the prediction is that the average selling price of a 10G Ethernet port will drop from $715 to $212.

So the state of the Ethernet market is, well, strong, if not exactly robust. There’s definitely growth here, and buyers are scaling just as much, if not more, while looking to spend less.

One thing’s for sure: Without changing, without dramatic enhancement, without innovation, there’s no way to make a mark. But with all that. . .

Stay tuned.

This is part one of a series that highlights common questions in Brocade’s “Fabrics 101: Essentials of Ethernet Fabrics” workshops.

In Brocade’s recent Ethernet Fabric 101 workshops, the dialogue has centered around some crucial questions about fabric technology. There is a lot of confusion and misinformation in the industry to some basic questions, and a handful of more technical questions. EthernetFabric.com bloggers Chip Copper and Jon Hudson provided answers to some common questions in the hopes that they may also address some thoughts you may have yourselves.

Question 1: What is the real advantage of Ethernet Fabrics? Is it just moving all of the complexity from Layer 3 to Layer 2?

Chip Copper: Only if we do it the same way we’ve done it before!  Decades have passed since the original designs of Layer 3, and unfortunately, some Ethernet/IP professionals were slow to change their way of thinking.  Ethernet Fabrics move more of the intelligence into the network rather than depending on constant supervision by administrators.  For over a decade, the advantages of modern fabrics can be seen in Storage Area Networks (SANs), where the baggage of the old way has been removed.  We now have the chance to do the same thing with Ethernet/IP.

Jon Hudson:

1.)    No more STP. Ever. Dead. Gone. There’s a 10 year plan for the world wide eradication of STP.

2.)    Active/Active paths. Passive 1G links are fine, passive 10G, 40G, 100G, 400G links are NOT fine. Imagine if while sitting in stopped traffic you found out there was another totally open 8 lane freeway with no one on it that is being reserved for emergencies? Well, that’s STP.

3.)    Intelligent Networks. Automated actions, distributed control plane, sync’d MAC tables, distributed port profiles.

Question 2: New technology is driving the industry to change and to adopt new technologies. How do you prepare for potential unforeseen costs?

Chip: By doing the research and completing the calculation to show how much will be saved by this transformation.

Jon: If the question is with all the automation how do you handle the excess load since the switches have to think harder, then it’s easy. Get custom, high end, kick ass ASICs. Not the one solution for all chips that so many vendors use today, but 6^th and 7^th generation ASICs that we can design to have all the horsepower they need to be as smart and nimble as a dynamic datacenter needs to be.

Question 3: How will the role of the IT department change with the rise of employees bringing their own devices to work or departments being able to set up their own applications?

Chip:  This transformation is not that different than the one which allows users to utilize cloud services rather than depending on the whims of the data center management.  The IT department must become the coordinator of change and of adopting the use of technologies, not in their deployment.  Change is uncomfortable, but the users demand it, and so the IT departments must concentrate on how to satisfy the users rather than just doing what is easiest for them.  Is mandating the exclusive use of one device simpler? Absolutely!  Does that approach stifle productivity, limit users, reduce the choice of applications and cause frustration?   Yes, it does that too.

Jon: How did PGE and AT&T scale to their size? By changing the expectations of support and ending their service at the box OUTSIDE of your house. Inside you house, you get to use whatever you want, but it’s your problem if it doesn’t work. This is where IT is headed. BYOD is a great idea, IF the users agree that the expectations of “hold your hand, do everything” IT no longer applies. So you end up with two offerings.

1.)    BYOD: We support you up to the connection to your device.

2.)    Current: We supply the device we think you should have and support it 100%.

Your choice.

Do you have a question about Ethernet Fabrics you’d like to ask?  Let us know by posting in the comments section below, emailing ethernetfabric@gmail.com or Tweeting @ethernetfabric.

Stay tuned for more insights and answers to your questions in the next installment of this series. For more information about Brocade’s Fabrics 101: Essentials of Ethernet Fabrics workshops, you can visit the registration site here and follow along with #Fabric101 on Twitter.

“I found the ‘wrong organizational structure’ and ‘insufficient executive support’ as two sides of the same coin: about a third of practitioners don’t feel their company is organized for success. Of course, that probably has something to do with both the ‘lack of resources’ and ‘lack of broad-based skills’ observations”

“While many traditional BI analysts are simply functionaries in a larger information-gathering-and-analysis supply chain, the precise opposite seems to be true with data science professionals.

As you can see here, they’re involved from everything from sourcing new data sets (usually from outside the company!) to telling data-driven stories to business stakeholders with the intent of positive change.”

“In many situations, data scientists find themselves working across the entire organization (in addition to other data scientists, of course).

Look at some of the roles they say they work with frequently: graphic designers, HR professionals, marketing, sales, etc. — clearly not just technological professions.”

“The overwhelming number of data science respondents prefer to work in ostensibly smaller settings. Think focused teams, collegial work environment, easy to navigate the organization, and so on.”

“The structure, isolation and inflexibility of most corporate environments appears to be something they’re not warmly embracing.”

This suggests an interaction between the supporting IT infrastructure data scientists depend on and the organization of “data ownership” within the business. IT infrastructure reflects data ownership models. For example, most IT development is defined by business groups who fund projects to build the infrastructure supporting an application important to them. In biological terms, this is a single cell model of data ownership that reflects a similar single cell model for organizing the business functions. Although there are many functions in a business, different functions remain isolated from each other and in many instances expend considerable energy defending their perimeter similar to how single celled organisms behave.

Evolution moved on from single cell organisms to multi-cellular and in time we end up with cells that can network together forming the brain. I have been reading about the brain and its plasticity in a book by Norman Doidge, “The Brain That Changes Itself.” The striking thing about this research is the discovery of ability of the brain to reinforce connections that are in use and interconnect more neurons to improve processing for tasks that are in demand. The brain creates a highly interconnected topology of neurons across large areas. In short, the brain’s network acts like a fabric.

Back to Big Data, IT infrastructure and business organization. If most applications and their data act like self-contained single cell organisms, then Big Data is the new multi-cellular organism. To work efficiently, it requires brain-like connective tissue, neurons, that can dynamically and quickly connect together as needed to process more information. Big Data needs a network that provides a high level of interconnectivity between individual nodes containing data resources. Further, as more access occurs between nodes, network connectivity should increase with minimal effort. Ethernet fabrics inherently provide this type of network flexibility, scalability and policy mobility as workloads migrate. They will be important as Big Data becomes more common.

As Chuck points out, the multi-cellular organism that is Big Data alters the business structure itself. Instead of single celled owners of data (aka, departments) with a defensive perimeter to protect “their” data, a highly connected multi-cellular structure, like the brain, has superior abilities to respond to environmental change. It will dominate for this reason and cause organizational changes. Rigid hierarchy will give way to “on-demand” structures where skills in needed for a particular project can easily connect together to do work. Imagine using “Craig’s List” to advertise a Big Data project and have interested people sign up to work on it. And when the work is done, resources (people with brains) disconnect from one project to connect to a new one. The need for a dynamic network now extends to the campus/LAN not just the data center. The campus network has to enable collaboration, real time desktop-to-desktop video streams, phone conversations and chat. I think Unified Communications promises to provide this and once again, the connective tissue of the network begins to look like a fabric.

It may be that Big Data is the driver for not only new networking constructs but also new business structures. With a fabric for the connective tissue, businesses can operate with the same efficient plasticity as the human brain.