Tim Veil (00:05):

Welcome to the Big Ideas in App Architecture Podcast. I'm your host, Tim Veil, and joining me today is Ken Pickering, the Senior Vice President of Engineering at Starburst Data. Thanks for joining us today, Ken.

(00:17):

Ken, I thought I would just kind of read a little bit about what I understand your background to be, and then certainly fill in the gaps or add to it if you like to. But you got your bachelor's degree from University of Virginia in Computer Science, ultimately got a master's degree in computer science from UMass Lowell, and then went on to do all sorts of really exciting roles. One of the reasons I was so interested and excited to talk to you today is your background in software engineering and architecture is really, really impressive. You've had a lot of unique and different experiences most recently at Rue La La and then at Hopper where you were Head of Engineering, and of course now we have the pleasure of talking to you as SVP of Engineering at Starburst Data. I know, I didn't go into all the details, but is that a fair summary of kind of your journey to date?

Ken Pickering (01:12):

Yeah, absolutely. I've got the privilege of working in both B2B and B2C systems, which has been interesting from a architecture and capacity planning and engineering perspective. So yeah.

Tim Veil (01:26):

Now one thing I'm always curious about it, and maybe it's because I was just at Disney World with the family and thinking back about childhood and aspirations and growing up, I found myself in an engineering capacity not long after graduating, but I don't know that that's ever what I thought I was going to do. You not only got a bachelor's degree in computer science, but a master's degree, is that what you'd always wanted to do is get into technology, be an engineering leader? Or did you have aspirations to do other things as you was growing up? I'm always just curious about how people wind up where they are today like you and I are here in this kind of technical field.

Ken Pickering (02:04):

So I took apart my record player when I was six to see how it worked. So I think I've always had this intrinsic curiosity as to how things are built and how things operate, but actually engineering was a side hustle for, at my time, my music career.

Tim Veil (02:21):

Oh, really?

Ken Pickering (02:22):

Yeah, well, I grew up, I really love music. I played the violin and then the trumpet and then later in life picked up bass and drums and stuff like that, and my parents were like, "You can't be a music major. Absolutely not. That's not a career." I was like, "All right, I'll do this." I started out in electrical engineering and then pivoted to computer engineering, which was sort of new at the time, but it was a hybrid of double ENCS work. I'd say it's like doing FPGA type stuff before the days of raspberry pies. So I was happy I did it, because the music thing just sort of fell apart. But yeah, I didn't get into this 100% thinking I'd be an engineer someday, but I just sort of fell into the profession and I've always liked math and science and technology.

Tim Veil (03:17):

Yeah, that's great. I had very similar background. I don't know that I ever took apart a record player, but pretty close. I did a lot of deconstructing and reconstructing of things. So it's no surprise I think we find ourselves in the kind of profession that we're in. So let's talk a little bit about Starburst Data. You've been there, I guess at this point it'd be a little over two years, maybe right at the two year mark, Starburst is a really fascinating company. Itself has had kind of an interesting journey, but tell me a little bit about what Starburst is, a little bit more about the role that you're playing there. I'd love to hear what the day in the life at Starburst is and really what Starburst is about.

Ken Pickering (03:57):

Absolutely. So Starburst is based on the open source project, Trino, formerly known as Presto, and I'd say Starburst, the company has a couple different origin stories in regards to that. I mean, the Presto project was worked by three of our CTOs, Dane, David, and Martine at Facebook for quite some time, and it was really designed to solve the problem of how do you query internet scale data? The best common practices at the time were data warehousing, but if your data is so physically large that you can't warehouse it, what do you do? And so it's a very interesting and cool and occasionally somewhat complicated piece of technology. But I think, and so the other side of the company is more of the business side, which comes out of the days of Adapt. Justin Boorman, our CEO, was the co-founder of Adapt, and he is always had this vision of SQL on top of unstructured storage or alternative storage types.

(04:58):

