Welcome!

SDN Journal Authors: Liz McMillan, Yeshim Deniz, Elizabeth White, Pat Romanski, TJ Randall

Related Topics: SDN Journal, Containers Expo Blog, @CloudExpo

SDN Journal: Blog Feed Post

Abstracting vs Ignoring

The primary goal of abstraction is to break something down into its most essential elements

There’s a running meme in networking that has caught a lot of momentum with SDN: abstraction. Just about every vendor these days has bold ambitions to abstract out the complexity. There are APIs, abstraction layers, and architectural shims that all aim to hide complexity from the user. But what does that really mean?

The primary goal of abstraction is to break something down into its most essential elements. You then expose only those parts that require end-user participation (think: configuration knobs, for example). Ideally, a small set of relatively well-understood parameters can then move the mass of hulking machinery underneath. The complexity? It is hidden, cleverly abstracted away from the user.

This leads to an interesting question: which bits need to be exposed to the end user?

The question seems innocuous enough. But the answer depends an awful lot on your context.

Networking has long been a management-through-precision proposition. That is to say that network behavior is determined by correctly setting a bunch of configuration knobs. The problem is at its absolute most horrible when specifying edge policy. So acute is our collective need for control that we have developed entire businesses around merely demonstrating proficiency in the knobs themselves.

The subtle point about abstraction is that by reducing networking to only the most critical characteristics, you are actually taking away some of the power from a user base that has defined their careers by their knowledge of said details. On the other extreme, you have an entire class of companies for whom the network is just not that interesting. At the limit, these companies simply want the network to work. That this currently requires an army of specialists with total command over thousands of widgets is more necessary evil than desired outcome.

So what do we do?

In some ways, we need to fight our own instincts. Our need for absolute control is our own doing. We have taken a largely incremental approach to networking for more than a couple of decades now. We have layered functionality on top of functionality, using configuration to incrementally enable each piece. The thought of things working across the whole of the network is a scary proposition, so we have grown accustomed to piecemeal deployments. And change has become so difficult that you don’t dare do anything unless you absolutely have to.

But despite all of this, where are we headed now?

We want to code our way out of the problem. We want to add another complex system on top of an already complex—and crumbling—system. Consider that SDN is largely an organic reaction to the failure of vendors to make networks that are manageable. Building another management layer on top of the existing failed infrastructure might hide the complexity, but it doesn’t remove the source of the underlying infrastructure rot. Without cutting away that rot, we are really just punting the problem into the future.

None of this is meant to suggest that APIs and programmability are not important. For a certain class of user, they are extremely powerful. But not every user has or event wants the kind of sophistication that goes with this type of approach. And fewer still have a solid enough foundation from which to build.

How do I know? We celebrate programmability while swapping stories of companies relying on screen scraping. How is that latter class of networking professionals going to make the leap?

The answer is actually simple: they won’t.

This creates an interesting market dynamic. The number of companies who are actively pushing the envelope is relatively small. Sure, there are lots of people who are constantly evaluating new technologies, but if you measure actual deployments, the business tilts heavily to the less sexy, less risky networks of yesteryear. For every SDN trial that nets a couple of devices in some deal and generates a snazzy press release, there is a pile of uncontested deals that get closed with the incumbent vendors.

Why? Because things barely work the way they are, and adding more capability on top of existing stuff isn’t actually the need for most people.

There is an enormous opportunity for companies that provide a solution to the underlying infrastructure rot. The billions of dollars spent on networks that users wish they could just ignore are mostly in play. The vendors pursuing those dollars need to make sure they keep their eye on the ball. The shiny object that is abstraction and programmability will undoubtedly be important, but pursuing that at the expense of fixing the underlying network is chasing an opportunity that might very well forever be just on the horizon. Over time, the obvious end game here is that both things needs to happen. Abstraction and underlying correction are both required.

