Screaming in the Cloud - Saving Vowels and Upping Security with Clint Sharp

Episode Date: August 25, 2021

About ClintClint is the CEO and a co-founder at Cribl, a company focused on making observability viable for any organization, giving customers visibility and control over their data while maximizing value from existing tools.Prior to co-founding Cribl, Clint spent two decades leading product management and IT operations at technology and software companies, including Splunk and Cricket Communications. As a former practitioner, he has deep expertise in network issues, database administration, and security operations.Links:Cribl: https://cribl.ioCribl sandbox: https://sandbox.cribl.ioCribl.cloud: https://cribl.cloudJobs: https://cribl.io/jobs

Hello, and welcome to Screaming in the Cloud, with your host, Chief Cloud Economist at the Duckbill Group, Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud. This episode is sponsored in part by Cribble Logstream. Cribble Logstream is an observability pipeline that lets you collect, reduce, transform, and route machine data from anywhere to anywhere.

Simple, right? As a nice bonus, it helps you not only improve visibility into what the hell's going on, but also helps you save money almost by accident. Kind of like not putting a whole bunch of vowels and other letters that would be easier to spell into a company name. To learn more, visit Cribble.io. That's C-R-I-B-L dot I-O, and tell them Corey sent you, and wait for the wince. And now for something completely different. Welcome to Screaming in the Cloud. I'm Corey Quinn. My guest this week for this promoted episode is Clint Sharp, the CEO and co-founder of a company called Kribble. Clint, thank you for joining me. And let's get the big question out of the way first. What is Kribble? Yeah, so Kribble makes a stream processing engine for log and metric data. And that sounds really

dry and boring, but what it really means is we help connect in the observability and security world lots of log and metric sources. So you can take stuff from anywhere, put it to anywhere. And you can think of it like ETL or you can think of it like middleware. It sits there in this particular space and it's built for SRE and security people.

Now, I looked into this a little bit previously and I had a sneaking suspicion when I started kicking a few of the tires on this, that there's probably going to be an economic story of optimization and saving money because of a couple things. One, that's what I do. I pay attention to things that save customers money in the end run. And two, your company is called Cribble. That's C-R-I-B-L. That should probably have another L, and certainly you should buy a vowel to go in there somewhere. But that's someone optimizing, but still keeping things intact enough to be understood

slash pronounceable. It really does feel like in this space, saving money on vowels is a notable tenant for companies that focus on saving money. Yeah. So what's interesting about enterprises is they care about money and then they don't care about money. And so it's a really good way to get a meeting. We definitely do help people save a ton of money, but ultimately I think what the value people get out of the product is helping connect all the things that they have. And so one of the biggest problems

that we see in the space is, hey, I have like all these agents deployed. Maybe it's FluentD or FluentBit or ElasticBeats or Splunk's Forward. And I want to get this data over to my fancy new data lake or over to my machine learning and AI systems. And maybe I want to put it on a Kafka topic, but it's only designed to work with the thing it's designed to work with. So if I have Beats

deployed, it works with Elastic. Okay, great. How do I also use that same data elsewhere? And really, that's the big problem that we end up solving for our customers. It's the many to many problem. There's a lot of work that's implemented multiple times in multiple ways. It feels like it's effectively logging the same thing 15 different times in 15 different ways. Well, then you look at the endpoint and you find, oh, hey, we've got like eight agents rolled out here, which is, you know, one from each vendor. They're all collecting the same thing. And then people are like, oh man, this is chewing up a ton of resources and we're spending 20 or 30% of every box just like collecting security data and IT data. And couldn't that be better? And then, oh, by the way, each one of those agents has their own security surface area. So you have to make sure that those

agents themselves are secure because they're often making outbound connections. They're listening for inbound connections. So we really kind of help at the edge, help people reuse existing resources. One thing you said a few sentences ago caught me a little bit off guard, and I want to dive into that a little bit. You talked about the observability and security world. Now, every time I talk to folks in one of those two spaces, they're sort of tangentially aware the other one exists on some level, but they're always framed as two very distinct universes, and you talk about them as if they're effectively one and the same. Was that intentional? Well, the data is the same and it