And so when the company was acquired by Teradata, Justin and the team started working with, at the time, Presto, and saw the potential of it. And so Starburst was founded after that to work directly with Presto and the Presto community. And then after Dane, David and Martine left Facebook and forked the project everybody came together at Starburst and sought to, I'd say bring Presto, now Trino, to the masses. And actually leverage this technology in a way that can lift all sorts of businesses, not just internet scale companies. So that's what we've been working on. It's a very kind of stereotypical open core journey. We have the open source technology widely utilized by some of the biggest companies in the world. We built the enterprise platform, and we have a ton of customers on the enterprise platform and now we're in the cloud platform part of the journey, how do we as a business make it simple, easy to use, any company can do it and leverage Trino in that capacity?

Tim Veil (06:01):

I spent some time at Hortonworks and so was kind of had a front row seat during the heady days of Hadoop and big data. And certainly at that time, Presto was a very, very interesting technology. One of the things I'm curious about is, I think in a large part, Hadoop kind of peaked a little bit in terms of its, I don't know, mass appeal. I don't know how you might characterize it, but I think Starburst has done a wonderful job of continuing to be a very, very attractive technology for those big data problems. I mean, you've only been there a couple years, but I just wonder what your perspective is on that kind of journey from the heady days of Hadoop, when everybody had to have a Hadoop solution to a big data to something that's very different now with the emergence of cloud. I don't know if that's something you've thought much about, but I'm always curious about companies that started in those early days and have managed to transition in this journey in some ways kind of a post-Hadoop era.

Ken Pickering (07:08):

Well, in a lot of ways, the Hadoop era really set the stage for where we are today in terms of data technology and data analysis. I'd say that some of the inspiration of Presto in the first place was derived from Hadoop. So where I think Starburst and the Trino project excel is what we're really trying to do is actually push for the separation of storage and compute. If you work with us, if you buy the product, I think you lean into that axiom of you can separate compute and storage, which is a stark differentiation from the coupled data warehouse or cloud data warehouse, snowflake model of coupling both things together. So I think that's where, but I think that that's that purity of concept of separation of storage and compute tier is what's carrying the vision forward. And then I think that being able to provide optionality of where customers can choose to store the data and the federation capacities of Trino to do query federation across Mongo or S3 object storage or traditional databases or Snowflake.

(08:20):

To be able to do that gives customers the ultimate freedom and flexibility to store their data where they want and leverage it how they see fit. And not be tied into, okay, well a huge part of Starbursts early years was like, "I have Snowflake, but I also have Cloudera, and how do I marry these two things? Because I don't want to move everything in Cloudera to Snowflake." But Starburst can come in and solve that problem. And so you can do data migration, but it gives you that kind of single source of truth or that kind of fabric layer on top of everything to drive business results. Because at the end of that's what most customers are most concerned with is, "How am my analysts making insights? I'm on this cloud transformation journey, sure but it's going to take a while, and how do we as a company actually continue operating our business while underneath, maybe we're doing other things." Or incorporating new technologies into the mix, but then saying like, "Oh, but now how do I transform this data and get it into the cloud data warehouse? Someone brought in Mongo and now we don't know what to do with all the data in Mongo." And so solving those problems is, I think that's the thing that the technology does super well. That's definitely the sweet spot of the technology.

Tim Veil (09:37):

Yeah, I'd love to understand a little bit more or hear you talk a little bit more about this separation of computing storage, because again, that's something that we find at Cockroach to be, I think a place directionally we want to head more and more because there are fundamental limitations when those things I think are bound together. But from an application of architecture, and ultimately performance, which leads again to something I think you called out which is important to understand is business value. What are you seeing or not seeing that working to effectively separate those things that has done for the business over the technology itself? I think that's, in other words, it's a really key architectural concept I'd like to explore.

Ken Pickering (10:19):

So what it lends really well is I think it makes the concept of a data lake much more functional, but it doesn't specifically require everything be in a data lake. And that I think a lot of companies are going into the data lake plus, that's what we call it internally is data lake and a couple other things type strategy of, you're landing everything in a lake, but also you have data other places. And that's kind of okay, and we'll figure out how to get it there eventually. But I'd say it's the combination of exceptionally cheap object storage, exceptionally cheap ways to store all of your data. But then how do you leverage it in a way that's performing on top of it? So I'd say, but you also have app databases and other things that you want to include into the mix, and where do those fit into the scenario?

