devopsy.kinsta.cloud

Tag: DevOps workflows

  • CNCF Takes LitmusChaos Platform to the Incubation Level

    CNCF Takes LitmusChaos Platform to the Incubation Level

    The technical oversight committee (TOC) for the Cloud Native Computing Foundation (CNCF) announced today it is elevating the open source LitmusChaos application testing platform to the incubation level.

    LitmusChaos is a chaos engineering platform donated to the CNCF by ChaosNative in 2020. Since then, it has seen adoption within production environments by more than 25 organizations, including Intuit, Lenskart, Orange, Red Hat and VMware.

    ChaosNative CEO Uma Mukkara says LitmusChaos was developed to provide DevOps teams with a chaos engineering platform built using containers that makes it easier to scale up and down than existing monolithic alternatives. The platform itself, however, can be used to test both monolithic and microservices-based applications.

    The platform consists of a Chaos Operator based on a software development kit (SDK); a ChaosHub for hosting and sharing experiments; Litmus Workflows that declaratively chains experiments (either in sequence or parallel) to build a chaos scenario; a centralized control plane, dubbed ChaosCenter, to design, schedule and monitor Litmus Workflows; Litmus Probes for creating chaos scenarios that automate steady-state validation and remediation actions and a Chaos Observability tool to export Prometheus metrics.

    In total, there are now more than 400 contributors to the LitmusChaos project and more than 4,000 pull requests have been made. Mukkara said since the beginning of this year, Litmus operator installations have grown to more than 2,000 per day. Going forward, the goal for 2022 is to significantly increase the number of LitmusChaos integrations there are for a wider range of DevOps platforms, added Mukkara. Additional sets of experiments for Kubernetes and non-Kubernetes targets, improved observability and integration with other platforms—via the open source OpenTelemetry agent software also being advanced by the CNCF—is also planned.

    In general, it’s still early days as far as the adoption of chaos engineering with DevOps workflows is concerned. However, Mukkara said that as more organizations embrace observability to better understand IT processes, the number of organizations that also use chaos engineering to test IT resiliency should also increase. In fact, as IT environments become more complex—thanks mainly to the rise of microservices-based applications—chaos engineering approaches to testing may someday be required, noted Mukkara.

    In the meantime, there are still a lot of IT professionals that are uncomfortable with chaos engineering approaches to testing that deliberately break underlying services to test the resiliency of an application. The core idea, however, is that no application should have a single point of failure that could lead to it becoming unavailable. In theory, a microservices-based application won’t fail because when a service becomes unavailable calls are automatically rerouted to another service. The performance of that application will degrade, but it won’t go offline. The challenge is that building an application that achieves that level of resiliency using microservices requires a significant amount of DevOps expertise.

    Regardless of how an application is constructed, the one thing that is clear is how dependent organizations are on applications to drive revenue. As such, the tolerance for application failures—or performance degradation—has never been lower.

  • Atlassian Embeds Metrics for Measuring DevOps in Jira

    Atlassian Embeds Metrics for Measuring DevOps in Jira

    Atlassian today announced it has added four features to Jira Software Cloud that allow developers to visualize and measure progress across DevOps workflows.

    Suzie Prince, head of product for DevOps at Atlassian, said rather than organizations having to acquire and deploy separate tools to track DevOps metrics, Atlassian is moving to incorporate those capabilities in a platform that is already widely employed to manage application development projects.

    Two capabilities being added to the standard edition of Jira Software Cloud are Code in Jira, which makes it possible to view the most recently active repositories in Bitbucket, GitHub, GitLab or Git Integration for Jira from within Jira Software Cloud, and Deployments in Jira, which makes it possible to similarly view in real-time at what stage any deployment is on any continuous integration/continuous delivery (CI/CD) platform.

    The Premium Edition of Jira Software Cloud is gaining tools to track both deployment frequency and cycle times to provide more insight into how application development teams are maturing in terms of their overall DevOps proficiency.

    These tools eliminate the need for analytics tools that otherwise would be required for each DevOps platform an organization employs, noted Prince. Jira Software Cloud also exposes a REST application programming interface (API) through which DevOps teams can integrate the Atlassian platform with other DevOps tools.

    It will be up to each organization to determine how they may want to employ the insights surfaced within Jira Software Cloud. However, Prince said most IT teams should identify areas of weakness where there is an opportunity to coach DevOps teams on how to improve.

    There is, of course, a lot more focus on improvement as application development projects have accelerated in recent months, thanks mainly to the increased focus on digital business transformation. Organizations of all sizes are trying to maximize investments in application development at a time when the economic downturn brought on by the COVID-19 pandemic is forcing IT teams to make difficult tradeoffs. Metrics, of course, are critical when it comes time to prioritize one project over another.

    At the same time, Prince noted that many teams are trying to keep the number of tools and platforms incorporated into a DevOps toolchain to an absolute minimum to limit costs and minimize complexity. Many DevOps teams have been employing Jira software to manage application development projects for years now, so Prince said these new capabilities are a logical extension of the company’s project management software.

    Of course, the best metrics are the ones that manifest themselves automatically. No project manager relishes having to badger developers to enter data into a project management application. The more the data residing in a DevOps platform can automatically populate a project management application, the happier all involved will be. After all, the goal is to head off as many issues as possible today before they become major problems tomorrow.

  • Opsera Simplifies Building of DevOps Pipelines

    Opsera Simplifies Building of DevOps Pipelines

    Fresh off raising $4.3 million in funding, Opsera today launched a namesake platform that enables IT teams to orchestrate both the tools employed by developers as well as the pipelines that make up a DevOps process.

    Company co-founder Chandra Ranganathan said the Opsera platform automates setup of DevOps pipelines using a declarative approach that doesn’t require DevOps teams to standardize on a specific set of tools.

    Ranganathan said the Opsera platform also acts as a repository for pipelines that can be reused by DevOps teams. To facilitate that effort, Opsera also includes a set of pipelines that DevOps teams can employ immediately, he said.

    Opsera is designed to be a layer of abstraction that can be deployed across multiple continuous integration/continuous delivery (CI/CD) platforms, he said, noting that capability makes it possible for IT teams to reuse pipelines without having to standardize on a specific CI/CD platform.

    Developers, meanwhile, can still choose among any number of third-party tools that have been integrated into the Opsera platform. The goal is to automate what currently is a manual process for setting up DevOps environments, which often can take months, in a few hours using a declarative process, said Ranganathan.

    Once deployed, the Opsera platform also provides access to analytics tools that enable DevOps teams to optimize those workflows, he added.

    While much progress has been made in terms of accelerating application development thanks to the rise of DevOps, the setting up and maintaining of a DevOps platform often requires a dedicated IT operations team in part because each development team wants to continue to use the tools they prefer. However, platforms that automate the DevOps process have thus far required IT organizations to standardize on specific development tools. The Opsera platform reduces the size of the IT staff needed to support DevOps workflows without forcing developers to employ a specific set of tools, Ranganathan said.

    Each development team is also automatically given its own virtual data center environment to ensure isolation between projects, he noted.

    In the wake of the economic downturn brought on by the COVID-10 pandemic, the need to automate IT processes has increased sharply as organizations look to reduce the total cost of IT. DevOps processes are no exception. In fact, DevOps processes by design should lend themselves more to automation than legacy waterfall-based approaches to application development. As DevOps processes become more automated, it also should free additional resources to develop applications faster.

    Regardless of the motivation, automation of DevOps processes will need to become more automated to keep pace with increasingly complex IT environments. Development teams are increasingly being required to build and then regularly update hundreds—sometimes thousands—of microservices. As the tools for building those microservices become more diverse, the DevOps team needs to find a way to embrace tool innovations without requiring a DevOps platform to be entirely reconstructed. Striking that balance requires a level of abstraction that minimizes the impact any change in tooling preferences can have on the underlying CI/CD platforms.

  • CircleCI Looks to Advance DevOps Best Practices Adoption

    CircleCI Looks to Advance DevOps Best Practices Adoption

    CircleCI today launched a developer hub as part of an effort to further advance adoption of DevOps best practices.

    Company CEO Jim Rose said CircleCI developer hub provides access to a set of resources for optimizing continuous integration/continuous delivery (CI/CD) pipelines. In many cases prior to the onslaught of the COVID-19 pandemic, organizations had only partially implemented best DevOps practices, noted Rose. The CircleCI developer hub will make it easier for those DevOps teams to extend the scope of those processes while serving to educate IT teams that have had limited exposure to DevOps workflows, he said.

    The CircleCI developer hub provides access to, among other things, CI/CD configuration optimizations and pre-built packages, migration guides and documentation. There are also reusable snippets of CircleCI configuration code, customized open source Docker images that can be used on any platform, and command-line interfaces (CLIs) and application programming interfaces (APIs).

    Later phases of the developer hub will include an orb development kit to help users quickly create new orbs using CircleCI CLI commands. An orb is a software development kit (SDK) that simplifies integrating the CircleCI CI/CD platform with third-party tools and platforms. CircleCI also plans to provide a much more streamlined search engine experience for CircleCI documentation.

    The CircleCI developer hub was built in part using $100 million in additional funding the company raised earlier this year. Overall, CircleCI claims it processes nearly 2 million jobs across 100,000 projects per day.

    In general, Rose said DevOps is becoming more challenging as organizations attempt to orchestrate the building and deployment of monolithic and microservices-based applications constructed using container and serverless computing frameworks. There are plenty of instances in which deploying a monolithic application is still more appropriate, so IT organizations need to be able to create DevOps workflows capable of spanning multiple classes of frameworks and platforms, he noted.

    Making matters more complex is the testing of microservices now needs to be integrated within production environments, added Rose. It’s not really possible to completely test a microservices until IT organizations see what impact it might have on other microservices that have already been deployed in a production environment, said Rose.

    It’s not clear what impact COVID-19 has had on the productivity of DevOps teams. It might be easier for developers to generate more code working from home than in the office. However, generating quality code at the right time during a project requires a lot more orchestration when members of the application development team are highly distributed. More than a few organizations either already have or soon will be tuning DevOps workflows to align with the so-called new normal.

    Of course, there are plenty of places to find tips and advice when it comes to building and extending DevOps workflows. The challenge is creating workflows that are not only flexible and resilient but also simple to implement and maintain.

  • RunSafe Allies With JFrog to Secure Applications

    RunSafe Allies With JFrog to Secure Applications

    RunSafe Security, a provider of Alkemist tools that prevent memory exploits, has partnered with JFrog to create a plug-in for the Artifactory repository manager platform.

    Alkemist employs a combination of runtime application self-protection (RASP) and moving target defense (MTD) methods to neutralize memory corruption exploits such involving, for example, a memory overflow.

    Based on a research project for the Advanced Research Projects Agency of the Department of Defense (DARPA), the integration with Artifactory will make it easier to harden binaries and containers against memory corruption attacks before applications are deployed in a production environment, said RunSafe CEO Joe Saunders.

    RASP describes a class of application security tools that detect attacks in real-time as an application is running. MTD refers to a strategy that relies on changing the attack surface regularly for applications to make it more difficult for cybercriminals to target them.

    Cyberattacks that employ memory exploits attempt to either replace executables with malicious code or overwrite data in a way that changes application behavior. When aimed at operating systems, these attacks commandeer entire systems. They have also been used to launch self-replicating Worm attacks that both cripple systems and insert malware to steal data, corrupting files or installing a back door that enables remote access.

    Saunders said the Alkemist plugin will enable developers to defend applications from these types of attacks without slowing down the pace of application development. Friction is removed from the DevOps process because as code moves through the DevOps workflow, Alkemist automatically hardens it to prevent memory exploits, he said.

    With the growing popularity of containers, Saunders noted that as cybercriminals begin to target them the need to protect containerized applications from memory exploits using best DevSecOps processes will become even more pronounced than it is today.

    While there is clearly a lot of interest in DevSecOps, most developers still don’t have access to the tools needed to better secure applications. As more cybersecurity plug-ins become available for repositories such as Artifactory, the easier it will become to embrace best DevSecOps practices.

    JFrog, for its part, has been making a case for focusing DevOps teams on managing binaries rather than source code. The alliance with RunSafe extends that strategy into the realm of application security.

    It may be a while before DevSecOps practices are widely employed. However, increasingly the issue is becoming less about the tools that might be available. Rather, the cultural challenges associated with implementing cybersecurity gates within a DevOps pipeline is now the major challenge. DevOps teams will need to reconstruct existing DevOps workflows to incorporate cybersecurity gates before an application is deployed. Once that’s accomplished, monitoring applications for anomalies will then need to be incorporated into observability platforms.

    It’s not clear what role cybersecurity professionals will play in this new world of DevSecOps. The one thing that everyone can agree on, however, is the less involved cybersecurity professionals are in the application development and deployment process, the easier it should become to deploy applications that are truly secure.