debugging
Auto Added by WPeMatico
The great stink in software pipelines
It’s the summer of 1858. London. The River Thames is overflowing with the smell of human and industrial waste. The exceptionally hot summer months have exacerbated the problem. But this did not just happen overnight. Failure to upkeep an aging sewer system and a growing population that used it contributed to a powder keg of effluent, bringing about cholera outbreaks and shrouding the city in a smell that would not go away.
To this day, Londoners still speak of the Great Stink. Recurring cholera infections led to the dawn of the field of epidemiology, a subject in which we have all recently become amateur enthusiasts.
Fast forward to 2020 and you’ll see that modern software pipelines face a similar “Great Stink” due, in no small part, to the vast adoption of continuous integration (CI), the practice of merging all developers’ working copies into a shared mainline several times a day, and continuous delivery (CD), the ability to get changes of all types — including new features, configuration changes, bug fixes and experiments — into production, or into the hands of users, safely and quickly in a sustainable way.
While contemporary software failures won’t spread disease or emit the rancid smells of the past, they certainly reek of devastation, rendering billions of dollars lost and millions of developer hours wasted each year.
This kind of waste is antithetical to the intent of CI/CD. Everyone is employing CI/CD to accelerate software delivery; yet the ever-growing backlog of intermittent and sporadic test failures is doing the exact opposite. It’s become a growing sludge that is constantly being fed with failures faster than can be resolved. This backlog must be cleared to get CI/CD pipelines back to their full capabilities.
What value is there in a system that, in an effort to accelerate software delivery, knowingly leaves a backlog of bugs that does the exact opposite? We did not arrive at these practices by accident, and its practitioners are neither lazy nor incompetent so; how did we get here and what can we do to temper modern software development’s Great Stink?
Ticking time bombs
Powered by WPeMatico
Lightrun raises $4M for its continuous debugging and observability platform
Lightrun, a Tel Aviv-based startup that makes it easier for developers to debug their production code, today announced that it has raised a $4 million seed round led by Glilot Capital Partners, with participation from a number of engineering executives from several Fortune 500 firms.
The company was co-founded by Ilan Peleg (who, in a previous life, was a competitive 800m runner) and Leonid Blouvshtein, with Peleg taking the CEO role and Blouvshtein the CTO position.
The overall idea behind Lightrun is that it’s too hard for developers to debug their production code. “In today’s world, whenever a developer issues a new software version and deploys it into production, the only way to understand the application’s behavior is based on log lines or metrics which were defined during the development stage,” Peleg explained. “The thing is, that is simply not enough. We’ve all encountered cases of missing a very specific log line when trying to troubleshoot production issues, then having to release a new hotfix version in order to add this specific logline, or — alternatively — reproduce the bug locally to better understand the application’s behavior.”
Image Credits: Lightrun
With Lightrun, as the co-founders showed me in a demo, developers can easily add new logs and metrics to their code from their IDE and then receive real-time data from their real production or development environments. For that to work, they need to have the Lightrun agent installed, but the overhead here is generally low because the agent sits idle until it is needed. In the IDE, the experience isn’t all that different from setting a traditional breakpoint in a debugger — only that there is no break. Lightrun can also use existing logging tools like Datadog to pipe its logging data to them.
While the service’s agent is agnostic about the environment it runs in, the company currently only supports JVM languages. Blouvshtein noted that building JVM language support was likely harder than building support for other languages and the company plans to launch support for more languages in the future.
“We make a point of investing in technologies that transform big industries,” said Kobi Samboursky, founder and managing partner at Glilot Capital Partners . “Lightrun is spearheading Continuous Debugging and Continuous Observability, picking up where CI/CD ends, turning observability into a real-time process instead of the iterative process it is today. We’re confident that this will become DevOps and development best practices, enabling I&O leaders to react faster to production issues.”
For now, there is still a bit of an onboarding process to get started with Lightrun, though that’s generally a very short process, the team tells me. Over time, the company plans to make this a self-service process. At that point, Lightrun will likely also become more interesting to smaller teams and individual developers, though the company is mostly focused on enterprise users and, despite only really launching out of stealth today and offering limited language support, the company already has a number of paying customers, including major enterprises.
“Our strategy is based on two approaches: bottom-up and top-down. Bottom-up, we’re targeting developers, they are the end-users and we want to ensure they get a quality product they can trust to help them. We put a lot of effort into reaching out through the developer channels and communities, as well as enabling usage and getting feedback. […] Top-down approach, we are approaching R&D management like VP of R&D, R&D directors in bigger companies and then we show them how Lightrun saves company development resources and improves customer satisfaction.”
Unsurprisingly, the company, which currently has about a dozen employees, plans to use the new funding to add support for more languages and improve its service with new features, including support for tracing.
Powered by WPeMatico
Rookout raises $4.2M for its rapid production debugging platform
Few people get into coding because they enjoy debugging, but since there’s no such thing as perfect code, issues inevitably pop up. Israeli startup Rookout is tackling one aspect of this by helping developers track down issues in production code without forcing developers to do any additional coding to write additional tests and re-deploy their apps. As the company announced today, it has raised $4.2 million in seed funding from TLV Partners and Emerge.
Rookout co-founders Or Weis and Liran Haimovitch told me that their own experience in writing code led them to starting this project. Weis, who has taken the CEO role, with Haimovitch being the CTO, noted that only a few years ago, your code would run in its own box and you’d have full control over it. These days, however, your code may run in multiple locations and it’s virtually impossible to get access to the entire state of an application. So when bugs pop up in production — as they often do, despite all of the testing that happens throughout the development process — debugging becomes a real pain point.
Rookout’s solution for this is to instrument the code with “breakpoints that don’t break.” To make this work, you connect Rookout’s online IDE with your code repository on GitHub, Bitbucket or another git hosting service (or with your local file system). The IDE will pull in the code and let you browse it. Developers typically have a hunch about where a bug may be, so when you get to the suspect file, you use Rookout’s visual rule editor to set your virtual breakpoint. Once the production code runs again, all of the data is automatically pushed into the IDE so that you can examine the entire stack trace up to where you set the breakpoint.
All of this works for code that was written in Python and Node.js, as well as for Java virtual machine (JVM) languages like Scala or Kotlin. As for environments, the service currently works for code that’s deployed on AWS, Azure, Google Cloud and local servers, where it can be used with both serverless and containerized applications, too.
While Rookout focuses on collecting data, the team was pretty clear about the fact that Rookout doesn’t want to be an application performance monitoring tool. You can, however, forward your Rookout data to these kind of tools.
Weis and Haimovitch tell me the company now has 14 employees and “dozens” of customers in the pipeline. Looking ahead, the team plans to add support for Go and other languages as the requests come in, and gradually add more IDE support, too.
Like at many a startup, the founders are still working out their pricing model. The current plan is to focus it around the number of hosts that a company is using, though that could still change.
Powered by WPeMatico
Backtrace, a debugging startup led by former AppNexus engineers, raises $5M
Debugging startup Backtrace I/O was launched to solve a real problem that its founders faced when they were engineers at adtech company AppNexus — at least according to Backtrace CEO and co-founder Abel Mathew. Mathew told me Backtrace aims to “solve the process of debugging,” something that most companies tackle by “cobbling together very old, outdated solutions”… Read More
Powered by WPeMatico