(11:09):

A good example is in the consumer space, new feature development where maybe your object model isn't a hundred percent solidified or you're not a hundred percent focused on what metrics you're tracking, but how do you actually join that with other large data sets? And how do you actually link that to marketing inbound data or something like that is a good use case for the technology because in a lot of places, especially more mature digital native companies, they're already landing a ton of data lake, but it's not also the source of truth. And so there are definitely two ways to solve that problem. The first is sort of like, "Okay, well we link everything and everything goes to Snowflake and we feed Snowflake." We just don't see the need for that. And we think that if you can aid in things like schema discovery, Starburst has leaned heavily into the concept of data products or the concept of data APIs. How do you actually define and scope data in a way that makes it easier to consume? And then thinking about Lineage and other things, how do you actually take something as unstructured as a data lake and produce useful, viable outcomes? Has been a big area of research for us.

Tim Veil (12:17):

And one thing I'm always curious about, and we see this at Cockroach where when we look out at the market, there are just so many databases and so many data, you said data products, but I guess I'm using the term a little differently here. I mean, there's just so many places to put things, right? And ultimately the companies that we work with want to get them out of a transactional system or get into or out of a transactional system. But as I think you guys see day in and day out, data can get and be everywhere. For us, the amount of different places people are looking to put things or have put things or applications that are over here using PostgreSQL, over here using MySQL, over here using Mongo. I guess where I'm going is there's just so many products out there. Has that been a challenge for Starburst to walk into a company and say, "Oh, geez, we have to build yet some other integration that we didn't have before in order to fully realize the potential of pulling all this data together."? Or is that a problem you guys have effectively solved over the years, or are you still finding that, "Hey, every day there's some new thing we're being asked to integrate with?"

Ken Pickering (13:34):

Yeah. So we do run into that problem, but I think one of the benefits of the technology is the pluggable agent architecture in that Trino and Presto were designed out the get-go to have a pluggable architecture to incorporate new connectors. So because of that, I think it's easier for us to adopt new connector patterns and keep abreast. The other part's the community aspect of it too. A lot of our connectors actually come in from the community, and so someone wants to write a connector for X because they use it at their company and they write it, and Starburst directly benefits from that contribution. I would say that we definitely focus on ruggedizing and testing connectors we bring in from the community and in that regard, but at the end of the day, the ecosystem itself kind of feeds it. So there's occasionally things we run into in terms of some of the bigger companies with their own home brew, open source projects where they extended a specific open source technology, which I was like-

Tim Veil (14:48):

No, people aren't really doing that are they?

Ken Pickering (14:50):

Oh, no, yeah, they do do that. And that's a case by case decision, right? It's like, do we integrate with this or not? But yeah, no, I'd say the good thing about the tech is that it was designed to be this adaptable. And so we're not fighting against every single connector we run into.

Tim Veil (15:08):

From our perspective, it's just amazing to me, it seems like every day there's a new database around a new something or other that people are asking about. And I think if our job was to figure out how to connect all those things, which it isn't necessarily, it would it'd be daunting.

Ken Pickering (15:24):

Yeah, I was going to say definitely having to Google a new technology is kind of embarrassing sometimes, like, "Oh, I haven't heard about it." Yeah, exactly, so.

Tim Veil (15:31):

As an SVP, you're supposed to have all the answers, SVP of engineering have all the answers to every question that's asked. I know that's how I feel sometimes, but you're right, the amount of time I have to look up things is amazing. You mentioned something I kind of wanted to shift a little bit to the people aspect. So you mentioned community, as the SVP of engineering and somebody who is responsible for wrangling, I think not only employees of Starburst, but ultimately contributors who may or may not be employed. Talk to me a little bit about how you guys organize your work. I know there's many different philosophies about how to organize engineering teams. I've always been fascinated and have worked with open source projects in the past. I'm just curious how you, not only philosophically organizing your team, but how are you incorporating that broader ecosystem of community contributors in order to build the ultimate vision for Starburst?

Ken Pickering (16:30):

