Screaming in the Cloud - Handling Time-Series Data with Brian Mullen

Episode Date: December 1, 2021

About BrianBrian is an accomplished dealmaker with experience ranging from developer platforms to mobile services. Before InfluxData, Brian led business development at Twilio. Joining at just thirty-five employees, he built over 150 partnerships globally from the company’s infancy through its IPO in 2016. He led the company’s international expansion, hiring its first teams in Europe, Asia, and Latin America. Prior to Twilio Brian was VP of Business Development at Clearwire and held management roles at Amp’d Mobile, Kivera, and PlaceWare.Links:InfluxData: https://www.influxdata.com

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 my friends at Thinkst Canary. Most companies find out way too late that they've been breached,

and Thinkst Canary changes this, and I love how they do it. Deploy Canaries and Canary tokens in minutes and then forget about them what's great is that then attackers tip their hand by touching them giving you one alert when it matters i use it myself and i only remember this when i get the weekly update with a we're still here so you're aware from them it's glorious there's zero admin overhead to this there are effectively no false positives unless i do something foolish. Canaries are deployed and loved on all seven continents. You can check out what people are saying at canary.love.

And their kubeconfig canary token is new and completely free as well. You can do an awful lot without paying them a dime, which is one of the things I love about them. It's useful stuff and not a, oh, I wish I had money. No, it is spectacular. Take a look. That's canary.love because it's genuinely rare to find a security product that people talk about in terms of love. It's really just a neat thing to see. Canary.love, thank you to Thinks Canary for their support of my ridiculous, ridiculous nonsense. Writing ad copy to fit in a 30-second slot is hard, but if anyone can do it, the folks at Quali can. Just like their Torque infrastructure automation platform can deliver complex application environments anytime, anywhere, in just seconds instead of hours, days, or weeks. Visit qtorque.io today to learn how you can spin up application environments in about the same amount of time as it took you to listen to this ad.

Welcome to Screaming in the Cloud. I'm Corey Quinn. This promoted guest episode is brought to us by our friends at Influx Data. And my guest is titled as the chief marketing officer at Influx, and I don't even care because his bio has something absolutely fascinating that I want to address instead. Brian Mullen is an accomplished dealmaker, is how the bio starts. And so many of us spend time negotiating deals, but so few people describe ourselves in that way. First, Brian, thank you for joining us. And secondly, what's up with that? Well, thanks, Corey. Very excited to be here. And yes, dealmaker, I guess that would be apropos.

How did I get into marketing? Well, a lot of my career is spent in business development. And so I think that's where the dealmaker part comes from. Several different roles, including my first role at Influx when I joined Influx, was in business development and partnerships. And so prior to coming to Influx, I spent many years building out the business development team at Twilio, growing that up. And we did a lot of deals with carriers, with cloud partners, with all kinds of different partners.

You name it, we worked with them. And then moving into Influx, joined in a BD capacity here and had a couple different roles that eventually evolved to chief marketing officer. But yeah, that's where the dealmaker comes from. I like to do deals. It's always nice to have one kind of on the side when whatever capacity you're working in, it's nice to have a deal or two working on the side, kind of keeps you fresh. It's fun because people think, oh, a deal. You're thinking mergers and acquisitions, and how hard could that be? You just show up with a bag of money and give it to people, and then you have a deal closed. And oh, if only it were that simple. Every client engagement we

have on the consulting side has been a negotiation back and forth. And the idea is to ideally get everyone to the point where they're happy. But honestly, if everyone's slightly unhappy but can live with the result, we'll take that too. And as people go through their own careers, it's, you're always trying to make a deal in some form when you're trying to get a project approved or you're trying to get resources thrown at something, by which I generally mean money, not people,

though people do. It's something that isn't necessarily clearly understood or discussed very often, despite the fact that half of what I do is negotiating with AWS on behalf of clients for better contractual terms. The thing that I think takes people by surprise the most is that dealmaking is almost never about pounding the table, being angry, and walking out like you read the world's worst guide to buying a car or something.

