devopsy.kinsta.cloud

Author: Mike Vizard

  • Lack of Continuous Testing Mastery Slows DevOps Progress

    Lack of Continuous Testing Mastery Slows DevOps Progress

    Progress in achieving the maximum benefits to be gained from investing DevOps processes appears to be held in check by a failure to master the art of continuous testing. A new survey of 923 IT and testing professionals published this week by CA Technologies suggests that only 20 percent of the respondents could be classified as “leaders” when it comes to implementing continuous testing.

    A full 93 percent of respondents identified testing automation as important, but only 1 in 5 respondents said they achieved a high level (80 percent or more) of test automation coverage. Seventy-five percent said continuous testing is important as well. Unfortunately, most of the respondents continue to rely on manual processes. In fact, respondents attributed continuous testing challenges to the lack of automation in almost every aspect of the testing process, including generation of test cases through test execution to critical activities such as fast, safe and efficient test data management.

    Scott Edwards, senior director of product marketing for CA Technologies, says failure to automate continuous testing will only lead to an increased DevOps divide. Organizations that have automated DevOps processes not only release more code faster, the report find they enjoy advantages such as:

    • 2.3 times more likely to have succeeded in left-shifting testing activity to developers;
    • 2.6 times more likely to reduce defects by more than 50 percent;
    • 2.4 times more confident in quality of output;
    • 1.9 times more confident in speed of delivery; and
    • 3.9 times more likely to be working in an organization exhibiting rapid revenue growth.

    Edwards says those results indicate that organizations that are further down the DevOps process will enjoy a substantial competitive advantage at a time when organizations of all sizes are realizing how dependent they are on software to differentiate themselves. Organizations may be operating in a variety of vertical industries, but increasingly they are becoming software companies that happen to specialize in a specific area, says Edwards.

    Making that shift requires IT organizations to move away from thinking about developing applications as an art to building what amounts to a software factory, he says. The factory approach not only eliminates silos in the DevOps process, it also should ideally allow developers to continuously test their own applications. Of course, the biggest issue with testing may very well be the simple fact that most developers build applications today using notebooks and workstations that don’t accurately reflect the complexity of the data center environments those applications will ultimately be deployed in. However, thanks to the rise of technologies such as service virtualization and cloud-based development environments, it has become easier to more closely mimic production environments.

    The degree to which an absence of continuous testing impedes both the rate at which applications are deployed in a production environment will naturally vary by organization. But the one thing that is almost certain is that organizations that have mastered continuous testing are much more likely to deliver a quality application experience than those that don’t.

    — Mike Vizard

  • Study: Half of Enterprises Have Achieved DevSecOps

    Study: Half of Enterprises Have Achieved DevSecOps

    The inclusion of IT security into DevOps processes, also known as DevSecOps, appears to be occurring at an accelerated rate. A new survey of 300 enterprise IT organizations published this week by DigCert, a provider of identity management and encryption software, finds that almost half (49 percent) of the respondents says they have completed DevSecOps, while another 49 percent say they are already working on it.

    In terms of overall impact, however, only 22 percent say they are doing well in terms of achieving and maintaining higher levels of security.

    In addition, those that have achieved DevSecOps say it took them anywhere from 12 to 14 months to make the transition. Those that have not completed the transition are estimating it will take them seven to 11 months. Based on the experience of the organizations that have completed the transition, there would appear to be a natural tendency to underestimate how much the cultural difference between developers and IT security teams can negatively impact integration objectives.

    Jason Sabin, chief security officer (CSO) for DigiCert, says that while many organizations may have brought IT security professionals into the process, an increase in the overall security of applications being built requires more time and patience, says Sabin.

    DigiCert recommends IT organizations identify an IT security champion within a DevOps process and automate the implementation of IT security controls as much as possible. Those moves can help lower developer cultural resistance to having to spend time on what often are considered mundane programming issues.

    It’s worth noting that most IT security professionals don’t have much in the way of programming skills. They can secure an application using any number of platforms that have a management console. But understanding how to employ APIs to help plug security holes before an application gets deployed is beyond the capabilities of most IT security professionals. IT security professionals can make developers aware of issues, but in general there’s not much they can do to fix the application itself.

    Also, IT security professionals typically don’t understand the amount of coding that might be required to fix an issue, and they are not always able to access the true risk associated with a specific vulnerability. All vulnerabilities tend to be treated as equal threats regardless of number of instances a vulnerability has been exploited.

    The good news is a full 88 percent of respondents saying it is somewhat to extremely important to integrate security into DevOps. Failure to do so will lead to issues such as increased costs (78 percent), slower application delivery (73 percent) and increased security risks (71 percent). Awareness of these issues should eventually lead to the development and deployment of more secure applications.

    The issue, of course, is that not every development team is equally along the DevSecOps maturity code. Because of that issue, it unfortunately may be years before the preponderance of applications running in a production environment are able to defend themselves from even the most rudimentary cybersecurity attacks.

    — Mike Vizard

  • Pivotal Enlists Rackspace to Advance DevOps in Cloud Foundry Environments

    Pivotal Enlists Rackspace to Advance DevOps in Cloud Foundry Environments

    In a sign of the level of complexity now associated with managing DevOps, Pivotal has partnered with Rackspace to create a managed services practice for its distribution of the Cloud Foundry platform-as-a-service (PaaS) environment.

    Ian Andrews, vice president of product for Pivotal, says that at least half of the company’s customers have a least one instance of Pivotal Cloud Foundry (CF) that they would like to have managed by a third party. The reason for that is two-fold. For one, the Cloud Foundry PaaS can be complex for many IT organizations to deploy and manage on their own; Andrews notes that Pivotal releases updates to its distribution of the Cloud Foundry PaaS every 90 days. That’s a cadence the average internal IT organization is not prepared to keep pace with without help from an external services provider, he says.

    Also, increased usage of microservices based on containers running on Cloud Foundry is driving organizations to shift allocation of their own internal resources away from managing underlying infrastructure. By relying on managed services providers such as Rackspace to manage both the PaaS and the underlying infrastructure, Andrews says more resources can be focused on managing the DevOps pipeline.

    Pivotal opted to partner with Rackspace because Rackspace is capable to supporting instances of Cloud Foundry running on a public cloud, in a hosting center or on-premises, he says, adding that 60 percent of the Pivotal instances run on VMware vSphere platform, while the rest are distributed across multiple clouds and other on-premises environments. Pivotal is a sister company of VMware, operating under the umbrella of Dell Technologies.

    Brannon Lacey, vice president and general manager for applications and platforms at Rackspace, says his company is embracing Pivotal as part of a larger push to deliver managed services above the infrastructure level. Previously, Lacey says, Rackspace managed e-commerce and content management applications, then acquired TriCore to add a portfolio of managed ERP application services. However, the company doesn’t have any plans to add more PaaS environments to its portfolio beyond the Cloud Foundry PaaS curated by Pivotal.

    Historically, managed services have accounted for about a quarter of all IT spending. But as the number of deployment options available to IT organizations continue to expand, Lacey says Rackspace is expecting the number of companies that look beyond their internal IT organizations to manage that complexity will only increase.

    As more managed services providers become part of the DevOps pipeline, it’s clear that many companies will soon need to consider how to create processes that extend well beyond their own organizations. That may prove to be a significant challenge because of the cadence of the update process is dictated by the external entities. Of course, IT organizations can dictate the pace of the upgrades. But the further an IT organization falls behind in terms of upgrades, the more expensive the managed service tends to become. In short, there’s no such thing as a proverbial DevOps easy button.

    — Mike Vizard

  • Barracuda Networks Enhances API to Advance DevSecOps

    Barracuda Networks Enhances API to Advance DevSecOps

    Recognizing that DevOps teams deploying applications in the cloud need a more sophisticated approach to security, Barracuda Networks at the Microsoft Inspire 2017 conference unveiled an enhanced REST API for its Web Application Firewall (WAF), in addition to providing integration with the IT automation framework developed by Puppet Labs.

    At the same time, Barracuda Networks revealed that it has integrated all of it firewall offerings with the Microsoft Operations Management Services running on the Microsoft Azure Cloud. Finally, Barracuda Networks announced it is now including a software-defined wide area network (SD-WAN) capability with the Barracuda NextGen Firewall platform.

    Tim Jefferson, vice president of cloud for Barracuda Networks, says the REST API the company is exposing in its WAF enables IT organizations to better manage security within the context of larger DevOps environment. As part of that effort, Jefferson says, Barracuda Networks also plans to integrate its WAF offering with other IT automation frameworks.

    Jefferson says many IT organizations are discovering that public clouds are more secure than on-premises environments because of the level of security and instrumentation that cloud service providers now routinely include. For example, cloud service providers make it easier to track unusual API calls that might indicate an IT security breach or even an attack in progress. Those capabilities, says Jefferson, make it easier for vendors such as Barracuda Networks to provide more visibility into what’s occurring in a public cloud than what’s generally feasible on-premises.

    However, each cloud service provider has its own unique network stack that requires security tools to be optimized for each platform, says Jefferson. Because of that issue, most IT organizations have not had the security wherewithal needed to rise beyond adopting more than one public cloud service in their production environments, he says.

    In general, Jefferson says, developers are not likely to consume security technologies on a public cloud that can’t be invoked via an API. Because of that issue, many IT organizations are discovering that the security platforms they have employed on-premises simply can’t be lifted into the cloud. That issue, he says, creates a level of friction inside the organization that inevitably hampers usage of cloud platforms more than any other challenge an IT organization faces. Cloud applications require a DevSecOps approach that developers will view as a natural extension of existing DevOps processes, says Jefferson.

    To achieve that goal, organizations need to make it easier for developers to secure their applications and invite IT security experts inside their organization to participate in, for example, scrum teams that collaboration build, deploy and manage applications. In fact, Jefferson notes most DevOps teams don’t even want to talk to a vendor’s sales representative; they prefer to be able to download code that they can test and deploy on their own before committing to buying a license.

    It’s still relatively early in terms of appreciating the impact DevSecOps will have on improving IT security. But one thing is clear: IT security vendors that don’t make it simple for developers to invoke the capabilities they provide soon will be left behind.

    — Mike Vizard

  • Microsoft Woos Development Partners

    Microsoft Woos Development Partners

    If Microsoft has its way, many more DevOps processes will revolve around the cadence at which the company upgrades its applications. At its Inspire 2017 conference, the tech behemoth announced an ISV Cloud Embed initiative designed to entice more developers to add value by extending application functionality it has already developed and deployed in the cloud.

    Rather than reinvent the same functionality over again, Microsoft will provide developers with access to its application at price points that are as much as 50 percent less than what an end user might pay, notes Alysa Taylor, general manager for Microsoft Business Applications and Industry. In addition, the company is promising to help software developer partners reach 100 million commercial active users of Office 365 and Dynamic 365 customers through the Microsoft AppSource online store.

    The specific software modules the company is providing developers access to under this program include:

    • Dynamics 365 Embedded: a suite of business applications the company is hoping third-party developers will customize and extend across a variety of vertical industries.
    • Microsoft Flow Embedded: Makes it possible to customize workflows to automate business processes within their application.
    • PowerApps Embedded: Provides access to extensions that make it easier to deliver an application via a browser or as a mobile application.
    • Power BI Embedded: Allows users to easily embed fully interactive reports and dashboards.

    This latest initiative is a logical extension of the work the company has been doing to entice developers to employ Microsoft Office as the front end for accessing a wide variety of back-end services.

    The challenge IT organizations that go down this path will face is aligning the pace of DevOps with the rate at which the company is updating its applications.

    Microsoft is not the only IT vendor that presents this DevOps challenge. The more a software developer invokes APIs, the more complicated managing the DevOps process can become. The whole concept of continuous integration/continuous deployment (CI/CD) can get sorely tested when control over when the back-end services being invoked via an API are updated.

    In effect, software developers are being asked to make a buy-versus-build decision. To entice developers to make a buy, the company not only provides a common API framework, but also developers will be able to take advantage of any investments it makes in artificial intelligence across the entire Microsoft application portfolio.

    Taylor says Microsoft is committed to working with partners to eliminate any competitive friction. The company is in the process of implementing a massive reorganization under which the company’s core technology groups are being aligned around four technology groups: Modern Workplace, Business Applications, Applications and Infrastructure, and Data and AI. The rest of the company is then being organized around a go-to-market strategy that is focused on education, financial services, government, healthcare, manufacturing and retail industry segments. Microsoft is looking for partners that can apply their own intellectual property to extend its core applications into each of those segments, says Taylor.

    It remains to be seen just how well partnering with Microsoft can work on a practical DevOps level. But the one thing that is clear is that there will be no shortage of software developers who are about to find out.

    — Mike Vizard

  • CircleCI Injects Workflow Flexibility into CI/CD Platform

    CircleCI Injects Workflow Flexibility into CI/CD Platform

    Nobody likes to be told how to get a specific task or job done. In fact, it’s arguably that very sentiment that holds backs adoption of DevOps processes inside many IT organizations. Aiming to provide IT organizations with a more flexible approach to DevOps, CircleCI has updated its continuous integration and continuous deployment (CI/CD) software to give IT organizations more granular control over workflows within a DevOps environment.

    CircleCI CEO Jim Rose says the issue with most CI/CD frameworks is that they are too monolithic. Rather than allowing IT organizations to apply different types of workflows against various types of scenarios, Rose says most CI/CD platforms are too prescriptive in how they define workflows.

    To provide some additional flexibility, version 2.0 of the company’s namesake CI/CD platform provides IT organizations with the ability to employ different types of workflows whenever appropriate, including:

    Sequential job execution: Provided in the first release of CirceCI, this class of workflow is optimal for approaching jobs in a lockstep build-deploy-test model.

    Parallel job execution: Allows IT organizations to run multiple jobs simultaneously in a way the resolves dependencies before deployment.

    Fan-in/fan-out in a repo: Ideal for a more complex build orchestrations involving different test suites against commits to get faster feedback.

    Branch-level filtering for job execution: Allows deployment of code off specific branches.

    Job execution from failed and job execution from start: Allows IT operations teams to choose where and how build reruns are implemented to save repeating unnecessary jobs. IT allows IT operations teams to start jobs from the last failed job, instead of rerunning every job or stage.

    Rose says the rise of microservices has begun to stress CI/CD platforms that were not designed to scale to support environments where Docker containers in any given microservice often are replaced. Any change to an element of microservice is likely to have a significant impact upstream and downstream. Rather than having to continually rerun every job, Rose says CircleCI now enables IT organizations that have embraced microservices to respond more adroitly to changes in the overall environment.

    In an ideal world, DevOps processes lead to faster rollout of new applications and updates. In reality, however, there are more dependencies than ever. Rose contends that CI/CD platforms need to evolve to the point where they can allow IT operations teams to cope with accelerated rates of change instead of becoming a bottleneck. The irony of that, of course, is that CI/CD platforms were adopted to eliminate bottlenecks. But as microservices architectures continue to evolve, in many cases the CI/CD platform has become a new bottleneck.

    It’s too early to say what impact microservices will have on DevOps. There’s no doubt that adoption of microservices will finally force the DevOps issue inside many organizations. But at the same many organizations that have already gone down the CI/CD path may soon find that some of their initial assumptions about what the word “continuous” meant were considerably misguided.

    — Mike Vizard

  • How AI Impacts DevOps Pipelines

    How AI Impacts DevOps Pipelines

    The rise of machine- and deep-learning algorithms is about to create some interesting data-gravity challenges for IT operations teams. Over most of the last decade IT operations teams have been caught up in a public- versus private-cloud computing debate that has mostly been species. The truth is that most organizations wind up employing both. But as IT organizations are just now getting used to that multi-cloud reality, the rise of machine- and deep-learning algorithms to create a new generation of advanced artificial intelligence (AI) applications are about to add some significant nuances to managing the DevOps pipeline.

    New applications tend to be built and deployed where they can access the most relevant data. Most of the data employed by the average enterprise resides on-premises today. But it’s clear that the data being created in various types of cloud services is growing at a faster rate, thereby altering data gravity forces across the enterprise.

    To get the most value out of that, developers are now building a new generation of advanced applications that employ machine- and deep-learning algorithms. In most cases those algorithms are being deployed wherever data happens to reside. For example, Salesforce just announced at its Salesforce TRAILHEADX 2017 conference that it is making available additional APIs to the Salesforce Einstein Platform Services for building custom applications that can now be infused with sentiment analysis, the ability to detect objects and understand customer intent.

    Michael Machado, director of product management for Salesforce Einstein, says that the success of any AI initiative will come down to both the amount and quality of the data being accessed. As a CRM application consisting of a mix of structured and unstructured data concerning customers, Salesforce represents an attractive platform for building AI applications. In fact, to facilitate the building of applications, Salesforce also is making it simpler for developers to collaborate across multiple alliances in addition to providing access to DevOps tools from Atlassian and Github.

    But CRM applications are only one element of the typical application portfolio. The more data that any set of algorithms can be applied against, the faster the application learns and the more accurate it becomes. As developers build the next generation of applications, they are going to want to be able to access as much data as possible. For many IT organizations, that will mean the applications will be hybrid almost by definition—attempting to centralize all their data will prove to be impractical as well as prohibitively expensive. Constructing application pipelines spanning multiple data sources, however, requires a very mature set of DevOps processes.

    Arguably, the rise of these next-generation applications might finally force the DevOps issue inside most organizations. Most have been able to manage application development on various cloud platforms in isolation. Going forward, that may no longer be practical, as developers seek to incorporate more data sources within their application environment. The challenge IT operations teams will need to wrestle with is providing timely access to that data in way that doesn’t ultimately compromise their performance.

    — Mike Vizard

  • Riverbed Aims to Unify App, Network Performance Management

    Riverbed Aims to Unify App, Network Performance Management

    Much of the initial focus on DevOps has been on accelerating the rate at which applications are built and deployed. But once those applications are deployed, it’s not too long before the focus shifts to the quality of the end-user experience. Aiming to make it easier to determine what the quality of that experience really is, Riverbed Technology has launched a Digital Experience Management initiative based on the SteelCentral management platform.

    Erik Hille, director of product marketing for Riverbed, says the latest release of SteelCentral provides tighter integration between SteelCentral Portal and the SteelCentral Aternity end-user monitoring tool and SteelCentral AppInternals, an application performance management (APM) platform. The goal, says Hille, is to make it easier for an organization to holistically manage individual end-user experience by correlating information at the device, network and application levels. As part of that effort, Riverbed also has integrated the workflow between SteelCentral Aternity and AppInternals to create an integrated monitoring system.

    Hille says IT operations teams can use a comprehensive approach to managing digital experiences that can be set up in fewer than 10 days. Once in place, IT operations teams can more quickly identify the root cause of any issue by correlating application, device and networking data through a single pane of glass. In addition, Riverbed is employing REST APIs to make it possible to consume alerts generated by collaboration tools such as Slack and HipChat. IT operations teams can not only automatically open incident management tickets, but also collect additional metrics via those APIs.

    Riverbed is also providing integration between NetProfiler, a network performance monitoring tool, and NetIM, a network device management tool, to provide more visibility into how network infrastructure impacts network performance.

    Hille notes that most IT operations teams are swiveling between different sets of tools to correlate the same information. The problem is that as more organizations strive to become a digital business, any performance issue has a direct impact on customer satisfaction and the amount of revenue being generated. Faced with that increased business pressure, Hille says IT organizations need to re-evaluate legacy approaches to IT operations based on silos. The goal should be to implement a more proactive approach to IT focused on proactively preventing issues from occurring or escalating, versus merely reacting to isolated events as they occur.

    One of the few things in DevOps that developers and IT professionals can agree on is that whenever there’s an issue, it’s the fault of the network guy. That’s not always true, but it does take networking professionals a long time to prove their innocence. Until then, there’s a tendency to assume their guilty until proven otherwise. Obviously, that kind of bias isn’t in keeping with the whole spirit of integrated DevOps. A more comprehensive approach to application and networking performance management should go a long way toward reducing the amount of finger-pointing inside any organization.

    There will never be a perfect IT environment. The goal is to discover issues before the end-user notices—and, failing that, resolve that issue in as little time as possible. Any argument about what exactly happened to cause the problem can occur at a later date and time.

    — Mike Vizard

  • Fleetsmith Pulls Apple into DevOps Orbit

    Fleetsmith Pulls Apple into DevOps Orbit

    For too long now Apple Macintosh systems have been the proverbial red-headed stepchild of DevOps. There are a lot of ways to incorporate Windows systems automatically into a larger DevOps pipeline, but Macintosh systems generally require a lot of manual intervention.

    As part of a larger effort to automate application deployments across Apple systems, Fleetsmith has announced that the platform it created for automating the management of Apple systems now supports both the Puppet and Chef automation frameworks. DevOps teams looking to extend the reach of those frameworks to Apple systems can now invoke Fleetsmith to automate the deployment of Chef and Puppet like any other Macintosh application.

    Of course, once Puppet or Chef are installed, IT organizations can control what gets deployed on those systems going forward. But in general, organizations that deploy Macintoshes prefer to employ tools that provide a native Macintosh experience when it comes to managing those systems, says Fleetsmith CEO Zack Blum. There are plenty of options when it comes to cross-platform management tools, but Blum notes each of the tools compromises the Apple Macintosh experience such that individuals who prefer Apple systems must manage those systems using a construct that was not primarily designed for use in, for example, a Windows environment.

    Over the years, a number of developers have shown a marked preference for Apple Macintosh systems. As a result, it’s difficult to develop a coherent approach to DevOps that does not include some way to automate the management of those platforms, including the ability to deploy DevOps tools such as Puppet and Chef. Blum says that, in time, Fleetsmith plans to increase the number of Macintosh applications that can be distributed via its platform.

    Naturally, Apple is too focused on the end-user experience to trifle with IT management issues. It prefers to leave those issues in the hands of partners such as Fleetsmith, JAMF Software, IBM and SAP. The other alternative is to rely on open-source software that has been created to address this same issue. But Blum says open-source alternatives are more complex than commercial software, while rival commercial approaches to provide the same level of fleet management of Apple system at scale.

    Fleetsmith was developed when its founders worked at Dropbox and Fandom. Both organizations had evaluated several Mac management options before deciding to develop their own code. The company launched last fall with $3.1 million in funding.

    Pricing for the service, which officially is still in beta, is $10 per month per device. The service is free for any organization with fewer than 10 Apple devices. In addition, Fleetsmith integrates with Google G-Suite to make it simple to authenticate users of the service.

    Obviously, there’s more to be done in terms of pulling Apple devices into the greater DevOps ecosystem. But as a first step, making it simpler to deploy Chef and Puppet on these systems signals greater awareness of the overall issue.

    — Mike Vizard

  • Cisco Looks to Bridge Gap Between Networking and DevOps

    Cisco Looks to Bridge Gap Between Networking and DevOps

    Networking in the enterprise has always stood apart. It might take two minutes or less to spin up a virtual machine, but it can take two weeks to set up the network connections. To help bridge some of the gaps between networking and the rest of the DevOps team, Cisco Systems this week unveiled a series of intelligent switches that promise to do just that.

    Via a Cisco intent-driven networking initiative, it soon will be possible to describe a business outcome that will be automatically enabled at the networking level, says Kiran Ghodgaonkar, senior marketing manager for Cisco. To achieve that goal, Cisco is moving to unify networking on an end-to-end basis, which Ghodgaonkar says primarily will require building a common controller that can be implemented at both the edge of the network and in the data center.

    The first concrete step in achieving that goal is a set of Catalyst 9000 switches running an IOS XE operating system, which Cisco has imbued with machine learning algorithms. Over time, those algorithms will be deployed across both legacy networking infrastructures when appropriate, as well as any new networking and security equipment Cisco brings to market in the future. Once in place, IOS XE will make it easier to implement policies in software that spans everything from prioritizing traffic to implementing security polices.

    This latest Cisco initiative follows the rollout a Tetration analytics platform based on an instance of Apache Spark and Cisco’s acquisition of AppDynamics, provider of an application performance management service delivered via the cloud. Ghodgaonkar says Cisco is aiming to combine analytics and machine learning algorithms to simplify network management in a way that furthers DevOps integration. Right now, however, the biggest impedance to achieving that goal, says Ghodgaonkar, is the fact that 80 percent to 90 percent of networking tasks still require manual intervention. Because of that issue alone, many organizations have experienced limited success in terms of integrating server, storage and networking management, despite the rise of software-defined networking (SDN) in the data center. In fact, to get past that issue, many organizations make investments in pre-integrated systems such as the Cisco Unified Computing System (UCS) platform. But the number of organizations willing to make that kind in forklift investment in IT infrastructure is not all that high when compared to the size of the overall IT market.

    The biggest DevOps issue IT organizations now face, says Ghodgaonkar, is that as various elements of the IT organization invest in automation, silos of automation are created. Cisco says it has developed open application programming interfaces (API) will provide interoperability between its technologies and the rest of the IT environment to help break down those silos.

    It’s still a little unclear these days just how much networking and IT operations can get automated. The good news is that, given the state of network management inside most organizations, things can only improve. The real issue (as any existing DevOps team already knows) may not be so much the technology as it is the culture differences spanning the compute, storage and networking teams.

    — Mike Vizard