Welcome!

DevOps Journal Authors: Yeshim Deniz, Liz McMillan, Pat Romanski, Elizabeth White, Mike Kavis

Related Topics: DevOps Journal, Java, Linux, Cloud Expo, Big Data Journal, SDN Journal

DevOps Journal: Blog Feed Post

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

Latest Stories from DevOps Journal
Qubell, an innovator in application deployment and configuration management, empowers online companies to do what they have never been able to do before: put into consumers' hands innovative new features and services, almost as fast as they can conceive them, without sacrificing control, reliability or uptime. Qubell emerged from stealth in the summer of 2013 (see related press release) and announced that Kohl's completed its initial implementation (see press release). Founded by pioneers in enterprise cloud applications and services, Qubell has its headquarters in Menlo Park, Calif. For more information, visit qubell.com.
BlueBox bridge the chasm between development and infrastructure. Hosting providers are taking standardization and automation too far. For many app developers it does nothing but spawn mayhem and more work. They have to figure out how their creations live on a pre-fab infrastructure solution full of constraints. Operations-as-a-Service is what BlueBox does. BlueBox utilizes development tools such as OpenStack, EMC Razor, Opscode’s Chef and BlueBox's proprietary tools give the power to do the unorthodox things which most hosting providers shun.
DevOps Summit at Cloud Expo Silicon Valley announced today a limited time free "Expo Plus" registration option through September. On site registration price of $1,95 will be set to 'free' for delegates who register during special offer. To take advantage of this opportunity, attendees can use the coupon code, and secure their registration to attend all keynotes, DevOps Summit sessions at Cloud Expo, expo floor, and SYS-CON.tv power panels. Registration page is located at the DevOps Summit site. Your DevOps Summit registration will also allow access to @ThingsExpo sessions and exhibits. Register For DevOps Summit "FREE" (limited time) ▸ Here
SYS-CON Events announced today that Serena Software will exhibit at DevOps Summit Silicon Valley, which will take place on November 4–6, 2014, at the Santa Clara Convention Center in Santa Clara, CA. Serena Software supports DevOps and Continuous Delivery by providing application deployment automation and software release management solutions to replace slow and error-prone manual processes. 2,500 enterprises around the world trust Serena to help them develop and deploy better software.
Founded in 1997, ActiveState is a global leader providing software application development and management solutions. The Company's products include: Stackato, a commercially supported Platform-as-a-Service (PaaS) that harnesses open source technologies such as Cloud Foundry and Docker; dynamic language distributions ActivePerl, ActivePython and ActiveTcl; and developer tools such as the popular Komodo Edit and Komodo IDE. Headquartered in Vancouver, Canada, ActiveState is trusted by customers and partners worldwide, across many industries including telecommunications, aerospace, software, financial services and CPG. ActiveState is proven for the enterprise: More than two million developers and 97% of Fortune 1000 companies use ActiveState's solutions to develop, distribute, and manage their software applications. Global customers like Bank of America, CA, Cisco, HP, Lockheed Martin and Siemens rely on ActiveState for faster development, ensuring IT governance and compliance, and accelerating time-to-market.
The old monolithic style of building enterprise applications just isn't cutting it any more. It results in applications and teams both that are complex, inefficient, and inflexible, with considerable communication overhead and long change cycles. Microservices architectures, while they've been around for a while, are now gaining serious traction with software organizations, and for good reasons: they enable small targeted teams, rapid continuous deployment, independent updates, true polyglot languages and persistence layers, and a host of other benefits. But truly adopting a microservices architecture requires dramatic changes across the entire organization, and a DevOps culture is absolutely essential.
High performing enterprise Software Quality Assurance (SQA) teams validate systems are ready for use – getting most actively involved as components integrate and form complete systems. These teams catch and report on defects, making sure the customer gets the best software possible. SQA teams have leveraged automation and virtualization to execute more thorough testing in less time – bringing Dev and Ops together, ensuring production readiness. Does the emergence of DevOps mean the end of Enterprise SQA? Does the SQA function become redundant?
Achieve continuous delivery of applications by leveraging ElasticBox and Jenkins. In his session at DevOps Summit, Monish Sharma, VP of Customer Success at ElasticBox, will demonstrate how you can achieve the following using ElasticBox and the ElasticBox Jenkins Plugin: Create consistency across dev, staging, and production environments Continuous delivery across multiple clouds to handle high loads Ensure consistent policy management across environments: tagging, admin boxes, traceability Spin up machines and environments quickly Deploy applications to any cloud Enable real-time collaboration between developers and operations
Docker offers a new, lightweight approach to application portability. Applications are shipped using a common container format and managed with a high-level API. Their processes run within isolated namespaces that abstract the operating environment independently of the distribution, versions, network setup, and other details of this environment. This "containerization" has often been nicknamed "the new virtualization." But containers are more than lightweight virtual machines. Beyond their smaller footprint, shorter boot times, and higher consolidation factors, they also bring a lot of new features and use cases that were not possible with classical virtual machines.
WaveMaker CEO Samir Ghosh is taking a new pass at aPaas, and leveraging the increasingly popular Docker open-source platform, with the announcement of WaveMaker Enterprise. The new version of the company's eponymous software “enables instant, end-to-end custom web app creation and management by professional and non-professional developers (alike) and development teams,” according to the company. We asked Samir a few questions about this, and here's what he had to say: Cloud Computing Journal: You've mentioned the previous challenge of business-side developers making that jump from design to deployment. What sort of learning curve will they still face with Wavemaker Enterprise? Samir Ghosh: “Business-side developers” can include non-programming business users or professional developers under tight schedules or with limited mobile or front-end programming expertise. Both can use WaveMaker to meet their app development needs, but may have different deployment needs. I think business users just want their app to run as easily as possible. In WaveMaker, they can literally click a button and their application will run, either on our public cloud or on the enterprise’s private...