Yeah, it's one of those case by case things where in some cases, especially Connectors is a great example because that is an atomic unitive work. And in a lot of ways it's easier for people to contribute those than core engine enhancements. And I'd say it's much more of a partnership model. We believe that if we help invest in the community, that we can reap rewards from that. So having Starburst, because I'd say we employ probably the most Presto, Trino experts in the world at this point. And so it is assisting to help lift, so that could be community management that's assistance in PRs, that's making sure that we're providing timely feedback. We have people manning the Slack, the open source Slack to answer questions and help people get unblocked.

(17:21):

And so I'd say it's really just having a practical level investment in the community and helping to lift it, making sure that if someone comes in, they have a positive experience with the Trino community and that we're clear and concise on either why or why not an initiative should be taken on and accepted. Because we just as many things that are probably not as appropriate for the project as are appropriate for the project. But I'd say when Dane, David, and Martine founded the Trino Software Foundation, growth of the community was really top of mind for them. And so we are a majority of the maintainers and a majority of the contribution to it. But I'd say making sure that we at Starburst are continually keeping an eye on how we make it better is a huge part of it.

Tim Veil (18:09):

How big is the team, out of curiosity? The engineering team.

Ken Pickering (18:12):

Engineering's about 150 today.

Tim Veil (18:14):

Wow.

Ken Pickering (18:15):

Yeah.

Tim Veil (18:16):

That's a big team. And are they everywhere? In all corners of the world at this point?

Ken Pickering (18:22):

Yeah, we operate really globally. So we have offices in Palo Alto, Austin, Boston, London, Paris, Warsaw, and Tel Aviv. But we have employees in India and Japan and South America and all over Europe and all over the US and Canada. So yeah, we are a global remote first company.

Tim Veil (18:46):

Now, is part of your role in responsibility to get to travel to all those destinations regularly or is that something that is not necessarily required?

Ken Pickering (18:54):

No, it is. Actually I go to Poland, and Tel Aviv a moderate amount of times, Palo Alto once a quarter. And I'll say it is great. I mean, Bay Area is awesome, and seeing friends out there is great. And then going to Warsaw, Poland's grown on me. A huge chunk of our engineering organization is in the greater Warsaw area, so that's been a lot of fun. And Tel Aviv's gorgeous, the beach there is amazing and it's just a beautiful city.

Tim Veil (19:18):

Yeah, two places I've never been and would like to go. Well, one thing I'm curious about, everybody I think certainly in technology, and if you read the news at all lately, you've heard I think about various layoffs in different places. Who knows why these things are necessarily happening, each individual company, but I think we can all agree the last couple years have been certainly a challenging place to do business and to be in tech, whether it's COVID or other kind of macroeconomic things. Just curious, you've got a big team and here we are trying to build fascinating and interesting products that people care about and use, whether it's the pandemic or who knows what else, how has that impacted your engineering teams, your engineering effort, and I guess more broadly just the development of your products over the last couple years?

Ken Pickering (20:15):

So Starburst was really tiny going into COVID. It wasn't under a hundred people. I mean, I joined in August of 2020, so I joined mid pandemic. And I think at that point we were physically located mostly in Boston and Warsaw with a smattering of people in Palo Alto. And I think as we progress, we just decided that the future of us, we still wanted offices and we still wanted to meet in person and those sorts of things eventually someday. But the concept of people going into a building to work every day just seemed outdated and that we thought that we could continue to hire better and better people by being flexible. I actually really liked the remote first paradigm in that we can hire remote people, but we can also hire people that want to go to an office. I have engineers that go into an office every day because they want to go and they want to socialize and they want to be in an office.

(21:17):

And so I think we're able to get the best of both worlds from that. And it was a very realistic, evolving thing that just sort of happened. But I'm really happy with the outcome of it in that I feel like we can hire in the geo locals that we're present in, but also people that just want to stay home. I'm contacting you live from my home office right now. I think, I go into our Boston office on occasion, but at the end of the day, wherever people feel most efficient, and I think especially for engineers, that's a very practical framing is like, "Well, if you feel like it's more productive to fly somewhere, fly somewhere, if you feel like it's productive to be in an office, be in an office, if you need to work from home, work from home." And we're really focused more on the outcome of our business than physical policies on, "You got to be in the office two days." You know what I mean? But I don't know if we would've made that decision without COVID. I think it was a very practical decision we made as we grew up in the pandemic, but I don't know if that would've been a natural decision we made otherwise.

