Category: News

  • GitLab Expands Scope of DevOps Ambitions

    GitLab Expands Scope of DevOps Ambitions

    GitLab, with the release of its 12.0 update, is extending the reach of its namesake continuous integration/continuous delivery (CI/CD) platform to include both cybersecurity professionals and traditional IT operations staff.

    John Jeremiah, senior product marketing manager at GitLab, said the goal is to provide organizations with a single CI/CD platform that unifies the management of everything from source code to best DevSecOps processes.

    To address that latter requirement, GitLab 12.0 adds a dashboard designed specifically for security personnel along with the ability for cybersecurity teams to approve merge requests and automatically apply patches for vulnerabilities detected. Those capabilities complement existing support for scanning and secrets detection.

    New capabilities embedded in the platform for IT Operations professionals include an operations dashboard and an embedded incident management capability that makes it easier to create a coordinated response to a specific event.

    GitLab 12.0 also adds support for feature flags to better manage the application delivery process, along with a platform-as-a-service (PaaS) environment to provision and maintain the infrastructure needed for developing and launching an application.

    Jeremiah said the new and existing capabilities in GitLab will make it possible for organizations to unify their DevOps tool chains in a way that also enables IT operations teams and cybersecurity professionals to be included in the process.
    At the same time, GitLab is making DevOps more accessible by eliminating many of the silos between various tools that have emerged over the years, including, for example, built-in support for feature flagging versus requiring organizations to acquire and maintain a separate tool, he noted.

    Because those capabilities are embedded in the platform, organizations will be able to make the cultural shift required to adopt DevOps more easily, he added. IT teams don’t always know what other tools they will need as their DevOps skills mature. With all the tools embedded in GitLab readily available, it becomes easier for organizations to expand their DevOps processes as the organization starts to implement more sophisticated processes, Jeremiah said.

    That approach is starting to resonate with the 100,000-plus developers actively using the GitLab platform and more than 2,000 contributors actively contributing code to the underlying open source platform, he added. GitLab in March saw its millionth merge request.

    It’s too early to tell how broadly any CI/CD platform might be able to consolidate the DevOps toolchain. Developers are notorious for adopting new tools as they see fit. Internal IT teams, of course, are not always excited to be asked to support yet another tool. The right level of balance between ultimate flexibility and the need for a standard set of processes that can be implemented across multiple application development teams must be determined by each organization.

    In the meantime, DevOps processes are starting to expand beyond traditional development team to now include IT operations staff and cybersecurity personnel. The challenge now that they’ve been invited to the proverbial DevOps party is making them feel welcome and appreciated.

    — Mike Vizard

  • HPE Extends Hybrid Cloud Computing Strategy

    HPE Extends Hybrid Cloud Computing Strategy

    Hewlett-Packard Enterprise (HPE) today advanced its hybrid cloud computing strategy by announcing at its HPE Discover 2019 conference an alliance with Google to embrace Kubernetes in hybrid cloud computing environments and then extending the reach of its software-defined infrastructure for building private clouds to legacy ProLiant servers.

    Lauren Whitehouse, director of marketing for the software-defined and cloud group at HPE, said the HPE Composable Cloud now extends beyond new ProLiant servers to include everything from legacy hardware to cloud computing platforms running virtual machines or as bare metal servers optimized for Kubernetes.

    To achieve that latter goal, HPE will make it possible to deploy Google Anthos, a previously announced framework for delivering cloud-native computing services across public clouds and on-premises IT environments, on HPE-managed platforms.

    HPE is giving customers the option of deploying configuring local servers with virtual machines with either a VMware vSAN storage software or the HPE SimpliVity hyperconverged infrastructure platform. Additionally, customers can choose to deploy Kubernetes on those platforms or run Kubernetes on a bare-metal server. On top of those stacks, HPE also embeds the HPE OneView IT infrastructure management and HPE Composable Fabric networking solution to create what the company calls a composable rack environment.

    Finally, HPE announced it will extend the reach of the HPE InfoSight artificial intelligence engine, which it gained for storage environments when it acquired Nimble Storage, to the rest of its data center portfolio.

    Whitehouse said that, by extending the reach of its composable computing strategy to include legacy servers, HPE seeks to make it easier to modernize on-premises IT environments within the context of a larger hybrid cloud computing strategy.

    One of the primary reasons so many workloads are being deployed in the cloud is because of the inherent flexibility of the IT environment. HPE is investing in higher levels of infrastructure abstractions to enable an equivalent amount of agility to be injected into on-premises IT environments. Those efforts will then make it easier for organizations to extend best DevOps practices across a hybrid cloud computing environment, said Whitehouse. The company is now removing the objection by organizations to have to implement a forklift upgrade across their entire on-premises IT environment to achieve that goal, she added.

    It’s not immediately clear who will manage what in this brave new world of hybrid cloud computing. Application developers have been exercising a lot more influence over platforms, while advances in automation appear to be heralding a consolidation of management functions within the local data center. As site reliability engineers, or so-called “super administrators” capable of managing compute, storage and networking infrastructure continue to emerge, the silos around job functions in the enterprise were built are breaking down. In fact, the more organizations embrace DevOps best practices, the faster consolidation of job functions is occurring.

    In the meantime, whoever provides the infrastructure that remains in an on-premises IT environment had better be able to enable local IT teams to be just as flexible as any cloud service provider an application developer is likely to encounter.

    — Mike Vizard

  • Moogsoft Advances AIOps Workflow

    Moogsoft Advances AIOps Workflow

    Moogsoft is moving to make it easier to create custom workflows around its AIOps platform while expanding the number of integrations provided to include connectors to New Relic Insights, Microsoft Teams and proxy support for polling integrations with IT platforms Zenoss, Zabbix, vCenter, vSphere, Solarwinds, Spectrum and SevOne.

    Gabe Coelho-Kostolny, senior product management and product marketing leader at Moogsoft, said a Workflow Engine that has been added to version 7.2 of the Moogsoft AIOps platform makes it possible to trigger actions such as notifications, ticket creation and other automated tasks within Moogsoft and external systems. Those actions can be employed within incident management workflows ad other automated remediation tools, he said.

    Moogsoft has also added tools that make it possible to visualize alert clustering algorithms in real time and, if needed, fine-tune them. That capability is intended to provide IT operations teams with more confidence in the recommendations being generated by the AIOps platform, Coelho-Kostolny said.

    Finally, Moogsoft is making available an analytics dashboard dubbed Individual Statistics, which enables managers to drill down from the team level to better understand the workload and key performance indicators of each team member.

    Coelho-Kostolny noted there is already a high correlation between organizations that have adopted best DevOps practices and those moving to implement AIOps. The complexity of many DevOps environments is in many cases forcing the AIOps issue because all the alerts being generated creates a level of fatigue among human IT administrators that results in them not being able to keep pace with the overall rate of change, he said. The concern now is no longer so much whether human IT administrators will be replaced by artificial intelligence (AI) as much as it is enabling IT teams to stay on top of all the tasks required. The opportunity now, he said, is to make it easier for organizations that have embraced DevOps to also customize the AIOps platform.

    Of course, AIOps platforms presuppose that IT organizations have access to massive amounts of accurate data about the IT environment. Collecting that data often winds up being a bigger challenge than most organizations appreciate. In general, Coelho-Kostolny said it’s clear AIOps platform adoption is reaching a tipping point in the enterprise. Organizations, however, need to be careful distinguishing between what is truly artificial intelligence and what may be simply a rules-based engine that has been added to an existing IT service management (ITSM) platform, Coelho-Kostolny said.

    Regardless of the AI path chosen, the ongoing shortage of IT expertise with critical skills means organizations will continue to experiment with AI. The real issue is determining to what degree of confidence IT teams will have in those AI platforms. After all, if the assumptions an AI system is relying on to make a recommendation prove faulty, the potential for harm tends to be a lot greater than any mistake a single human IT administrator might ever make on their own.

    — Mike Vizard

  • VMware to Acquire Avi Networks for NetOps Capability

    VMware to Acquire Avi Networks for NetOps Capability

    VMware announced it intends to acquire Avi Networks for an undisclosed price as part of an ongoing effort to close the gap between network operations (NetOps) and DevOps.

    Once this deal closes, sometime between now and August, VMware plans to add a software-based load balancer, along with a web application firewall (WAF) and a service mesh to its network virtualization software portfolio.

    Tom Gillis, senior vice president and general manager for the networking and security business unit at VMware, said the goal is ultimately to make it as simple to deploy applications in an on-premises IT environment as it is on a public cloud by enabling IT organizations to automate the provisioning of network resources exposed via the VMware NSX network virtualization overlay. Avi Networks will extend those capabilities by adding a high-performance programmable load balancer, which eliminates reliance on legacy load balancers based on proprietary hardware platforms that are both expensive and rigid.

    Gillis said VMware will then infuse the WAF technology developed by Avi Networks into its network overlay platform to further secure east-west traffic in the data center.

    Finally, VMware intends to marry the service mesh technology from Avi Networks that supports a high-performance ingress controller with its ongoing efforts to integrate the open source Istio service mesh with NSX.

    Once all that work is completed, Gillis said it should be possible to deploy a workload on any platform with a single click. The challenge organizations face today is that provisioning and securing the network resources required to deploy an application outside of a public cloud computing environment still takes multiple days to sometimes weeks. VMware has already signaled its intention to make NSX network overlays available across multiple clouds and on-premises IT environments.

    Avi Networks CEO Amit Pandey noted that both companies are on a similar trajectory to leverage x86 processors to eliminate reliance on proprietary networking hardware. That shift to software-based networks and security services is driving the biggest transformation in the data center in the last 25 years.

    In terms of leveraging application programming interfaces to automate the provisioning of networks, it’s clear networking technologies have been lagging behind advances made in both compute and storage infrastructure. The challenge and the opportunity vendors such as VMware now see is the ability to more holistically manage IT environments spanning from the network to the application. As part of that strategy, VMware has been making a string of acquisitions to extend its core virtual machine franchise.

    It’s still too early to say whether all those investments will pay off for VMware. Reliance on VMware technologies in public clouds is relatively slight compared to the dominance VMware has today in on-premises IT environments. VMware is banking that its ability to extend the reach of its portfolio to foster the development of hybrid cloud computing, which is strongly anchored around on-premise IT environments that still run the majority of the workloads in the enterprise, will prevail.

    — Mike Vizard

  • RDX Eases Oracle Database Migration to PostgreSQL on AWS

    RDX Eases Oracle Database Migration to PostgreSQL on AWS

    RDX this week launched a set of tools designed to make it easier to convert applications running on an Oracle database to Amazon Aurora, an instance of an open source PostgreSQL database running on the Amazon Web Service (AWS) cloud that is compatible with Oracle databases.

    Announced at the AWS Summit event in Washington D.C., the clckwrk Refactoring Service for Oracle promises to reduce the amount of manual effort associated with refactoring applications for the Amazon Aurora platform by automating as much as 60% of the database schema conversion process.

    James Ball, chief strategy officer for RDX, said in addition to reducing costs, many organizations want to shift applications to open source databases in the cloud to further their DevOps ambitions. Each time an application needs to scale, an organization will incur additional Oracle licensing fees. In contrast, an open source database enables DevOps teams to scale database instances as required automatically, he said.

    AWS has been making a concerted effort to convince customers to give up proprietary databases in favor of open source databases running on its cloud platform. That competitive pressure is a driving force behind new alliances that previously would have been considered unimaginable. Oracle, for example, recently partnered with Microsoft to promote the integration of the Oracle Cloud platform with the Microsoft Azure cloud. Oracle would prefer its database run on its cloud, but through the alliance is signaling its willingness to work with Microsoft to deploy Oracle database on Azure, a cloud platform that is the leading industry alternative to AWS. Microsoft, of course, has its proprietary database to adopt in the form of Microsoft SQL Server.

    Ball said RDX not only provides tools to accelerate the conversion to Amazon Aurora, but it also provides managed services for customers that want to outsource the management of Amazon Aurora to RDX.

    It takes most organizations several months to migrate a legacy application on to a public cloud. AWS has a vested interested in helping accelerate that process whenever possible. But many organizations that have embraced best DevOps practices find their efforts are hampered by reliance on proprietary databases. In fact, one of the reasons so many developers tend to favor open source databases is to avoid all the headaches associated with getting approvals for new database licenses.

    It’s unclear to what degree the rise of DevOps in the enterprise will ultimately shift database allegiances. Oracle is trying to maintain as much control as possible by making its databases available as a managed service that eliminates some of the purchasing overhead associated with spinning up new instances. However, the cost of an Oracle database license is still buried in the cost of the managed service.

    Not every organization is looking to transition away from a proprietary database, but there is now enough momentum around the “open source first” movement to make it worthwhile to build tools that automate the refactoring of legacy databases not just to reduce costs, but also to make IT a lot more agile.

    — Mike Vizard

  • Pulumi Advances DevOps on AWS

    Pulumi Advances DevOps on AWS

    Pulumi announced the availability of Pulumi Crosswalk for Amazon Web Services (AWS), an open source framework for deploying applications on Amazon Web Services (AWS).

    Company CEO Joe Duffy said Pulumi Crosswalk for AWS provides a software-as-a-service (SaaS) application through which DevOps teams can automate the deployment of applications on AWS infrastructure using software development kits (SDKs) from Pulumi. The SDKs are based on programming tools such as JavaScript, Python, TypeScript and Go, which most developers already know how to use. That approach eliminates the need for DevOps teams to learn how to employ YAML files or to acquire tools such as CloudFormation or Terraform to deploy applications on AWS, he said.

    Pulumi Crosswalk for AWS also embeds the best DevOps processes recommended by AWS directly within its SaaS tools, including patterns for containers and serverless computing frameworks, Duffy noted.

    Pulumi Crosswalk for AWS is available on GitHub. It is designed to be integrated with existing Team and Enterprise Editions of Crosswalk that come with support and training provided by Pulumi.

    In addition to AWS, Pulumi Crosswalk supports other cloud platforms, including Microsoft Azure and Google Cloud Platform (GCP). The company also plans to provide support for private clouds and leverage Kubernetes clusters to automate deployments across hybrid cloud computing environments.

    Duffy noted that despite all the enthusiasm for DevOps, many IT operations teams have been left behind. While much time and effort has been put into unifying backend cloud services, the operational experience in the cloud still revolves around low-level application programming interfaces (APIs) or specialized tools that are challenging for IT operations teams to employ. That situation often creates a backlog of applications for IT operations to deploy. Crosswalk enables IT operations teams to leverage the skills developers have to deploy applications they approve on AWS, he said.

    As cloud computing evolves in the age of DevOps, the relationship between developers and the IT operations team is becoming more nuanced. IT operations teams still need to put guardrails in place, but they can’t afford to be perceived as a bottleneck slowing down the rate at which applications can be deployed in the cloud. The challenge IT operations teams must overcome is finding a way to enable developers to self-service their application deployment requirements as much as possible within a set of policy guidelines defined by the internal IT team. That approach will enable developers and IT operations teams to get out of each other’s way.

    It may be a while before IT operations and developers find the right DevOps balance that best suits their organizations. Individual teams within enterprises tend to define their own best practices based on the expertise available within the team. Ideally, those best practices are then shared and implemented as appropriate across the rest of the enterprise.

    In the meantime, it will be interesting to see how aggressively cloud service providers embrace tools such as those from Pulumi. Cloud service providers have a vested interest in getting as many workloads deployed in their clouds as quickly as possible. They tend to be a little less enthusiastic about anything that makes it easier to move those workloads anytime a DevOps team sees fit.

    — Mike Vizard

  • Pivotal Software Embraces OpenJDK

    Pivotal Software Embraces OpenJDK

    Pivotal Software has officially thrown its weight behind OpenJDK, the open source version of the standard edition of Java, by adding support for OpenJDK to the Pivotal Spring Runtime on its Spring framework.

    At the same time, Pivotal announced it is extending its commercial support for open source Apache Tomcat servers in addition to providing commercial support for all the major open source Spring projects, including Spring Framework, Spring Boot, Spring Cloud and Spring Cloud Dataflow.

    Since 2011, Oracle, IBM and SAP have been making a case for employing OpenJDK. Ryan Morgan, vice president of engineering for the application platform at Pivotal, said that while other languages have become increasingly popular, the primary workhorse for building back-end applications in the enterprise remains Java. Now that Oracle has formally relinquished control over Java source code to The Eclipse Foundation, research and development into the legacy programming environment should accelerate. Oracle retains licensing rights to the name Java, but versions 8 and higher of Java Enterprise Edition are being converted to an open source platform known as Jakarta.

    Morgan said much of the work going forward would be focused on modernizing monolithic Java applications to make it either to turn them into microservices or at least make it easier for microservices developed in other languages to make calls via application programming interfaces (APIs) to those back-end applications. As enterprise IT organizations make the shift, they increasingly will rely on DevOps processes to manage the transition. The effort should accelerate the extent to which many organizations will need to rely on modern best DevOps practices.

    As both OpenJDK and Jakarta continue to move forward, Morgan said Pivotal is committed to continuing investment in the Spring framework, which has done much to make developing Java applications a much more agile endeavor. The most immediate benefit, of course, is the reduction of licensing fees associated with employing Java platforms. Many IT organizations that have mandated open source code-first and adopted alternative programming languages now may want to reconsider their options, especially when the number of developers who know how to write applications in more modern languages is comparatively small.

    Of course, it will take many years for enterprise IT organizations to fully make this transition. In the meantime, many of them will continue developing applications in Java simply because they have large teams that have mastered a programming construct that has been in place for three decades or more. Many of those same organizations may be making greater use of rival programming constructs, but Java and its descendants will play a major role in the enterprise well into the next decade. The primary challenge Pivotal will face is maintaining dominance of the frameworks employed to build new applications based on Jakarta and OpenJDK, in addition to updated existing Java applications.

    — Mike Vizard

  • GitLab Updates Advance Its CI/CD Platform

    GitLab Updates Advance Its CI/CD Platform

    GitLab has expanded the capabilities of its continuous integration/continuous development (CI/CD) platform to include tighter integration with collaboration platforms from Slack and Mattermost along with the ability to support Docker containers running on Windows.

    Version 11.11 of GitLab adds a caching dependency proxy for Docker images to the Premium edition of GitLab along with the ability to provision an instance-level Kubernetes cluster using instances of GitLab that are managed by an internal DevOps team. Those capabilities are arriving on the heels of GitLab last month announcing its initial support for Kubernetes as a platform on which its CI/CD environment now can be deployed.

    The latest edition of GitLab also adds support for multiple assignees for a merge request capability, which allows multiple members of a DevOps team to manage merge requests within a DevOps pipeline.

    Finally, GitLab 11.11 also provides guest access to releases, extends the add-on CI runner minutes to the GitLab Free edition, supports the OpenID Connect authentication protocol, includes serialized commit graphs and simplifies reviews by auto-resolving a discussion whenever a suggestion is applied.

    Priyanka Sharma, technical evangelist for GitLab, said GitLab is starting to see increased interest in using Docker containers to build applications on Windows. A Windows Container Executor for GitLab Runners capability makes it easier to orchestrate pipelines that include Docker containers destined to be deployed on Windows. Previously, DevOps teams needed to rely on a shell executor to orchestrate Docker commands. This update makes it possible to employ Docker containers on Windows in the same way they are deployed on Linux platforms. GitLab also has improved support for PowerShell, in addition to making available helper images for various versions of Windows containers.

    Sharma said GitLab is starting to see IT organizations that have embraced Windows starting to catch up in terms of enthusiasm for Docker containers. Also, DevOps teams that have embraced both Linux and Windows platforms are looking to apply best DevOps practices to both platforms.

    Microsoft has signaled its intention to continue investing in making Docker containers a core element of its overall strategy. As the work progresses in collaboration with Docker Inc., the need for a CI/CD platform that can support Windows environments will become more acute.

    In the meantime, GitLab continues to focus on making it easier to implement best DevOps practices at scale, Sharma said. As enterprise IT organizations continue to embrace DevOps, many of them soon discover the need for a CI/CD platform designed from the ground up to support pipelines that are being accessed by many concurrent users.

    The decision many of those enterprise IT organizations will have to make is how much they will want to rely on an open source versus closed source platform. The enterprise edition of GitLab is a closed source platform, but the company does make available an open source community edition. While the open source Jenkins platform currently dominates among CI/CD platforms, enterprise IT organizations that have adopted DevOps have shown a willingness to embrace proprietary DevOps platforms that address challenges ranging from the scale of deployments to security and compliance.

    It’s too early to say how the next major CI/CD battle involving the shift to microservices will play out. However, if history is any guide, there should be plenty of room for both open source and proprietary CI/CD platforms.

    — Mike Vizard

  • CloudBees Increases Size of DevOps War Chest

    CloudBees Increases Size of DevOps War Chest

    CloudBees has increased the pool of dollars it is aggregated to drive further consolidation across the DevOps sector by $10 million, thanks to an investment from HSBC. The investment comes on the heels of $62 million in funding that CloudBees raised last year, which brings the total amount invested in the company since 2010 to now more than $120 million.

    CloudBees CEO Sacha Labourey said that funding announced this week will be used for, among other things, adding more products and services to the CloudBees portfolio via acquisition. CloudBees last month revealed it acquired Electric Cloud, a provider of a continuous delivery platform for both monolithic and microservices-based applications.

    Labourey said the HSBC investment represents of vote of confidence on two levels: Banks tend to be more conservative when it comes to investing in IT companies, and HSBC has already adopted CloudBees’ open source Jenkins continuous integration/continuous delivery (CI/CD) platform.

    Citing industry analysts’ estimates, CloudBees says the DevOps sector is currently valued at $4.61 billion. Within that sector, CloudBees estimate there are more than 15 million developers using some instance of Jenkins to automate their software delivery pipelines and 46 of Fortune 100 enterprises—including three of the Fortune 10—rely on the CloudBees Suite to implement Jenkins.

    While CloudBees clearly is a dominant provider of DevOps tools and platforms, the category is starting to draw attention from financially well-heeled vendors such as VMware. The virtualization platform arm of Dell Technologies earlier this month announced it will acquire Bitnami, a provider of tools for packaging applications that has gained a following among DevOps proponents.

    That wave of acquisitions coincides with a major shift from monolithic to microservices-based application development. CloudBees launched Jenkins X to provide a CI/CD platform optimized specifically for microservices. But just because CloudBees and Jenkins were able to dominate the first DevOps wave, it doesn’t necessarily follow that Jenkins X will be widely adopted as a de facto standard for building microservices applications. Competition to provide the CI/CD platform for next-generation cloud-native applications based on microservices is already considerable.

    In the meantime, traditional enterprise IT organizations will continue to monitor with interest merger and acquisition activity across the DevOps sector. Enterprise IT organizations tend to be wary of standardizing on development tools and platforms when there’s a chance the provider of that tool might be acquired by another vendor or entity they’d rather not work with. On the plus side, all the money being invested in DevOps startups is one of the primary reasons why DevOps is one of the most vibrant category in all of IT.

    It remains to be seen which company or tool will come out on top. But the contest will be fierce. The ultimate beneficiary of that competition is almost always the end customer—assuming, of course, they bet on the right DevOps horses in the first place.

    — Mike Vizard

  • CircleCI Adds Integration With Atlassian Jira

    CircleCI Adds Integration With Atlassian Jira

    One of the trickier issues IT vendors in the age of DevOps are dealing with is that very few organizations have standardized on a platform from a single vendor. Not only do organizations mix and match tools as they see fit, but different departments within the same organization also embrace different tools to automate the same tasks. That DevOps reality requires collaboration between IT vendors that normally would prefer to not work together, whether they like it or not.

    Case in point is a move by CircleCI, a provider of a continuous integration/continuous delivery (CI/CD) platform, to provide integration with the Jira project management software developed by Atlassian. While Atlassian makes its own CI/CD platform, customers and business partners alike have made it clear they needed CircleCI to support Jira, says Tom Trahan, head of business development for CircleCI. In some cases, those organizations have adopted Jira without having Atlassian’s CI/CD platform in their environment, while in other cases, a department within one part of an organization has opted for CircleCI while others are employing a CI/CD platform from Atlassian.

    At the same time, Trahan notes that many DevOps projects now span multiple organizations that have standardized on different DevOps platforms. Jira provides a way for teams in differentorganizations to manage those projects collaboratively, he says.

    To achieve integration with Jira, CircleCI now offers its CircleCI for Jira module, through which teams can assign new tasks and fixes based on job status with CircleCI orbs, a set of reusable configuration packages that allow CircleCI customers to integrate external tools into their workflow. That capability also makes it possible to launch new Jira issues directly from the job page within the CircleCI user interface.

    CircleCI Integrates with Jira

    Trahan says that in the polyglot world of DevOps, it is apparent vendors are being required to expose open application programming interfaces (APIs) that enable organizations to build and integrate various DevOps platforms anyway they want. Organizations won’t consider IT vendors that are too rigid in terms of what level of integration they enable, he says.

    As DevOps continues to evolve, it’s clear that a wave of merger and acquisition activity is makeing the IT vendor landscape somewhat volatile. Providers of DevOps tools that organizations have standardized on are being acquired at a rapid rate. IT organizations can’t be certain that any given tool or platform they are using won’t be scooped up by a vendor they might not want to engage. In that kind of environment, it’s critical for IT organizations to leverage open APIs that not only make it easier to collaborate, but also replace elements of their DevOps stack whenever they deem necessary.

    The challenge, of course, is that IT vendors are always trying to lock customers in as much as they can. Those efforts are not as heavy-handed as they once might have been. But almost inevitably, the extension being offered to access functionality will disappear if the underlying platform that enables it suddenly disappears. IT organizations, therefore, need to determine whether those extensions are worth any potential trouble they might cause somewhere down the DevOps road.

    — Mike Vizard