starts there because we're collecting log data and that log data may go into a SIM tool and people are using that to try to understand their security posture and malicious actors and threats. Oh, and by the way, that same log data is also used for understanding the performance and availability of your systems. The same type of metric data is used in both. The same type of catalogs that say, hey, what is my inventory and what assets do I have, and where are they deployed,

and all of that is relevant for both sides. The tooling often ends up being very similar, if not identical. And I used to work at Splunk many years ago. That's a tool that's well known for being popular sort of in both camps. And so I developed this kind of decade long perspective of like, man, I'd show up and like, actually, they're sitting right next to each other. There's DevOps, DevSecOps now, which are now trying to marry those things. And so certainly there's just a ton of overlap. It's still all just sparkling systems administration, but people fight me on that one. Oh yeah. Well, yeah. So SRE is sysadmin+++++. I've told it, what is it? It's SRE if it's in the Mountain View region of

Silicon Valley. Otherwise it's just sparkling DevOps. Yeah. Same story. It's from my perspective, we called ourselves sysadmins. And then if we called ourselves DevOps, but I know, but DevOps isn't a job title. Great, but it is a 40% raise. So I'm going to be quiet about the purity of titles and take the money was my approach back then. And now there are 10 or 15 different ways you can refer to people who are more or less doing the same job. And there's no consistency between company to company in many respects.

They almost become buzzwords and trite at some point, but it's easier than trying to have a 15 minute conversation in response to, so what do you do at whatever company you work at? Well, also the grizzled sysadmin persona, very much now a security person as well, right? So, you know, coming out of that sysadmin lineage, now I have to learn a whole bunch of new words. And security very much is a discipline. What I would criticize as saying it's very gatekeepy in terms of like, okay, we're going to come up with our own vernacular so that we know that you're not one of us. That's one of my big criticisms of security, but the skillset, the same people

who were assist admin 20 years ago are definitely becoming security specialists. They're becoming SREs. And so if you share the same lineage, then you're really not all that different. Well, that's why I launched last week an AWS security newsletter podcast combo that I just recently started launching as of the time that this airs. Because security is everyone's job, but strangely they don't pay everyone like that. And it ties into an entire ecosystem of folks

who have to care about security, but the word security doesn't appear in their job title. And most security products seem to be pitched at the executive level where they use the same tired wording that you'll see on airport ads everywhere, or they're talking to infosec practitioners, whatever those might look at, and tying into, in some cases, a very hostile community. In other cases, they're talking extensively about the ins and outs of how to overcome and defeat particular attack styles or the worst of all worlds, where it just reduces down into compliance and auditing checkboxes, which no one gets super excited about. I'm not interested in any of that.

I want to tell stories about, okay, as someone who has other work to get done, what's the security impact of what's happening lately? How do you round it up and distill it down into something useful instead of something that winds up just acting as a giant distraction and becoming a budget justifier? Well, security detection, I think, is a really fascinating area. You're seeing a lot of consolidation now between traditional SIM companies that Swonk would be in there, but then you've got newer players like Exabeam, you've got newer players like CrowdStrike who are coming from the EDR space, and they're coming very strongly and saying, hey, look, I own the endpoint,

but really what I need to be able to do is analyze all this data. That's where really these things are combining because tell me that XDR is not fundamentally the same, I keep using the word lineage, but the same type of product that I was building a SIM from before. Most people I talk to are having a really hard time, like, what's the difference between XDR and SIEM? Like, aren't these things largely the same? But at the same time, then when you look at observability, it's the same problem. I need to be able to ask and answer arbitrary questions of data. And security and detection is fundamentally the same

problem. I have all this data that's being egressed from my complex systems, all my endpoints, all of my VMs, my containers, all of my infrastructure, all my applications. And I need to be able to detect when somebody's doing something wrong, like some malicious actor is doing something wrong. Tell me that's not observability. Of course it is. And the same problems apply to both, where if I have something happen to my application and my observability tooling doesn't

