Welcome to another edition of our newsletter. This time we bring you the summary blog of our session w/ Milin Desai, which Naresh Agarwal moderated. We discussed various topics, from observability to open source and their interplay.
As promised, here are the learnings and key takeaways for our readers from the session.
But before we begin…
If you aren’t already a subscriber, please consider subscribing to get early access to all future posts & announcements.
Today’s email might be a trimmed one. Please open it up on a browser to read.
👋 Introducing the panel: Milin and Naresh
For the third session, we had Milin Desai (CEO, Sentry) discuss Observability, Monitoring, and Open Source with the community. Milin currently serves as the CEO of Sentry. He joined Sentry from VMware, where he was responsible for VMware’s cloud strategy, the company’s transition to SaaS, and expanding the portfolio with solutions for the public cloud.
The session was moderated by Naresh Agarwal, a veteran Product and Engineering leader w/ over 2 decades of experience building deep-tech and SaaS/Cloud Platforms. He’s very passionate about DevTools, DevOps, Data Platforms, Cybersecurity, and Open Source. He currently leads engineering for Traceable.ai, an early-stage startup in cloud native API security.
In case you want to, you can watch the entire session here. However, we’ve got you covered with the summary right below.
🗒️ The evolution of software
Software runs the world today, and every company is becoming a software company. These are all different ways of paraphrasing Marc Andreesen’s famous adage: “Software is eating the world”.
Interestingly, however, it’s worth noting and studying how we got here.
In the 2000s, the world was moving into a “software-defined infrastructure” wave where the players like VMware pioneered compute virtualization. And this is a roundabout when networking was moving to software simultaneously.
Subsequently, the past decade has been largely about “Cloud and SaaS”. Infrastructure moved to software but now has become an API. Today, if you’re provisioning infrastructure for an application, you’re likely hitting APIs and no longer worry about auto-scaling the infrastructure or managing physical hardware. Cloud has also enabled us to consume the best services in the form of SaaS - think your favorite event streaming, monitoring, or security services are now available as APIs to consume w/o going through the hassle of figuring out everything yourself.
Per Milin, this has enabled us to move into the decade of data and developers. As infrastructure becomes normalized and a commodity, developers can build and iterate software much faster. Also, the applications are producing a lot of data that can now be harnessed to make decisions that will come out ahead. This requires a lot of investments in data pipelines and data querying capabilities.
There are three key industry trends in parallel →
Open Source & Standardization: Be it Grafana and Prometheus w/ the Observability stack or Kubernetes in Infrastructure, Open Source is becoming mainstream regarding how software is being built today. Also, technologies like Open Telemetry (OTel) are standardizing collection pieces from different end-points, and eBPF is trying to emerge as a way to instrument the kernel for data and insights and enforcement going forward.
Front-end proliferation: With the proliferation of smaller devices w/ increasingly more compute power, the world is moving towards a front-end-driven world. Earlier, it was mostly about backend processing, and now it’s the era of user end.
Consumerization of the product experience: Today, all software has to have a consumer-like product experience.
As a side note, I’ve found it helpful to think of OSS as a means of accomplishing something. Sometimes, it’s an amazing and sustainable way of generating leads by giving away the source code for free. Sometimes it’s a powerful way to build a highly engaged community of power users. Sometimes, it’s a very critical piece of infrastructure that requires strong integrations w/ a lot of infra components and sometimes, it helps bypass the info-sec/IT teams in an org and letting the end-users experience the product.
🧑🏻💻 The rise of Developers and Shift-Left Observability
The culmination of the factors discussed in the previous section brings us to a point where code is the artifact that’s changing the most as the underlying infrastructure becomes normalized. With that in mind, it’s imperative to think about developer-first experience → asking developers to own things like monitoring, security, and privacy isn’t very simple.
The number of developers inside an organization is 5-50x the number of ops and security people. Thus, the things we used to do for them wouldn’t naturally apply to the developer persona. Understanding the persona you’re building for will be very important. People working in IT Operations are used to collecting data from different sources, building a dashboard, and then doing some kind of analytics. But just alerting developers won’t be enough. They want actionable data to determine if an alert is important and how they should go about solving it.
Shift-left means you’re serving a larger audience and community that needs easy answers and have their own preferred set of workflows. Developers do not prefer logging into a product and searching for the problem. They prefer working in Jira or Github or the like and having tight, nifty integrations w/ them is critical for the product's success.
In the entire observability landscape, the left is where the majority of $$s are spent as it deals w/ the following → monitoring, CPU, memory, services, deep database tracing, among others, and all of this is focused on a different persona inside an organization. Product analytics tools like Mixpanel, Amplitude, Pendo, and others play on the extreme right focusing on GTM (Go-To-Market) teams. And in between is the entire opportunity for developer-focused monitoring.
🛅 Sentry’s Journey
Sentry’s initial focus was going all-in and focusing on the front end first. They became the best in Javascript and gave away the entire functionality free as an OSS version. And the SaaS offering for the customers means they’d not have to operationalize Sentry.
Sentry also has a lot of depth regarding the breadth and depth of Javascript frameworks. They started w/ web monitoring and extended their support for mobile only in Year 5. Thus, staying focused on the core problem statement and crafting the best possible developer experience is a critical tenet for success.
A very important takeaway for founders, builders & investors alike is Sentry’s commitment to the SaaS business model and to creating the best SaaS product experience for all of their developer base. They walked away from multiple 6-7 figure deals early on and manically focused on creating a SaaS service that could potentially delight every developer in the world. A tactical example is that Sentry would have possibly done a lot more Java than Javascript if they wanted to focus on large potential customers.
Often startups struggle w/ figuring out their second acts. This is especially true for developer-centric companies. Per Milin, here are a few things/points that would help founders think through this →
Can you be #1 in this market, or will you be #2? If you can be #2, would you be comfortable because you’re already #1 in your primary market?
This will be an adjunct revenue stream, and the product will sell into the install base.
Is the aimed persona the same or different?
In the longevity of Sentry, people advised them to do security but security is a different persona and a separate GTM. Thus, despite possibly being able to do it technology wise, it doesn’t make sense to go out and do it. Moreover, the primary motion of Sentry up until that point was bottoms-up. So any new product needs to be a self-serve product and an easy price point for a frictionless “try & buy” experience.
Sentry did expand into the area of performance as a part of their second act. They tried doing code performance by taking a little bit of what Application Performance Monitoring but for developers w/ a developer-first experience in mind and a frictionless “try & buy” experience. So if you were a developer and were building a new API, you could turn the product on in minutes as opposed to tradition APM solutions that needed a lot of backend instrumentation.
They do leave a part of the market away and integrated it w/ their core business of errors and are in the process of integrating something called dynamic sampling where based on business rules they can control what we store → for instance, you can release samples 100% of the time or 48 hours later, sample reduced down to 30%. Or for enterprise customers, there would be 70% sampling and 60% for their mid-market customers. Doing this dynamically helps the company save money. This was Sentry’s second act and it came in Year 8.
Sentry is also venturing into its Act 3 via an acquisition of Specto and is slowly moving into Replay but Replay in the context of solving all problems of user stories and funnel analysis and the like. The focus remains on software developers and their workflows.
Milin’s advise for companies was to think about winning in Act 1 before thinking of doing other/adjacent things.
Some other core key learnings from Sentry’s journey →
The try & buy motion: Removing friction for users from accessing the product’s value is the single biggest investment of resources for any company, especially if you’re serving developers. OSS or not, making the product easily accessible or providing some value that can be accessed for free helps kick a strong bottoms-up, developer-centric GTM motion.
Community Engagement: Community participation can be thought of in different forms. Contributing more code to the community is one piece but compensating the creators and contributors of open source software components used in building the solution is one very powerful way.
Pricing & Packaging: Pricing & Packaging is a conversion problem for any company, requiring a lot of iterations. A helpful way to think about it is to begin w/ a baseline and then iterate on top of it. For instance, the 2nd SKU of Sentry was offered free to the entire installed base as a part of their base package.
International Sales Expansion: For context, Sentry has 45k+ customers in North America and only hired their first sales rep in Europe this quarter. Thus, it’s possible to get to a lot of scale for many bottoms-up SaaS companies w/o investing in a fleet on the street.
❓Moderator discussion & Audience Q&A
A quick summary of the session by Naresh
Sheer Focus on removing friction for end-users from experiencing value from the product. This is the magic sauce behind how many bottoms-up SaaS companies have scaled. This is especially true for any DevOps or DevTools product.
Decision-making criteria before choosing On-Prem vs. SaaS is super critical in the journey of a company. Many companies have been struggling w/ this for multiple years and taking a clear, hard call of letting go of some enterprise dollars for global product availability and a world-class product experience.
Getting to 45k+ customers in North America by leveraging a strong community-led, bottoms-up GTM motion is a testimony to how powerful the business model is today. Typically, companies in this space think about moving to EMEA in Year 4 and especially in countries like UK, Germany, and France.
Whitespaces and trends in Observability
Monitoring anything has always been about what’s been the most dynamic or most broken in the environment. And back in the day, infrastructure wouldn’t auto-scale. There will be issues w/ things like load balancer or storage. Core Infrastructure monitoring continues to be a great investment area, and there’s a lot of consolidation that’s happening there. Doing a better, cheaper, faster way of metrics monitoring is interesting, but roughly a couple dozen vendors are trying to fight it out there.
Thus, Milin believes that the next big opportunity, in the long run, is monitoring data ranging from everything like → who has access to data, security patterns on top of it, and everything else that follows it. Data and Code observability is where the $$s are at.
Another opportunity here is analytics, but there are many companies there. The avenue for differentiation could be to focus on an underserved persona, which Milin thinks is software builders and data and security teams. This could be an opportunity for new product innovation.
eBPF in the context of Observability
Baseline data collection through OTel (Open Telemetry) and eBPF will become normalized. OTel started at the backend and is now coming to the front end, and it’s taking time. eBPF today is starting at the networking and security domain and will move up the stack.
Builders start thinking of them as a couple of standardized data feeds and figure out how to augment them further in your domain w/ a specific workflow or product architecture.
Milin sees it as an initial data set but not a complete one. Builders can think of leveraging a standardized way of data collection and make intelligent decision-making around customers and what can be done to improve their business outcomes.
eBPF will be one of the standard elements at play because of its adoption in the cloud layer. Its attributes are multi-play w/ a focus on networking, security, and maybe even observability.
Can security and observability be solved w/ the same product?
The entire data instrumentation and collection part are becoming a commodity. OTel and eBPF are making a lot of things standardized. Data collection layer is becoming common for observability and security, but the buyer is different. The buyer personas are different, and the data collection part is common. Does it lead to interesting opportunities?
Persona that cares about security will have to interface w/ a central security team of 5-7 members to look at the supply chain and some of the other elements. As long as those security attributes are delivered in a consumable way in the developer workflow, the CI workflow, or as a part of the pull request, it’s not an additional thing for a developer to do. Baking these components into the CI pipeline to make them a part of the platform would help developers achieve more as well as not hinder their productivity.
Ops and Ops-Sec will likely intersect, and some elements will go all the way to the dev side or truly shift left. But it’ll be a journey. So do you expect your developers to be security aware suddenly every day, or when you’re pulling your next library to update, is it signed, secured, and tested? The sign, secure and test piece of the workflow can be owned by the Ops & Ops-Sec teams vs every developer
Top things that worked for Sentry in the context of PLG
The simplest way to drive initial adoption of the product is to log in w/ Github credentials using SAML or SSO and can experience the value of the product in the first few minutes. Sentry does this remarkably well, and if products can get to this, this is magic for their end-users. Bottoms-up or PLG motions are all about is your product accessible to the desired end-users and if they can get to value.
Accessibility and affordability are the two biggest things for anyone solving anything in infrastructure. If the product can be used for free for a limited time or is very cheap to try and use, it’s game-set-match.
Content in the form of tutorials, walkthroughs, and documentation has to be perfect and invested in. These are core components of a world-class product experience.
Onboarding of customers into the constructs of cloud accounts like AWS, GCP, and Azure has to be seamless too. A security product shouldn’t need admin credentials for the VPC of the customer. There are technology-driven ways to solve this, which are all ways to remove friction from making your product accessible and affordable for your end-user.
It all comes down to reducing the time to value for your end-users and getting them to experience the value of the product w/o anyone involved in the picture. A good piece of the content tutorial should be able to excite the user enough for them to go out and write a piece of content.
If you can solve for accessibility and availability, do you still need Open Source?
If developers can access the software and use it, and it’s affordable, and it delivers value, people will use it. The decision to be completely open-source or not can be made later.
The Open Source Module can be thought of in a variety of ways →
A particular core module of the product will be useful to a lot of people and also drive virality for the product.
Or a baseline of the product is OSS while the rest is not. 80% of the product is OSS, and the remaining 20% is not, as it’s the company's IP, which will be delivered via SaaS.
Or you can think of entirely open-sourcing the product as Sentry did.
It’s also possible to begin w/ a module and then slowly offer the entire product via open source as you mature in the business. This is especially true if the offering is net-new in the market.
But if you’re taking an OSS technology and layering on things on top of it, it’s a very good idea to contribute something back to the community or product since it’s someone else’s work.
Usage-based pricing in DevOps & Observability
If the market segment under consideration is everyone in the world, specifically including mid-market, it becomes very important to consider usage-based pricing. You negotiate pricing and billing in enterprises, but if the desired product route is friction-free SaaS, the following becomes critical for the usage-based pricing model →
The end-user must have clarity on what they’re spending on
Control and filtering on deciding which levers can be used for pricing for the end customer becomes super important
At large-scale volumes, traditional monitoring products are very expensive. There are newer companies in the market that are applying deduplication logic and reducing the bill by half. And some products are doing deduping at the edge.
Sentry’s product gives fidelity right back to the user where the user can apply filters and control the fidelity. If it’s a product release, the fidelity will be turned up, and if it’s in a steady state, they will turn down the fidelity. And all of this is based on rules that the end user is putting in instead of the vendor.
In usage-based pricing, these capabilities will have to increasingly be offered in the product, which has not existed in the monitoring systems up until now. This is an interesting differentiation opportunity in the market for new vendors coming up.
That was it from us for this edition. We had a great time bringing this session and hope you all enjoyed it too. Until next time.
🥁 Join the SourceCode community and attend our next session
To participate live in such sessions and get a chance to ask your questions to some of the best minds building products for technical end-users, we’d need you to do two things →
And sign-up for our next event, which will be announced shortly
If you liked the content, please leave us a “❤️” - it’d mean a lot. If you have any feedback/suggestions on how to improve, please do not hesitate to let us know.
Thank you for reading Source Code. This post is public, so feel free to share it.
