We are super thrilled to launch Deepfactor out of stealth today! For the entrepreneur in me, it has been a fascinating journey of discovery….going from a product whose architecture was drawn on a paper napkin at Starbucks to a well-funded, well-positioned tech startup with a solid v1 GA product, with an A+ founding team, super helpful investors and highly supportive early customers. As Deepfactor says ‘Hello World‘ today, I’d like to take a brief pause, and share my journey of discovery so far, with all of you.
Leaving a comfortable job & starting a company from ground zero?
As a serial entrepreneur with a couple of successful exits, it is always a tough decision to go back to the drawing board and start a new company…again. The joy of creating something new, is inseparable from startup drudgery, pay cuts, and going back to being an underdog. While I thoroughly enjoy the bigger impact one can create at a larger organization, when there is a worthy enough problem to solve, I don’t mind being an underdog and pushing that big rock uphill with a smile on my face. So the hard part was not ‘whether to do another startup’…it was ‘what to build to create a bigger impact than my previous ventures’!
When I left Cisco, this was the first thing I had to decide. I took some time off, got some much needed R&R, spent time with family, traveled the world, and got the band back together, teaming up with my (now second time) co-founder & the father of the OpenBSD Hypervisor, Mike Larkin. Over countless Starbucks visits (these were the good old pre-COVID days!) and chai lattes, Mike and I explored a few different ideas. When we presented our initial ideas, we got laughed out of some meetings, went back to the drawing board several times, built a few prototypes, threw some of them away, until the current Deepfactor idea started taking shape.
Why? Because market demand is driving enterprises to deliver software at a much more rapid pace than ever before in the history of software. I’ve been a key believer and contributor to enterprise DevOps journeys since 2015. My previous company, ContainerX, acquired by Cisco and now evolved into the Cisco Container Platform, was aimed at creating one of the essential elements to enabling microservices architectures, one of the key tailwinds behind DevOps.
Today, Continuous Integration (CI) & Continuous Delivery (CD) are two of the key forces that are driving DevOps. These practices allow enterprises to Build Fast, Test Fast & Deploy Fast. They are the seats, engine and tires for your DevOps race-car! But your race-car won’t go too far without all its sensors and dashboard indicators for fuel/oil/pressure etc.. We are missing ‘Monitor Fast’….aka…Continuous Monitoring (CM)
Things we learned from 50+ customer conversations
As we started working on the ideas that created Deepfactor, we had in depth discovery conversations with over 50 engineering teams over the last year and a half, and learned the answers to the following questions:
What does Continuous Monitoring mean in the context of DevOps/pre-production monitoring?
Continuous Monitoring has 3 pillars:
- Know your app behavior
Topology, composition, behavior of your app & how it is changing with each build and which set of code check ins introduced which changes.
- Know your security & compliance
OWASP Top 10 risks, runtime vulnerabilities, indicators of bad behavior, compliance deviations…how that is changing with each build.
- Know your performance
CPU, Memory, API response times…and how they are changing with each release.
What do engineering teams do today to solve this problem?
- Continuous monitoring in pre-production is not a thing …yet!
– Performance & Security testing usually occurs towards the end of the release.
– Monitoring happens after deployment to prod & used by Site Reliability Engineering (SRE) or Cloud Ops teams.
- Current Solutions involve many tools & teams working in silos, with little actionable input for development
– Application Performance Monitoring (APM) tools are for performance. They are used by the Cloud Ops teams, and some dev teams but are built for production, not pre-production monitoring.
– DAST, IAST, Vulnerability testing tools & penetration testing initiatives are run by security teams. They are set up & managed by the AppSec (application security) teams. Several of these tools are more common in production than in pre-production/DevOps, and certainly much less common in early stages of development.
– Many teams fly blind when it comes to application behavior. Some advanced teams use home-grown scripts for basic things like detecting new ports, new web services or new processes created by apps to catch unexpected behaviors.
- There’s a lot of effort and cost delivering very limited value to developers today
– You need to purchase multiple tools, spend time and money to setup & manage them, spend more money for their cloud deployment costs.
– To bring this visibility into pre-production for developers, you need some of the features of all these tools (DAST, IAST, APM & home grown scripts)
– These tools must be setup properly, and strung together into the DevOps pipeline
– You need a DevOps team, with the help of AppSec teams & Cloud Ops/SRE teams to setup and manage all this properly & triage alerts. No clear owner…or multiple owners, which is equally problematic.
The Core Idea
Based on these customer learnings, we came up with the core idea for Deepfactor: building the first ‘Continuous Pre-Production Monitoring’ platform for developers.
The question we kept asking ourselves was: “What if we combined just the right elements of security, performance and behavior visibility into one simple solution, tailor made for pre-production/DevOps environments, and design it for engineering teams?”
This approach removes the pains of buying & managing multiple tools, as well as enabling engineering teams to be the clear owner of Continuous Pre-production Monitoring. Of course, Cloud Ops/SRE teams and AppSec teams can certainly contribute & influence the flows & the triaging process, but the ownership stays with engineering teams, similar to how most engineering teams own their CI & CD tooling today.
And that is how, ladies & gentlemen, we arrived at the lofty ambition for Deepfactor!!
[bring on the confetti!]
After raising investment from Security Leadership Capital , Emergent & a humbling group of high profile silicon valley angels, Mike and I have built a team that has no shortage of rockstars. We are proud of the team we have built, and that has been due to a rigorous interview process. We are now 15 people strong, working across two offices: San Jose, CA and Bangalore, India, along with a couple of consultants. Small but mighty as they call it! Since Covid, we’ve made the strategic decision to hire across the US as well. So remote is A-OK!
The Secret Sauce of Deepfactor
Now let’s geek out a bit and talk about the tech. Here are the main technologies that make Deepfactor different:
#1 – Deep Passive Monitoring™
To arrive at insights around security, performance or behavior, you essentially need the same fundamental application internal telemetry – what system calls is it using, what library calls is it making, what URIs is it doing GETs and POSTs on, what config info does it have, what env vars, what identity info etc.. etc..
We set a lofty goal for ourselves – Unlike the first generation of security & performance monitoring tools, we wanted to get this application telemetry without changing the code, without kernel modules or eBPF, and without language specific instrumentation!
I am proud to say that we have implemented just that…and along the way, filed several patents in this area of 100% user-space-based-instrumentation. We call it Deep Passive Monitoring™. It works seamlessly with both containers and traditional applications.
#2 – Application Runtime Intelligence
The Deepfactor portal backend can be set up either on the cloud (we support AWS today) or on-premises (VMware). It is self-managed today, with a SaaS option in our roadmap.
All the telemetry from the Deepfactor monitored apps is sent to the Deepfactor portal, placed in a time series DB. Anomalies are detected and insights are provided across the 3 pillars of visibility – Know your app, Know your security & compliance, and Know your performance. Insights can be consumed from the Deepfactor portal, OR more commonly, fully integrated into your engineering team’s existing toolset.
To learn more about Deepfactor, please check out our product brief.
What’s next for Deepfactor?
The ability to continuously monitor all the behavioral aspects of your applications in pre-production and as part of the DevOps pipeline is such a game changer for all of us. This ability enables organizations of all sizes to realize the true value of DevOps. It enables every engineering organization to not only ship software rapidly, but ship rapidly with confidence, quality, performance & security.
Engineering teams can now stay ahead of the game and have full visibility into how their apps will behave in production. AppSec teams are welcoming this because these capabilities present a whole new way to partner better with development teams. Cloud Ops/SRE teams are welcoming this because the number of service disruptions in production environments will be significantly fewer thanks to better predictability.
We, therefore, have big dreams to realize! And today, with the general availability (GA) of our version 1, we are just getting started! Over the next few quarters, we will continue to improve the product with more insights across behavior, security, performance & compliance. We will add more integrations and of course, look to serve more community members and customers.
A product like Deepfactor can easily get inundated with feature requests, because there is no limit to how much one can monitor about an app’s behavior. The only way for us to continue to deliver value is to be customer-obsessed and maintain our focus on what matters the most for our customers. We would, therefore, love your feedback.
We’ve curated a list of frequently asked questions about Deepfactor on our knowledge base.
Co-founder & CEO