devopsy.kinsta.cloud

Author: Mike Vizard

  • SmartBear Integrates Test Tools with Atlassian DevOps Platforms

    SmartBear Integrates Test Tools with Atlassian DevOps Platforms

    At the Atlassian Summit 2019 conference this week, SmartBear announced it has integrated the Zephyr test automation tools it acquired last year with the Jira portfolio of tools from Atlassian.

    In addition, SmartBear announced it has integrated Zephyr with the rest of the company’s SoapUI Pro, TestComplete, CrossBrowserTesting and LoadNinja testing tools.

    SmartBear committed to integrating its entire portfolio of tools with other Atlassian offerings as well, including the Bitbucket continuous integration/continuous development platform and Confluence content management software.

    In general, SmartBear views efforts to modernize applications using DevOps practices as a primary driver of increased demand for tools to test application programming interfaces (APIs). A recent global survey of 3,000 API developers, architects, testers and product leaders conducted by SmartBear finds nearly three-quarters of respondents believe that adoption of microservice architectures will drive the biggest growth in API adoption in the next two years.

    The biggest challenge faced by well over half the respondents (58%) is finding a way to standardize API development. In pursuit of that goal, the survey finds 69% of survey respondents are now developing APIs that comply with the OpenAPI Specification (OAS). That specification defines a language-agnostic interface to RESTful APIs that enables both humans and computers to discover and understand the capabilities of the service without access to source code or documentation, or having to inspect network traffic.

    The SmartBear survey also finds 76% of respondents say they already have a formal API monitoring process in place and that 76% of organizations are developing both internal and public-facing APIs.

    Daniel Giordano, associate director of product marketing for SmartBear, said these days there’s a lot more focus on trying to make it easier to discover APIs whenever possible by setting up API catalogs. Those catalogs are also now making it easier for organizations to reuse APIs rather than develop new ones for each microservice that gets developed, he added.

    In fact, Giordano noted that many organizations now define the APIs they are going to depend on to integrate their applications long before they begin to write application code. Those APIs are then reviewed by an architecture team to make sure they meet performance requirements while still being flexible enough to evolve consistently with the other APIs the organization needs to maintain, he said.

    Today, organizations make use of many more private APIs than they do public ones. APIs first came into their own as a means to expose applications to enable external applications to consume data from another application as part of the so-called API Economy. Since then, the number of private APIs that organizations rely on to integrate internal applications has exploded. In fact, building and deploying those APIs has become an integral part of any DevOps process.

    Naturally, the relationship between API management and DevOps processes is still evolving. But as DevOps processes within IT organizations continue to mature it’s only a matter of time before they are applied equally to both the applications being developed and the APIs relied on to integrate them.

    — Mike Vizard

  • Atlassian Integrates DevOps Portfolio

    Atlassian Integrates DevOps Portfolio

    At its Atlassian Summit 2019 conference, Atlassian announced updates to all the DevOps tools that make up Atlassian Data Center as well as upgrades to its Opsgenie incident management software to provide deeper integration with the rest of the company’s portfolio.

    At the same time, Atlassian revealed it has rebranded the AgileCraft business planning application it acquired earlier this year to Jira Agile.

    New capabilities added to Atlassian Data Center include the ability to set up smart mirror farms for Bitbucket Data Center; content delivery network (CDN) support for Jira Software, Confluence, Bitbucket and Jira Service Desk Data Center; rate limiting for Bitbucket, Jira Software and Jira Service Desk Data Center; issue archiving for Jira Software and Jira Service Desk Data Center; templates for deploying on Microsoft Azure and Amazon Web Services public cloud; and a mobile application for Jira Server and Data Center.

    Atlassian Data Center now incorporates Jira Software 8.0, Confluence 7.0, Bitbucket 6.0, Jira Service Desk 4.0 and Portfolio 3.0. The latest version of Jira Software 8.0 now executes advanced searches using Jira Query Language (JQL) 31% faster on average, while agile boards load two times faster and re-indexing times are now 71% faster. The latest version of Confluence adds support for multimedia files and additional analytics tools to the content management platform.

    The Atlassian Cloud service has also been expanded to increase the user limit to 5,000, with an early access program signaling an intention to bring that up to 10,000 users soon.

    Meanwhile, specific capabilities being added to OpsGenie include support for incident timelines to track response activities and key events; postmortems to help discover root causes and track remediation activities, a user interface that aligns with the rest of the Atlassian portfolio that fosters bi-directional workflow, the ability to automatically trigger events, integration with Slack collaboration software, the ability to encrypt data and Statuspage services integration to make it possible to share alerts with third-party services. Atlassian has also rebranded its Automation Actions to Opsgenie Actions; the company acquired Opsgenie last fall.

    Berkay Mollamustafaoglu, co-founder and head of product for Opsgenie, said now that Opsgenie is part of the larger Atlassian product family there’s clearly more focus on helping organizations integrate best DevOps practices with more structured processes based on the ITIL format. The latest version of the ITIL format provides makes those processes more flexible, but there’s still plenty of room for Atlassian to improve the tenor of the conversation across what has become a bi-modal IT operations environment. As the level of synchronization across those processes increases, the amount of fatigue IT operations teams experience lessens as the number of alerts that need to be correlated across multiple platforms decreases, Mollamustafaoglu noted. In fact, rather than convening in a physical “war room” to resolve a issue, most incidents will increasingly be resolved via online chats, he said.

    It may take a while before a period of détente emerges between advocates of DevOps and ITIL processes inevitably emerges. In the meantime, the more IT services management (ITSM) platforms become integrated with one another, the easier it becomes to achieve that goal. In fact, the major obstacle that needs to be overcome are much more likely to cultural rather than the level of integration that can be achieved using any specific ITSM platform.

    — Mike Vizard

  • xMatters Looks to Meld DevOps and ITIL

    xMatters Looks to Meld DevOps and ITIL

    With the launch today of a flow design tool from xMatters, the divide between DevOps and ITIL-based approaches to managing IT is narrowing.

    xMatters Flow Designer is a drag-and-drop graphical tool that either developers or IT operation teams can employ to create incident management workflows on top of xMatters incident management software. Doug Peete, chief product officer of xMatters, said those workflows feed data into a variety of third-party IT management tools to enable IT operations and DevOps teams to consume the same data in different tools—for example, in an instance of ServiceNow for IT operations and as a message in Jira or Slack for DevOps teams.

    Peete said the goal is to enable organizations to develop a more consistent approach to incident management. A recent survey of more than 1,000 IT professionals conducted by xMatters and Atlassian found that while 81 percent of developers and operation teams share information and tools, only 17 percent provide open access to information without time restrictions. The survey also found that 50 percent of respondents said the tools, processes and steps they employ vary from incident to incident.

    Most of those organizations have very little in the way tools that enable them to effectively conduct a post-mortem analysis of those incidents, added Peete.

    The arrival of the xMatters Flow Designer tool comes at a time when organizations are trying to find ways to meld the highly structured ITIL processes that most IT organizations rely on today and the inherently more agile approaches based on best DevOps practices. The most recent iteration of the ITIL framework incorporates some DevOps principles, but it’s apparent the two approaches to managing IT will be employed side by side in many organizations for many years to come. Developers these days tend to prefer DevOps methodologies, while IT administrators tend to appreciate the consistency of an ITIL framework that was designed to address IT governance concerns. By providing a set of workflow tools that span both those approaches, Peete said IT organizations can more easily meld those two approaches on their own terms.

    At the same time, an extensible approach to incident management makes it possible for IT organizations to incorporate new tools into those workflows as their IT environment evolves. That capability also should make it easier to integrate incident management workflows across multiple organizations as well as incorporate a new IT environment as a result of acquiring another company.

    Regardless of the path chosen, it’s clear that as organizations increasingly realize how dependent their business processes are on software in the age of digital business transformation, the more likely it is they will embrace DevOps practices. However, that doesn’t mean organizations need to abandon ITIL; there are plenty of IT processes that benefit from a highly structured approach. In fact, arguably the most important thing is to not let a philosophical debate over the merits of DevOps versus ITIL wind up becoming a major distraction that creates two isolated cultures who refuse to collaborate with one another.

    — Mike Vizard

  • Google Revamps Hybrid Cloud Strategy

    Google Revamps Hybrid Cloud Strategy

    At the Google Cloud Next 2019 conference, Google announced it will make available cloud services based on Kubernetes under the brand name Anthos on its own cloud and on-premises platforms, as well as on third-party cloud services. such as Amazon Web Services (AWS) and Microsoft Azure. Google also announced a tool dubbed Anthos Migrate that enables any virtual machine to be encapsulated in a container that then can be migrated on to Anthos Migrate. More than 30 vendor partners, including Cisco Systems, Hewlett-Packard Enterprise (HPE), Lenovo, Dell EMC, VMware and Intel, announced their support for the latest expansion of the Google hybrid cloud strategy.

    Google also is now making available in beta a runtime for the Apigee API management platform that can be used anywhere. Dubbed Apigee hybrid, Google acquired the API management platform in 2016.

    In addition, Google is making available a managed set of database services in collaboration with Confluent, MongoDB, Elastic, Neo4j, Redis Labs, InfluxData and DataStax.

    The company also announced Cloud Run, a managed serverless computing offering based on the Knative middleware Google developed to make it possible for applications running on Kubernetes clusters to dynamically invoke a serverless computing framework. Google also announced it is updating its App Engine serverless computing framework to add support for Node.js 10, Go 1.11 and PHP 7.2 runtime in general availability and Ruby 2.5 and Java 11 runtimes in alpha.

    Finally, Google updated both its functions programming framework and virtual private connection (VPC) software used to create virtual private networks, while also revealing it has added regions in Salt Lake City and Seoul, South Korea. In all, there are now 22 GCP regions.

    Like other cloud service providers, Google continues to invest heavily in managed services through which it essentially functions as the IT operations team for application developers. In the case of the databases Google is making available as a managed service, those offerings are distinguished by the fact that they are being delivered in collaboration with the companies that oversee the open source projects that maintain and update those databases.

    DevOps teams will, of course, need to determine to what degree they want to deploy and manage open source databases in the cloud versus relying on Google and its partners. Mavinder Singh, head of infrastructure partnerships for Google Cloud, predicted the long-term trend will be to rely more on databases delivered as a service to allow organizations to focus more resources on developing applications.

    The challenge DevOps teams increasingly face is that next phase of cloud computing is considerably more complex than the previous phase. In the first phase of cloud computing most organizations replaced an on-premises IT environment based on virtual machines from VMware with virtual machines made available of cloud infrastructure. The second phase is more complex in that monolithic applications are now being eclipsed by so-called cloud-native applications based on instances of Kubernetes clusters running on top of virtual machines that are augmented by serverless computing frameworks. Most IT organizations don’t yet have the skills required to deploy, manage and secure those cloud services on their own. In time, however, as it becomes easier to automate the provisioning of the platforms required to run cloud-native applications, many IT organizations may prefer to rely on their own internal DevOps team versus contracting for a managed service, especially if those managed services don’t conform easily to the DevOps processes those organizations have adopted.

    It may take a while for organizations to determine which path forward ultimately suits them best. But the one thing that is clear is that cloud service providers are investing heavily in providing managed services direct to developers to add value on top of what have rapidly become commodity IT infrastructure services.

    — Mike Vizard

  • TypeFox Ties Cloud-Based IDE to GitHub

    TypeFox Ties Cloud-Based IDE to GitHub

    TypeFox has launched a GitPod.io service that melds the integrated development environment (IDE) based in the cloud from TypeFox with the open source GitHub repository.

    Sven Efftinge, co-founder of TypeFox, said this level of integration will make it easier for developers to navigate multiple projects from which they pull code from GitHub into an Eclipse-based IDE.

    In addition, when developers open a Gitpod.io workspace, they will find that any build involving an update to an artifact housed in GitHub will have been automatically completed, said Efftinge. That will reduce substantially the amount of time developers spend waiting for build to finish, he noted.

    TypeFox collaborated with Google, Ericsson, Arm and Red Hat to develop the open source Eclipse Theia project, which provides a foundation for building IDEs in the cloud using TypeScript, CSS and HTML for a desktop-like user experience. At the highest level, Theia consists of a front end running in a browser or in the local desktop application and a back end running on any host or locally within the desktop application. Both the front end and back end communicate through JSON RPC over WebSockets. TypeFox then leveraged that project to build its own cloud-based IDE.

    Gitpod.io further advances the collaboration capabilities that are inherent of cloud-based IDE by adding the ability to capture and share snapshots of the development environment.

    Efftinge said following initial support for GitLab, the next effort will be focused on integrating Gitpod.io with the GitLab repository, which is used widely in traditional enterprise IT organizations.

    Regardless of the repository employed, more attention needs to be paid to reducing the daily friction developers encounter when developing applications. While best DevOps practices go a long way to accelerating application development and deployment, there a lot of wasted steps during the development process that, if eliminated, would increase developer productivity substantially. Of course, the more productive developers become, the more applications there are moving through the continuous integration/continuous development (CI/CD) pipeline.

    It’s still a bit unclear to what degree application development will move to the cloud. It’s certainly easier to streamline development process in the cloud. But many developers remain attached to individual workstations because they may not always be in a location that has reliable access to the internet. However, as application development—especially in the age of microservices—becomes more of a team sport, it’s clear that more application development is being pushed into the cloud. Pushing application development into the cloud also provides the benefit of reducing the number of high-end PCs and workstations an organization may need to acquire for its developers.

    Whatever the path chosen, it’s clear repositories such as GitHub and GitLab are now at the center of application development. Very few developers these days are writing raw code. Most of them are combining artifacts stored in repository to build their applications. The challenge organizations now face is bringing some consistency to what otherwise could easily become a chaotic process.

    — Mike Vizard

  • Gremlin Brings Chaos Monkey Testing to Spinnaker CD Platform

    Gremlin Brings Chaos Monkey Testing to Spinnaker CD Platform

    Gremlin this week announced it will integrate its hosted chaos engineering service with continuous delivery platforms starting with the open source Spinnaker project developed by Netflix.

    Chaos engineering traces its roots to a resiliency testing philosophy that posits applications should be able to keep functioning regardless of any service or infrastructure failure. Most IT organizations, however, don’t have the expertise required to build the tools required to testing resiliency based on those “chaos monkey” principles that randomly turn services off to see if an application fails.

    Matt Jacobs, principal software engineer for Gremlin, said the decision to integrate with Spinnaker is being driven by the need to infuse chaos monkey resiliency testing directly into the application development and deployment pipeline at a more granular level. That capability is now a bigger requirement than ever because as organizations embrace microservices to build the next generation of cloud-native applications, it’s simply not possible for DevOps teams to manually track every dependency, he said, adding resiliency testing based on chaos monkey principles is just another type of testing that should be automated as part of a larger continuous integration/continuous delivery (CI/CD) platform to ensure an application doesn’t fail completely.

    Integrating with a Spinnaker project that has drawn support from Google, Microsoft and Oracle provides the easiest path to achieving that goal. Spinnaker is also now a core element of a Continuous Delivery Foundation led by Alibaba, Anchore, Armory, Autodesk, Capital One, CircleCI, CloudBees, DeployHub, GitLab, Google, Huawei, JFrog, Netflix, Puppet, Red Hat, SAP and Snyk.

    The Gremlin service is accessed via a user interface and comes in two forms: a free edition and an enterprise edition, which comes with support from Gremlin. While the concept of chaos monkey testing has been around for some time among the most advanced DevOps practitioners, enterprise IT organizations, which tend to be more conservative when it comes to introducing anything that might deliberately break their applications, will need a considerable amount of hand-holding. Gremlin is designed to learn the application environment in a way that introduces chaos in a controlled fashion before an application is deployed in a production environment.

    On the positive side, resiliency testing based on chaos monkey principles tend to accelerate the rate at which IT staff learn how an application has been architected, said Jacobs. That can prove especially invaluable when training new members of a DevOps team, he noted.

    Ultimately, the decision to embrace resiliency testing comes down to how proactive an organization wants to be when it comes to preventing downtime. When mission-critical applications are offline, there is a direct impact on the amount of revenue an organization generates. There are plenty of functional and performance testing tools, but the real difference between having an issue and a catastrophic event that requires DevOps teams to get out of bed in the middle of the night often comes down to how truly resilient any given mission-critical application really is.

    — Mike Vizard

  • Sauce Labs Combines Functional and Performance Testing

    Sauce Labs Combines Functional and Performance Testing

    Sauce Labs announced it is now moving beyond functional testing, adding a front-end testing tool it has dubbed Sauce Performance to make it easier to accelerate testing within the context of a DevOps process.

    Lubos Parobek, vice president of products for Sauce Labs, said the goal is to enable developers or testers to begin testing both how well application functions work and perform much earlier in the DevOps process using the same testing tool.

    Parobek said that as organizations embrace modern application development architectures based on microservices, it’s become crucial to test the capabilities of any module within an application because the number of interdependencies between modules continues to increase. That approach accelerates the rate at which applications can be developed. However, any flaw that impacts how the application works or performs can have a debilitating impact on any number of microservices that make up the application, he noted.

    Sauce Performance makes use of debugging and performance trace logs to identify the root cause of an issue in addition to capturing metrics such as Time to First Meaningful Paint, Time to First Interactive, Page Weight and Speed Index. Sauce Performance also employs algorithms to automatically establish a baseline that can be used for regression testing.

    Parobek said Sauce Performance serves to streamline testing processes as well. Most existing front-end performance testing solutions require integration with a load/stress testing tool or a separate application performance monitoring (APM) tool. However, Sauce Performance allows developers to use their existing Selenium test scripts to capture both functional and performance test data.

    In addition, Sauce Performance has been designed to integrate with multiple continuous integration/continuous deployment (CI/CD) platforms to make it possible to feed test results directly back to developers, which can then decide to prioritize issues that need to be addressed.

    Sauce Performance is available as part of the Sauce Labs Continuous Testing Cloud.

    Parobek said organizations want to be able to make it easier for developers to test their own code as part of their DevOps best practices. That doesn’t eliminate the need for dedicated testers for evaluating functions, but potential performance issues today are being addressed often long before applications are deployed in a production environment.

    One of the reasons applications are not as thoroughly tested as they might be is that many organizations require developers to learn how to use tools that have different user interfaces and then switch between testing tools. The result is a complex testing process that makes it more tempting to short-shrift elements of the testing process as application delivery deadlines loom.

    More challenging still, many organizations still don’t continuously test applications after they are deployed to ensure new functionality does not adversely impact the user experience.

    For as long as applications have been built, tension has existed between the developers who create applications and the people who test them. That debate may never be resolved, but everyone agrees in this age of DevOps that it’s better to test early and often.

    — Mike Vizard

  • VMware Doubles Down on IT Automation

    VMware Doubles Down on IT Automation

    VMware this week moved to inject application and operating system monitoring capabilities into the VMware vRealize cloud management platform to make it easier to employ dashboards to map the relationships between applications and the underlying IT infrastructure they run on.

    In addition, VMware enhanced its capacity optimization tools to enable IT teams to run “what if” scenarios based on the amount of IT infrastructure available both on-premises and in the cloud. The company also embedded integrated compliance and automated drift remediation capabilities into VMware vSphere.

    Finally, VMware added support for VMware NSX Data Center network virtualization software to the VMware vRealize Automation platform, and instances of Kubernetes clusters can now be seen by VMware vRealize Network Insight tools.

    Taruna Gandhi, director of product marketing for the VMware Cloud Management business unit, said these efforts are part of a continuing initiative to drive intent-based computing that leverages automation across a software-defined data center (SDDC).

    VMware views application and operating system monitoring capabilities as being critical tools for making informed decisions about those intents, said Gandhi. However, these tools are not intended to replace the need for classes of management technologies such as application performance management (APM) platforms, she said. Instead, VMware envisions using dashboards to more efficiently troubleshoot issues based on metrics gathered by Telegraf agents embedded in VMware vRealize. In effect, IT teams will be able to identify anomalies faster versus wasting time in “war rooms” trying to prove the innocence of any element of an IT stack.

    VMware is pursuing a dual strategy where DevOps and automation are concerned. The VMware vRealize framework can be invoked either through application programming interfaces (APIs) or a graphical user interface (GUI), which tends to appeal more to traditional VMware administrators who don’t have extensive programming skills but still need to respond to rapidly changing IT operation environments.

    Thanks to automation, operational costs are falling considerably, according to VMware. A report from Forrester Consulting commissioned by VMware found organizations that have adopted vRealize have seen a 30% productivity improvement and a 93% reduction in unplanned work. That same report also noted that, thanks to capacity optimization, VMware customers have also seen a 20% reduction in hardware cost savings, a 10% reduction in storage costs, and a 50% reduction in database software licensing costs.

    In most cases, VMware is employing machine learning algorithms to automate IT operations whenever possible within its cloud management suite. But Gandhi said VMware is hesitant to embrace the term “AIOps” until it becomes clearer how employing machine learning algorithms represents a new class of IT management tools rather than an ongoing set of enhancements to existing management frameworks.

    Whatever the outcome, it’s apparent that algorithms are here to stay. How much they will be employed to advance adoption of best DevOps practices across the enterprise, however, remains to be seen.

    — Mike Vizard

  • Pivotal Software Previews Automation Framework

    Pivotal Software Previews Automation Framework

    At the North America Cloud Foundry Summit 2019 conference, Pivotal Software announced it is beta testing an automation framework that promises to keep its distribution of the platform-as-a-service (PaaS) environment continuously updated.

    In addition, Pivotal revealed it will be adding support for open source technologies including Envoy load balancing and Istio service mesh software developed outside the auspices of the Cloud Foundry Foundation (CFF) to its Pivotal Cloud Foundry (PCF) distribution. Envoy and Istio are being employed to add a new routing tier to tier to PCF to give developers more control over network traffic.

    Richard Seroter, vice president of product for Pivotal, said Platform Automation for PCF consists of a series of building block modules that will be applied to all the components of PCF as well as eventually the distribution of Kubernetes that Pivotal curates in collaboration with sister company VMware.

    Pivotal also announced that Pivotal Application Service (PAS), the runtime for PCF, will soon support Windows Server 2019 along with the ability to configure multiple custom ports per PAS container to make deploying containerized applications in a PaaS environment more efficient from a networking perspective.

    Finally, Pivotal is adding more descriptive metadata to the application programming interfaces (API) it exposes across the PAS runtime.

    Seroter said Pivotal continues to focus on automating as much of the IT operations pipeline as possible. Rather than allocating IT staff to create and manage these pipelines, Pivotal is making a case for relying on a set of managed services that span instances of Cloud Foundry and Kubernetes running on top of virtual machines deployed on either a public cloud or on-premises. That approach relies on a highly opinionated operational pipeline defined by Pivotal that IT organizations will need to adopt to benefit from a highly consistent and repeatable approach to managing IT operations at scale, he said.

    The need for a more structured approach to managing IT operations is only becoming more acute as organizations embrace Kubernetes platforms alongside Kubernetes, Seroter added. In fact, a survey of 501 IT leaders published by the CFF finds almost half of respondents (48%) report using some combination of PaaS, containers and serverless technologies together.

    It’s still unclear how much IT organizations will standardize on a particular application development platform. PaaS environments typically have a more robust set of application development tools, but they can consume tens of virtual machines to stand up. Development tools for Kubernetes platforms are still evolving, but the platform provides a more efficient way to consume both virtual machines and bare-metal servers. It is apparent that for some time to come that many IT organizations will find themselves managing multiple platforms. The challenge that creates for DevOps teams is finding a way to manage those platforms consistently using a common framework rather than having to deploy and master separate management. It may take quite a while for IT leaders to rationalize their management platforms, but with each passing day it becomes clearer that goal increasingly is within reach.

    — Mike Vizard

  • Chef Commits to 100 Percent Open Source Code

    Chef Commits to 100 Percent Open Source Code

    Chef has decided to open source its entire portfolio of IT automation software as part of an effort to make it easier for organizations to construct a DevOps pipeline using the company’s software.

    A part of that effort, Chef also launched the Chef Enterprise Automation Stack—which combines Chef Infra for managing infrastructure, Chef InSpec for maintaining compliance, Chef Habitat for managing applications, Chef Automate for managing hybrid clouds and Chef Workstation, a starter kit for launching Chef—within a single distribution of Chef software. Chef Infra is the original Chef project around which the company was launched.

    Corey Scobie, senior vice president of product and engineering for Chef, said the company previously offered a mix of open source and proprietary software that made engaging with some customers overly complex from a licensing perspective. This approach aligns the entire Chef business model around providing support for open source software, he said.

    At the same time, Chef is now open to collaborating more closely with developers who want to contribute code to its various projects. That’s critical because code contributions are now the primary means through which many IT organizations help shape the direction of products as they continue to evolve, Scobie noted.

    Of course, many IT organizations today either mandate the use of open source software or have instituted an “open source first” policy that makes it challenging for any proprietary software to be adopted.

    Chef expects that by making its software easier to consume via a unified open source transition it will be able to further accelerate adoption of what is described as a “Coded Enterprise” to managing IT. Rather than manually configuring IT assets in isolation, that approach encourages organizations to adopt best DevOps practices that treat all aspects of IT, including infrastructure, as code, said Scobie, adding that capability is more important than ever as IT organizations are increasingly require to manage heterogenous cloud computing environments.

    Chef claims that approach has already resulted in more than half of the Fortune 500 having adopted at least one module of its software and, in the fourth quarter of 2018, the highest level of bookings in the company’s history.

    While Chef helped pioneer the IT automation category, competition across this sector has intensified. Chef and its primary rivals Puppet and Red Hat are the leading proponents of frameworks for automating IT operations. Although adoption of those frameworks has increased substantially in recent years, use within IT organizations often remains fragmented, often resulting in islands of automation. Chef is clearly hoping that IT organizations will increase adoption of its software stack now that it’s  based entirely on open source software. Many organizations face challenges teaching their IT operations teams enough programming skills to automate their processes. In absence of those skills, adoption of IT automation frameworks within the context of a set of well-defined DevOps best practices often remains uneven, at best.

    — Mike Vizard