It's about finding the win for everyone. At least that's the way I always approached it. That's a good point. And actually, that wording that you described of finding a win for everybody, that's how I always thought about it. I think about it as, first of all, you're trying to understand what the other party, and it could be an individual, it could be a company, it could be a group of companies sometimes. You're trying to understand what their goals are, what their agenda is, and see how that matches with your own. Sometimes they're opposing. Sometimes they're overlapping.

And then everyone has to have some perceived win, I think, in a deal. And it's not competitively. It's more like you just have to have value. That is kind of what the win is, is having value in that deal. And so that's the way I always approached it. And doing deals, whether you're in BD or sales, or if you're working with vendors and you're in like a different functional role, sometimes it's not even commercial. It's just about aligning resources, perhaps. Like our deal might be that you and I are both going to put a collective effort into build something or take something to market. In another scenario, it might be like, I'm going to

pay for this service that you're delivering, or vice versa. Or we're going to go and bring two revenue-generating products together and take them to market. Whatever it might be, it doesn't matter so much what the mechanics are of the deal, but it's usually about aligning those agendas and having someone get utility, get value on the other side.

I think that people lose sight of the fact as well that when you're talking about a service provider, and let's be clear, Influx Data has launched a cloud platform that we'll talk about in a minute. This is not the one-off transactional relationship. Once the deal is signed, you've got to work with these people. When they host parts of your production infrastructure, whether you want to admit it or not, they're your partner more so than they are your vendor. It has to be an ongoing relationship that people are, if they at least aren't thrilled with it, can at least be happy enough to live with. Otherwise it just winds up with this growing sense of resentment and it just sort of leads nowhere. Yeah. There really is no deal moment. Yes. People sign

agreements with companies, but really that's just the very beginning. Your relationship evolves from there. And we're delivering a product, we're delivering this platform that handled time series data to our customers. And we're asking them to trust us with their product that they're taking out to market.

They're asking us to handle their data and to deliver service to them that they're turning into their production applications. And so it's a big responsibility. And so we care about the relationship with our customers to continue that. So I first really became aware of time series data a few years back during a reInvent keynote when they had a pre-announced time stream, which took entirely too long to come to market. Okay, great. So you're talking about time series data. Can you explain what that means in simple terms? And I learned over the next eight minutes that they were talking about it that no,

no, they couldn't. I wound up more confused by the end of the announcement than I was at the beginning. So assuming that I have the same respect for databases as you would expect for someone whose favorite data store is Route 53, because you can misuse that as a beautiful database, what is time series data and why does it matter in 2021? Sure, it's a good question. And I was there in that audience as well that day. So we think of time series data as really any type of data that's stamped in time in some way. It could be every hour, every minute, every second, every half second, whatever. But more specifically, it's any type of data that is generated by some source.

And that could be a sensor, sources within systems, or an actual application. And these things change over time and then therefore stamped in time in some way. They could come at different frequencies, like I said, from nanoseconds to seconds or minutes and hours. But the most important thing is that they usually trigger a workflow, trigger some sort of action. And so that's really what our platform is about, allows people to handle this type of data and then work with it from there in their applications, trigger new workflows, etc. Because the historical context of what happens is super important. And when we talk about sources, it could be really many things. It could be in physical spaces, and we have a lot of IoT types of customers and use cases.

And those are things like devices and sensors on the factory floor, out in the field. It's on a vehicle. It's even in space, believe it or not. It's like, you know, Influx there are customers are using us on satellites. And then it can also be sources from within software, applications and infrastructure, things like VMs and containers and microservices, all emitting time series data. And it could be applications like crypto or financial or stock market, agricultural type of applications that are themselves as applications emitting data. So you think about all these sources that are out there from the physical

world to the virtual world, and they're all generating time series data. And our platform is really specially designed to handle that kind of data. And we can get into some details of what exactly that means, but that's really why we're here. That's what time series is all about. And this is the inherent challenge I think we're seeing across the entire industry slash ecosystem. This is airing during re-invent week, but at the time we are recording this, we have not yet seen the Tuesday keynote that Adam Solipski will take to the stage and no doubt render the stat I'm about to throw at you completely obsolete. But depending on how you count them, there's somewhere between 13 and 15 managed database or database-like services today