Tim Veil (22:22):

One of the things you said to me earlier was that you thought it was kind of hard to build a product without a whiteboard. And I thought that was super interesting because I know in our experience, in my experience with our teams, you do miss sometimes the ability to just grab a bunch of folks, pull them into a room and draw something out and move on. And I think it's made the times that we are together so much more valuable. Have you found that not being together has had any impact on velocity? Because I can see it both ways, as you just described, sometimes you can get find wonderful people and far flung places of the world, but at the same time you miss that kind of communal engagement. What's your take on that? Has it been hard to build a product without a whiteboard? I mean, I would imagine at this point you've managed through that, but I'm just curious. I thought it was such an interesting kind of statement to make about the challenges of the last couple years.

Ken Pickering (23:27):

No, it is hard. I'd say the thing I've discovered is tactics are easy, strategies hard. If you're just heads down, working on something, working from home is great, no distractions, put the headphones on, there's nobody moving behind you. I'm like a person who's easily distracted by offices. So for me it was 100%. But working through something when everybody's on Zoom and the social norms are weird and you can't just walk up to something for me it felt like losing a sense or something. It was something was missing in the conversation that I had to devote hours to something because I just couldn't articulate it well enough via Zoom. So I think one of the things that our executive team has done, even through pandemic, we'd meet outside, but we met in person to discuss issues that mattered.

(24:29):

And so from an engineering perspective, we started doing that and that's why we established our office in Palo Alto. It was like we needed a more high bandwidth conversations to work through this stuff. And it's like either I fly out to California for 2 days, or I spent the next 60 days in a variety of Zoom meetings trying to articulate the same thing. And so I really do think that, especially high bandwidth, really organic design and strategy discussions were super challenging to do. And for people who are watching, it's a struggle, I can't overemphasize the benefits of co-location to doing those things because five minutes on a whiteboard saves me 35 minutes on a Zoom call. So yeah, 100%.

Tim Veil (25:16):

I couldn't agree more. I mean, as I said, I think the times that we've been able to get together, and we're starting to do that more frequently, I don't know how y'all have kind of adjusted, but I think what's happening for us at least is the kind of offices are definitely opening back up and there's a lot more encouragement to be back together. But it's just that time that you spend together to be able to really discuss, like you mentioned those high band that is so important. So I know we're running up on about 30 minutes, but no meeting of two technologists would be complete without talking about the cloud. I don't know, somehow we got 25 minutes into this without actually saying the word cloud, which I don't think is legal in some states, you have to mention it.

Ken Pickering (25:58):

Let's talk about the cloud, yeah.

Tim Veil (25:59):

So let's talk about the cloud. I know y'all are building a product to simplify deployment management as are we just curious about maybe your perspective on that, not only the journey, but how has that product been received? I mean, tell us a little bit about it, but how has that product been received in the market and what's been that journey of building it, if you will?

Ken Pickering (26:29):

Yeah, I mean, Trino was many things, but in a lot of cases it's not super easy to configure and tune and optimize and deploy and operate. So that was really the original inception of the cloud product was even our enterprise product engineers are operating it. It's a self hosted product that is driving mission critical stuff in a business, but they're doing the upgrades and everything else. So when we designed Trino, I mean, we designed a galaxy out of the get-go, right? It was really, we were looking for the ease of use axiom. So we're like, all right, people want to spin up, the people just... Like let's not even talk clusters, people want an answer to a question, they want to submit a sequel query and get an answer. So when we looked at that, we're like, "All right, start with small, medium, large clusters that auto shut down and auto start because we don't want people to have to worry about cluster management." And then we throw in auto scaling and we throw in other technologies that make it easier. We're launching our batch processing service, which is making customers high availability.

(27:42):

