Welcome!

@DXWorldExpo Authors: Zakia Bouachraoui, Yeshim Deniz, Liz McMillan, Elizabeth White, Pat Romanski

Related Topics: @DevOpsSummit, Java IoT, Linux Containers, @CloudExpo, @DXWorldExpo, SDN Journal

@DevOpsSummit: Article

Chicken or Egg: Abstraction and Automation

But will abstraction necessarily lead to automation?

For many SDN and DevOps enthusiasts, the natural outcome of this wave of technological change is a highly-automated network that is well-orchestrated with surrounding systems and applications. One of the prevailing thoughts is that this level of automation is a well-formed abstraction layer. With the abstractions in place, the army of network engineers will be unencumbered by device configuration, and automation will ensure.

Or will it?

First off, let me say that abstraction is absolutely necessary. There is no doubt that networking will only advance if we can both remove unnecessary elements and simplify those that remain. We have to accomplish this in a way that is vendor (and ideally technology) agnostic. Abstraction is clearly the path forward.

But will abstraction necessarily lead to automation?
For the vast majority of network engineers who are designing and actively managing networks today, automation means writing shell or Perl scripts. The scripts themselves qualify as automation insofar as they remove keystrokes, but they basically execute the same serial logic that has dominated networking devices for decades.

When you want to make a switch or a router do something, you specify some configuration. Then you specify some other configuration. And again and again until you get through the litany of parameters that collectively make the device work. This workflow is so ingrained in our collective psyche that we inherently serialize the tasks required to make the network work.

There have actually been companies that have done a decent job of breaking the habit of serialized configuration. Juniper’s flagship operating system Junos moved to a more code-like representation of configuration, making no assumptions about the ordering of specific tasks. But our training runs deep, and even the Juniper guys will tell you that the biggest barrier to entry is familiarity with the UI.

We are addicted to our serialized behavior.
One of the side effects of highly-serialized configuration is that we tend to think extremely linearly and transactionally. There are a lot of network engineers for whom any kind of object-oriented approach is almost too foreign to really embrace. So when they try to automate tasks, they fall back into a sequencing of steps, repeated as many times as necessary. Automation without reuse is painfully difficult to propagate beyond only the most repetitive tasks.

And so we end up in a scenario where automation is basically synonymous with scripting, and where the value is largely applied only to the most frequently-executed tasks.

Where could automation take us?
If we think through where automation could take us, we ideally aim a little higher. Automation could mean the automated exchange of data between collaborative systems in support of some task. For instance, you might want your servers to communicate to your network so that when a new application is spun up (or a VM moves), you get corresponding policy changes, firewall or load balancer changes, and potentially network capacity allocation.

For most network engineers, the idea that infrastructure communicates and dynamically provides a service is science fiction. Our serialized mode of operation simply doesn’t support this kind of multilateral communication. Even if the abstractions remove some of the configuration complexity, the mental block is around sequencing.

If the current networking model has taught us anything, it should be that our network engineers are quite capable of managing tons of inputs and outputs. Now, whether that ought to be a requirement for the job is another question entirely. But as a group, network engineers are certainly capable of handling a lot of variables. That abstraction reduces these variables to the most meaningful is very interesting, but it wouldn’t seem that input management is the biggest bottleneck to automation.

The barrier to automation

Rather, the biggest barrier to automation is that workflow is so structured. First, it was the devices themselves that forced the structure. Then it was the processes (ITIL anyone?) that forced it. The end result is that we have built a discipline so dependent on structure that it actually impedes our own progress.

If we want to get to automation, we need to find a way to work around—or perhaps work within—this structure.

What we are really talking about is changing how we think about provisioning and managing a network. Why do you think there is so much angst when people talk about network engineers needing to learn to code? It’s because moving from a serialized set of steps to an object-oriented way of thinking about the problem is extremely difficult.

People aren’t pushing back because learning a new language is hard. Or at least they shouldn’t be. Look at any networking device configuration and tell me that you aren’t already a master coder. The biggest difference is that you you are using an interpreted language called Cisco CLI (or Junos CLI or whatever CLI).

