devopsy.kinsta.cloud

Tag: code bugs

  • AIOps and the Myth of ‘Move Fast and Break Things’

    AIOps and the Myth of ‘Move Fast and Break Things’

    Observability through AIOps enables developers to find problems faster by cutting through the noise

    Years and years ago, a little-known entrepreneur named Mark Zuckerberg uttered the phrase, “Move fast and break things,” to his development team. Since then, dev teams have stuck to this “move fast and break things” mantra, where fast development far outweighs dealing with a few bugs down the road. Under this mindset, finding and fixing problems is essentially the last step in the development process.

    The Problem With Breaking Things

    This way of working has served dev teams well over the years as consumers continue to demand speedier innovation. But as end user expectations around deliverability speed rise, so do expectations around service reliability. Customers now want better products faster. Not only does the “break things” way of development lead to extra work for the dev teams down the road, but it also degrades customer trust over time as issues, from a buggy user experience to major security concerns, pop up once the product is already shipped.

    Even Zuckerberg realized this years later, admitting, “What we realized over time is that it wasn’t helping us to move faster because we had to slow down to fix these bugs and it wasn’t improving our speed.” He realized this so much so that the Facebook team officially changed their mantra to “move fast with stable infra” in 2014. Sure, Zuckerberg shouldn’t be our role model after everything that has happened, but if he can realize the need for stable infrastructure, so should we.

    So, how do dev teams meet growing end user expectations while cleaning up the now hurried development process for more stable systems?

    Observability With AIOps and the Development Process

    This is where observability strengthened by AIOps (artificial intelligence for IT operations) comes into play. Observability—or simply making data readily available from a system that you want to monitor—enhanced through AIOps allows dev teams to automate their monitoring. This automation can include applying AI/ML algorithms to all data; eliminating noise; detecting anomalies; correlating relevant metric anomalies, traces, changes and log events triggered by incidents; using contextual data to surface incidents; and identifying probable root causes of those incidents. This gives the teams a more complete picture of what’s happening in their systems, where the bugs are and how to resolve issues quicker, ultimately speeding the development processes overall.

    Through observability with AIOps, dev teams can actually build systems faster by finding problems earlier, cutting out the time-consuming process of retroactively fixing mountains of problems after the product has already shipped. On top of that, finding these problems earlier ultimately leads to more reliable services—and reliable services mean happier customers. When the product actually works the first time around and there’s a system in place to find and fix evolving issues, there’s less legwork to make customers happy. It’s a win-win.

    Observability with AIOps also means freeing developer time and effort to focus more on innovation and less on operations. And who doesn’t want to work on higher impact projects more often instead of spinning their wheels making sure the work they’ve already done is actually functioning correctly?

    We Need to Stop Stalling

    It’s easy to get stuck in your ways, but that is the only reason dev teams haven’t improved their processes to streamline workflows and build better products. Simply put, we have to stop stalling on making this change because, finally, moving fast doesn’t have to mean breaking things.

    We can continue to move fast while building products that are better quality and keep customers happier if we change our mindset around the development process. As developers, it’s our responsibility to evolve with the best strategies for our team, customers, and business—and we now have a way to do so by embracing observability with AIOps.

  • Survey: Organizations Knowingly Deploy Vulnerabilities

    Survey: Organizations Knowingly Deploy Vulnerabilities

    A survey published today by Synopsys, a provider of electronic design automation (EDA) and application security tools, finds nearly half (48%) of respondents admit they consciously push code with known vulnerabilities into production because of time constraints.

    Based on a survey of 378 cybersecurity professionals conducted by Enterprise Strategy Group (ESG) on behalf of Synopsys, the survey also finds 65% of respondents said developers in their organization are participating in a formal security training program.

    However, only a third (34%) are employing application security tools across more than three-quarters of their codebase. And, as the rate at which code is created increases, only 30% expect they will be able to protect more than three-quarters of their codebase 12 months from now despite the fact that more than half (56%) said they apply highly integrated sets of security controls throughout their DevOps process.

    Nearly three-quarters (72%) also said their organization makes use of 10 or more application security tools.

    Patrick Carey, director of product marketing for the Software Integrity Group at Synopsys, said the survey shows many organizations are making trade-offs between potential risks to the business and the desire to deliver software faster. As the rate at which updates to applications are being delivered increases, thanks largely to the adoption of best DevOps processes, Carey noted it becomes easier to justify knowingly allowing vulnerable code to be deployed in a production environment. The assumption is that most severe vulnerabilities will be prioritized while less critical vulnerabilities are addressed over the course of the application lifecycle management process.

    In most organizations, the survey finds either a development manager or the application security analyst is responsible for making these decisions. Just under a third of organizations make both jointly responsible. More than three-quarters (78%) also report their security analysts are directly engaged with their developers. Just under a third (31%) work directly with developers to review individual features and code, compared to 28% who work with developers on threat modeling and 19% that participate in daily scrums.

    The survey finds that integrations that complement high-velocity application development process are critical for 43% of respondents. As a result, more organizations are looking for application security tools that can be directly embedded within an integrated development environment (IDE), noted Carey.

    However, the fact that application security tools are shifting further left does not mean organization won’t also have to invest in other tools that are embedded within DevOps platforms that manage runtime deployments, added Carey.

    As is always the case when it comes to best DevSecOps practices, the two biggest challenges are getting the right tools in the hands of developers and then aligning workflows between development and cybersecurity teams. The survey suggests substantial progress has been made on the latter, while tools for developers are increasingly becoming available. After all, most developers want to do the right thing when it comes to application security. The issue is determining what precisely that means.