So there's a ton of things we're introducing, but that's really centered around the experience of people just want answers to data derived questions. So it should be easy to connect sources, easy to manage clusters, the system is versionless, so people don't know what version of Trino they're running, but that's the kind of level of thing we wanted was making it easy and transparent to operate the product. Then because of the decentralized nature of Trino in the first place, as I talked about earlier, the separation of storage and compute, we didn't even want to be tied to a cloud. So we launched our product initially in all three public clouds. And I think our eventual goal is solving multi-cloud hybrid cloud analytics, which is a problem because the monetization policies of the CSPs make that kind of a problem. But our goal really is to make Starburst the product that people can use anywhere, use anywhere to get answers to their questions that we optimize for their situations. So I think approaching the problem with a bold, kind of ambitious statement of, "Yes, we want to be the solution for wherever," really lended itself to really driving simplicity and multi-platform support.

Tim Veil (29:02):

Yeah, I couldn't agree with you more. It's funny listening to your description, it's precisely I think in a lot of ways, what drives Cockroach, the ability to run these complicated systems without having to be burdened by that complexity. And you touched on something that we're spending a lot of time thinking about, which is I think one of the reasons why our companies work so nicely together, and that is the cloud is this big thing, but it's obviously when you get right down to it's a handful of key vendors that are in the space. Being able to run a product across multiple clouds is becoming important, certainly to our customers. It sounds like it's becoming important to your customers. Do you see that trend continuing? It's one of those things, just quickly from my perspective, that sometimes you feel like, "Is this a marketing thing or people really asking for this?" I am surprised how many times we walk into customers and they are demanding that we have a multi-cloud server. Is that something you're finding as well? I mean, how has that multi-cloud journey evolved for you? 'Cause I know for us that hasn't necessarily been easy, but it's definitely important.

Ken Pickering (30:15):

We have seen it, that's why we're working on it. At the end of the day, whether it's people are running in multiple clouds for things like resiliency and failover or playing the vendors off of each other for cost perspective or acquisition is a huge use case. You're an Amazon shop, but you buy a big company that's in GCP or Azure and all of a sudden you're multi-cloud. So for a variety of reasons I think it's a common scenario for all the reasons I just sort of mentioned. And I think it's a reality, and I don't think you have to build a cloud agnostic product, but I think if you want to solve some of the things at the scale we're trying to solve them, you sort of have to be cloud agnostic, you sort of have to just embrace that reality.

(31:05):

And I would say that it's an uncomfortable reality for an emerging company because the economics of it don't 100% work right now. And because even companies that are like, "Oh, well, we run in all three clouds, it's a siloed product in all three clouds," and we're kind of trying to forego that aspect of it and try to think beyond that aspect of it. So yeah, I think it's kind of daunting to proceed down that avenue. But I also think 10 years from now, if you're thinking long term, the people are going to want to treat CSPs like a commodity because no companies like being locked in, no company likes being 100% dependent on another business to the extent of it's like a utility. And I just think for economic reasons, it's something that most major companies have to seriously consider.

Tim Veil (31:58):

I couldn't agree more. We're in the OLTP space, and so we get a lot of folks who have had bad experiences with vendors kind of locking them into their product for a long time and making that experience rather painful. And so I think when it comes to these big cloud vendors, that's precisely what we're seeing. Or at least as you described, we see it for a lot of reasons, but one of the most important reasons is this idea that, "Man I just came out of this bad experience being locked into something. I don't want to jump all into a cloud provider, as benevolent as that cloud provider may be at the moment, I don't want to be locked into them forever in the future." And so having this optionality to run solutions in different places has become a big and important driver for us.

Ken Pickering (32:41):

Absolutely. I think that vendor lock-in topic is huge, and I think that there's a argument for why open source or why multi-cloud, or why a lot of things. I think at Starburst we focus on making a great product so that we don't have to rely on lock-in. I think the purity of purpose there forces you to make a great product.

Tim Veil (33:07):

Yeah, make it the thing that people want regardless.

Ken Pickering (33:10):

Exactly.

Tim Veil (33:11):

