Tag: tracing

  • 5 Myths About Software Development

    5 Myths About Software Development

    2020 has broken many rules about software development. Some perceived trends, however, remain myths

    Some trends come and go, some trends stick. I remember when Docker launched and it was barely mature enough to run unit tests, and now containers are a common way for modern orgs to deploy applications. We’ve seen the rise of microservices but also the return to the monolith. We’ve seen “observability” take off in popularity, while serverless remains a buzzword with limited (but fast-growing!) adoption. Machine learning and artificial intelligence are still click-worthy headlines, but how much actual ML is being used within our applications?

    The True State of Software Development

    Let’s look at five common myths about the current state of software development and evaluate why they’re not completely true:

    Digital Transformation Initiatives Will Be Hindered by the Pandemic

    We live in an online world where every business is already a software business (or rapidly becoming one). The impact of the pandemic further highlighted ISG’s research which stated that “2020 will still see the rapid scaling of digital initiatives across industries.” While some industries have been hit so hard that digital projects had no choice but to stop (e.g. the airline industry), in many circumstances this will be the catalyst to fully embrace digital transformation.

    The Waterfall Method Still Works

    Organizations that haven’t adopted more agile and iterative approaches to building software are operating at a significant disadvantage. I know there are many big companies that still believe in doing all of the strategic planning upfront (I know this because I talk to these companies), but the truth is that it leaves very little room for flexibility and improvement in real-time. In today’s world, the customers and the users are kings—it is no longer possible to build great products without their input. If you take anything away from this article, it’s that the waterfall methodology needs to be abandoned once and for all.

    Everyone Loves Kubernetes

    K8s is not a one-size-fits-all solution. The fact of the matter is that a large chunk of the enterprise still hasn’t fully embraced the cloud, let alone started containerizing their applications. So while we have to give credit where it’s due and acknowledge that K8s is the clear leader for orchestrating containers, we also have to acknowledge that the hype doesn’t quite match the adoption. It’s still a relatively young technology.

    According to a report from Datadog last year, 45% of their customers that run containers use Kubernetes. That number is growing and is certainly impressive, but when you realize that only a chunk of their customers run containers in the first place and they are a modern monitoring solution where we’d expect to see a higher percentage than a random sampling, it’s clear that K8s is far from mainstream.

    Everyone Is Doing Tracing

    The rise of the digital age has put monitoring and observability in the forefront. As we rely more and more on online services for internal and external interactions, we better make sure they are working properly. But at the same time, regardless of industry headlines and conference talks focusing on tracing, the truth is that the industry at large has yet to adopt it.

    For most organizations, there’s so much room for improvement in getting logging and metrics right, that there’s no need to opt for tracing (yet). After all, Google built most of its global platform relying on metrics. Unlike SREs, developers often find tracing alien and very cumbersome to deploy and wield. Instead, more and more companies are opting to empower their engineers to see what’s going on in remote environments through software understandability.

    AI Will Solve Our IT Problems

    We’ve been hearing about the promises of AI in IT for a long time now. One of the terms still actively promoted that I am very skeptical of is “AIOps.” What does that even mean, really? According to a recent report from OverOps, only a very small percentage of companies are even considering AIOps in their plans for the future.

    That said, I do believe in making better, data-driven decisions. So the more data we can collect, contextualize and understand, the better. We see how this helps companies identify anomalies, alert on issues and even project out into the future. But none of this, really, is artificial intelligence.

    Conclusion

    There’s often a gap between hype and actual adoption. That’s the role of good marketing. And ultimately, hype helps drive adoption. But as technical practitioners, we need to stay rooted in reality in software development and beyond. So while I am convinced agile has proven to be the best way to build and deploy software, and that most organizations would benefit from letting go of old-fashioned waterfall processes; on the other end, I haven’t been fully convinced of the benefits of tracing and AIOps for most companies.

  • LightStep Unfurls Dynamic Tracing Service

    LightStep Unfurls Dynamic Tracing Service

    LightStep announced a stand-alone dynamic tracing tools capability that visualizes patterns in code based on 100 percent of the data available.

    Company CEO, Ben Sigelman, said LightStep Tracing differs from other approaches to tracing because it does not rely on a small sample of data that usually doesn’t wind up providing much actionable insight. Instead, LightStep Tracing makes it possible to search and visualize distributed traces across 100 percent of the data made available with a software-as-a-service (SaaS) application.

    Unveiled at the QCon London 2019 conference, LightStep Tracing is based on functionality originally developed in the application performance management (APM) platform, dubbed LightStep [x]PM, that is optimized for microservices-based applications. LightStep Tracing, however, does not require DevOps teams to implement LightStep [x]PM to take advantage of distributed tracing.

    Distributed tracing is becoming more widely employed because that capability makes it much simpler to visualize patterns indicative of a potential performance issues. Sigelman built one of the first instances of distributed tracing during his tenure at Google. Known as Dapper, the project now analyzes more than two billion transactions per second. Sigelman subsequently co-created the OpenTracing Application Programming Interface (API) standard that is now made available under the auspices of the Cloud Native Computing Foundation (CNCF).

    According to Sigelman, one of the most common mistakes many DevOps teams make today is overvaluing a distributed trace as a data source. While access to distributed traces are required, the real value comes from being able to dynamically inspect 100 percent of all the traces available in a way that visually surfaces patterns, added Sigelman. DevOps teams should be careful what conclusions they draw from analysis based on samples of data because outliers that could have a significant impact on application performance can be easily missed, cautioned Sigelman.

    LightStep Tracing provides DevOps teams with access to dynamic system diagrams that visually summarize the bottlenecks, as well as real-time performance histograms enable organizations to understand what defines normal application behavior in their environment. Sigelman said that DevOps teams, for the first time, can also capture shareable snapshots of system behavior that explain performance anomalies based on statistical summaries of thousands of relevant traces. Within minutes, Sigelman said LightStep Tracing can be employed to instrument and visualize service-to-service interactions across web, mobile, microservices, serverless and monolithic applications.

    One of the more frustrating aspects of DevOps is that most teams will spend far more time looking for the source of the problem, versus fixing it. But until the source of a problem can be identified, the reputation of the IT organization in the eyes of the application owner continues to suffer. There’s also an unfortunate tendency for DevOps teams to spend an inordinate amount of time in “war rooms” trying to proof that whatever element of the IT environment they manage is not part of the root cause of the problem. Rather than wasting all that time at the expense of the reputation of the IT organization, perhaps the time has come to discover and visualize issues hopefully long before any application owner even becomes aware they exist.

    — Mike Vizard