staging-devopsy.kinsta.cloud

Tag: systems reliability engineer

  • Harness Acquires ChaosNative to Meld Chaos Engineering, DevOps

    Harness Acquires ChaosNative to Meld Chaos Engineering, DevOps

    Harness this week announced it acquired ChaosNative as part of a plan to more deeply integrate chaos engineering with DevOps workflows.

    At the same time, the company added a Harness Service Reliability Management (SRM) and Harness Security Testing Orchestration capability to its continuous integration/continuous delivery (CI/CD) platform.

    Chaos engineering, as a discipline, refers to experiments on a software system that test its resiliency in the face of an unplanned outage. The goal is to deliberately make resources unavailable to see how the application environment either adjusts or whether it fails.

    ChaosNative’s LitmusChaos platform, which manages these chaos engineering tasks, was donated to the Cloud Native Computing Foundation earlier this year.

    Scott Sanchez, chief marketing officer for Harness. said the company plans to shift chaos engineering further left as part of an effort to enable developers to test the resiliency of their applications before they are deployed in a production environment.

    It’s still early days where adoption of chaos engineering within DevOps workflows is concerned. Many IT leaders’ performance is measured based on the stability of application environments. The idea that they should deliberately break something as part of an effort to make an application more resilient requires a shift in mindset, noted Sanchez.

    However, once IT leaders start to appreciate how chaos engineering actually improves the availability of applications it’s only a matter of time before the practice becomes more widely implemented, he added.

    In the meantime, Harness is looking to automate more of the lower-level tasks that today’s DevOps teams often manually manage. Harness SRM enables DevOps teams to automatically track service level objectives (SLOs) that are attached to specific pipelines within the Harness CI/CD platform.

    The Harness STO module, meanwhile, makes it simpler to orchestrate security testing across multiple pipelines.

    In general, there is now more focus on the productivity of DevOps teams as the number of applications that are being built simultaneously increases. The challenge, however, is not just the number of applications but also the dependencies that exist between them.

    Harness is making a case for a CI/CD platform that automates DevOps tasks by employing, for example, machine learning algorithms to identify which applications are most likely to fail before a build is completed. The goal is to reduce the amount of time DevOps teams waste waiting for builds to complete only to discover that the application almost immediately failed.

    The time, effort and cost of maintaining a DevOps platform will naturally vary as the overall environment becomes more complex. However, as DevOps processes become more automated, the platforms themselves become more accessible to a wider range of organizations. Today, the effort required by a DevOps to set up and then support a CI/CD environment is often considerable.

    Nevertheless, as more organizations rely on custom applications to drive digital business processes, it’s only a question of when and to what degree DevOps best practices will be more widely adopted. After all, the total cost of application downtime is only going to rise in the age of digital transformation.

  • The Evolution of SRE and Developer Roles

    The Evolution of SRE and Developer Roles

    As an industry, we’ve seen cultures and roles shift throughout IT teams — specifically, the role of ITOps site reliability engineers (SREs), various developer roles and the culture of DevOps. Most of these roles operated – or still operate – in silos, and didn’t understand (or care to understand) how each other’s role worked. More importantly, they didn’t know how to work together. But these roles are starting to overlap, driven by the increase in demand for customer experience and, subsequently, in intelligent observability, or observability with AIOps. Before we dive into the ‘how’ behind the overlap, let’s look at how each of these roles performs today.

    Developer

    While the specifics of what a developer does varies by project, the overarching responsibilities haven’t changed much since the introduction of the role. Simply put, developers write code to create and improve product functionality.

    IT Operations and SRE

    Traditionally, an IT operations professional focused on operating the code a developer put into production; aka keeping the lights on. However, we’re now seeing evolution of the role of highly skilled operations pro to that of an SRE who oversees automation and features surrounding the product, like CI/CD pipelines, infrastructure-as-code and the ability to monitor and observe the services and components within.

    QA

    Traditionally, QA would test the code the developer wrote and move it down the deployment pipeline. But we’re moving away from traditional QA. Now, the role sets up an automated framework for the developer so they can automate tests — similar to how the SRE sets up the CI/CD pipeline and observability framework to build, test, deploy, verify and monitor their code.

    DevOps

    DevOps has, in some cases, evolved from a practice and culture into a role. The DevOps engineer prepares the automation and the CI/CD pipeline for the developer to push out their code to test and, ultimately, production. But let me be clear – I believe the idea behind the practice of DevOps is that the practitioner does everything — they own testing frameworks, CI/CD pipeline and infrastructure. They own end-to-end product development and operation, so when anything does go wrong, they know exactly what to do, where to go and how to fix it.

    In the end, if a SRE can develop everything around the product code and knows how to fix the product — isn’t an SRE actually a developer? What if we have a really skilled developer who sets up the automation and observability framework to get their code from their keyboard to the user as quickly as possible — without breaking anything, of course — while also building and improving all the infrastructure and components surrounding the product? Isn’t the developer an SRE, or at least performing site reliability engineering?

    The short answer, in my opinion, is yes. And there’s one guiding force behind this amalgamation, this crossover; ultimately, this evolution: intelligent observability.

    The role of observability with AIOps

    Traditionally, and with the use of many tools, DevOps practitioners and SREs have had to — manually — battle floods of data coming in from all their endpoints, services and products. This can feel like a never-ending struggle. It can lead to a lot of toil and time spent on maintenance, when what developers really want is focused time to do what they love – write code, create and innovate. Not to mention, the result has a negative impact on the customer experience.

    But now, new tools are surfacing to support the everyday needs of SREs and DevOps practitioners. For example, intelligent observability, or AIOps, applied to observability data like events, metrics, traces, changes and logs, gives teams clearer insight into not only where complex data is coming from, but why an issue is happening and what action they need to take to resolve it. They can spend less time operating and more time innovating.

    As these roles continue to evolve, it’s important SREs and DevOps practitioners remain agile and willing to adjust to keep up with the latest technologies supporting their day-to-day workflow. AI can be the key to keeping the incident count down and the customer experience up.

    Looking Ahead

    If you’re currently in one of these roles, consider how you are practicing. Whether you’re a developer, a QA engineer, a DevOps practitioner, or an SRE, have you evolved your role to fit your company and customers’ needs right now? As these roles overlap with the application of intelligent observability throughout your development life cycle, it’s possible to deliver better products and fix reliability issues faster. It’s up to you to decide if you want to embrace the evolution of your role and intelligent automation or stay put and risk falling behind.