>> From San Mateo, it's theCUBE,
covering Scalyr Innovation Day.
Brought to you by Scalyr.
>> Everyone, welcome to this special CUBE Innovation Day
here in San Mateo, California, Scalyr's headquarters.
I'm John Furrier, host of theCUBE.
We're here with two great guests,
Claudia Carpenter, co-founder,
Dave McCalister who's dev evangelist.
Great to have you guys here,
we were chatting before we came on, thanks for having us.
>> Yeah, great to be here.
>> So, Scalyr, it's all about the logs,
the answer is in the logs.
That's the title of this segment.
Obviously log files, there's a lot of exhaust in there
and data value, extracting that
but it's got more operational impact.
Why is the answer in the logs?
>> Because that's where the real information is,
it's one thing to be able to tell
that something is going wrong on one of your systems,
but what is going wrong?
As engineers what we tend to do is the old printf.
It's like here's everything that I can think of
in this moment and leave it as breadcrumbs
for myself to find later
and then I need to go and look at those bread crumbs.
>> And the challenge is, of course, with this
is that logs themselves are proliferating,
there's lots of data,
there's lots of services that have had this logged
so you got to be able to find your answers
as fast as possible.
You can't afford to wait
for something else to lead you to them,
you need to deep dive right away.
>> You guys have this saying, it's a place to start.
What does that mean and why is that the new approach?
>> What we're trying to differentiate
because there's this trend right now
in the DevOps world towards metrics because they're much
smaller to store,
predigesting what's going on in your systems
and then you display a lot of graphs and things like that.
We agree with that you do need to be able see whats going on
you need to be able to set alerts.
Metrics are good but they only get you so far.
A lot of people go through, look at metrics
dig through and then they stop
and switch over and go to their logs.
We like to start with the logs,
build our metrics from them
and then we go direct to the source.
>> Claudia, take a minute to explain
what you mean by metrics,
because that has multiple meanings because the current way
around metrics and you are kind of taking a new approach
can you just take a minute to explain
what you meant by metrics
and how logs are setting up the metrics
and the difference there?
>> So to me, metrics is just counting things right?
So log files are these long textual representations
of what's going on in my system
and it's impossible to visually parse that.
I mean literally 10,000 lines.
So you count, I've got five of this and six of this one
and it's much smaller to store,
I've got five of this one and six of this one
but that's also not very much information.
So that's really the difference.
>> But we have customers who use their metrics to help
them indicate something might be wrong inside of here
the problem is that modern environments where we have
instant gratification needs and people,
if you wait five seconds
basically that's a lost sale online here,
you need to know what went wrong
not just where went wrong or that something went wrong.
So building for the logs to the metrics,
allows you to also have a perfect tie back to that specific
entrance that let's you figure out what was wrong.
>> You mentioned Claudia, DevOps and this is really kind of
a fun market because DevOps is now going mainstream
and see the enterprise now starting to adopt but still
Gene Kim from Enterprise DevOps estimates
only three percent of the Enterprise really there yet
so the actions on the cloud native, public cloud side
where it's full blown cloud native,
more services are coming, you see Kubernetes,
things of that nature out there
and these services are being stood up and torn down
algorithmically, so who the hell stores that data?
So logs, the nature of log files and data
is changing radically with DevOps
and certainly this is going to be more complications
for developers and figuring out what's-what.
How do you see that?
What is your reaction to that trend?
>> Yeah, so DevOps is a very exciting thing,
when we were at Google, it was sort of like the new thing,
it's that developers had to do their own operations
and that's where this comes from.
Unfortunately a lot of enterprise
will just rename their ops peoples, DevOps.
And that's not the same thing,
it's literally developers doing operations
and right now it's never been so exciting as it is right now
in the text stacks because, you can get so much
that's opens source, pre-built,
glue all these things together,
but since you haven't written the code yourself
you have no idea whats going on so it's kind of like braille,
you got to go back and look and feel your way through it
to figure out what's going on
and that's where logs come into play.
>> So logs essentially can lift up and give people eyesight
into visibility of things that they care about?
>> Absolutely >> So what's this RED thing?
You said something about RED.
What is RED? >> So RED is one
of the approaches, you'll hear things like golden signals,
you'll hear USE, and you'll hear RED.
RED stands for rates, errors, and durations
and RED is a concept that says
how do you actually work
with some of these complex technologies working with,
you're talking about
and actually determine where your problems are.
So if you think about it,
rate is kind of how much traffic is going through a signal.
For this, it's a metric.
It's a cumulative number.
So, back to Claudia's point, it's just a number here
but if your traffic goes up,
you want to know what's going wrong.
Errors self explanatory, something broke, fix it
and then duration is how long things took.
You talked about Kubernetes.
Kubernetes works hand and hand
with this concept of microservices.
Microservices are everywhere
and there can be places that have thousands
of little services, all serving the bigger need here.
If one of them goes slow,
you need to know what went slow as fast as possible.
So rate, duration, and errors actually combine
to give you the overall health of your system while
at the same point,
logs let you figure what is causing those problems.
>> Well I think I'm intrigued by what Claudia
said around this braille concept
because essentially a lot of people,
are flying blind with what's going on,
but you mentioned microservices,
that one area that's coming, you got stateful data,
stateless data, now we're in a API economy,
certainly a state becomes important for these applications.
The developers don't or may not know what's happening
so they need to have some intelligence
also security, we seen in the cloud
when you have a lot of people standing up.
Instances whether it's on Amazon or other clouds,
they don't actually have security, on some of their things
so they got to figure out the trails
of what the data looks like, you need log files
to have understanding of
did something happen, what happened.
What is the bottom line here, Claudia?
What do people kind of do to get visibility,
so they're not flying blind as developers and organizations?
>> Well you got to log everything you can within reason,
you always have to take into account privacy and security
but log as much as you can and pull logs
from every one of the components in your systems.
The microservices that Dave was just talking about
are so cool and as engineers we can't resist them.
We love complexity.
>> And cool things.
>> And cool things, especially cool things.
And new things.
>> And new things. >> And green things.
Sorry, easily distracted.
But they are harder to support
they can be a really difficult environment
so again it's back to breadcrumbs
leaving that trail and being able to go back
and reconstruct what happened.
>> Okay so what's the coolest thing about Scalyr?
Since we talked about cool and relevant.
You guys certainly in the relevant side, I think we've
checked the box there.
What's cool?
What's cool about Scalyr technology?
>> What isn't? >> Tell us.
>> That's a great answer, what isn't?
Honestly when I came to work here, I no idea,
I was familiar with log management,
I was familiar with log search and so forth
and the first time I actually
saw the product, my jaw dropped.
Okay, I now go to a trade show for instance
and I'm showing people the uses
and I hit my return button to get my results
and the show bandwidths can be really bad
and it stalls for 1/10 of a second
and I complain about it now.
There's nothing quite as thrilling
as getting your results as fast as you can think about them
almost your thought process is the slow part
of determining what's going on
and that is mind boggling.
>> So the speed is the killer coolness.
>> The speed is what killed me but honestly,
something that Claudia has been heavily involved in
it takes you two minutes to get started,
I mean there's no long learning curve,
you get the product and you are there, you're ready to go.
>> Claudia , lets talk about ease of use and simplicity
because developers are fickle but they're also loyal if
you have a good product, they love to get in,
they love the freebie,
the 30 day trial, they'll kick the tires on anything
but if the product isn't working, you hear about it.
When it does work, there's mass traffic to it,
people will pound at the doorstep of the product.
What's the compelling value proposition
for the developer out there?
They don't want to waste time, that's like the killer death
to any product for developers, they waste their time
they don't want to deal with it.
>> So we live in the TL;DR world right now,
frankly, if I have to read something,
I usually move on
and that's the approach we take with Scalyr as well,
yes we have some documentation
but I always feel like I have failed
with the user interface design
if I require you to go read the documentation.
So I try to take that into account
with everything that we put out there
making it really easy and fast
to just jump in and try stuff.
>> How do you guys solve the complexity problem?
Through distraction software,
what's the secret sauce for the simplicity of the system?
>> For me it's a complete lack of patience,
it's just like, I wouldn't put up with that,
I'm not going to ask you to.
Frankly, I view, this sounds a little bit trite
but I view software as a relationship
and I view whoever who is looking at it
as a peer of mine and I would be embarrassed
if they couldn't figure it out, if it wasn't obvious.
>> Right.
>> We do have this sort of slope here of people
who really know what going on and people who want to optimize
this is your 80-20 split and people that don't know
and just want to come in
and I want both of them to be happy
so we need to blend those two.
>> Talk about the value proposition
of what you guys have because we've been covering log files,
mentioned log managements, log events we've gone to.
There's been solutions there
that I think maybe going on 10-years-old
that were once cutting edge
but the world changes so fast with Amazon Web Services,
with Google Cloud, with Azure then you got the international
clouds out there as well, it's here.
I mean the scale is there, you got compute you get the edge
of the network right around the corner.
The data problem is not going away,
log files going to be needed you going to have all these data
and exhaust that needs to be valued.
>> If anything there's always going to be more data
that's out there, your going to have more sources
of that data coming in here.
You're talking a little bit about
you're going to have a hybrid cloud
where it's part on-prem, part in the cloud,
you're going to have multi clouds where it crosses boundaries.
You're going to have the wonderful IoT world
where you have no idea when or where
you're going to get an upload from to this
to an edge environment
and you got to worry about those and at the same time
the logging everything, the breadcrumbs,
you have ephemeral events, they're not always there
and those are the ones that will kill you.
So the model is really simple and I applaud Claudia
for concept wise but you are playing with concept of KISS.
Well here it's keep it simple and sophisticated
at the same time, so I can teach you to do this demo
in two minutes flat and from there,
you can teach yourself everything else
that this product is capable of doing, it's that simple.
>> Talk about who the person out there, that you want to use
this product and why should they give Scalyr a look,
what's in it for them?
>> So for me, I think the perfect is to have DevOps
use it, its developer, we really have designed a product
less for ops and more for engineers so one of the things
that is different about Scalyr is you have somebody
come in and set it up, you parse the logs
and ingestion of logs,
which is different than Splunk and Sumo
and then it's ready to use right out of the box.
So, for me I think that our sweet spot
is engineers because a lot of our formulations
of things you do are more technical,
you're thinking about what are the patterns here.
I'm not going to say it's calculus
cos then that wouldn't be simple,
but it's along those lines.
>> For engineers it might be, calc one maybe.
>> Well calculus is fabulous!
>> Also, cloud native is a really key part,
I mean people who are cloud native
or are actually looking at more in the cloud
or cloud migration.
>> We see a lot, for instance, in Kubernetes space
from Cloud Native Computing Foundation.
We're seeing tremendous interest in Prometheus,
we're seeing a lot of interest in Istio Service Mesh.
The nice thing is they're already
all admitting logs themselves.
And so from our viewpoint, we bring them in,
we put them together so now you can look at each piece
and see how it relates to every other piece.
>> Claudia, share with the folks watching this
just some anecdotal use cases of what you guys have used
internally but other customers have.
Give them a feel for how awesome Scalyr is
and what could they expect.
>> Oh boy putting me on the spot here.
>> I'll kickoff.
So we have a customer in Germany,
they're an E-commerce shop.
They have 1,000 engineers, for here.
When we started, the product we replaced
because it was on a charge basis,
that was based per user.
They came back and they said,
"Oh my God, you don't understand, our queries
"are taking 15 minutes to get back.
"By the time the query comes back,
"the engineer has forgotten
"why he asked the question for this."
And so they loaded it up,
they rapidly discovered something unique.
It's that, they can discover things,
'cause anyone can use it.
We now have 500 engineers that touch the log files everyday.
I will attest, having written code myself,
nobody reads log files for fun
but Scalyr makes it easy to discover new things
and new connections and they actually look at what happens.
>> So discovery is a real value proposition.
>> Discovery is a massive value proposition.
Where you figure out things that you don't know about.
Back to that events thing Claudia started about,
was you can only measure the events you already considered.
You can't measure things that didn't happen.
>> Claudia, could we talk about the culture
and Dave you can chime in,
what's the culture like at Scalyr?
>> It is a unique culture
and I know everyone probably says that about their startup
but we keep work-life balance as a very important component.
We're such nerds and unabashed nerds.
We love what we do, it's a joyful atmosphere to work in.
Our founder Steve Newman is there in his flannel shirt
and his socks, cruising around.
And we are very much into our quality of our code,
we have a lot of the principles of Google
sort of combined into a startup.
I would say it's a very honest environment to work in.
>> Solve hard problems, make it a good work environment.
>> Yeah and provide real value!
Provide real value, it's so critical for me.
>> And have fun at the same point and time.
>> Yeah, we do laugh a lot. >> The people here work hard
but they share what they're working on,
they share information,
they're not afraid to answer
the what are you working on question.
But we always manage to have fun,
we are a pretty tight group that way.
>> Well, thanks for sharing the insight,
we are having a lot of fun here
at Innovation Day with theCUBE here,
I'm John Furrier, thanks for watching.
(upbeat music)