Tag: code base

  • New Survey Highlights Codebase Size Problems

    New Survey Highlights Codebase Size Problems

    Sourcegraph and Dimensional Research have released a survey of developers at large organizations, which shows a massive growth in codebase size, number of repositories in use and complexity concerns.

    “The Emergence of Big Code – A 2020 Survey of Software Professionals” is definitely intriguing reading, and a few of the results are eye-opening—such as the difference between what development managers think developers are using to search code and what developers say they are actually using. But most of it simply validates what we all knew: Codebases are growing at an alarming rate, through a variety of growth vectors—support for new platforms, use of open source and internal development. Adding environment to code à la GitOps, systems reliability engineering and/or environment automation is adding a layer of completely new source and a layer of complexity not normally in the developer’s realm of immediate concern.

    I’ve been working with Accelerated Strategies Group over the last few months, and we’re looking at tools in this market. The ability to quickly get up to speed on large codebases and the ability to find a specific area in a codebase that is massive and/or spans repositories is a very real need that is not currently well-served. This piques my interest in what Sourcegraph brings to the table, but at the moment we’re focused on the survey, so perhaps in a future blog we’ll talk about Sourcegraph.

    While there is a lot packed into the survey, I think my favorite part is crammed in with other “What would you find useful?” results (the slide is below). Fifty-eight percent of respondents—all of whom are developers—chose, “Finding code by querying semantic relationships, not just matching a string.” As developers, these respondents no doubt are aware of the complexities of this type of feature, particularly in environments with a variety of programming languages and scripts (be they bash, SQL, whatever) all working together. This is huge, and first iterations would be shallow, but is a worthy goal. I’m intrigued to see how well SourceGraph et al solve it.

    Source: The Emergence of Big Code – A 2020 Survey of Software Professionals

    It is also intriguing to see more than half of respondents want the ability to explore ” … both known and unknown code with code intelligence that provides contextual understanding.” That, too, is a tall order. Code analysis has gotten better over time, but contextual analysis of large codebases is notoriously difficult. I’ll be intrigued in the near future to play with this concept and tools that offer it to see how reliable they are and how much human guidance is accepted and/or required to make it a reality.

    Code change velocity reporting and contextual information about code are both available and pretty solid from the majority of full-stack DevOps vendors. Perhaps that is why that particular response only netted 45% and 43% of responses, respectively—the other 50+% are already using them.

    We’re in an interesting time when consolidation appears to be on the upswing and the needs of developers and DevOps teams working in large codebases are becoming more clear and more complex at the same time. Over the next few years the needs reported in this survey will likely be replaced by more specific needs as these are fulfilled and find general use. The question of databases and database integration in large codebase migrations, for example, has these needs, but has other needs closer to the problem domain. As these general issues are resolved, expect your vendors to turn to those more specific, but every bit as complex, problems.

    And just keep rocking it. Find out what the tools and companies already in use at your org have added, and if those capabilities fit with your needs or can enhance your Dev/DevOps exercises. Keep the lights on, keep customers happy and watch for tools to help you make it even better.

  • LightStep Unveils APM for Microservices

    LightStep Unveils APM for Microservices

    Various forms of application performance management (APM) platforms have been around for some time. But with the rise of microservices many IT organizations are discovering that legacy APM platforms were not designed to handle the volume of software modules or the rate at which those modules are updated. But LightStep, a startup founded by former Google employees and flush with an additional $29 million in funding, is positioning itself as the first APM written from the ground up for microservices environments.

    LightStep CEO Ben Sigelman says regardless of where software modules and components get deployed, LightStep [x]PM is capable of monitoring and troubleshooting performance issues across all web and mobile clients, monoliths and microservices.

    Most of the demand for LightStep [x]PM, he says, is being driven primarily by microservices based on containers such as Docker. But the APM platform itself can support both microservices and legacy monolithic applications. That creates an opportunity to rationalize APM platforms as organizations make the shift to microservices while continuing to need to support existing legacy applications running in a production environment, Sigelman says.

    Twilio, Lyft, Yext, GitHub and DigitalOcean are already using LightStep [x]PM, which traces its roots back to Dapper, an always-on distributed tracing system that Sigelman developed at Google in production environments. A decentralized architecture enables LightStep [x]PM to continuously analyze 100 percent of transactions across all services. A statistical engine is then employed to detect anomalies, which the APM can then record and replay as part of an end-to-end tracing capability based on OpenTracing, an open API standard co-created by Sigelman and others that has now become a project administered by the Cloud Native Computing Foundation (CNCF).

    Other capabilities embedded within LightStep [x]PM include support for service mesh and load-balancing technologies such as Envoy, linkerd, nginx and haproxy.

    With every new era of enterprise computing, a contest occurs between startup companies such as LightStep and incumbent providers of technology platforms. LightStep is clearly trying to fill a void before incumbent providers of APM platforms can add support for microservices. Incumbents occasionally rely on their own organic efforts to upgrade their platforms, but more often they buy a startup company and then spend several years trying to unify disparate code bases.

    Of course, there are many organizations that are just beginning their DevOps journey. Many of the them may not have any kind of APM platform in place. Most tend to be cost-sensitive as well, so offerings based on open-source code tend to have greater appeal.

    However the APM wars play out, it’s apparent they are about to enter a new phase. The winners and losers of those wars will be determined by DevOps teams rather than C-level IT executives trying to impose a framework from on high. After all, if IT organizations have learned anything in the last few years, it’s that DevOps tends to have a more lasting impact when it comes from the bottom up.

    — Mike Vizard

  • Big DevOps: Too Slow to Win?

    Big DevOps: Too Slow to Win?

    There’s DevOps. And then there’s Big DevOps.

    DevOps is a set of disciplines that accelerates time-to-value for digital deliverables. It is being embraced by all kinds of companies, from pure-play digital market disrupters to mainstream corporates trying to maintain competitive parity with their mobile apps.

    Big DevOps is something else entirely. Big DevOps resembles mainstream DevOps, because it’s a process by which companies bring code to market. But if you’re a game developer or large bank, your code bases are massive—and your software life cycle requires you to distribute those massive code bases across globally dispersed dev and test teams.

    Distribution of massive code bases on a global scale creates time-to-value challenges that are totally foreign to programmers checking bite-sized blocks of work in and out of GitHub. These scale-related distribution challenges chronically delay DevOps workflows—impeding your company’s digital agility and seriously undermining your ability to compete in today’s time-gated markets.

    So you must overcome your Big DevOps code base distribution problem.

    Choking on Code

    The main culprit responsible for the slowness of Big DevOps is the network. It just takes too much time to push a massive code base through the relatively narrow pipe of an enterprise network. Even if you spend lots of money on bandwidth and network acceleration, the ratio between your bits of code and your bits-per-second of network is untenable. Every distribution of every large code artifact gets delayed. Over and over, day in and day out.

    Those days add up. And when you pile days lost due to network-related delays on top of the other delays that plague large, complex software projects, you wind up persistently late to market.

    And cloud alone can’t help you. Globally dispersed teams can’t work on a massive code base in the cloud. They have to work with it locally. So you have two problems. First, all your teams all over the world have to keep downloading and uploading massive files. Second, you have to make sure everything everybody does everywhere stays synced.

    That’s why you need a much better way to globally distribute massive code bases.

    Work Locally, Dedupe Globally

    That better way is a hybrid hub-and-spoke model that lets you maintain a “gold copy” of your code base in the cloud—while giving everyone everywhere a local copy that is continuously updated with any changes to the current build. This approach eliminates network-related delays while ensuring conflict-free collaboration across geographically dispersed teams.

    It’s a simple approach that works. In fact, it’s been used by CAD/CAM teams for years to address a very similar file distribution problem.

    Hybrid cloud hub-and-spoke also saves money—because you can spend less on your network and your local storage infrastructure.

    Cost, however, is not the existential issue facing Big DevOps. Time is. Companies that are slow to market with their digital deliverables can’t win against fast ones. So if your company is big—and if you’re doing Big DevOps—you have to solve your time-to-market problem. The realities of digital competition demand it.

    — Barry Phillips