that AWS offers. And they never turn things off, and they're always releasing new things, supposedly on behalf of customers in practice, because someone somewhere wants to get promoted by launching a new service. Good for them. Godspeed. If we look into the uncertain future, at some point, someone's job is going to be disambiguating between the 40 different managed database services that AWS offers and picking the one that works. What differentiates time series from, let's just start with the easy one, something like MySQL or Postgres or Postgresquille is how I insist on pronouncing that one.

Let's stay away from things like Neptune because no one knows what a social graph database is. And I assure you, you almost certainly don't need one. Where does something like Influx work in a way that, huh, running this on MySQL is really starting to suck? When and why is it time to consider a specialized tool? And in fact, that's actually what we see a lot with our customers is coming to us around that time when a time series is a problem to solve for them is reaching the point where they really need a specialized tool that's kind of built for that. And so one way to look at that is really just to think about time series in general as a type of data. You know, it's rapidly rising. It's the fastest growing data category out there right now. And the reason for that is it's being driven by two big macro trends. One is the

explosion of all these applications and services running in the cloud. They're expanding horizontally. They're running in more regions. They're, in many cases, running on multiple clouds. And so it's just getting big. The workloads are getting bigger and bigger. And those are emitting time series data. And then simultaneously, you, you know, time series data. And then simultaneously, you have this like growth of all these devices and sensors that are coming online, like out in the real world, batteries and temperature gauges and all kinds of stuff, both new and old that is coming online. And those sources are generating a lot of time series data.

So typically, we're in a moment now where a lot of developers are faced with this, you know, massive growth of time series data. And if you think about some data set that you have that you're putting into some kind of traditional database, now add the component of time as a multiplier, basically, by all the data you have. Instead of that one data, that one metric, you're now looking at doing that every one second in perpetuity. And so it's just an order of magnitude more data that you're dealing with. And then you also have this notion of when you have that magnitude of data, you have fidelity. You're taking a lot of it in at the same time, I mean, very quickly.

So you have batch or stream data coming in at super high volume, and you may need that for a few minutes or a few hours or days, but maybe you don't need it for months and years. And so you'd maybe drop down to kind of a lower fidelity for the longer term. But you really have this like toggling back and forth of the high fidelity and low fidelity all coming at you at pretty high volume. And so typically what happens is when the workloads get big enough, the legacy tools, they're just not equipped to do it. And like anyone, a developer, if they have a small set of time series they're dealing with, what is the first thing they're going to do?

They're going to look around and be like, hey, what do I have here? Oh, I've got Mongo over here. I've got Splunk or I've got this old relational database I can put it in. And that's typically what they'll do. And that works fine until it doesn't. And then that's when they come people are considering a specialized tool just because a workload has gotten such that it requires that. Yeah, taking a look at most of the offerings in the space, anything that winds up charging anything more than a very tiny fraction of a penny from what you're describing is going to quickly become non-economical. Where it's, oh, we're going to charge you using S3. Every, I think, thousand writes costs a penny.

Oh, we're just going to use S3 for this. Well, at some of these data volumes, that means that your request charge on S3 is very quickly going to become the largest single line item in your bill, which is nothing short of impressive in a lot of cases. But it also probably means that you've taken a very specific tool like an iPad

and tried to use it as something else, like a hammer. And no one's particularly happy with that outcome. Yeah. First of all, having usage-based pricing is really important. We think about it as allowing people to have the full version of the product without a major commitment and be using it in test scenarios and then later in the very early production scenarios. But as a principle, it's important for people that just signed up two hours ago using your product are basically using the same full product that the biggest customers that you have are using,

that are paying many, many thousands or tens of thousands per month. And so the way to do that is to offer usage-based pricing and not force people to commit to something before they're ready to do it. And so there's ways to unlock lower pricing. And we, like a lot of companies, offer annual pricing. And we have a sales team that works with folks to basically draw down their unit costs on the use of the platform once they kind of get comfortable with their workload. So there's definitely avenues to get lower price, and we're believers in that.