tell me for 20 minutes, that's kind of a problem, the same way that you have that in the security space. Yet somehow, AWS's CloudTrail takes about that, on average, to wind up surfacing various things that are happening in the environment. In many cases, the entire event can be over by the time CloudTrail says, hey, there's a thing going on. For those who aren't familiar, CloudTrail effectively captures management events that happen talking to the AWS APIs. So someone creates something, someone accesses something, et cetera, et cetera. That's useful when you need that. But if you're going to take action based on that, you kind of want to know sooner rather than later. Same story with any sort of monitoring tool that, oh yeah, the site's taking an outage and our system will let us know in only 20 short minutes. Oh, I assure you, customers will

tell us long before then. That sort of dovetails into some of the things that we see in the marketplace that we help with, which are talk about CloudTrail. People say all data is security relevant, but I have to pay for all that data too. So that data has to go somewhere. Do I care about every cloud? Of course I don't care about every every cloud trail event. I care about some subset of those. Honestly, in the full sweep of time, you really care about that one specific cloud trail thing, but it's the needle in the haystack. And so AWS, this is a constant conflict between people who have to observe and secure systems need all the data because I may not know in advance what question I want to ask. But at the same time, I do know that not all of that is necessarily interesting

right now. And so there's kind of a fundamental tension between, okay, the developer says, well, look, you can't ask a question of data that's not there. So I'm going to put everything in the log, literally every byte of data, everything that I could ever think of, I'm going to go put in that log. And then the receiver of that says, like, I'll give a good example. We've been talking about EDR, CrowdStrike EDR logs, phenomenal data source, have a ton of really interesting information about the security of your endpoints. And they also have like an extra hundred fields that nobody gives a crap about. So what do I do with that data? Do I pay to ingest all that data? Because all my vendors are charging me based off the bytes of data that are going into

their platforms. And so there's a real optimization potential there to have like a really strong opinion on what good data is. Part of the problem, too, is that you absolutely want the totality of everything captured around the specific event you care about. But by and large, we've all been in environments where we have a low traffic app and we see giant piles of web server logs. Okay, great. Let's take a look at what those web server logs are. And by volume, it's 98% load balancer health checks showing up. It seems to me there might either be a way to strip them out entirely or alternately express those in a way that is a

lot more compact and doesn't fill things out. I still feel like there's some terrible company somewhere where their entire way of getting signal from noise is to pay a whole bunch of interns to read the entire log by hand. I like to imagine that that is me speaking hyperbolically, but I'm kind of scared it's not. Yeah. And then the question is like, well, then how do I achieve a goal of actually getting the right data to the right place? So that's something that we help out about. I think that I feel a lot for the persona of this kind of sysadmin, this type of security person, because they're caught in this tension. Like, do I go write code? My skill set as an SRE or my skill set as a security person is being an expert in the data itself. Like, I know that that event is good and I know that event is bad. Am I also supposed to be a person who then needs to go write a bunch of pipelines and Lambda functions? And how do I actually achieve the goal? Because there's always way more demand than there is capacity to be able to onboard all of this data. So fundamentally, how do we get the right thing to the right place?

That's on some level a serious problem. I will say that looking at what you do and how you do it, you take a whole bunch of different disparate data sources and then effectively reduce all of those into passing through the Fribble log stream and then sending the data out to exactly where it needs to go. And I have to imagine that when you talk about what you're doing to typical VCs and whatnot, their question is, ah, but what if AWS launches a thing to do that? To which I can only assume that your response must have been, you're right. If AWS does learn to speak coherently and effectively across all of their internal service

teams, we're going to have a serious problem. At which point I can only imagine that your VCs threw back their heads, you shared a happy laugh, and then they handed you another $200 million, which you have just raised. Congratulations, by the way. Thank you so much. People say a lot of times in startup land, like, oh, we shouldn't celebrate the fundraising. I'll tell you, as a person who's done it a few times, I celebrate. That's a shit load of work. Oh, absolutely. I looked into it in the very early days of, okay, as a person who's done it a few times, I celebrate. That's a shitload of work. Oh, absolutely. I looked into it in the very early days of, okay, as I'm building out what would become the Duckbill Group, do I talk to VCs and the rest?