It's just the best. So one thing I'm always curious about as we wrap up is, and especially as we talked about at the beginning, you've had such an interesting career, lots of different experiences, been at the front row of building lots of interesting things. Now I personally have never made a mistake, but I assume others have, perhaps you have. That's a joke of course for people listening, I make mistakes all the time. But as you think back on your journey as an engineer, architect, SVP, are there some things, a thing that you reflect back on and say, "Geez, I shouldn't have done that technically," or, "Boy that was a mistake we made," or just anything that I think someone in your position with your experience. Anything you can offer to people who may be listening to this to say, "Here was an important lesson I learned in my journey getting to this point."?

Ken Pickering (34:09):

I think so. I would say especially at growth phase companies, if you're not actively making architectural mistakes almost every other day, I don't know what you're doing. Because in all honesty, you're proceeding in an unclear space and you're not a hundred percent sure where your business is going to go. And so you make decisions. And I think a lot of the ways that we make decisions technically is we try to make sure we're going through two-way doors instead of one-way doors. So we can revisit decisions later. But I'd say, I mean, I've run into to technology selection choices or vendor selection choices. A lot of it probably revolves around picking the wrong tech for the wrong reason, or not being to scale beyond a certain point. But I think that those are great problems to have because you made a choice and you hit a level of scale where you're running into cascading failure issues because of that selection, because your proctor company is successful. So I think mean at Hopper, we were super reliant on Kafka, which over time really got progressively, progressively more complicated. And then-

Tim Veil (35:26):

You don't say.

Ken Pickering (35:28):

... we forked the open source, and we wrote our own client, we did a lot of stuff to make it keep working. Then on why that decision at some point, talking to Confluent and being like, "Hey, Confluent, we'd like you to host our Kafka infrastructure for us." And then being like, "Wait, you wrote your own client? No, get out." So it's things like that where at the time it was absolutely the right decision, but at the end of the day, eventually you're like, "Okay, we are way beyond what we intended to be here and we've made it work, but what's the go forward strategy?" And I think there's a lot of stuff like that I'd say in my background in terms of, "Okay, we operate under the best possible information at the time." But Rue La La was a great example of that too, in terms of it's a flash sale company. So high throughput during holiday season would always shed a floodline on your bad technical decisions because on the one day you have to be up, you're getting flooded with requests and you're like, "Oh, well, all right, that's what it was this year."

Tim Veil (36:30):

It reminds me, so we did a webinar with Sean from DoorDash, this was a while back, and he said something so interesting I thought during that, which is, you often hear the term, things go bump in the night, all right, you don't want to build systems where if something goes bump in the night, all hell breaks loose. And his retort to that I thought was super insightful, which is, he wasn't worried about things going bump in the night, he was worried about things going bump in the day. Which is, failures happen of course all the time. And the worst kind of failure are those that are happening right when everybody needs your service. So I just thought that was kind of a fascinating way that, things will break, things will fail, and you can't necessarily predict it, but you have to be ready for it.

(37:15):

And the other thing, I'm curious of your thought on this, I feel like at times we struggle with this. I've seen my teams and other teams and other companies struggle with this, where the phrase don't let perfect be the enemy of good. I think where we almost spend too much time trying to find the ultimate and perfect solution, when I think what oftentimes works better is just being able to quickly iterate over maybe a reasonable first solution and just let that evolve over time. Obviously it takes the care and time and feeding, but sometimes you just have to jump right in with both feet, build something kind of as you described based on the conditions that exist in the moment and be prepared to improve them as new facts present themselves.

Ken Pickering (38:03):

Yeah, 100% agree. I think a lot of what I coach my teams to do is, let's prove the concept first. Let's prove an idea, let's prove this business idea is worth investment. Don't lose sight of the eventual goal and let's not make actions that are counter to where we want to be. But you don't have to design a bulletproof system if we don't even know it's going to work.

Tim Veil (38:31):

Pre optimization.

Ken Pickering (38:33):

It's, otherwise, yeah. It's like you get something out in a month. Let's set a threshold. What's the best thing we can do in a month? And we'll vet it, we'll put it in private preview, we'll see if customers like it. We can keep it in preview for a while where we actually flesh out the real technical solution for it. But yeah, no, nobody gets bonus points for overbuilding. At the end of the day, we're a business and if we spent six months on something and we could have spent two months on it, no one's going to thank us as on how system is right. It's so good though, it is really-