And we also want to, from a product development perspective, try to make the product more efficient. We basically are trying to drive down the cost through efficiencies in the product, make it run faster, make queries take less time, and also ship products on top of it that require developers to write less code themselves, do more of the work for them. One of the things I find particularly compelling about what you've done is it is an open source project. If I want to go ahead and run some time series experiments myself, I can spin it up anywhere I want and run it however I see fit. Now, at some point, if I'm doing this for anything more than, oh, let's see how I can misuse this today, I probably want to at least consider letting someone who's better at running

these things than I am take it over. And as I'm looking through your customer list, the thing that strikes me is how none of these things are quite like the other. We're talking about companies like Hulu is probably not using it the same way as Capital One is, at least I certainly hope not. You have Texas Instruments. You also have Adobe, and it sort of runs an entire gamut of none of these companies quite look alike. I have to imagine their use cases are also somewhat varied too. Yeah, that's right. And we really do see as a platform and with time series being the common problem that people are looking to solve, we see this pretty broad set of use cases and customer types. And we have some more traditional customers like the Ciscos and the IBMs of the

world, and then some relatively new folks like Tesla and Hulu and others that are a little bit more recent. But they're all trying to solve the same fundamental problem with time series, is how can I handle it in an efficient way and make use of it meaningfully in my applications and services? And we were talking earlier about having some sources of time series data being in kind of virtual space, like in infrastructure and software, and then some being in physical space,

like in devices and sensors out in the real world. So we have breadth in that way too. We have folks who are building big software, observability, infrastructure solutions on us. and we also have people that are pulling data off of the devices on a solar panel that's sitting on a house in the emerging world, right? So you have basically these two far ends of the spectrum, but all using the specialized tool to handle the time series data that they're generating. It seems to me that for most of these use cases and the way you describe it, it's more about the overall shape of the data when we're talking about time series

more so than it is any particular data point in isolation. Is that accurate or are there cases where that is very much not the case? I think that's accurate. What people are mostly trying to understand is context for what's happening. And so it's not necessarily, to your point, like not searching for one specific data point or moment, but it's really a kind of understanding context for some general state that has changed or some trend that has emerged, whatever that might be. And then making sense of that and then taking action on that.

And taking action could mean a couple of different things too. It could be in kind of an observability sense where somebody is kind of in a more of an operator type of mode where they're looking at dashboards and paying attention to say, you know, infrastructure that's running and then need to, you know, take some sort of action based on that. It also, in many cases, it's automated in some way. It's either some series of automated responses to some state that is reached that is visible in the data, or is actually kicking off some new series of tasks or actions inside of an application based on what is occurring and shown by the time series data. You know what

doesn't add to your AWS bill? Free developer security from Snyk. Snyk is a frictionless security platform that meets developers where they are, finding and fixing vulnerabilities right from the CLI, IDEs, repos, and pipelines. And it integrates seamlessly with AWS offerings like CodePipeline, EKS, ECR, and oh so much more. Secure with Snyk and save some loot. Learn more at Snyk.io slash Scream. That's S-N.io slash scream. offering, which is more or less, I presume, a supported distribution of this, or lack of a better term, that you then wind up providing blessed configurations thereof and helping run support for companies that want to run it on-prem. Is that directionally accurate, or am I grossly

mischaracterizing what your enterprise offering is? Directionally, you know, accurate, of course. You could have a great job in marketing. I really think you could. Oh, you know, I would argue on some level I probably do. The challenge I have is that I keep conflating marketing with spectacle, and that leads down to really unfortunate, weird places. But one additional area, which is relatively recent since the last time I spoke with Paul, one of the co-founders of your company, on this show, is InfluxDB Cloud, which is one of those, oh, let me see if I'm right.

And sure enough, yeah, you wind up managing the infrastructure for us. And it becomes a pay-per-consumption model the way that most cloud service providers do without the really obnoxious hidden 15 levels of billing dimensions. Yes, we're trying to bring the transparency back. But yes, you're correct. We have open source,, that's very popular. We have over 500,000 plus instances of that deployed globally today in the community. And that's typically very common for developers to get started using the open source, easily recognizable. It's been out for a long time. And so many people start the journey there. And then we have InfluxDB Enterprise, which is actually a clustered version of InfluxDB open source. So it allows you to basically handle in an environment that you want to manage yourself.

