(upbeat music)
>> Hello, welcome to this CUBE conversation
I'm John Furrier your host here in theCUBE
in Palo Alto, California,
featuring Cribl a hot startup taking over the enterprise
when it comes to data pipelining,
and we have a CUBE alumni who's the co-founder and CEO,
Clint Sharp.
Clint, great to see you again,
you've been on theCUBE, you were on in 2013,
great to see you, congratulations on the company
that you co-founded,
and leading as the chief executive officer
over $200 million in funding,
doing this really strong in the enterprise, congratulations
thanks for joining us.
>> Hey, thanks John it's really great to be back.
>> You know, remember our first conversation
the big data wave coming in, Hadoop World 2010,
now the cloud comes in, and really the cloud native
really takes data to a whole nother level.
You've seeing the old data architectures being replaced
with cloud scale.
So the data landscape is interesting.
You know, Data as Code you're hearing that term,
data engineering teams are out there,
data is everywhere, it's now part of how developers
and companies are getting value whether it's real time,
or coming out of data lakes,
data is more pervasive than ever.
Observability is a hot area,
there's a zillion companies doing it,
what are you guys doing?
Where do you fit in the data landscape?
>> Yeah, so what I say is that Cribl and our products
and we solve the problem for our customers
of the fundamental tension between data growth and budget.
And so if you look at IDCs data
data's growing at a 25%, CAGR,
you're going to have two and a half times the amount of data
in five years that you have today,
and I talk to a lot of CIOs,
I talk to a lot of CISOs,
and the thing that I hear repeatedly
is my budget is not growing at a 25% CAGR so fundamentally,
how do I resolve this tension?
We sell very specifically into the observability
in security markets, we sell to technology professionals
who are operating, you know, observability in security
platforms like Splunk, or Elasticsearch, or Datadog,
Exabeam, like these types of platforms
they're moving, protocols like syslog, they're moving,
they have lots of agents deployed on every endpoint
and they're trying to figure out how to get the right data
to the right place,
and fundamentally you know, control cost.
And we do that through our product called Stream
which is what we call an observability pipeline.
It allows you to take all this data,
manipulate it in the stream and get it to the right place
and fundamentally be able to connect all those things
that maybe weren't originally intended to be connected.
>> So I want to get into that new architecture
if you don't mind, but let me first ask you
on the problem space that you're in.
So cloud native obviously instrumentating,
instrumenting everything is a key thing.
You mentioned data got all these tools,
is the problem that there's been a sprawl of things
being instrumented and they have to bring it together,
or it's too costly to run all these point solutions
and get it to work?
What's the problem space that you're in?
>> So I think customers have always been forced
to make trade offs John.
So the, hey I have volumes and volumes and volumes of data
that's relevant to securing my enterprise,
that's relevant to observing and understanding
the behavior of my applications
but there's never been an approach that allows me
to really onboard all of that data.
And so where we're coming at is giving them the tools
to be able to, you know, filter out noise and waste,
to be able to, you know, aggregate this high fidelity
telemetry data.
There's a lot of growing changes,
you talk about cloud native, but digital transformation,
you know, the pandemic itself and remote work
all these are driving significantly greater data volumes,
and vendors unsurprisingly haven't really been
all that aligned to giving customers the tools
in order to reshape that data, to filter out noise and waste
because, you know, for many of them they're incentivized
to get as much data into their platform as possible,
whether that's aligned to the customer's interests or not.
And so we saw an opportunity to come out
and fundamentally as a customers-first company
give them the tools that they need,
in order to take back control of their data.
>> I remember those conversations
even going back six years ago
the whole cloud scale, horizontally scalable applications,
you're starting to see data now being stuck in the silos now
to have high, good data you have to be observable,
which means you got to be addressable.
So you now have to have a horizontal data plane if you will.
But then you get to the question of, okay,
what data do I need at the right time?
So is the Data as Code, data engineering discipline
changing what new architectures are needed?
What changes in the mind of the customer
once they realize that they need this new way to pipe data
and route data around, or make it available
for certain applications?
What are the key new changes?
>> Yeah, so I think one of the things that we've been seeing
in addition to the advent of the observability pipeline
that allows you to connect all the things,
is also the advent of an observability lake as well.
Which is allowing people to store
massively greater quantities of data,
and also different types of data.
So data that might not traditionally fit
into a data warehouse, or might not traditionally fit
into a data lake architecture,
things like deployment artifacts,
or things like packet captures.
These are binary types of data that,
you know, it's not designed to work in a database
but yet they want to be able to ask questions like, hey,
during the Log4Shell vulnerability,
one of all my deployment artifacts
actually had Log4j in it in an affected version.
These are hard questions to answer in today's enterprise.
Or they might need to go back to full fidelity packet
capture data to try to understand that,
you know, a malicious actor's movement
throughout the enterprise.
And we're not seeing, you know,
we're seeing vendors who have great log indexing engines,
and great time series databases,
but really what people are looking for
is the ability to store massive quantities of data,
five times, 10 times more data than they're storing today,
and they're doing that in places like AWSS3,
or in Azure Blob Storage, and we're just now starting to see
the advent of technologies we can help them query that data,
and technologies that are generally more
specifically focused at the type of persona that we sell to
which is a security professional, or an IT professional
who's trying to understand the behaviors
of their applications,
and we also find that,
you know, general-purpose data processing technologies
are great for the enterprise, but they're not working
for the people who are running the enterprise,
and that's why you're starting to see the concepts
like observability pipelines and observability lakes emerge,
because they're targeted at these people
who have a very unique set of problems
that are not being solved by the general-purpose
data processing engines.
>> It's interesting as you see the evolution
of more data volume, more data gravity,
then you have these specialty things
that need to be engineered for the business.
So sounds like observability lake
and pipelining of the data, the data pipelining,
or stream you call it,
these are new things that they bolt into the architecture,
right? Because they have business reasons to do it.
What's driving that? Sounds like security is one of them.
Are there others that are driving this behavior?
>> Yeah, I mean it's the need to be able to observe
applications and observe end-user behavior
at a fine-grain detail.
So, I mean I often use examples
of like bank teller applications, or perhaps,
you know, the app that you're using to,
you know, I'm going to be flying in a couple of days.
I'll be using their app to understand
whether my flight's on time.
Am I getting a good experience
in that particular application?
Answering the question of is Clint getting a good experience
requires massive quantities of data,
and your application and your service,
you know, I'm going to sit there and look at,
you know, American Airlines which I'm flying on Thursday,
I'm going to be judging them based on off of my experience.
I don't care what the average user's experience is
I care what my experience is.
And if I call them up and I say, hey,
and especially for the enterprise
usually this is much more for,
you know, in-house applications and things like that.
They call up their IT department and say,
hey, this application is not working well,
I don't know what's going on with it,
and they can't answer the question
of what was my individual experience,
they're living with, you know, data that they can afford
to store today.
And so I think that's why you're starting to see the advent
of these new architectures
is because digital is so absolutely critical
to every company's customer experience,
that they're needing to be able to answer questions
about an individual user's experience
which requires significantly greater volumes of data,
and because of significantly greater volumes of data,
that requires entirely new approaches
to aggregating that data, bringing the data in,
and storing that data.
>> Talk to me about enabling customer choice
when it comes around controlling their data.
You mentioned that before we came on camera
that you guys are known for choice.
How do you enable customer choice
and control over their data?
>> So I think one of the biggest problems I've seen
in the industry over the last couple of decades
is that vendors come to customers
with hugely valuable products that make their lives better
but it also requires them to maintain a relationship
with that vendor in order to be able to continue
to ask questions of that data.
And so customers don't get a lot of optionality
in these relationships.
They sign multi-year agreements,
they look to try to start another,
they want to go try out another vendor,
they want to add new technologies into their stack,
and in order to do that they're often left with a choice of
well, do I roll out like get another agent,
do I go touch 10,000 computers,
or a 100,000 computers in order to onboard this data?
And what we have been able to offer them
is the ability to reuse their existing deployed footprints
of agents and their existing data collection technologies,
to be able to use multiple tools and use the right tool
for the right job, and really give them that choice,
and not only give them the choice once,
but with the concepts of things like the observability
lake and replay, they can go back in time and say,
you know what? I wanted to rehydrate all this data
into a new tool, I'm no longer locked in
to the way one vendor stores this,
I can store this data in open formats
and that's one of the coolest things
about the observability late concept
is that customers are no longer locked in
to any particular vendor,
the data is stored in open formats
and so that gives them the choice
to be able to go back later and choose any vendor,
because they may want to do some AI or ML on that type of data
and do some model training.
They may want to be able to forward that data
to a new cloud data warehouse, or try a different vendor
for log search or a different vendor for time series data.
And we're really giving them the choice
and the tools to do that
in a way in which was simply not possible before.
>> You know you are bring up a point
that's a big part of the upcoming AWS startup series
Data as Code, the data engineering role
has become so important and the word engineering
is a key word in that, but there's not a lot of them, right?
So like how many data engineers are there on the planet,
and hopefully more will come in,
come from these great programs in computer science
but you got to engineer something
but you're talking about developing on data,
you're talking about doing replays and rehydrating,
this is developing.
So Data as Code is now a reality,
how do you see Data as Code evolving from your perspective?
Because it implies DevOps,
Infrastructure as Code was DevOps,
if Data as Code then you got DataOps,
AIOps has been around for a while,
what is Data as Code? And what does that mean to you Clint?
>> I think for our customers, one, it means a number of
I think sort of after-effects
that maybe they have not yet been considering.
One you mentioned which is it's hard to acquire that talent.
I think it is also increasingly more critical
that people who were working in jobs
that used to be purely operational,
are now being forced to learn,
you know, developer centric tooling,
things like GET, things like CI/CD pipelines.
And that means that there's a lot of education
that's going to have to happen because the vast majority
of the people who have been doing things in the old way
from the last 10 to 20 years,
you know, they're going to have to get retrained and retooled.
And I think that one is that's a huge opportunity
for people who have that skillset,
and I think that they will find that their compensation
will be directly correlated to their ability
to have those types of skills,
but it also represents a massive opportunity
for people who can catch this wave and find themselves
in a place where they're going to have a significantly
better career and more options available to them.
>> Yeah and I've been thinking about what you just said
about your customer environment
having all these different things like Datadog
and other agents.
Those people that rolled those out can still work there,
they don't have to rip and replace and then get new training
on the new multiyear enterprise service agreement
that some other vendor will sell them.
You come in and it sounds like you're saying, hey,
stay as you are, use Cribl,
we'll have some data engineering capabilities for you,
is that right? Is that?
>> Yup, you got it.
And I think one of the things that's a little bit different
about our product and our market John,
from kind of general-purpose data processing
is for our users they often, they're often responsible
for many tools
and data engineering is not their full-time job,
it's actually something they just need to do now,
and so we've really built tool that's designed for
your average security professional,
your average IT professional,
yes, we can utilize the same kind of DataOps techniques
that you've been talking about, CI/CD pipelines, GITOps,
that sort of stuff, but you don't have to,
and if you're really just already familiar
with administering a Datadog or a Splunk,
you can get started with our product really easily,
and it is designed to be able to be approachable
to anybody with that type of skillset.
>> It's interesting you, when you're talking
you've remind me of the big wave that was coming,
it's still here, shift left meant security
from the beginning.
What do you do with data shift up, right, down?
Like what do you, what does that mean?
Because what you're getting at here
is that if you're a developer, you have to deal with data
but you don't have to be a data engineer
but you can be, right?
So we're getting in this new world.
Security had that same problem.
Had to wait for that group to do things,
creating tension on the CI/CD pipelining,
so the developers who are building apps had to wait.
Now you got shift left, what is data,
what's the equivalent of the data version of shift left?
>> Yeah so we're actually doing this right now.
We just announced a new product a week ago
called Cribl Edge.
And this is enabling us to move processing of this data
rather than doing it centrally in the stream
to actually push this processing out to the edge,
and to utilize a lot of unused capacity
that you're already paying AWS, or paying Azure for,
or maybe in your own data center,
and utilize that capacity to do the processing
rather than having to centralize and aggregate
all of this data.
So I think we're going to see a really interesting,
and left from our side is towards the origination point
rather than anything else,
and that allows us to really unlock a lot of unused capacity
and continue to drive the kind of cost down
to make more data addressable
back to the original thing we talked about
the tension between data growth,
if we want to offer more capacity to people,
if we want to be able to answer more questions,
we need to be able to cost-effectively
query a lot more data.
>> You guys had great success in the enterprise
with what you got going on.
Obviously the funding is just the scoreboard for that.
You got good growth, what are the use cases,
or what's the customer look like
that's working for you where you're winning,
or maybe said differently what pain points
are out there the customer might be feeling right now
that Cribl could fit in and solve?
How would you describe that ideal persona,
or environment, or problem, that the customer may have
that they say, man, Cribl's a perfect fit?
>> Yeah, this is a person who's working on tooling.
So they administer a Splunk, or an Elastic, or a Datadog,
they may be in a network operations center,
a security operation center,
they are struggling to get data into their tools,
they're always at capacity,
their tools always at the redline,
they really wish they could do more for the business.
They're kind of tired of being this department of no
where everybody comes to them and says, "hey,
can I get this data in?" And they're like, "I wish,
but you know, we're all out of capacity,
and you know, we have, we wish we could help you
but we frankly can't right now."
We help them by routing that data to multiple locations,
we help them control costs by eliminating noise and waste,
and we've been very successful at that in,
you know, logos, like, you know, like a Shutterfly,
or a, blanking on names, but we've been very successful
in the enterprise, that's not great,
and we continue to be successful with major logos
inside of government, inside of banking, telco, et cetera.
>> So basically it used to be the old hyperscalers,
the ones with the data full problem,
now everyone's got the, they're full of data
and they got to really expand capacity
and have more agility and more engineering
around contributions of the business
sounds like that's what you guys are solving.
>> Yup and hopefully we help them do a little bit more
with less.
And I think that's a key problem for our enterprises,
is that there's always a limit
on the number of human resources that they have available
at their disposal, which is why we try to make the software
as easy to use as possible,
and make it as widely applicable
to those IT and security professionals who are,
you know, kind of your run-of-the-mill tools administrator,
our product is very approachable for them.
>> Clint great to see you on theCUBE here,
thanks for coming on.
Quick plug for the company, you guys looking for hiring,
what's going on? Give a quick update,
take 30 seconds to give a plug.
>> Yeah, absolutely.
We are absolutely hiring cribl.io/jobs,
we need people in every function from sales, to marketing,
to engineering, to back office, GNA, HR, et cetera.
So please check out our job site.
If you are interested it in learning more
you can go to cribl.io.
We've got some great online sandboxes there
which will help you educate yourself on the product,
our documentation is freely available,
you can sign up for up to a terabyte a day on our cloud,
go to cribl.cloud and sign up free today.
The product's easily accessible,
and if you'd like to speak with us
we'd love to have you in our community,
and you can join the community from cribl.io as well.
>> All right, Clint Sharp co-founder and CEO of Cribl,
thanks for coming to theCUBE.
Great to see you, I'm John Furrier your host
thanks for watching.
(upbeat music)