Tim Veil (39:09):

It's the best.

Ken Pickering (39:10):

... it's the best. It's nobody else in the world has built a system this great. But no, yeah, 100% agree. But that's where skilled architects come in. You don't just employ them for perfect technical solutions, you employ them because it's like, they know when to take out the duct tape. They know when to just, "All right, we'll make it work." But you don't fall into a trap with that. And I think that's really where the best technologist can apply themselves.

Tim Veil (39:35):

Well, speaking of perfect systems, maybe as we wrap up, can you talk a little bit about how Starburst is leveraging CockroachDB today? I know we are part of, I believe, the Galaxy solution, but I'd love to hear really just a little bit about your perspective on the journey to finding and maybe ultimately implementing a CockroachDB in your solution.

Ken Pickering (40:02):

Yeah, so for the same reasons I spoke about before, in that we wanted to be multi-cloud and resilient to being multiple cloud, we didn't want to pick a specific CSP solution for... I mean, it started with our secret storage like, how do we get encrypted secrets deployed globally in a minimum amount of time? And that's sort of how, and then it became, what other information do we need globally sort of replicated? Because we are a global system, we're selling to larger companies and there are people accessing in Europe and Asia and the US. And so the technology was selected really for that reason, which is how do we get a solution in that matches our SLAs on what we want our technology to be? And we didn't feel right going with a specific CSP like solution for it or one of the ancillary related Cockroach techs. So we specifically narrowed down to Cockroach because of those reasons. It matched our high availability and performance heuristics for what we're looking for with Galaxy. Because as you can imagine, if we have to rely on an external system for fetching data during operation of a query, it has to be lightning fast, there has to be a certain response time on that because otherwise our system looks slow. So we can't critically depend on other systems that are not sort of matching the tight global reliable SLAs that we have for ourselves.

Tim Veil (41:32):

Yeah, it's awesome to hear a lot of what you just called out are the reasons why others have been drawn to the technology, and I know we've been very excited and happy with the partnership and glad to count you among our customers. Y'all have been fantastic to work with. Just maybe as a last question just as we look toward the future, and again, I so deeply appreciate the time you've spent and the conversation. I've really enjoyed it. What are you looking forward to? Maybe you're a football fan and you're looking to next season of UVA, I don't know if that's true, maybe it's a product thing. What kind of gets you motivated in the morning to face what, I guess we're here at the end of January, is going to be undoubtedly another interesting year?

Ken Pickering (42:20):

So I am a diehard New England Patriots fan. I'll just get it out of the way. This was not our year, not our year. We've had great years in New England, this was not one of those great years. I'm always looking forward to next season now as a Patriots fan and I'm a general New England sports fan, so Bruins and Celtics too. I would say for me, I mean work is obviously a huge chunk of my life and I love the phase that Starburst is in right now. I think it's, being part of a growing business and the inertia and excitement of being part of a growing business, even with the economy the way it is, is really exciting. It's energizing. Everyone wants to build a great company. And so that gets me out of bed every day. I have a great team I work with, a great executive team. Everyone is on mission, which I love. Everyone is, there's no politics, everybody's on mission and we're all rolling in the same direction. And that definitely is energizing. And I got two kids, February vacation's coming up. We're going down to Florida, visit my mom that's always... Spend some time in the pool, warm up a little bit, there's definitely a bunch of snow outside my window right now so that's on the docket too.

Tim Veil (43:32):

Well, Ken, again, thank you so much for taking time to speak with us, a fascinating conversation. As clearly anybody listening will see, you've got a wonderful background and work for I think just a fascinating and exciting company. So thank you again for spending the time with us.

Ken Pickering (43:52):

Awesome. Thank you for having me. Pleasure talking.

Tim Veil (43:55):

Thanks for listening to this week's episode of Big Ideas in App Architecture. If you could, please rate the podcast five stars on Apple and Spotify and we'll talk to you next time.