>> From San Mateo, it's theCube,
covering Scalyr Innovation Day, brought to you by Scalyr.
>> I'm John Furrier with theCube.
We're here for an innovation day at Scalyr's headquarters
in San Mateo, California.
Profiling the hot startups, technology leaders
and also value prop, as our next guest is Casey Clark,
who's the chief customer officer for Scalyr.
>> Great to see you.
>> Great to see you as well.
>> Thanks for having us.
>> Thanks for coming in.
>> So what does it,
talk about the customer value proposition?
Let's get right to it.
Who are your customers, who are you guys targeting?
Give some examples of what they're dealing with?
>> Yeah, we sell primarily to engineering driven companies.
So you know, the top dog is that the CTO,
they're probably born in the cloud
or moving heavily towards the cloud.
They're using, things like microservices, Kubernetes
maybe starting to look at that server list.
So really kind of forward thinking
engineering driven businesses are where we
start with some of the companies that we work with,
Career Builder, Scripps Networks, Discovery Networks,
a lot of kind of modern E-Commerce,
media, B2B, B2C types of SAS businesses as well.
>> I want to get, I want to drill down that little bit later.
But you know, basically born in the cloud,
seems to be that's a big cloud native.
>> Yep, absolutely.
>> Alright, so you guys are Startup Series, a funded,
which is, in Silicon Valley terms,
you guys are right out right out the gate,
talk about the status of the product,
evolution of the value proposition stages.
You guys are in market selling to customers actively?
What's the status of the products?
Where is it from a customer standpoint?
>> Sure, yeah, we've got, over 300 customers
and so fairly mature in terms of product market status.
We were very fortunate to land some very large customers
that pushed us when we were, you know,
seven so on employees maybe three or four years ago
and so that that forced us to mature very quickly,
large enterprises that had,
we have this one customer Zalando in Germany,
they're one of the largest E-Commerce businesses in Europe,
and they have two, three thousand engineers
using the product on a weekly basis,
and we landed them when it was seven employees,
three or four years ago.
And so that forced us to mature.
And so it was very easy for us
to go to other enterprises and say,
yeah, we can work with you.
And here's the proof points on how
we've helped this business mature,
how they've improved kind of their their speed to truth,
their time to answer whenever they have issues.
>> And so just to kind of back up,
the playbook was early on
when you had seven folks and growing.
Beta status, was that kind of commercially available?
When did it, when was the tipping point
for commercially available, when did that click in?
>> Yeah, that probably tipped
when I joined about a little under four years ago,
I had to convince Steve
that he was ready to sell this product,
as you would expect with a kind of technical founder.
He never thought the product was ready to go,
but they already had maybe a dozen or so
kind of friends and family customers.
And so I kind of came in and went to my network
and started trying to figure out
who are right fits for this.
And we immediately found traction,
the product just stood up and we started pushing and so--
>> And you guys attracted some good talent.
Yes, Silicon Valley Tech leaders are joining you guys,
Which is a great sign when you got talent coming in.
On the customer side, a lot's changed in four years.
Obviously the edge of the network,
when digital transformation has been a punch line,
and kind of a cliche, but now I think it's more real.
As people see the power of scale to cloud, on premise,
you're seeing hybrid multi cloud is being validated.
What is the current customer profile
when you look at pure cloud versus on premise,
are you guys seeing different traction points?
Can you share a little bit of color on that?
>> Yeah, so I talked a little bit about
our ideal customer profile being
of these kind of four categories
E-Commerce, media, B2B SAS, B2C SAS,
most of these companies are running
some production workloads in the cloud,
and probably the majority are in the cloud.
When we started this thing, and it was only AWS
and GCP and Azure were never talked about.
We're seeing significant traction with Azure
and in specific regions, Southeast Asia, GCP is very hot.
So we're seeing a high demand there.
And then with the proliferation of microservices
Kubernetes has absolutely taken off.
I mean, I'll raise my hand and say,
I wasn't sure if it was going to be Kubernetes or Mesos.
Two years ago, I was saying I think Mesos
is going to be the one to bet the company on.
Thank God, we didn't do that and we went with Kubernetes.
And so we're seeing a lot more of kind of
these distributed workloads, distributed team development.
>> Yeah, and that's got a lot of headroom.
Now the, cubeCon was just last week, so it was interesting,
kind of the growth of that whole,
you had service measures right around the corner.
Microservices going to be--
>> Yeah service measures-- >> (mumbles) data.
>> Yeah, for sure it's been,
and that's one of the big problems that we run in with logs
is that people just say they're too voluminous.
It's either too hard to search through it,
it's too expensive, we don't know what to do with it.
And so they're trying to find other ways
to kind of get absorbed mobility.
And so you see kind of the growth
of some of the metrics companies
like Datadog infrastructure monitoring,
phenomenal infrastructure monitoring company.
You've got lots of tracing companies come out.
And really, they're coming out
because there's just so many logs,
it's either too expensive, too hard,
too slow to search through all that data.
That's where your answers live.
And they're just extracting, summarizing value
to to try to kind of minimize
the amount of search that you have to do.
>> Talk about the competition
and because you mentioned a few of them,
Splunk's out there as well
and they went public a couple years ago.
And there's different price points, I get that.
But what's, why can't they scale
to the level that you guys have?
Because and how do you compare to them?
Because I mean, I know data is getting larger,
but what's different about you guys
vis-à-vis the competition?
>> Yeah, absolutely, this is one of the reasons
why I joined the company, what excites me the most
is I get to go talk to engineers, and I can just talk shop,
I don't really talk about the business value quite as much
we get there at some point, obviously.
But we made some some very key decisions
early on the company's history.
I mean, really, before the company started
to kind of main backend architectural decisions.
One, we don't use Elasticsearch, Lucene,
any sort of keyword indexing,
which is what almost every single logging tool
uses on the backend.
Keyword indexes, Elasticsearch are great
for human legible words, relatively stale lists,
where you're not looking through
infinite numbers of high cardinality kind of machine data.
So we made an optimized decision to use a NO SEQUEL,
databases proprietary columnar database.
So that's one aspect of things,
how we process and store the data is highly efficient.
The other piece is, we're a SAS business,
but we're true SAS, we're true multi tenant.
And so when you put a query into Scalyr, every CP corn,
every server is executing on just that query.
It's very similar the way Google Search works.
So not only do we get better performance,
we get better costs and better scalability
across all of our customers.
>> And you guys do sell to a engineering lead buyer,
and you mentioned that.
A lot of SAS companies, a lot of companies
are trying to come in and sell that market.
Bump into people who want to build their own.
I don't need your help, because I might get fired
or might not make me look good.
That seems to be a go to market dynamic
and or consumption piece.
What's your response to that?
How does that, how's that fared for you guys?
>> Engineers want to engineer,
whether it's the right thing or not, right?
And so that that is always hard,
and I can't come in and tell you your baby's ugly, right?
Because your baby's beautiful in your eyes.
And so, that is a hard conversation to have.
But that's why I kind of go back to what I was saying is,
we just talk shop, we talk about, you know,
the engineering decisions around you know,
is that the right database, is this the right architecture,
and I think they start nodding and nodding and nodding,
and then we say and the values
are going to be X, Y and Z, cost performance scalability.
And so when you kind of get them to understand that
Elasticsearch is great for a lot of things
product search, web search, phenomenal,
but log management, high cardinality machine data,
it's not what it's designed for.
And okay, okay, okay, and then we start to get them
to come around and say, not only can you reallocate, I mean,
we talked about how getting talent is hard,
well let's put them back on
mission critical business, engineering objectives.
And we get, you know, a service that this is all we do,
like, you can have a couple people on their part time
managing a logging service.
This is all we do.
And so you get things like tracing
that we're rolling out this quarter,
better cost optimization, better scalability,
things that you would never get with an open source--
>> So the initial reaction might be to go in and sell on
"Hey, it's cheaper solution, economic buyer",
not really for these kinds of products
because you're dealing with engineers.
They want to talk shop first,
that seems to be the playbook.
>> Yeah, our hardest is getting that first meeting,
getting the first meeting is hard
because you know, they're busy, everybody's busy,
they just wave you off, they ignore the email,
the calls and we get that.
But once we get in, we have kind of this consultative
conversation around why we made these technology decisions.
They get it.
>> Let's do a first meeting right now.
People watching this video,
what's the architectural advantages, let's talk shop.
Why you guys?
>> Yeah, absolutely, so kind of two technical
differentiators, and then three sort of benefits
that come from those two technical choices.
One is what I mentioned this proprietary,
columnar, no sequel database,
specifically designed for kind of high cardinality,
machine data, right, there is no indexes
that need to be backed up or tuned.
You know, it's a massively parallel to Grep
to its simplest form.
So one piece is that database.
The other piece is that architecture, where we get,
one, performance benefits of throwing
every CP core and every server on just your query,
very simple, the way Google Search works.
If I go say, How do I make a pizza in Google?
It's not like it goes to like a Case C server
in a data center and Alaska and runs for a bit.
They're throwing a ton of compute power at every query.
So there's the performance piece,
there's the scalability piece.
We have one huge, massive pool of shared compute resources
and so your log volume can spike
but relative to the capacity we have,
it means nothing right?
But all these other services that are single tenant,
hosted services, you know, there's a capacity limit
and you, a single customer, if your log volume doubles,
well, it wasn't designed to handle
that log volume doubling.
And then the last piece is the cost.
There's a huge economy as a scale, shared services,
we run the system at a significantly lower cost
than what anybody else can.
And so you get cost benefits,
performance benefits and scalability--
>> In the life of the engineer, your buyer here,
what are some of the Day in the Life use case,
pain in the butts that they have, I mean, it's a challenge.
DevOps is basically usually the people
who do DevOps are pretty hardcore.
And they love it, and they tend to love
the engineering side of it.
But what are the hassles with them.
>> Yeah, yeah, >> That you saw.
Yeah so kind of going back to what we're all about.
We're all about speed to truth, right?
And in kind of a modern environment
where you're deploying every day, multiple times per day,
a lot of times there's no QA,
you're deploying directly to production, right?
And your kind of butt is on the line,
when that code goes live.
You need to be able to kind of get
speed to truth as quickly as possible, right.
You need to be able to identify when a problem went wrong
or when something went wrong immediately.
And then you need to be able
to come up with a resolution, right?
There's always two things that we always talk about
meantime to restore and meantime to resolution, right?
There is, you know, maybe the SREs
are responsible for meantime to restore.
So they're in Scalyr, they get an alert,
they're immediately diving through the logs to figure out,
okay, it's this service, either we need to restart it,
or how do we kind of just put a bandaid on top it
to make sure our customers don't see it, right?
And then it gets kicked over to the developer
who wrote the code and say,
Okay, now meantime to resolution,
how long until we figure out what went wrong?
And how do we fix it to make sure it doesn't happen again,
and that's where we help.
>> You know, it's interesting, Casey,
you mentioned the resolution piece.
A lot of engineers that become,
operationalize through your service,
not operations, people just being called DevOps,
is that they have to actually do this as an SLA basis,
when they do a lot of API to API,
it only gets more complicated with service meshes.
Right, well, these microservices frameworks
because now you have services being stood up and torn down
literally without human intervention.
So this notion of having a path of validation,
working with other services is a,
could be a pain in the butt, big time.
>> Yeah, I mean, it's very difficult.
We've, you know, with some of these
large organizations we work with,
they've tried to build their own service meshes,
and they've, you know, got into a massive conference room
and tried to write out all the different services
that are out there.
And the reality is, they can't figure out
there's no good way for them to map out, like,
who talks to what, when, and each little service knows,
like, okay, well, here's the downstream effects.
And they kind of know what's next to them.
They know their adjacencies,
but they don't really know much further than that.
And the nice thing about logs
and all kind of the voluminous data that is in there,
which makes it very difficult to manage,
but the answers are in there, right.
And so we provide a lot of value
by giving you one place to look through all of that.
>> At cubeCon, this has been a big topic
because a lot of times just to be more hardcore
is that there could be downtime on the services,
they don't even know about it.
>> Yeah, yeah, that's exactly right.
>> So discovering and visualizing that or surfacing is huge.
>> Yeah.
>> Okay, what's the one thing that people
should know about Scalyr that haven't talked to you guys
or know about you guys should know about you guys, consider?
>> Yeah, I mean, I think the reality is,
everybody's trying to move as quickly as possible
and there is a better way observability,
telemetry, monitoring, whatever you call your team
is core to the business, its core to moving faster,
its core to providing a better user experience.
And we have spent a significant amount of time
building unique technology to support your business' growth.
And I think you can look at the benefits,
I've talked about them cost performance scalability, right.
But these align well with whatever you're looking at,
if it's P&L, if it's service uptime.
That's exactly what we provide as a tool
to help you give a better experience to your own customers.
>> Casey, thanks for spending the time
and sharing that insight.
Of course, we love speed to truth.
So our motto at theCube, we go to the events
and try to get the data out there.
We're here at the Innovation Day at Scalyr's headquarters,
I'm John Furrier, thanks for watching.
(technological music)