devopsy.kinsta.cloud

Tag: automation

  • The New Norm for Modern Apps: Security Observability

    The New Norm for Modern Apps: Security Observability

    Observability has burst onto the scene across all types of operational and security-focused activities. Its need is being driven by increased demands for businesses to be more responsive to changes and more proactive when dealing with potential problems. In particular, security observability holds the promise to help reduce the time to detect a cyberattack. And going a step further, it can help detect security vulnerabilities before an attack even occurs.

    What is security observability?

    In the past, most operations relied on visibility into their systems and applications to manage security. Visibility would be achieved via monitoring applications, systems, and their logs. Monitoring solutions would collect and analyze information to detect suspicious behavior or unauthorized system changes. And having defined which types of behavior should trigger alerts, solutions would take action as needed.

    Perhaps more to the point, monitoring lets you detect a known set of problems or conditions. Thus, it is essential for alerting and analyzing long-term trends. Simply put, monitoring lets users know how their systems and applications are functioning and being used.

    However, the problem with security monitoring of complex distributed applications is that it is a passive approach to highly dynamic operations. And it often does not provide any insights into root cause problems or anomalies that might be precursors to problems in the making.

    Security observability expands on monitoring by enabling correlation and inspection of the data to provide much deeper insights. Observability typically requires logs, metrics, and deep tracing. All data is used for modeling and analytics. Companies can mine the data, look for patterns, use artificial intelligence and machine learning to remediate problems and proactively defend against problems.

    Why security observability is needed now

    The need for security observability is growing due to the way applications are developed.

    The general industry trend is a move to cloud-native architectures based on microservices. Such an approach brings many benefits. Applications can scale quickly. Companies can easily change or update a small aspect of a larger application without impacting the rest of the app. And businesses can make use of new technologies. For example, a business can add a new front-end or implement more sophisticated AI or machine learning modeling.

    Such a development approach can introduce potential blind spots and complexity. In particular, modern applications built using cloud-native architectures and microservices introduce new challenges. The loose coupling of such applications, their distributed nature, and increased complexity makes it harder to understand vulnerabilities. As a result, traditional cybersecurity approaches break down. They miss the interactions and inter-dependencies of the many elements that comprise modern applications.

    Furthermore, traditional security monitoring solutions can be limited. For example, visibility often must be split across tools resulting in insecure platforms or situations where relevant data is not even used in monitoring.

    Adding to the security challenges is the widescale embracement of low-code/no-code development methodologies. Such technologies open development up to business units and citizen developers. These groups can build sophisticated applications, often with little oversight or guidance. As a result, apps may be created by assembling building blocks that may be outdated, unpatched, or simply have vulnerabilities.

    DevSecOps needs security observability

    With all these trends, it is not surprising that businesses are exploring new approaches to security. Just as quality assurance was melded into development processes using automated testing, security ops are being meshed with development. Hence, the rapid implementation of DevSecOps methodologies in organizations today.

    While security issues can grow when using cloud-native development methodologies, there is a lesser-known security benefit. Applications and services constructed using APIs and microservices have an advantage over other systems because developers and security staff can more easily observe what’s happening inside them. In addition, businesses can add links to the APIs and microservices and use tools to collect the details of such operations.

    Given this wealth of data, security observability expands on monitoring. Rather than just detecting vulnerabilities and incidents that raise compliance issues in the development process, DevSecOps using security observability, seeks to identify issues and automatically take corrective actions.

    Moving forward, businesses should expect more adoption of DevSecOps and more automation based on security observability. This will only serve to strengthen security and compliance across systems and applications.

  • Gotta Fix ‘Em All: AWS BugBust 2021

    Gotta Fix ‘Em All: AWS BugBust 2021

    Software bugs are vexing. Code reviews and error finding aren’t a particularly fun part of a developer’s job description. Finding bugs is tedious, time-consuming and hard on your eyes. Bugs not only wreak havoc on your code, they wreak havoc on your day. But what if bashing bugs could earn you a payoff greater than pride? That’s where AWS BugBust comes in.

    AWS BugBust is the world’s first global competition for Java and Python developers. The contest has two overall goals:

    1. Fix 1 million bugs and
    2. Reduce technical debt by over $100M, globally

    Code reviews and monitoring are common practice; some organizations even hold bug bashes where members come together to reveal bugs and fix them. However, fixing code is still an arduous process and there is more that could be done to make bug-bashing efforts fun and fast. AWS BugBust does both by adding in gamified points/competition/prize components!

    How does AWS BugBust work?

    The more bugs you fix, the more points you earn and the higher up in the leaderboard you get. Using Amazon’s CodeGuru, developers will compete to fix the most bugs (identified by CodeGuru Reviewer) and the most expensive lines of code (highlighted by CodeGuru Profiler). Amazon CodeGuru eases the pain of code review and error finding by automating the process. Using Machine Learning, Amazon CodeGuru will scan code quickly, identify errors and provide fix-it recommendations.

    Here is more info about the contest:

    How do you earn points?

    AWS BugBust uses Amazon CodeGuru Reviewer to analyze applications’ code to identify bugs and CodeGuru Profiler for performance issues. The bugs and profiling groups are available on the challenge dashboard and are available for participants to claim them, fix, and score points. Points are earned based on the severity of the bug (low, medium, and high)

    To score points, participants make code changes in their repositories, create a code review request, and trigger a code build. CodeGuru Reviewer will analyze the code changes as part of the build process and notify whether the code that was changed addressed the bug.

    The collective number of bugs fixed and dollars saved will be stored in the AWS Global BugJar. The totals for both metrics will show on the global leaderboard.

    Participants will receive digital badges and bespoke swag at three key milestones: 100, 2,000, 10,000 bugs fixed. Swag includes pins, t-shirts, BugJars, backpacks, and hoodies/jackets.

    When will AWS BugBust take place?

    The contest will launch Thursday, June 24. You can get started by setting up an AWS BugBust for your team.

    What’s the ultimate prize?

    The top ranking developers of the global leaderboard by the end of September 30, 2021 will receive an all-expense-paid trip to re:Invent 2021. AWS will also award the top 10 enterprises who collectively contribute the most bugs to the global BugJar through their private events with two tickets to re:Invent 2021 for their top BugBusting developers. If you’re a Java/Python developer, this competition will be like doing your job while enjoying a game-like atmosphere!

    Here are important rules:

    1. An AWS account is required to participate in the challenge (participants can create one at the beginning of the challenge or any time during the contest period).
    2. Customers who have their code bases in Java and/or Python and stored in supported GitHub, GitHub Enterprise, Bitbucket and AWS CodeCommit repositories are able to participate in the AWS BugBust.
    3. Challenge registration and console experience, overall, are much better on the desktop. Links in the console will direct to code repositories which are more easily accessible on the desktop, as well. Mobile placements will be considered for awareness, but desktop should be prioritized.

    AWS BugBust isn’t your grandma’s bug hunt. You now have machine learning capabilities on your side, including the ability to automatically find bugs for you and present the list of bugs to you – even before the challenge begins. You can make the arduous inspection process fun, win some prizes, be the hero at busting bugs and find them, starting June 24!

    We have also provided additional information about the AWS BugBust competition on devopsy.kinsta.cloud.

  • Responsible Reproduction

    Responsible Reproduction

  • Father’s Day 2021

    Father’s Day 2021

  • Survey Reveals Slight Decline in Level of SRE Toil

    Survey Reveals Slight Decline in Level of SRE Toil

    The amount of routine toil that site reliability engineers (SREs) perform declined slightly in the last year even though IT environments in general are becoming more complex to manage.

    An annual survey of 300 SREs conducted by Catchpoint, a provider of an IT monitoring platform, in collaboration with VMware and the DevOps Institute suggests that the amount of toil—defined as low-level manual tasks—declined 15% in the last year.

    Only 22% of respondents claim to be scientifically measuring toil, so, to a degree, the survey results are apocryphal. Overall, the survey, published this week, finds SREs are, not surprisingly, spending the bulk of their time on responding to incidents and outages, followed by participating in postmortem analysis and on-call rotations. The primary sources of toil cited in the survey are too much technical debt, lack of alignment of priorities and goals, lack of appreciation of business value, lack of training and support and lack of collaboration.

    In terms of automation adoption, the most common use cases cited are release management, infrastructure management and application management. The tools most commonly employed by SREs are used to monitor infrastructure, networks and application performance. Adoption of artificial intelligence (AI) tools to manage IT operations (AIOps) remains low. The survey also finds respondents are roughly split evenly between centralized (42%) and decentralized (38%) approaches to managing IT. Another 20% said they have adopted a hybrid approach. Lack of visibility across the stack (53%) was the most cited cloud application monitoring challenge.

    The survey also finds only half of respondents continually refine their service level objectives (SLOs).

    Leo Vasiliou, director of product marketing for Catchpoint, said it’s clear that SREs are becoming more proactive in terms of preventing and containing the impact of IT incidents. The challenge they face is lack of visibility and context as those IT environments become more complex. Complexity is increasing, in part, because of the rise of cloud-native computing platforms running microservices-based applications that have lots of dependencies.

    Less clear right now is the percentage of IT environments managed by SREs today. In theory, a single SRE can do the same amount of work as multiple IT administrators by automating processes using various DevOps tools rather than relying on traditional graphical tools. However, SREs are hard to find and retain. It’s also not always apparent to what level of automation needs to be attained to qualify to be an SRE or, for that matter, what certifications may be required. Interest in becoming an SRE is rising, in part, because they typically command higher salaries.

    In the meantime, it’s clear organizations will need to find ways to automate the management of IT to a much greater extent. Most organizations cannot afford to hire a small army of IT professionals to manage IT environments that become more complex with each passing day. Everything from DevOps best practices and next-generation observability tools that promise to provide more context to AI platforms will all be part of the mix. The challenge is finding a way to implement those tools before IT management spins further out of control.

  • WSO2 Applies AI to API Management

    WSO2 Applies AI to API Management

    WSO2 today unfurled a Choreo cloud platform through which DevOps teams can create and manage application programming interfaces (APIs) more efficiently by leveraging machine learning algorithms and other forms of artificial intelligence (AI).

    Eric Newcomer, WSO2 CTO, said the integration platform-as-a-service (iPaaS) eliminates all the tasks associated with setting up a platform for and managing services based on APIs.

    Choreo, available in beta, employs AI to learn historical activities and performance behaviors in order to anticipate the needs of a developer. As developers build an API, the platform will provide performance feedback, identify anomalies, map data and even complete code, said Newcomer.

    The Choreo platform also comes with built-in observability tools for monitoring API usage and troubleshooting APIs, added Newcomer.

    In addition, Choreo provides access to the open source Ballerina programming language the company developed to enable developers to create APIs using both low-code and procedural code as they see fit, noted Newcomer. The low-code diagram that developers create generates source code that developers can then run wherever they want, said Newcomer. Developers can close the entire repository Choreo provides, Newcomer added.

    Developers can also trigger low-code integration logic to control hundreds of software-as-a-service (SaaS) APIs via pre-built connectors and templates provided by WSO2 or ones they create themselves.

    WSO2 is also making it possible to deploy APIs via a single click in Kubernetes environments, which eliminates the need to manage cumbersome YAML files. That capability is based on technology that WSO2 gained via the acquisition of Performer that the company revealed today.

    Finally, WSO2 is making available an API marketplace through which organizations can share APIs, event streams, data sources and templates.

    With the rise of microservices-based applications, API management has become a lot more challenging. Each additional microservice adds an API that needs to be managed and maintained. As more APIs are employed, it becomes increasingly difficult for DevOps team to keep track of the dependencies that exist between all those APIs without the aid of machine learning algorithms.

    It’s not likely machine learning algorithms will replace the need for DevOps professionals anytime soon. However, it’s becoming apparent that many of the manual tasks that DevOps teams routinely perform today are becoming automated by machine learning algorithms. In other cases. DevOps teams are gaining new capabilities that would have either been impossible for them to do on their own or would simply have taken too much time to complete.

    Of course, it takes time for any AI platform to learn the DevOps environment. IT teams need to invest a significant amount of time training an AI model to recognize relevant issues in much the same way they might train any new member of a DevOps team. The only difference is, once a machine learning algorithm learns something, they never forget it. Nor do they take a day off or announce one day they are leaving the company because they got a better offer somewhere else.

    It may take a while before DevOps teams are able to strike the right balance between man and machine, but one thing that is certain is that AI in DevOps environments is here to stay.

  • How Low-Code is Anchoring the Digital-First Enterprise

    How Low-Code is Anchoring the Digital-First Enterprise

    When the pandemic hit, digital transformation was accelerated, and many companies turned to low-code development in the hopes of winning in the new agile world. Technology aficionados have heard the phrase, “Faster, better, cheaper — pick two.” Fortunately, low-code gives you all three and then some, adding “flexible” to the mix. It’s no surprise that low-code development interest is now surging, as it’s quickly becoming a critical component of a modern enterprise technology stack, with estimated low-code development market growth predicted to exceed 25%, growing from $13B in 2020 to $65B in 2027, according to research from Brandessence Market Research.

    With their roots in the rapid application development (RAD) tools of the 1990s, low-code platforms are an application development environment that use graphical user interfaces and configuration instead of traditional hand-coded computer programming. Formal software engineering skills are not required to create applications since a visual user interface in combination with model-driven logic is used. This opens the door to a wider range of people who can build apps for the business. With a little training, employees can rapidly create and deploy secure scalable software. One note to remember–low-code is not interchangeable with no-code, which is a subset of technologies aimed at business users primarily working on enhancing their individual productivity.

    A New Player in the Enterprise Technology Stack

    It’s impossible to argue against the need and demand for low-code in the enterprise. According to Gartner, more than 65% of application development in 2024 will be performed by low-code platforms. That’s a remarkable shift for a software category that did not exist a decade ago. The number of digital applications and services being built is exploding as well. Between 2018 and 2023, more than 500 million apps will be created according to IDC. To put that massive number into perspective, that’s more than the previous 40 years combined. With low-code, companies can rapidly produce applications within a shorter time span and at a fraction of the cost. Some skeptics may point out the lack of available IT resources, but business users can learn low-code development methodologies quickly, typically in less than one month. Clearly the old way of building apps cannot keep pace with today’s digital marketplace.

    Process Intelligence Jump Starts Low-Code Journey

    To help accelerate use of low-code and scale it across the enterprise, process intelligence is a key enabler. You cannot improve how you operate tomorrow if you don’t fully understand how you work today. And most companies truly don’t understand how they operate on a daily basis, especially at the granular user activity level required to automate a process or streamline a workflow. They have limited process understanding. They don’t know how their applications and data interact, and they don’t really understand what their customers expect.

    The impact of this gap in process data is well documented. The 70% failure rate of transformation programs is widely reported. McKinsey pegs the cost at nearly $1 trillion annually and noted that 14% of companies have seen a sustained and material improvement in their business. Another study from Gartner noted only 1% of companies have sufficient understanding of their processes to take full advantage of the technology solutions.

    Before embarking on a major initiative, a company must map its processes, its systems and its experiences. Today, that necessary level of operational intelligence just does not generally exist in most companies and on top of that it is very difficult to obtain without process intelligence.

    Low-Code and Process Intelligence – Better Together Than RPA

    Process intelligence was a similar catalyst for robotic process automation (RPA), but the opportunity with low-code is even greater. RPA programs enjoyed massive early uptake, but the challenge was how to scale the initiatives. Companies still struggle getting more than 50 bots deployed. Once any obvious low-hanging fruit is automated, it becomes difficult to identify what to tackle next and how to tackle it. Process intelligence answers those questions to help scale RPA.

    With low-code, process intelligence accomplishes that and more. The combination will overtake RPA as the gateway for AI and automation. Low-code is more efficient and scalable than traditional RPA development because it does not operate at the user interface (UI) layer, making the applications more resilient. Additionally, where RPA is traditionally limited to task-based activities, low-code is much more capable of handling sub-process and process level activities, making it much more valuable to the enterprise. Coupling process intelligence with low-code helps steer an enterprise toward a next-generation operation model that is faster, cheaper, better and flexible. It may also fully realize the promise of citizen developers that RPA struggles to achieve.

  • There’s No Innovation Without Automation

    There’s No Innovation Without Automation

    Companies of all sizes and across virtually every industry today have ready access to hyperscale compute, storage and myriad other technologies — without needing the significant budget or technical expertise of a hyperscale cloud provider like AWS.

    This is a boon for innovation. Cloud opened the door to cost optimizations, previously out-of-reach cloud-native tools, security improvements and other tangible business benefits. This also created something of a myth in the industry: people commonly think of cloud as “easy.” Yes, migrating existing applications to the cloud can create significant business value. But saying “cloud is easy” can be dangerously misleading.

    There are reasons for this perception. A developer with a credit card can create an account and spin up a new environment in a matter of minutes, for example. That’s a far cry from the days when that same IT professional might need to submit a ticket to an internal Ops team days (or weeks) in advance to provision a new Dev environment.

    Operating in the cloud at any kind of enterprise scale is not necessarily easy, however. In fact, cloud can be much more complicated than on-premises infrastructure. Consider the sheer number of new tools and services a platform like AWS rolls out in a given month—keeping up with the pace of change and innovation can itself seem like a full-time job.

    Complexity becomes an even bigger issue when teams migrate to cloud (or begin pursuing greenfield cloud-native projects) while simultaneously trying to move with greater speed and agility, often driven by a new or ongoing digital transformation project in the company. Think about a team that’s undergoing a shift toward DevOps while also migrating a major legacy system to a cloud—that’s a lot to tackle at once.

    Fortunately, cloud complexity is an eminently addressable challenge — so long as you embrace automation. Automation, including the use of embedded or native tools from the hyperscalers themselves, is absolutely critical to cloud success.

    Automation is what enables today’s IT teams to achieve the benefits of a cloud migration without saddling themselves with an untenable operational burden. Furthermore, automation is what makes a lot of popular mantras in business and IT today — such as “fail fast” and similar ideas — actually possible.

    Automation is the foundation of innovation. There is no such thing as meaningful innovation without automation. That’s because sticking with largely manual operations turns IT into a bottleneck. Technology hampers the overall business rather than drive its most pressing strategic priorities. Organizations that don’t adapt to this reality face big headwinds. Cloud on its own does not solve the problem; cloud paired with automation is what is needed.

    Consider the various operational requirements of any IT environment: provisioning, configuration, security, scaling, resource management and optimization, and change control/change management. Without effective automation, each of these alone can require an intensive amount of manual effort to manage in the cloud and quickly become more complicated than their counterpart in a plain-vanilla on-premises environment. If you can’t quickly scale up as your application needs change, whether due to a demand surge or other factors, then you’re not achieving the speed and agility that cloud promises, for example. Likewise, if you can’t scale down machines that are no longer needed, you’re almost certainly wasting money on idle resources. This is where a cloud platform’s autoscaling capabilities come into play.

    Similarly, consider your organization’s existing change control or change management processes. It’s a necessary function of many enterprises, especially those who must manage regulatory compliance. When applied manually in the cloud, it can quickly become a byzantine effort that severely limits agility. That’s a nonstarter for most modern businesses. This is another challenge that can be addressed with automation in the cloud.

    It’s also important to understand that automation drives quality as much as it drives agility. It enables you to deliver new products and services faster and more frequently while fostering top-notch user experiences. The autoscaling scenario above can reduce capacity-related outages that damage customer experience and the bottom line, for instance. In this way, automation and cloud together form the basis for true operational excellence and its hallmark characteristics of capacity, elasticity, performance, and security.

    This is not just the purview of customer-facing applications, either. Competitive businesses must bring the same philosophy to their whole IT portfolio. Innovation depends on internal systems becoming as nimble as a web front-end.

    Think about an ERP system like SAP; change on SAP for enterprises has traditionally moved at the speed of an elephant when today’s businesses operate at the speed of a gazelle. You must apply the processes, tools and culture of cloud and automation to back-end systems, too. You can automate operational tasks in the cloud, such as system refresh and other system-level operations. This paves the way to zero-downtime maintenance, patching the database at the OS level while getting rid of the hours of downtime that task would previously have required. Or think of the necessity of backup-and-restore: Via cloud-based automation, you can deliver point-and-click restores that greatly reduce time to recovery.

    Again, this is about quality just as much as agility. Applying automation appropriately to a cloud-based ERP system can reduce or eliminate human error, too, further boosting system performance and reliability.

    In short, cloud offers great opportunities for enterprises to access transformational innovation.  However, you can’t be innovative without being agile, and you can’t be agile without automation.

  • Automation is Needed for Reliable Cloud Platforms

    Automation is Needed for Reliable Cloud Platforms

    From six to 1,400 microservices in less than five years? At first glance, that sounds like overwhelming complexity. Can you actually see the entire system across all of the microservices? This is the key to highly available and reliable SaaS cloud platforms. But what does this mean, and how can SaaS providers achieve it?

    Over the past decade, the cloud has become the virtual space where the majority of companies’ business processes and communications take place. Considering the accelerated digitization processes of the last year alone, cloud computing plays an increasingly crucial role when it comes to making distributed teams more productive. As a result of these developments, the number of applications, microservices and interfaces is increasing, creating a more complex IT infrastructure.

    The reliability and availability of cloud services must, therefore, be a high priority for providers. Weak services and downtime not only cause frustration among customers, but can also lead to considerable financial losses on the customer side. Accordingly, SaaS providers must establish processes and methods that help them provide secure and highly reliable cloud infrastructures, or risk losing their customers.

    Microservices as the Foundation for Reliability

    Complexity is implied with every SaaS cloud platform. This can be managed in two different ways. On one hand, management can be done via a centralized monolith. Through this, complexity arises from a single system with only one interface to external systems. On the other hand, complexity can be distributed via smaller system units in the form of microservices. This means that the various functions of an application or service are broken up and assigned to several individual instances that communicate with each other. The advantage of this is that if a microservice fails, the entire application is not necessarily affected.

    Microservices in cloud environments have been enjoying steadily growing popularity for some time now. In fact, 76% of the companies surveyed as part of a 2019 Forrester study stated that microservices will be high on the business agenda for many companies in the future. Only 4% disagreed with this statement at the time. In 2020, a TechRepublic survey found that the majority of experts surveyed (73%) have already integrated microservices into their application processes, and 66% of respondents use them in the form of cloud services. Microservices are everywhere!

    Service Level Objectives and Automation

    Due to the numerous interfaces that arise with microservices and the need to be monitored, this architecture appears, at first glance, to be more error-prone than traditional monolithic systems. Some companies already rely on service level objectives (SLOs) – i.e., targets and measurable KPIs to ensure service quality – for a higher level of security. However, these are often limited to the outer layer of the entire system.

    Formulating appropriate SLOs for each microservice with additional alerts can counteract this. In combination, these provide profound protection of the system against creeping errors.

    In order to maintain an accurate overview with regard to security and security-related incidents, and thus ensure the reliability of the system, the microservices and their respective SLOs must be closely monitored and continuously tested. When we surveyed software and IT professionals back in 2019, we found that 71% of respondents reported that microservices-based architectures are much easier to test than monoliths. And with the help of automation, operational teams can ensure that the overall reliability level is close to 100% in every single instance of the systems, no matter how complex. A separate, centralized automation tool monitors all microservices in use and is able to alert appropriate teams about any abnormal activity with respect to individual breached SLOs. In addition, this tool should be linked to an incident management platform so that any breach can be remediated directly. By following this framework, software developers will enjoy the benefits of a more manageable and scalable microservices system.

    We live in a time when consumers expect technology to be updated regularly and run reliably. If this is not the case, they will simply opt for better alternatives. To prevent this, companies need to invest in more effective service structures. Microservices, combined with a central platform that automates testing and management, is the foundation for achieving reliability and scalability.

  • 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.