What next?
What we need to do is bite off small (dare I say tiny) workflow elements, automate those, and then string them together into larger workflows. This implies a couple of things. First, we need to think less about discrete capabilities and more about how they exist within some broader workflow context. Second, we need to understand how these building blocks fit together. It’s the connecting of individual workflows that forms the basis for automation, and those connections highlight the pieces of information that flow across workflow boundaries.

More bluntly, the data that stitches together workflows ends up being the stuff that needs to be in an abstraction. It very well could be that getting the automation parts right will help us get to better abstractions.

Obviously we have to work the process from both ends – abstraction down, and workflow up. I don’t think it’s as simple as one or the other, which is why abstraction and automation might be a networking incarnation of the age-old chicken-and-egg question.

[Today’s fun fact: A parrot’s vocabulary is generally no more than twenty words. Who knew parrot’s and politicians had so much in common?]

The post Chicken or egg: Abstraction and automation appeared first on Plexxi.

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."

DXWorldEXPO Digital Transformation Stories
The deluge of IoT sensor data collected from connected devices and the powerful AI required to make that data actionable are giving rise to a hybrid ecosystem in which cloud, on-prem and edge processes become interweaved. Attendees will learn how emerging composable infrastructure solutions deliver the adaptive architecture needed to manage this new data reality. Machine learning algorithms can better anticipate data storms and automate resources to support surges, including fully scalable GPU-c...
Machine learning has taken residence at our cities' cores and now we can finally have "smart cities." Cities are a collection of buildings made to provide the structure and safety necessary for people to function, create and survive. Buildings are a pool of ever-changing performance data from large automated systems such as heating and cooling to the people that live and work within them. Through machine learning, buildings can optimize performance, reduce costs, and improve occupant comfort by ...
As Cybric's Chief Technology Officer, Mike D. Kail is responsible for the strategic vision and technical direction of the platform. Prior to founding Cybric, Mike was Yahoo's CIO and SVP of Infrastructure, where he led the IT and Data Center functions for the company. He has more than 24 years of IT Operations experience with a focus on highly-scalable architectures.
The explosion of new web/cloud/IoT-based applications and the data they generate are transforming our world right before our eyes. In this rush to adopt these new technologies, organizations are often ignoring fundamental questions concerning who owns the data and failing to ask for permission to conduct invasive surveillance of their customers. Organizations that are not transparent about how their systems gather data telemetry without offering shared data ownership risk product rejection, regu...
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 m...
Enterprises are striving to become digital businesses for differentiated innovation and customer-centricity. Traditionally, they focused on digitizing processes and paper workflow. To be a disruptor and compete against new players, they need to gain insight into business data and innovate at scale. Cloud and cognitive technologies can help them leverage hidden data in SAP/ERP systems to fuel their businesses to accelerate digital transformation success.
Poor data quality and analytics drive down business value. In fact, Gartner estimated that the average financial impact of poor data quality on organizations is $9.7 million per year. But bad data is much more than a cost center. By eroding trust in information, analytics and the business decisions based on these, it is a serious impediment to digital transformation.
Digital Transformation: Preparing Cloud & IoT Security for the Age of Artificial Intelligence. As automation and artificial intelligence (AI) power solution development and delivery, many businesses need to build backend cloud capabilities. Well-poised organizations, marketing smart devices with AI and BlockChain capabilities prepare to refine compliance and regulatory capabilities in 2018. Volumes of health, financial, technical and privacy data, along with tightening compliance requirements by...
Predicting the future has never been more challenging - not because of the lack of data but because of the flood of ungoverned and risk laden information. Microsoft states that 2.5 exabytes of data are created every day. Expectations and reliance on data are being pushed to the limits, as demands around hybrid options continue to grow.
Digital Transformation and Disruption, Amazon Style - What You Can Learn. Chris Kocher is a co-founder of Grey Heron, a management and strategic marketing consulting firm. He has 25+ years in both strategic and hands-on operating experience helping executives and investors build revenues and shareholder value. He has consulted with over 130 companies on innovating with new business models, product strategies and monetization. Chris has held management positions at HP and Symantec in addition to ...