devopsy.kinsta.cloud

Category: News

  • OverOps Integrates AI Code Analyzer With CI/CD Platforms

    OverOps Integrates AI Code Analyzer With CI/CD Platforms

    At the DevOps World | Jenkins World 2019 conference, OverOps announced it has integrated its namesake tools for analyzing Java and Microsoft .NET code at runtime with a variety of continuous integration/continuous deployment (CI/CD) platforms, including Jenkins, JetBrains TeamCity, Atlassian Bamboo and Pivotal Concourse.

    Eric Mizell, vice president of solution engineering for OverOps, noted that the more errors that are discovered by DevOps teams early in the development cycle, the less technical debt organizations must address after an application is deployed in a production environment. By pushing testing to further to the left of the application development process, the less troubleshooting will be required later on, he said.

    OverOps employs predictive analytics and machine learning algorithms to identify new, increasing, resurfaced and critical errors in a release. It then generates a code quality report that ranks all severe issues likely to impact end users and application functions. By integrating OverOps within the CI/CD pipeline, DevOps teams can use those reports to determine whether code is safe to promote or automatically block unstable releases from moving forward.

    In addition, because the machine learning algorithms surface the true root cause of an issue, DevOps teams can more efficiently remediate issues by routing code back to the development team responsible for all the issues that are being created downstream.

    Making testing an integral part of the CI/CD process not only tightens the relationship between developers and testers, but also in many cases enables developers to test their own code before submitting it for review.

    Mizell said the need to shift testing to the left has become more critical as customer tolerance for application errors is low, especially in use cases involving mobile applications—consumers are especially unlikely to give a mobile application a second chance after they’ve encountered an issue.

    In an ideal world, of course, testing tools that make use of machine learning algorithms would be employed to coach developers in a way that enables them to develop reliable code more consistently and faster. However, some organizations will use tools that leverage machine learning algorithms to identify developers who are not meeting expectations. That weeding out process is likely to begin much earlier in the application development life cycle as more advanced testing tools are embedded within CI/CD environments. Those tools won’t eliminate the need for developers and testers, but they do promise to increase dramatically the rate at which quality applications can be built and deployed at an industrial scale. Technical debt may never be completely eliminated, but at the very least the rate at which that technical debt is being accumulated should substantially decline.

    It may be a while longer before machine learning algorithms and other forms of artificial intelligence (AI) are employed pervasively across DevOps processes. In most cases, those algorithms will help developers write better code faster. However, it’s also apparent there will be other algorithms at work that one way or another ensure developers will have fewer opportunities to make mistakes in the first place.

    — Mike Vizard

  • GitHub Actions Advances Automation Strategy

    GitHub Actions Advances Automation Strategy

    GitHub Actions, a set of application programming interfaces (APIs) through which DevOps tools can automate workflows, is now available in beta.

    Previewed last year at the GitHub Universe event, GitHub Actions is intended to provide not only a way to automate responses to events occurring within a GitHub Repository but also share those workflows across multiple DevOps teams, said Max Schoening, senior director of product design for GitHub.

    Actions are based on YAML files, which makes it possible to write them in JavaScript or other programming languages or package them up as a set of containers. In either instance, they are designed to interact with the full GitHub API and any other public API.

    In addition, higher levels of automation enabled by GitHub Actions should make it more feasible for DevOps teams to test multiple versions of a project in parallel as workflows written in code replace manual processes, said Schoening.

    As more manual processes become automated, the number of IT teams who are intimidated by DevOps processes today should begin to decline. Organizations also should be able to apply best DevOps practices more consistently across multiple teams. Too often today the DevOps practices within the same organization tend to vary widely. Schoening also noted that given the open source history of GitHub, organizations will be able to see how workflows have been created for popular open source projects and then copy them.

    In addition, Schoening said the arm of Microsoft will continue to invest in analytics that will surface workflow recommendations that can be applied to any project regardless of the language employed or the platform on which it’s destined to be deployed.

    On one level, DevOps is all about a ruthless commitment to automation. But when automation goes wrong at scale, it can be extremely problematic. Rather than relying on “black box” approaches to automating processes, a truly open source approach to automation makes it possible for DevOps teams to see how a process is being automated and then extend it if they so choose, said Schoening. To help address the concern, GitHub Actions also provides access to live logs to provide real-time feedback as builds run, which Schoening said makes it easier for DevOps teams to debug automations created using GitHub Actions.

    It’s too early to say just how automated DevOps processes will get. There’s an emerging school of thought that contends the goal is to make it feasible for developers to spend 100% of their time writing business logic. It’s not clear whether that goal is achievable anytime soon, but progress is made with each update to continuous integration/continuous development (CD/CD) platforms. As complementary advances in machine learning algorithms and other forms of artificial intelligence (AI)—otherwise known as AIOps—occur, it’s apparent many manual DevOps processes will fall by the wayside.

    In the meantime, the workflows that make up any DevOps process should become increasingly sophisticated as advances in automation span everything from hybrid cloud computing environment to internet of things (IoT) deployments. The issue soon may not be how cumbersome any DevOps workflow is, but rather the potential limits of the imagination applied to automating them.

    — Mike Vizard

  • CollabNet VersionOne Advances End-to-End DevOps Strategy

    CollabNet VersionOne Advances End-to-End DevOps Strategy

    At its Agile 2019 conference, CollabNet VersionOne announced it plans to extend the capabilities of its software delivery and management platforms later this month as part of an effort to provide organizations with more visibility into how changing software development project schedules impact the business.

    Company CEO Flint Brenton said updates to the VersionOne value stream enterprise management platform will include a revamped user interface that provides more visibility into events occurring within the Continuum continuous integration (CI) platform.

    Brenton also said those updates will further advance adoption of agile frameworks such as the Scaled Agile Framework (SAFe), a prescriptive approach to combining best agile development and DevOps practices.

    While organizations may opt to employ VersionOne in combination with other CI/CD platforms, Brenton said CollabNet VersionOne provides a more comprehensive understanding of the impact changes to software development schedules will have on the business.

    As part of that effort, CollabNet VersionOne also announced VS Exchange, a marketplace for custom and preconfigured Continuum and VersionOne extensions and workflows, and enhancement to the Continuum TestDrive component within the company’s implementation of Continuum that streamline provisioning.

    With more organizations than ever starting to appreciate how dependent they are on software, Brenton said business leaders are now looking to exercise more control over software development projects. It’s no longer enough to generate more code, he noted; rather, DevOps teams are now being asked to generate more reliable code that has the greatest impact on the business faster. CollabNet VersionOne enables organizations to achieve that goal by providing a management platform in the form of VersionOne that is layered on top of Continuum.

    CollabNet VersionOne is now taking part in a race to infuse more business analytics into a software development lifecycle (SDLC) platform. While SDLC platforms have typically been employed to gather technical metrics, organizations now want to correlate that data against business metrics.

    Less clear right now is whether having access to business metrics will influence the selection of one CI/CD platform over another. Over time, the expectation is that various forms of business intelligence capabilities will be a standard capability of the platform, especially as IT leaders continue to assume larger business responsibilities in the age of digital business processes.

    It may be a while yet before business and IT roles start to converge. In the meantime, CollabNet VersionOne is clearly betting there will be a lot more collaboration between these two camps going forward. In many ways, the DevOps best practices that organizations have adopted to become more agile are about to be extended to the business processes enabled by software. Savvy business leaders will realize their ability to meet financial goals for any given quarter is tied to the timely manner in which new digital customer experiences are enabled. In fact, there may come a day when IT organizations are able to deliver software updates faster than most businesses will be able to consume it.

    — Mike Vizard

  • Twilio Adds DevOps Tool to Invoke Communications Services

    Twilio Adds DevOps Tool to Invoke Communications Services

    At its annual SIGNAL conference, Twilio today launched an initiative intended to make it easier to embed a variety of communication services within an application in the context of a DevOps process.

    Quinton Wall, senior director of developer marketing at Twilio, said the open source Twilio Command Line Interface (CLI) tool, now available in beta, will make it possible to incorporate Twilio cloud services within a larger DevOps toolchain.

    Twilio provides developers will access to a range of SMS, audio and video services that can all be incorporated into applications via application programming interface (API) calls. The pipelines created using those APIs now can be stored and shared via GitHub.

    The CLI tool also makes it possible to extend those services via Plugins, said Wall. In addition, DevOps teams can invoke an existing serverless computing capability from Twilio to invoke the company’s services using functions, added Wall.

    It’s not clear to what degree cloud services such as Twilio will be invoked using serverless computing frameworks going forward. Many of the capabilities that developers once were required to embed in their applications are set to become external services that applications call when needed by launching a function. While that approach makes the application more efficient, it puts additional pressure on IT teams to manage all the calls to various serverless computing frameworks within the context of already complicated DevOps pipeline.

    While serverless computing frameworks are still an emerging IT platform, the rate at which serverless computing frameworks are being adopted suggests the day when they are commonly included with a DevOps toolchain is not very far off.

    In the meantime, Twilio is clearly hoping that by making its communications services easier to invoke within the context of a DevOps toolchain will increase consumption. Twilio has long exposed REST APIs, but the CLI tool will make it easier for organizations to standardize on Twilio communication services across a range of applications. By exposing those services via APIs and a CLI tool, Twilio is betting that the days when end users opened a separate application to communicate are numbered. Instead, most users will invoke communications services within the context of, for example, a business intelligence application that is already open. That approach also eliminates the need to invest in dedicated network hardware to run unified communications applications that, from an API perspective, are often more difficult to invoke programmatically.

    As DevOps processes become more widespread, it will be interesting to see how many other providers of cloud services start to routinely make available CLI tools. Arguably, any provider of a cloud service that doesn’t make a CLI tool available will find themselves on the outside of a DevOps process looking in. Service providers that provide a CLI tool will be preferred among organizations that embrace best DevOps practices. In fact, the challenge DevOps teams soon may face is not whether there is a CLI tool available, but rather determining which of the many available best fits within the DevOps processes they have adopted.

    — Mike Vizard

  • CircleCI Extends CI/CD Reach to Windows Platforms

    CircleCI Extends CI/CD Reach to Windows Platforms

    CircleCI today announced it will make available its continuous integration and continuous deployment (CI/CD) platform available on a variety of Windows platforms.

    Matt Wyman, vice president of product for CircleCI, said the decision to support Windows stems from recent Microsoft DevOps initiatives, most notably its move to acquire GitHub. As Microsoft invests more time and energy promoting best DevOps practices, demand for CI/CD platforms running on-premises or in the Microsoft Azure public cloud will escalate sharply, said Wyman.

    The Windows environment on CircleCI also includes support for Docker Engine – Enterprise for Windows workflows and all Windows jobs run isolated on a virtual machine. Each new job uses an environment that gets created just in time and gets destroyed once the job finishes running. That approach is intended to ensure both build reproducibility and the security of the code, data and secrets stored in a CI environment. All CircleCI features such as caches, Workspaces, approval jobs and Contexts are now being made available for Windows jobs.

    Wyman said CircleCI now expects organizations to extend the same software development lifecycle processes for building and deploying both Windows and Linux-based applications. The ability to leverage the same pipelines within the context of a common CI/CD platform spanning both environments will help narrow the time and effort required today to build Windows applications, he added.

    Currently, it’s unclear whether a common set of processes for building and deploying applications in Windows and Linux environments might foster greater collaboration within IT organizations. Linux and Windows teams don’t tend to interact much. However, as more organizations look to apply repeatable processes that enable them to build more reliable software faster, the need to standardize DevOps processes has become apparent. Of course, Circle CI isn’t the only provider of a CI/CD platform looking to take advantage of that emerging hybrid cloud computing opportunity.

    It’s also worth noting that providers of platforms such as Microsoft and Red Hat are also promoting their own approaches to software development lifecycle management. Organizations need to decide how much they want to rely on the tools and processes made available by platform vendors instead of a CI/CD platform that integrates DevOps processes across multiple platforms. To fight that battle, CircleCI last month revealed it has raised another $53 million in funding. At that time, the company noted that the total monthly job count on its platform stood at 30 million, up from 7 million in January 2018.

    Regardless of the path chosen forward, organizations increasingly need to build and deploy software on multiple platforms. The challenges associated with managing those processes are nothing less than considerable. The issue IT leaders will need to determine first is how much they want to drive unification of software development from the top down versus simply providing a common set of tools and platforms that their teams will (hopefully) gravitate toward.

    — Mike Vizard

  • Armory Looks to Drive Enterprise Adoption of Spinnaker

    Armory Looks to Drive Enterprise Adoption of Spinnaker

    Armory this week committed to advancing adoption of the open source Spinnaker continuous delivery (CD) platform in enterprise IT environments after revealing it has raised an additional $28 million in funding.

    Company CEO Daniel Odio said Armory will add proprietary tools to a curated distribution of Spinnaker that will make it easier for the average IT organization to deploy and manage Spinnaker. Developed by Netflix, Spinnaker is gaining traction as a CD platform in the wake of becoming one of the four projects being managed under the auspices of the Cloud Delivery Foundation (CDF), an arm of the Linux Foundation.

    Spinnaker is designed to be a CD platform that includes all the management tools required to manage that process. While continuous integration/continuous deployment (CI/CD) platforms such as Jenkins have addressed aspects of CD, most of the daily usage of those platforms has been squarely focused on continuous integration. As part of an effort to meld CI/CD platforms and Spinnaker, the CDF has accepted both Spinnaker and Jenkins as part of the first four projects that will be developed under its auspices. The other two are Jenkins X, a CI/CD platform specifically designed for building microservices-based applications on top of Kubernetes, and Tekton, a set of pipelines also designed specifically for Kubernetes.

    Odio said there are already more than 500 organizations using Spinnaker, and each one is not standardized on a specific CI/CD platform. Armory is part of the CDF but also sees a need for a curated instance of Spinnaker that is optimized to meet the needs of enterprise IT environments, he said.

    In general, Odio said a “flywheel effect” manifests once an organization launches roughly its eighth project using Spinnaker. From that point on, adoption of Spinnaker starts to accelerate to the point where an organization sees the need to standardize on a single curated instance of Spinnaker, he said.

    The bigger issue as far as adoption of Spinnaker and other DevOps tools remains cultural, Odio added. Many organizations still don’t accept the fact that CI/CD platforms are intended to foster a level of accelerated development that makes it more feasible to experiment and innovate. There are, of course, inherent risks to that approach in the sense that many of those projects might fail. Many enterprise IT organizations are still coming to terms with the need to accept higher levels of failure as the price of learning, he noted.

    In the meantime, many organizations that have embraced DevOps now find themselves on the cusp of a major transition as the shift toward cloud-native applications increases. Most CI/CD platforms today were designed to accelerate development of monolithic applications. Now what’s needed is a new generation of CI/CD platforms that are designed to accelerate development of microservices-based applications based on containers. As a result, many organizations will end up employing multiple CI/CD platforms. Armory is betting many of them will try to delineate where CI leaves off and CD begins.

    — Mike Vizard

  • Morpheus Data Simplifies Management of Ansible and Kubernetes

    Morpheus Data Simplifies Management of Ansible and Kubernetes

    Morpheus Data is moving to make it easier to adopt and manage both Ansible and Kubernetes. Its Morpheus 4.0 update, announced today, includes a distribution of Kubernetes as well as tighter integration with the open source Ansible automation framework.

    Brad Parks, vice president of marketing and business development for Morpheus Data, said in the case of Ansible, Morpheus 4.0 will eliminate the need for some organizations to employ Ansible Tower, a web-based console and application programming interface (API) used to manage instances of Ansible. The goal is to make it easier for organizations to take advantage of the declarative Ansible automation framework without having to master all the low-level minutiae currently required to deploy and manage it, he said.

    Morpheus 4.0 also makes it possible to view real-time job status updates and detailed log output and execute phased-based and operational workflows using multiple playbooks and brings governance, auditing and reporting tools to Ansible. Morpheus 4.0 also makes it possible to configure Ansible to run over the Morpheus secure agent communication bus, allowing playbooks to be applied to instances where SSH/WinRM access may not be feasible due to security constraints. Available on both Linux and Windows platforms, Ansible also can employ that bus to query secrets securely from the Morpheus Cypher service for storing application secrets.

    In a similar vein, Morpheus Data is also moving to automate the deployment and management of Kubernetes, an open source container orchestration engine developed under the auspices of the Cloud Native Computing Foundation (CNCF).

    By including a distribution of Kubernetes in Morpheus 4.0 that has been certified by the CNCF, Parks said Morpheus Data now makes it possible to federate the management of Kubernetes clusters across a hybrid cloud computing environment. DevOps teams can employ either the distribution of Kubernetes provided by Morpheus Data or Morpheus to provision instances of Kubernetes services provided by public cloud service providers such as Amazon Web Services (AWS), Microsoft and Google.

    Morpheus 4.0 also makes it possible to securely share and govern resources using role-based access controls, optimize resource allocation using analytic tools and audit, monitor and manage logging. DevOps teams also have the choice of provisioning applications using either Morpheus or the Helm templates made available by the CNCF.

    As Kubernetes moves into the enterprise, Parks said IT organizations will need a management framework that can automate the provisioning of application stacks on any combination of legacy virtual machines, Kubernetes clusters and bare-metal servers. Rather than be required to acquire and master separate tools for each platform, Morpheus 4.0 provides a management platform that allows a single DevOps team to manage multiple platforms more easily, he said. As an enterprisewide orchestration and automation platform, Morpheus is designed from the ground up to eliminate the need for DevOps teams to create complex playbooks by providing out-of-the-box integration with wide a variety of IT platforms, Parks added, noting Morpheus 4.0 also now includes Morpheus Jobs, a tool through which jobs can be scheduled or run ad-hoc using Bash, PowerShell, HTTP, Ansible, Chef, Puppet, Groovy, Python, jRuby or JavaScript.

    The number of organizations attempting to unify the management of multiple platforms is expected to increase significantly in the months and years ahead as the number of cloud platforms being employed increases. The challenge those organizations will face involves not only what tools to employ to achieve that goal, but also defining the DevOps processes capable of spanning a hybrid cloud computing environment.

    — Mike Vizard

  • Micro Focus Lays DevOps Foundation for RPA

    Micro Focus Lays DevOps Foundation for RPA

    Micro Focus has announced the general availability of Micro Focus Robotic Process Automation (RPA), which sets the stage for employing DevOps processes to construct highly automated business processes.

    Thanks to the rise of artificial intelligence (AI) and digital business transformation initiatives, interest in RPA has increased significantly. However, rather than merely using RPA to build bots to automate a narrow set of static processes, RPA is now leveraging machine and deep learning algorithms to optimize a wider range of dynamic business processes and adjust more easily to changes within an application.

    Travis Greene, senior director for IT operations management ay Micro Focus, said new capabilities such as object recognition technology included within Micro Focus RPA enables the platform to detect and automatically adapt to changes to the user interface.

    Other new capabilities now include the ability to visually or programmatically create workflows using a tool that records screen actions, the ability to more easily combine graphical and programmatic workflows spanning multiple platforms and the ability to deploy hundreds of thousands of bots as needed. A centralized dashboard manages the bots, all of which have unique IDs and encrypted, role-based credentials.

    As RPA and other forms of AI continue to be integrated and embedded with applications, Greene said it’s a matter of time before DevOps practices are extended to RPA platforms. Organizations will seek to train bots continuously as more data is made available, which in turn will drive updates to applications that are dependent on those bots. In most cases, depending on the complexity of the task, the bots will be built using a mixture of application programming interfaces (APIs), command-line interfaces (CLIs) and graphical tools. Organizations will need to define the processes to determine how and when each organization will opt to invoke one interface instead of another, either in isolation or combination, added Greene.

    Historically, organizations have been able to apply RPA to static processes with mixed success. With the rise of AI, the scope of those efforts has become more ambitious. Business leaders are too inclined to believe that just about every business process can be automated using a combination of AI and RPA. However, AI and RPA still are confined to relatively narrow use cases involving highly predictable outcomes.

    That’s changing, however, and RPA and AI are becoming more pervasive across the enterprise. DevOps teams will need to find ways to update both their applications and RPA/AI models without breaking one or the other. Most of the current RPA/AI models are highly sensitive to any change made to the application environment they are monitoring. And, unfortunately, the data scientists who are largely responsible for constructing those RPA/AI models don’t yet tend to have much of an appreciation for best DevOps processes. There will, however, come a day soon when these two worlds will collide.

    — Mike Vizard

  • WSO2 Advances Microservices Gateway

    WSO2 Advances Microservices Gateway

    At the Open Source and Software Development Conference (OSCON), WSO2 this week announced it has updated an open source microservices gateway to make it possible to expose multiple microservices through a single application programming interface (API).

    Additionally, version 3.0 of the WSO2 API Microgateway now includes the ability to automatically discover microservices and transform legacy API requests into a more modern format. WSO2 also added support for the OpenAPI Specification (OAS), formerly known as Swagger, to make it easier for developers to collaborate on creating APIs, and has separated the WSO2 API Microgateway toolkit from the runtime to enable greater scalability and smoother upgrades.

    Ken Oestreich, vice president of product marketing for WSO2, said the WSO2 API Microgateway is designed to accelerate the convergence of application development and integration into a single team. As part of that effort, WSO2 has been advocating the adoption of Ballerina, a general-purpose programming language designed from the ground up to make it easier for developers to integrate distributed applications on their own. For example, Ballerina makes it possible for developers to create and embed their own micro-enterprise service bus (ESB) within a distributed application, he said.

    Those integration engines then could be deployed and updated within any DevOps processes layered on top of a continuous integration/continuous deployment (CI/CD), Oestreich added.

    A WSO2 API Microgateway is designed to boot up in less than a second and provides authentication, authorization, rate limiting, service composition, discovery, transformation and analytics capabilities. It is designed to be integrated with the WSO2 API Manager, an open source API management platform that can run on-premises or in the cloud.

    As the number of microservices being created within organizations increases thanks to the rise of containers, Oestreich noted there is now a critical need for organizations to find a lightweight approach to building and managing all the APIs required to connect thousands of microservices. WSO2 provides a flow diagram through which organizations can visually manage that process, said Oestreich. As part of its support for containers, the WS02 API Gateway provides built-in support for container orchestration tools such as Kubernetes, which makes it possible to generate artifacts that can be applied directly to Kubernetes clusters.

    Organizations of all sizes are clearly struggling these days with API management. In theory, APIs should remain stable as the software components they connect to are updated. The trouble is, each new microservice generates its own set of APIs, and before too long, organizations find themselves trying to manage thousands of APIs that are all dependent on each other. The removal of any one API might not crash an application, but it could adversely impact performance as API calls are re-routed around the application.

    It’s not all clear these days who inside most organizations is responsible for managing APIs. Developers certainly create the APIs. However, once they are deployed in a production environment, their care and feeding often pass over to an IT operations team. Regardless of whom, however, once any of those APIs break it’s not long before the entire DevOps team knows about it. The challenge now is figuring out how to make the management of all those APIs as natural an extension of a DevOps process as possible.

    — Mike Vizard

  • Chef Brings DevOps to Windows Platform Migrations

    Chef Brings DevOps to Windows Platform Migrations

    Chef and Microsoft revealed today that they are working together to apply DevOps processes to accelerate the migration of Windows Server 2008 and SQL Server 2008 to more current versions.

    Announced at the Microsoft Inspire conference, the goal is to enable organizations to leverage Chef Enterprise Automation Stack (EAS), which includes an EAS Migration Accelerator for Windows that will scan existing .NET applications running on legacy Microsoft platforms to discover configuration and dependency details, then encapsulate that information as code in a way that enables the application to run on the latest version of a Microsoft virtual machine or as a container.

    Ewan Dalton, partner development manager for Microsoft, said there are roughly a half-million .NET applications running on platforms that are scheduled for end-of-life support beginning in January. In an ideal world, most of those applications would be modernized to be deployed on the Microsoft Azure cloud, said Dalton.

    Vikram Ghosh, vice president of business development at Chef, said rather than merely lifting and shifting legacy applications onto a new platform, Chef EAS will make it possible to employ DevOps processes to modernize how those applications are updated and maintained. Chef EAS makes it possible to, for example, scan, extract and package legacy applications and their dependencies, using source control repositories such as GitHub, and convert them into cloud platforms using pipelines such as Azure DevOps. Customers can deploy these application packages in Azure and run continuous security and compliance scans, added Ghosh.

    Chef EAS

    The biggest challenge many organizations face when trying to migrate applications is the developers who created the application haves long since left the company. As such, most organizations only have documentation, which is usually sparse. They then must determine whether it is worth modernizing the application or whether they should simply replace it. In cases where it is deemed that the business logic contained within that legacy application is still critical enough to continue running, they need to find a way to automate that process as much as possible.

    Longer-term, of course, most organizations will work to modernize legacy monolithic applications even further by slicing them up into a series of more manageable microservices. But many organizations are already running out of time when it comes to existing .NET applications. Once Microsoft ends support for the platforms they are running on, patches to address cybersecurity issues no longer will be provided as part of the standard licensing agreement. In effect, that means there is enough time between now and January to re-engineer an application. Chef EAS essentially throws organizations a lifeline to determine what they want to do next in terms of replacing a legacy application, said Ghosh.

    Of course, there will always be some subset of the IT community that will continue to run .NET applications on outdated Microsoft platforms. It’s also unlikely that any of those organizations will be embracing DevOps processes to maintain those platforms anytime soon.

    — Mike Vizard