While it might be the CTOs and CIOs at the largest enterprises and carriers that drive overarching requirements, the middle and lower tiers of the market consume an awful lot. Interestingly enough, that business is somehow lost in all the noise. To make a difference here, networking doesn’t need to be more abstract; it just needs to be a whole lot more instinctive.

[Today’s fun fact: 100% of all lottery winners gain weight. Seriously, how does anyone know this is a fact?]

The post Abstracting vs Ignoring appeared first on Plexxi.

Read the original blog entry...

More Stories By Michael Bushong

The best marketing efforts leverage deep technology understanding with a highly-approachable means of communicating. Plexxi's Vice President of Marketing Michael Bushong has acquired these skills having spent 12 years at Juniper Networks where he led product management, product strategy and product marketing organizations for Juniper's flagship operating system, Junos. Michael spent the last several years at Juniper leading their SDN efforts across both service provider and enterprise markets. Prior to Juniper, Michael spent time at database supplier Sybase, and ASIC design tool companies Synopsis and Magma Design Automation. Michael's undergraduate work at the University of California Berkeley in advanced fluid mechanics and heat transfer lend new meaning to the marketing phrase "This isn't rocket science."

CloudEXPO Stories
Sanjeev Sharma Joins November 11-13, 2018 @DevOpsSummit at @CloudEXPO New York Faculty. Sanjeev Sharma is an internationally known DevOps and Cloud Transformation thought leader, technology executive, and author. Sanjeev's industry experience includes tenures as CTO, Technical Sales leader, and Cloud Architect leader. As an IBM Distinguished Engineer, Sanjeev is recognized at the highest levels of IBM's core of technical leaders.
René Bostic is the Technical VP of the IBM Cloud Unit in North America. Enjoying her career with IBM during the modern millennial technological era, she is an expert in cloud computing, DevOps and emerging cloud technologies such as Blockchain. Her strengths and core competencies include a proven record of accomplishments in consensus building at all levels to assess, plan, and implement enterprise and cloud computing solutions. René is a member of the Society of Women Engineers (SWE) and a member of the Society of Information Management (SIM) Atlanta Chapter. She received a Business and Economics degree with a minor in Computer Science from St. Andrews Presbyterian University (Laurinburg, North Carolina). She resides in metro-Atlanta (Georgia).
We are in a digital age however when one looks for their dream home, the mortgage process can take as long as 60 days to complete. Not what we expect in a time where processes are known to take place swiftly and seamlessly. Mortgages businesses are facing the heat and are in immediate need of upgrading their operating model to reduce costs, decrease the processing time and enhance the customer experience. Therefore, providers are exploring multiple ways of tapping emerging technologies to solve this industry problem. During this session, Chander Damodaran, Chief Blockchain Architect at Brillio Technologies, will discuss how blockchain could transform the mortgage business and its value chain. Blockchain can bridge the gap and provide a seamless digital channel to enable quicker and transparent mortgage processing thereby elevating the overall experience and helping drive costs down.
This session describes how Professional Services organisations can deliver within Technology-as-a-Service (IaaS) constructs, in private and public enterprise cloud scenarios. See how professional services can be packaged and funded by IaaS cash flows, based upon consumption of technology services. Learn how significant, IT infrastructure transformations can be funded through OPEX spending models with multi-year As-a-Services based contracts. Understand how the automation of repeatable services can positively impact the commercial viability of Professional Services within As-a-Service constructs. Hear how innovative IT infrastructure service offerings can elevate the impact of professional services engagements, and accelerate positive business outcomes.
If a machine can invent, does this mean the end of the patent system as we know it? The patent system, both in the US and Europe, allows companies to protect their inventions and helps foster innovation. However, Artificial Intelligence (AI) could be set to disrupt the patent system as we know it. This talk will examine how AI may change the patent landscape in the years to come. Furthermore, ways in which companies can best protect their AI related inventions will be examined from both a US and European perspective.