And I did a little bit of investigation. And it's, wow, it's so much work to build the pitch deck and have all the meetings and wind up doing all of that. I'd rather just go and sell things to customers and see how that works. And, oh, that turned out to raise money that I don't have to repay. Okay, that seems like a different path. And there are advantages and disadvantages to every approach you can take on this. I mean, again, no shade here on how you decide to build out a technology company using VC-backed resourcing, which is a sensible way to do it. But it's a different style. The sheer amount of work that very clearly goes into raising a

fundraising round is just staggering to me. And that's for seed level rounds. I can only imagine down the path, this is not your first round. Yeah. I mean, it's a validation, I think, of where we're going and really kind of our vision, because we've been talking a lot about how data moves. But I think one of the other key concepts that we're advocating for that there's kind of a net new concept in the industry is this concept of an observability lake. And back to that tension of there's always way more data. S3 is an example provides excellent economics, but very few people provide a way for you to use just raw data that I end up going and dumping into S3. And that's really kind of the fallback for like, if I don't know what to do

with this data, I don't want to delete it. Because what if it becomes security relevant? Let's talk about like, you know, the Sunburst SolarWinds attack. Like everybody in the industry wishes that they had every flow log, every log from every endpoint dating back two or three years

so that they could actually go do a detailed investigation of like, okay, that SolarWinds box got breached and what all was it talking to? And they can actually build a graph from that and go understand that. But most people have deleted all that data. They've decided that like, I can't afford to have it anymore. And so really this concept of a lake is like, well, look, I can finally at least put it somewhere as an insurance policy and make sure that that's actually going to be relevant. And then eventually what's going to be happening is people are going to go help you make use of that data. And we will as well be going out there to help you take petabytes and petabytes and petabytes

of log data, metric data, trace data, observability data, and give you the ability to analyze that effectively. My constant complaint about the term data lake, because I've seen this happen in various client environments. AWS will release something that specifically targets data lakes. And I'll talk to my client about that service. This is a data lake solution, but that would be awesome. And they look at me like I'm very foolish and say, yeah, we don't have a data lake,

to which my response is, great, what's that eight petabytes of data sitting in S3? Oh, it's mostly logs. And I don't think that they're foolish. I don't think I'm foolish. But very often, talking to folks who have data lakes do not recognize what they have as being a data lake, because that feels almost like it's a marketing term that has been inflicted on people.

They would consider it, because we all consider it this way, as more of a data morass. You're not really sure what's in there. You're told by your data science teams, who are incredibly expensive, that one day we'll unlock value in all of those web server logs, the load balancer health checks dating back to 2012. But we just don't know what that is yet, but do you really want to risk deleting it? And it becomes this effectively dead stock that sits there. So you want to retain it, particularly if you have compliance obligations. There's theoretically, at least, business value locked up in those things. And you need to be able to access that in a reasonable way.

And anytime I see tooling that winds up billing based upon amount of data stored in it, so, oh, just cut retention significantly. It feels like it cuts against the grain of what they're trying to do. Well, I mean, yeah, retention, I mean, especially for security people, this is the difference between security and operations. This is operations like, last 24 hours a day, I need pretty much after that, give me some aggregated statistics and I'm good. Security people want full fidelity data dating back years. But I think one of the other important concepts

that we haven't seen in the industry and part of what we're trying to change is, you know, when I put data into a tool today, it's that tool's data, right? So, and it doesn't matter which tool it is that I'm putting, they're all the same, but fundamentally I put data into a metrics or time series database. I put data into a logging tool and that data is now owned by that vendor. And the big difference that we see in the concept

of a lake is raw data at rest in S3 buckets or other object storage, depending on your cloud provider, depending on who on-prem is providing you that interface, in a way in which I can choose in the future what tool is going to use to analyze that, and I'm no longer locked in. And I think that's really what we've been trying to advocate as an industry is that every enterprise I talk to has everything. They've got one of every single tool, and none of them are going away. There is no such thing as a single pane of glass. That's like a myth that we've been talking about for 30 freaking years and it's just never actually going to happen. And so really what you need to be able to do is integrate things better

and just make sure that people can actually use the tool that they want to use to analyze the data in the way that they see fit and not be bound by the decision that was made six months ago as to which tool to put it in. This episode is sponsored in part by Thinkst Canary. This might take a little bit to explain,

