Virtualization Technology News and Information
VMblog Expert Interview: Lightrun Discusses Shifting Left Observability in the Service of Taming Wild Production Issues


Lightrun is a run-time observability engine that allows developers to dynamically adapt the observability pillars generated by their applications in real time, based on user context and application state. VMblog spoke with Ilan Peleg, co-founder and CEO of Lightrun, to learn more about how developers can use Lightrun's Continuous Observability solution to tackle difficult production issues.

VMblog:  What are the existing challenges - for both the developers writing the software and the production teams running that software - that Lightrun is trying to solve?

Ilan Peleg:  The information any application reveals about itself is defined today on the left of the software delivery process - during development. However, we observe this information - application logs, metrics and traces - on the right, in production. This workflow creates observability gaps that are painful for organizations building software at scale, and we're hard at work creating the toolchain to close them.

VMblog: What are some of the issues that lead to this gap between development and production environments that you mentioned above?

Peleg:  First, in order to gain more visibility, you need to create "hotfixes" with more logs and metrics - a non-agile, costly and iterative process. Moreover, the information eventually emitted is not granular enough - in the sense that specific users/tenants/system events do not trigger more specific information as they come along. This leaves us to try and understand the full picture without having all the required pieces.

VMblog: Can you explain what Continuous Observability is and how it fits into the narrative?

Peleg:  Observability means you can answer any questions about what's happening on the inside of the system just by observing the outside of the system, without having to ship new code to answer new questions. Continuous Observability is a direct extension of the concept, preferring a more active approach that allows you to answer questions by adding code-level information, without actually shipping any new code.

VMblog: How does employing Continuous Observability help tackle tough production issues in practice?

Peleg:  By adding real-time information - logs, metrics and traces - into the running application and streaming this information back into the developer's existing tools (like his IDE), we get high-value, granular information without incurring the overhead of shipping new code into production. This continuous process maintains developer flow, decreases MTTR and - by extension - reduces developer fatigue. 

VMblog: Can Observability, and how an organization employs it, define a company or departmental culture?  And, more specifically, how do you expect Continuous Observability will impact culture?

Peleg:  Complexity is everywhere in software nowadays - this is why we see companies spending large amounts of time and money on making their systems more observable. Continuous Observability is simply being aware that problems will happen in production, and setting in place the tools and processes that account for them in advance. That way, when an issue arises and the production application contains information gaps, teams can streamline the process of filling them ad-hoc.

Published Friday, October 23, 2020 7:33 AM by David Marshall
Filed under: ,
There are no comments for this post.
To post a comment, you must be a registered user. Registration is free and easy! Sign up now!
<October 2020>