You manage a cluster and scale it out and handle ever-increasing workloads and have things like redundancy and replication, etc. But that's really specifically for people who want to deploy and operate the software themselves, which is a good set of people. We have a lot of folks who have done that. But one of the areas that's a little bit more recent is InfluxDB Cloud, which is really for folks who don't want to have anything to do with the management.

They really just want to use it as a service, send their data in. Yeah, give me an API endpoint, and I want you to worry about the care and the feeding and the waking up at 2 in the morning when a disk starts filling up. Yeah, that is the best kind of problem from my perspective. Someone else's. Exactly. That's our job. And increasingly, we've seen folks gravitate to that. You know, we've got a lot of folks have signed up on this product since it launched in 2019.

And it's really increasingly where they begin their journey. Maybe not even going to the open source, just going directly to this because it's relatively simple to get started. It's priced based on usage. People pay for three vectors. They have the amount of data in, they have number of queries made against the platform, and then storage, how much data you have and for how long. And depending on the use case, some people keep it around for a relatively short time, like a few days or a couple of weeks. Other folks have it for many months and potentially years in some places. So you really have that option.

But I would say the three products are really about how you want to run it. Do you care about running the underlying infrastructure and managing it, or do you just want to hit an endpoint, as you said? You launched this, I want to say, in 2019, which feels about directionally right. I know it was after Timestream was announced. So I just want to say first how kind and selfless it was of you to validate AWS's market, which is how they always like to clarify and define what they're doing when they decide to enter every single market anywhere to compete with everyone. It turns out I don't get the sense that they like it quite as much being on the other side of that particular divide.

But that's the best kind of problem too. Again, someone else's. Yeah, I think that's really true. The challenge that I have is that it seems like a weird direction to go in as a company, though it is clearly based upon a number of press releases you have made about the success and market traction that you've found.

It feels on some level like it is falling into an older version of an open source trap of assuming that, well, we wrote the software, therefore we are the best people you could pick to run it. That was what a lot of companies did. It turns out that AWS has this operational excellence, as they call it, and what the rest of us call burning through people and making them wake up in the middle of the night to fix things before it becomes customer visible. But from the outside, there's no difference. It seems, however, that you have built something that is clearly resonating and in a big way, in a way that I've got to be direct with you, the AWS time series service that they are offering has not been finding success.

Thank you for saying that. And we feel pretty excited about the success we've had, even being in the same market as Amazon. And Amazon does a phenomenal job at running products at scale and the breadth that they have in their product lineup is pretty impressive, especially when they roll out new stuff at AWS reInvent every year. But we've been able to find some pretty good success

with our approach, and it's based on a couple of things. So one is, I think, being the company that actually develops and still deploys the open source is really important. I think people gravitate to that. Our roots as a company are open source. We've been a part of and foster this community over many, many years. And there's a certain trust in the direction that we're taking the company. And Paul, our founder, who you mentioned, he's been front and center with that community, pretty deeply engaged for many, many years. So I think that carries a lot of weight. At least that's the way we think about it. But then as far as commercial products go, we really think about it as going to where our

customers are, going to where developers are. And that could mean the language that they prefer, the language of preference. And it's very clear. It seems that most database companies that I talk to, again, without naming names, tend to focus on the top-down sale. But I've never worked in an environment where the database that will be used was dictated by anyone other than the application developers who are the closest to the technical requirements for the workload. I've never understood this model of, oh, we're going to talk to the C-suite because we believe that they're going to pick a database vendor based upon who has boxed seats this season. I've never gotten that, and that probably means I'm a terrible enterprise marketer on some level.

But unlike almost every other player in the database space, I've never struggled to understand what the hell your messaging has meant. Other than the technical bits that I just don't have quite enough neurons to bang together to create sparks to fully understand, it is very clearly targeted at a builder rather than someone who's more or less spending their entire life in meetings, which, oh God, that's me. Yes, it's very much the case. We are focused on the developer, and that developer is a builder of an application or service that is seeing the light of day. It's going out and being used by their own end users and end customers.

