Get the latest news

Episode 3: Cut Observability Costs (SDTimes Webinar)

In Episode 3 of the microwebinar series with SD Times on the topic of ‘Cut Observability Costs’, Liran Haimovitch, Rookout Co-Founder & CTO, discussed the transformative potential of developer-first observability in minimizing organizational costs. Building upon the previous discussions on snapshots as the fourth pillar of observability and the inherent limitations of logs, the webinar explored how a developer-centric approach to observability can streamline data collection, enhance code understanding, and significantly cut down on superfluous logging and associated expenses.

Key Takeaways:

  1. What is Developer-first Observability? This is a paradigm shift where observability tools are designed to cater to the specific needs of developers, enabling them to dig deeper into code performance and optimize their work. It offers a granular approach to data collection that is dynamic and customizable, unlike traditional black-box monitoring methods.
  2. The Drawbacks of Logging: Standard logging practices can be cumbersome and often yield too much unnecessary data. This ‘just in case’ approach to data collection can drive up costs and diminish the value extracted from the data.
  3. Cost-saving through Developer-first Observability: By allowing developers to decide in real time what data they need to collect, organizations can reduce logging volumes by 80-90%. This not only increases the usefulness of the collected data but also significantly lowers the total cost of ownership.
  4. Shifting Left with Observability: Like testing and security, observability can also be shifted left in the development cycle. This proactive approach makes it more appealing for developers and aligns with their skill sets, resulting in better applications and system performance.
  5. Transitioning to Developer-first Observability: The process involves adopting developer-first observability tools like Rookout and cutting back on default verbosity in logs. Cold storage can be used as an intermediate step to save on logging costs while retaining access to older logs, easing the transition.