so bear with me. I linked against an early version of their tool, canarytokens.org, in the very early days of my newsletter. And what it does is relatively simple and straightforward. It winds up embedding credentials, files, or anything else like that that you can generate in various parts of your environment,

wherever you want them to live. It gives you fake AWS API credentials, for example. And the only thing that these are empowered to do is alert you whenever someone attempts to use them. It's an awesome approach to detecting breaches. I've used something similar for years myself before I found them. Check them out. But wait, there's more, because they also have an enterprise option that you should be very much aware of, canary.tools. Take a look at this. What it does is provides an enterprise approach to drive these things throughout your entire environment and manage them centrally. You can even get a physical device that hangs out on your network and impersonates whatever

you want it to. Whenever it gets nmap scanned or someone attempts to log into it or access files that it presents on a fake file store, you get instant alerts. It's awesome. If you don't do something like this, instead, you're likely to find out you've gotten breached the very hard way. So check it out. It's one of those few things that I can look at and say, this is an amazing idea. I am so glad I found them. I love it. Again, those URLs are canarytokens.org and canary.tools. And the first one's free because of course it is. The second one is enterprising. You'll know which one of those you fall into.

Take a look. I'm a big fan. More to come from Thinks to Canary in the weeks ahead. I can tell this story. Why not? I don't imagine it was your direct fault. But nine years ago now, so I should disclaim this. I am not even suggesting this is the way it is today. I was at a startup and we reached out to

Splunk to look at handling a lot of our log analysis needs because it turned out we had a bunch of things that were spewing out logs. Nothing compared to what most sites look at these days, but back then for us, it felt like a lot of data. And we got a quote that was more than the valuation of the company at the time, because it seems like their biggest market headwind at the time was the rise of democracy, basically making monarchies go out of fashion. And there were fewer princesses that we could kidnap for ransom in order to pay the Splunk bill. And to their credit, they reached out every quarter and said, oh, have your needs changed any? No, we have not massively inflated the value of this company so we can afford your bill.

Thank you for asking. But the problem that I had is when I pushed back on this, because it's not just one of those make fun of it and move on stories, because Splunk was at the time very much the best of breed answer here. Their response was, oh, just go ahead and log less. And that brings your bill back into something that's a lot more cohesive and understandable. Which destroys the utility of the whole tool to begin with. Exactly.

The entire reason to have a tool like that is to go through vast quantities of data and extract meaning from it. And if you're not able to do that because you have less data, it completely defeats the value proposition of what it is you're bringing to the table. Because in the security space,

in many ways in the observability space, and certainly in my world of the cost optimization space, it's an optimization story. It does not speed your time to market. It does not increase revenue in almost every case. So it's always going to be a trailing function behind things that do. Companies are structured top to bottom in order to increase revenue and enter new markets with the right offerings at the right times and serve customers, because that can massively increase the value of the company. Reduction and I guess the housekeeping stuff is things people get really excited about for short windows of time, and then not again. It's inconsistent. Yeah, about every time the bill comes due is when they get really excited about it. Exactly. And I have to assume on some level, this was one of

those, okay, first start using it, you'll see how valuable it becomes, and then you'll start logging more data. But it didn't feel right because it's either being disingenuous or it's saying that, oh, don't worry, you'll find the money somehow, which is not true in that scenario. Now, they've redone their pricing multiple times since then. There are other entrants in the market that help us look at data in a bunch of different ways. But across the board, it's frustrating seeing that there are all these neat tools that I wanted to use and I was perfectly positioned to use back then. And now nine years later, when someone says, oh, we use Splunk, my immediate instinctive reaction is, oh, wow, you must have a lot of money to send that on services,

which is not necessarily even close to reality in some cases. But first impressions like that really stick around a long time. Oh, absolutely. They stick around often because they're reaffirmed multiple times throughout people's continued interactions. And I think there's just really a fundamental tension in the marketplace where the value proposition is massive amounts of data. And massive is different depending on the size of your organization.

If you're a big Fortune 100, massive might be 100 petabytes at rest and a petabyte a day of data moving. Or for you, massive might be a terabyte a day moving and maybe 50 terabytes at rest. And by the way, that's not going down. So some of the bigger trends that we're seeing with the advent of zero trust, with the advent of remote work, with just in general growth of cloud, containerized workloads, microservices, people are seeing a lot more data today than they were seeing two years ago, three years ago. And by the way, it's not like, you know, IT went from 2% of the budget to 10% of the budget. The beer of the budget is the same. So I got to do more with less. And it's a tension

