Welcome!

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

Related Topics: @DevOpsSummit, Java IoT, Linux Containers, Open Source Cloud, Containers Expo Blog, SDN Journal

@DevOpsSummit: Blog Post

There Are Four (Dev) Ops in IT | @DevOpsSummit [#DevOps]

DevOps isn't just applicable to one group of operations in the datacenter

While some might still be focused on SDN with an OpenFlow-style twist, 30% of the organizations in our survey this summer (report forth coming, I promise!) were looking at SDN to improve time to market. Of those, 73% considered an API-enabled infrastructure to be important to very important.

That makes sense, considering that programmability is increasingly seen as an enabler to improving time to market through automation and orchestration of provisioning and deployment processes as well as abstracting "the network" into services provisionable by line of business and application owners, a la IT as a Service.

Register For DevOps Summit FREE (before Friday) ▸ Here

These same types of efforts are ongoing in other operational areas under the moniker of DevOps. But as has been recently expounded upon, DevOps is not just about automation no matter how closely we associate the latter with the former. Yet most people, when asked, clearly indicate that automation and programmability are critical to a successful DevOps initiative.

54% of respondents from CA's "What Smart Businesses Know About DevOps" named "IT Automation" as the most critical component of DevOps, and Puppet Labs "2013 State of DevOps" found that 82% of the highest performing organizations relied on automation.

What might make everyone happier and clear things up a bit is if we start referring to the tools and programmability as what they are: software-defined operations or SDO. Some might prefer the term "continuous delivery" but that's an outcome of software-defined operations, not the tools and technologies themselves, IMO.

Much like its network-focused counterpart, SDN, SDO is about operationalization. It's about using APIs and templates and data path programmability in conjunction with automation and orchestration tools like Puppet and Chef, Ansible and VMware, and software-defining operations.

Why muddy the waters with another TLA? Because DevOps isn't just applicable to one group of operations in the datacenter. DevOps is, in fact, an approach highly applicable to network (and security) operations, too. There are four "ops" in core IT, and each one can benefit from DevOps because it isn't a set of tools or standards, it's an approach. The reality is that “ops” isn’t a single silo within IT. Every domain within IT has a segment of its population that are operations. Network operations, security operations, storage operations, and the group apparently with no other name but that focuses on app operations. DevOps is (or should be) about all ops and it’s really important to remember that because any ops left out will immediately become an obstacle to scaling the data center and a bottleneck in the quest to improve time to market.

there are four ops

SDN is DevOps for network operations. SDO is DevOps for app operations. When you put them together you get an end-to-end approach to operationalizing the deployment of applications.

Most of the time, introducing a new term into an already confused marketplace isn't a good idea. So introducing a term that spans two already confused marketplaces might be considered, well, crazy.

But in this case, making the distinction might actually help to clear up some of that confusion. Because what we've got now is an incredibly diverse set of opinions on what DevOps is and isn't, and what SDN is, and isn't that isn't really helping any one.

Stepping back and looking at the problem from "what are people trying to do with these architectures and approaches " yields a pretty simple and understandable picture.

operationalize all the things

Even if we don't call it SDO (and I don't really expect anyone to do so), the point is to recognize that SDN and SDO are really subsets of DevOps, each with a focal point on a different piece of the app deployment puzzle: one on the network, one on the app infrastructure. DevOps as an approach is the best way right now to address the bottlenecks that impede the time to market for applications critical to gaining and/or maintaining a competitive edge. It can reduce the risks associated with deployment and produce consistent, predictable and repeatable processes that are better able to manage more and more frequently deployed apps.

Its benefits aren't peculiar to either "app infrastructure" or "the network". DevOps benefits can be realized in both arenas and, in fact, must if we're going to enable the business to take advantage of the new application world.

Shameless plug: There will be a lot more discussion about the concept (DevOps and Networking) at Devops4Networks this month. Check it out and swing by if you can! If you can't, follow along on the Twitters @devops4networks

Read the original blog entry...

More Stories By Lori MacVittie

Lori MacVittie is responsible for education and evangelism of application services available across F5’s entire product suite. Her role includes authorship of technical materials and participation in a number of community-based forums and industry standards organizations, among other efforts. MacVittie has extensive programming experience as an application architect, as well as network and systems development and administration expertise. Prior to joining F5, MacVittie was an award-winning Senior Technology Editor at Network Computing Magazine, where she conducted product research and evaluation focused on integration with application and network architectures, and authored articles on a variety of topics aimed at IT professionals. Her most recent area of focus included SOA-related products and architectures. She holds a B.S. in Information and Computing Science from the University of Wisconsin at Green Bay, and an M.S. in Computer Science from Nova Southeastern University.

CloudEXPO Stories
DXWorldEXPO LLC announced today that Kevin Jackson joined the faculty of CloudEXPO's "10-Year Anniversary Event" which will take place on November 11-13, 2018 in New York City. Kevin L. Jackson is a globally recognized cloud computing expert and Founder/Author of the award winning "Cloud Musings" blog. Mr. Jackson has also been recognized as a "Top 100 Cybersecurity Influencer and Brand" by Onalytica (2015), a Huffington Post "Top 100 Cloud Computing Experts on Twitter" (2013) and a "Top 50 Cloud Computing Blogger for IT Integrators" by CRN (2015). Mr. Jackson's professional career includes service in the US Navy Space Systems Command, Vice President J.P. Morgan Chase, Worldwide Sales Executive for IBM and NJVC Vice President, Cloud Services. He is currently part of a team responsible for onboarding mission applications to the US Intelligence Community cloud computing environment (IC ...
When applications are hosted on servers, they produce immense quantities of logging data. Quality engineers should verify that apps are producing log data that is existent, correct, consumable, and complete. Otherwise, apps in production are not easily monitored, have issues that are difficult to detect, and cannot be corrected quickly. Tom Chavez presents the four steps that quality engineers should include in every test plan for apps that produce log output or other machine data. Learn the steps so your team's apps not only function but also can be monitored and understood from their machine data when running in production.
The best way to leverage your Cloud Expo presence as a sponsor and exhibitor is to plan your news announcements around our events. The press covering Cloud Expo and @ThingsExpo will have access to these releases and will amplify your news announcements. More than two dozen Cloud companies either set deals at our shows or have announced their mergers and acquisitions at Cloud Expo. Product announcements during our show provide your company with the most reach through our targeted audiences.
When building large, cloud-based applications that operate at a high scale, it's important to maintain a high availability and resilience to failures. In order to do that, you must be tolerant of failures, even in light of failures in other areas of your application. "Fly two mistakes high" is an old adage in the radio control airplane hobby. It means, fly high enough so that if you make a mistake, you can continue flying with room to still make mistakes. In his session at 18th Cloud Expo, Lee Atchison, Principal Cloud Architect and Advocate at New Relic, discussed how this same philosophy can be applied to highly scaled applications, and can dramatically increase your resilience to failure.
With more than 30 Kubernetes solutions in the marketplace, it's tempting to think Kubernetes and the vendor ecosystem has solved the problem of operationalizing containers at scale or of automatically managing the elasticity of the underlying infrastructure that these solutions need to be truly scalable. Far from it. There are at least six major pain points that companies experience when they try to deploy and run Kubernetes in their complex environments. In this presentation, the speaker will detail these pain points and explain how cloud can address them.