And so we care about going to where those developers are. And that could mean going and making your product easily used in the language and tool that that customer cares about. So if you're a Python developer, it's important for us to have tools that make it easy for Python developers. We have client libraries for Python, for example. It also means going to the cloud where your customers are. And this is something that differentiates as well

when you start looking at what the other cloud providers are offering in that data, like it or not, has gravity. And so somebody that has built their whole stack on AWS, then sure, they care about using a service that is going to receive their data and that also being an AWS. But it has to live where the customers are,

especially with data egress charges being what they are too. And data gravity is real. The cloud provider people pick is the one where their data lives because of that particular inflection in the market. Absolutely true. And so that's great if you're only going after people who are on AWS, but what about Google

Cloud and what about Microsoft Azure? There are a lot of developers that are building on those platforms as well. And that's one of the reasons we want to go there as well. So InfluxDB Cloud is a multi-cloud offering and it's the equal experience and capability and pricing on each of the three major clouds. You can buy directly from us. You can put it on any of your cloud bills in one of those marketplaces. And to us, that's like a really, really fundamental point is to bring your product and make it

as easy to use on those platforms and in those languages and in those realms and use cases where people are already working. I'm a big believer in multi-cloud for the use case you just defined. Because I know I'm going to get letters if I don't say this based upon my public, multi-cloud is a dumb default worst practice for most folks. Because it is on a workload by workload basis. But you're building a service that has to be close to where your customers are. And for that specific thing, yeah, it makes an awful lot

of sense for you to have a presence across all the different providers. Now, here's a $64,000 question for you. Is the experience as an Influx Cloud customer meaningfully different between different providers? It's not. We actually pride ourselves on it being the same. Using InfluxDB, you sign up for InfluxDB Cloud, you come in, you set up your account, create your organization, and then you choose which underlying cloud provider you want your account to be provisioned in. And so it actually comes as a secondary choice. It's not something that is gated in the beginning. And that allows us to deliver a uniform experience across the board. And you may, in a future use case,

maybe somebody wants to have part of what they're building data living in AWS and maybe part of it living in Azure. I mean, that could be a scenario as well. However, typically what we've seen, and you've probably seen this as well, is like most developers and organizations

are building mostly on one cloud. I don't see a lot of of multi-cloud in that organization. But we ourselves need to be multi-cloud in order to go to where those people are working. And so that's the distinction. It's for us as a company that delivers product to those people, it's important for us to go where they are, whereas they themselves are not necessarily running

on all three cloud products. They're probably running on one platform. Yeah, on a workload-by-workload basis, that's what generally makes sense. Anytime you have someone who has a particular workload that needs to be in multiple providers, okay, great, you're going to put that out there. But their backend systems, their billing, their marketing,

all the rest is not going to go down that path for a variety of excellent reasons, mostly that it is a colossal pain and a bunch of more or less solving the same problems over and over rather than the whole point of cloud being to make it someone else's. I want to thank you for taking so much time to speak to me about how you're viewing

the evolution of the market, how you're seeing your move into cloud and how you're effectively targeting folks who can actually care about the implementation details of a database rather than honestly suits. If people want to learn more, where can they find you? They can go to our website. It's the easiest place to go.

So influxdata.com. You can read kind of all about InfluxDB and pretty easy to sign up and get underway. So I recommend that people get their hands dirty with the product. That's the easiest way to understand what it's all about. And if you do go end up doing that, please tell them I sent you

because the involuntary flinch whenever people mention my name to vendors is one of my favorite parts of being me. Brian, thank you so much for being so generous with your time. I appreciate it. Thanks so much for having us on. It's great.

Brian Mullen, Chief Marketing Officer and Dealmaker at Influx Data. 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 a long, angry comment telling me that you work on the Timestream service team and your product is the best, it's found huge success, but I've just never met any of your customers and I can't because they all live in Canada.

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.