between data growth and cost and capacity. And so we got to get smarter. I like the fact that you're saying that you have to get smarter as you think about this from a tool perspective of being able to serve your customers, as opposed to a lot of tooling out there seems to inherently and intrinsically take the worldview. And I don't know if this is an actual choice or just an unfortunate side effect of, yeah, we have to educate our customers because right now our customers are fairly dumb and we'd like it if this is an actual choice or just an unfortunate side effect, of, yeah, we have to educate our customers because right now our customers are fairly dumb and we'd like it if they were smarter.

If you were smart enough to appreciate how we do things, then things will go super well. And I've always found that to be a condescending attitude that doesn't serve customers super well. And it also leaves a lot of money on the table because for better or worse, you have to meet customers where they are, at level of understanding at their expression of the problem. And I've talked to a number of folks over at Kribble and similar to certain large cloud

providers, one of the things that you focus on is the customer. It's clearly a value of the company. How do you think about that? I have a thousand percent agree with you. And for us, what I found after having been a practitioner for a decade and then kind of working my way over to the vendor side, it's really nothing specific about one particular employer. Being a vendor is so complex. Like there's all these things that you're trying to do. You have investors and you have the press and analysts, and you have people who are constantly trying to influence where it is that you're, I need to be in the upper right of the Gartner magic quadrant. So I have to make sure that those analysts, you know, really believe that, you know, what it is that I'm saying.

And then pretty soon, like just nobody even talks about the customer anymore. It's like, well, do people actually want to buy it? Like, is this thing actually solving real problems? And so from the beginning, me and my co-founders, we just wanted to make sure that the concept of the customer was embedded at the core of the company. And every time that an employee at Kribble is interacting and talking about what should we do next and what features should we build and how should we market and how should we sell, let's make sure the customer's there. Customer's first always is the value,

including in how we sell. We actively leave money on the table when it's not in the customer's right interest because we know that we want them to come back and buy from us again later. When we market, we try to make sure that we're speaking to our customers in a language that is their language. When we're building a product, we use the product. We try to make sure that this is actually every day. We don't look at, hey, it needs to look like this and have these features to meet these criteria and be called this. It's just like, well, does it actually help the customer solve a real problem for them? If so, let's build it. And if not, then who gives a ****? Exactly. It's understanding what your customer's pain points are. I mean, I ran into

some similar problems when I was starting my consultancy, where it turns out that I knew people who were more or less top of their class when it came to AWS, Bill, understanding, reconciliation, and the rest. And those are the people I reached out to because I assumed that they knew what they're doing. There must be lots of people like them. Everyone must be like these folks. And I talked to them about how they looked at their AWS bill.

And okay, they said, I would, I'd love to hire you to come in and do this as a consultant, but I would expect this, this, this, this, and this. And okay, I'd better come loaded for bear. And so I did. And it turns out there's a lot more people out there who have never heard of a savings plan or a reserved instance before, or wait, you mean it continues to charge me even after I'm still using it if I don't turn it off? Yes, that is generally how it works. There's nothing wrong with that level of

understanding of these things. Well, there are several things wrong, but that's beside the point. But understanding where folks are and understanding how you can meet them where they are and get them to a better place is way more important than trying to prove that I'm the smartest kid in town when it comes to a lot of the edge case and corner cases and nuanced areas. And so many tools seem to have fallen in love with their own tooling and in love with how smart they are and how clear their lines of thought leadership are that they've almost completely forgotten that there are people in the world who do not think like that, who do not have the level of visibility or deep thought into the problem space. They just know that the logs are unmanageable or the bill for this thing is really expensive or whatever

their expression or experience of that problem is, there are tools out there that can help them. But all of the messaging, all of the marketing distills down to, oh, you must be at least this smart to enter. Like it's an amusement park ride with a weird sign. Software is fundamentally a people business. And when you end up implementing a tool, what's become fascinating to me is I've become the CEO of this company rather than just kind of a product guy. So now I've had to sell and I've had to market it

and I had to start it very much from scratch. Is that like the stuff doesn't get implemented by magic. Like even if they download the tool and it's the easiest to use tool that you've ever used, they still don't have the time to learn all the details

and intricacies of your product. And so, hey, they actually want some professional services people to come go install that. They want a salesperson to help them understand the value. Like I know a lot of people, especially coming from my background

in like SRE or sysadmin from when I was doing it, kind of all salespeople, but like they do a real job. Like they help you articulate the value of this thing so that your bosses understand what you're actually buying.

The sales engineers help you understand like what those features are. And so having a customer aligned company means that every interaction that they have with you needs to be a really, really great interaction so that they want to interact with you again, because fundamentally, even though the bits are really awesome

and they solve this really awesome technology challenge, nobody really cares about it. Ultimately, they're buying from people, they're implementing software built by people and they're calling for support, which is another important part from people who fundamentally care about them as well. So in every interaction, fundamentally software built by people, and they're calling for support, which is another important part, from people who fundamentally care about them as well. So in every interaction, fundamentally software is a people business, and you've got to have the best people and the people that care.

I wish more people took that philosophy because, frankly, it's missing from an awful lot of different expressions of what companies do. It's, oh, if we could make the code just a little bit smarter, a little bit more productive, then we never have to talk to the customer at all. It's, no, you shouldn't write a line of anything before doing a whole bunch of customer research to validate that your understanding of the problem space aligns with theirs. A good way to find out that that doesn't work is to fail for a while too. So we did our fair share of that too, and kind of pontificating and trying to figure out what we thought was best at the market. And it turned out that really what you needed to be able to do was to work closely with

customers and understand their problems and tightly pair that sales cycle, that marketing messaging, that product all towards customer pain. And if you do that, customers are great because they see the people who care and they will reward you by becoming your customer and continuing to advocate for you and talk about you. And it's so rewarding if you can take the right perspective. So we've covered a fair number of things. Your philosophy on the world of security versus observability. We've talked about meeting customers where they are.

We've talked about AWS being so inept at communicating internally and cross-functionally that you're able to raise staggeringly large rounds. And we've talked about, I guess, how we wind up viewing the world of log collection, for lack of a better term. If people want to learn more about what you're up to and how you get there, where can they find you? Yeah, go to kribble.io. If you're a hands-on product person and you just want to see what we do, you can go to sandbox.kribble.io and there's a online learning course. Take about an hour, walk you through the product. We'd love for you to try it. Oh, I don't have to speak to a salesperson? No, you don't have to talk to anybody. You can download the bits. You can try our cloud product for free at Kribble.cloud. We are all about making

sure that engineers can get access to the product before you have to talk to us. And if you think that that's valuable, if this helps you solve a problem, then and only then should you engage with us. And we'll see if we can figure out a way to sell you some software. Customer focused. I'm also going to take a spot check here. I'm going to guess that given your recent funding news, you're also aggressively hiring. We are hiring across every function. And if you are interested in working for a customer's first software company, and this

sounds refreshing, please check out cripple.io slash jobs. And we've got, we're hiring everywhere. I can endorse. We used to hang out back before you wound up starting this place and you were kicking around this idea. I have an idea for a company and my general perception is, I don't know, it doesn't sound like it has legs to me. And well, here we are.

I sure can pick them badly. Clint, thank you so much for taking the time to speak with me. Thanks, Corey. It's been a pleasure. Clint Sharp, CEO and co-founder of Kribble. I'm cloud economist Corey Quinn, and this is Screaming in the Cloud. If you've enjoyed this podcast, please leave a five-star review on your podcast platform of choice. Whereas if you've hated this podcast, please leave a five-star review on your podcast platform of choice, along with an insulting comment telling me exactly why I'm wrong about the phrase data lake, and tell me how many petabytes of useless material you have sitting in S3.

If your AWS bill keeps rising and your blood pressure is doing the same, then you need the Duck Bill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duck Bill Group works for you, not AWS. We tailor recommendations to your business and we get to the point. Visit duckbillgroup.com to get started. This has been a HumblePod production. Stay humble.