Deploying Confluent Platform, from Zero to Hero ft. Mitch Henderson

Mitch Henderson (Technical Account Manager, Confluent) explains how to plan and deploy your first application running on Confluent Platform. He covers critical factors to consider, like the tools and skills you should have on hand, and how to make decisions about deployment solutions. Mitch also walks you through how to go about setting up monitoring and testing, the marks of success, and what to do after your first project launches successfully.

SEASON 2
Hosted by Tim Berglund, Adi Polak and Viktor Gamov
Produced and Edited by Noelle Gallagher, Peter Furia and Nurie Mohamed
Music by Coastal Kites 
Artwork by Phil Vo 

•  🎧 Subscribe to Confluent Developer wherever you listen to podcasts. 
• ▶️ Subscribe on YouTube, and hit the 🔔 to catch new episodes.
• 👍 If you enjoyed this, please leave us a rating. 
• 🎧 Confluent also has a podcast for tech leaders: "Life Is But A Stream" hosted by our friend, Joseph Morais.

Transcript

SPEAKER_01 0:00

When you actually deploy your first streaming application, a lot more happens than you writing some Java code and deploying it to a container somewhere. Today, I talked to someone whose job it is to help companies through the entire process of deploying the Confluent platform, from planning to the pizza party when it's all done. And is it really ever done? We'll talk about that on today's episode of Streaming Audio, a podcast about Kafka, Confluent, and the cloud.

SPEAKER_00 0:44

Hey Tim, thanks to having me.

SPEAKER_01 0:47

Mitch, tell us about yourself. What uh uh where are you from? And as they say, what what would you say you do here? You're a tourist. I think I said that. So yeah, you you work at Confluent. What do you do?

SPEAKER_00 0:59

Yeah, um, I'm from a little town in Missouri. Um, where it is really doesn't matter, but it's it's really small. I'm a technical account manager here at Confluent. Um, I guess what that boils down to is I help people be successful with the Confluent platform, help companies get the most value out of the Confluent platform, and uh make sure that they they stay on the happy path.

SPEAKER_01 1:23

There you go. So you you kick into gear like after someone has bought something, if they are a customer, you you help them.

SPEAKER_00 1:32

Um sometimes be successful. Sometimes. Oftentimes uh I get involved as part of the just the planning before they buy anything, uh making sure that I can kind of use my experience with other projects and uh help help them plan out their project before they buy anything. That way, whenever they do purchase and plan to go to production, everything's already on track.

SPEAKER_01 1:53

Nice, nice. And if you don't know uh in the listening audience, if you if you don't know the role of technical account manager or Tam, um these are and and you know Mitch is uh deeply technical folks who have a lot of hands-on experience building things and making them work. So they're they're you're I see you as a lot like consultants. I mean, you you could be a consultant in some different life, um in this in the the implementation sense of when somebody needs to put on a wetsuit and dive down the 15 meters and you know weld the beam. That's that's kind of you guys. Yeah. Uh you function in an advisory capacity, but extremely hands-on. And uh I view you guys as as it were knowing where the bodies are buried better than anybody else.

SPEAKER_00 2:44

Yeah, absolutely. We say uh heavy on the T, little on the M, and Tam. Um we uh the profile that we hire for is people that have experience deploying large-scale projects, being successful, um, knowing how to code, knowing what to avoid and what to use.

SPEAKER_01 3:02

Yeah, yeah. So it's a super cool role, and you get to see a lot of things. So what I and what I wanted to talk about talk about today is in your work as a TAM, um, you get to be very hands-on. Um, you know, in my work as uh a leader in the developer relations organization, is almost the opposite, right? I get to write code and build examples and teach, but I'm focused on uh getting people from zero to hero and you know helping them adopt and learn the basics, but then the you know, the building of the thing, that's kind of you guys. And so with your experience, I kind of wanted to talk through just the whole process uh of how it is, how it is one ought to deploy the confluent platform and what what it's like from the start, whatever that start is, until you know some end state.

SPEAKER_00 4:00

Yeah, absolutely. Um when I when I generally when I start with a customer, I kind of I start with what are your skill sets? What do you what do you know? What do you have? What are you coming from, and and what are you trying to do, right? And that kind of defines the the path that they take and uh the tools that we can leverage to to make sure that they can be successful.

SPEAKER_01 4:20

That's a very mature question. What are your skill sets? You know, because one could come in with a set of opinions about how well this is what should be done, and you know, it's gotta be Kubernetes, or you're stupid, or you know, whatever whatever opinions you might have about how all this ought to go, but that doesn't make a customer successful or somebody trying to build something. You know, you kind of have to ask what they're good at.

SPEAKER_00 4:41

Yeah, absolutely. Like uh I'd say a good 50 to 80 percent of my job is just doing that internal negotiation of we're really strong with VMs, we got no Kubernetes experience, or we have a ton of Kubernetes experience and we don't really do VMs. And kind of trying to find the happy path for each individual. Right.

SPEAKER_01 5:02

Um, and I'm I think I'm already distracting myself from the conversation that I had planned in my mind. We'll get back to that one, don't worry. But when you are on site, um I've I've had some experience in in you know previous lives in consulting that it's one thing to bring expertise, right? And you have a whole lot of that. Like you know how to run the confluent platform better than most human beings, like better than virtually all human beings there are. So that's cool. You actually enter the room with expertise and and knowledge that maybe they don't have. Do you find there's also uh a sense in which you kind of disrupt the equilibrium? Once you come in there, um, you know, there's there's this kind of internal political equilibrium of who knows what and who's got authority over what, and then you arrive in this consulting role. Do you see yourself shaking things up and enabling you know new kinds of decision making that people would have been stuck in? Does that make sense?

SPEAKER_00 6:07

Yeah, absolutely. I mean it's a question that I I get a lot, especially from you know technology managers and leaders. What's gonna have to change in my organization to make this successful? You know, what who do I need to take out for a coffee? Who needs to go to lunch with me, that kind of thing. Um it's often the most important question, right? For a lot of years, we've had a lot of data and a lot of a lot of systems that were very siloed, and they didn't really talk. You could kind of come use our stuff if you kind of want to, but you have to follow our rules. Right. And and the way that Kafka and Confluent work is it it gives the data to everybody, right? And but it kind of shifts around some of the responsibilities of who owns the data, what format it comes in, where it goes, you know, what's the governance over that data.

SPEAKER_01 6:55

And uh the you know, whatever the social equilibrium or political equilibrium is between the people there is disrupted by this new deployment. And just you by you being in the room, you kind of mix things up. Yeah.

SPEAKER_00 7:07

Yeah. I found that's a that's a good part of my my the role I I do here too, is is helping those negotiations, right? Making sure that everybody understands that, yeah, you're giving up this responsibility for this benefit, or you're getting this benefit, but you kind of have to do it a little differently.

SPEAKER_01 7:23

Yeah, yeah. Um so back to back to the whole deployment kind of life cycle. Um, how does that go when you've got somebody who is uh thinking about building something on Confluent platform, you know, maybe they've signed a deal and they're a customer, maybe they haven't. Kind of start there. What you know, you you said you start by asking who knows what and what you're good at, but take us to the next step.

SPEAKER_00 7:50

Yeah, the next step is just figuring out exactly what they want to do. Um generally people come and they have this idea that I'm gonna dump all my data in Kafka and magic happens, right? Right. Um That's what I think. Yeah, I I I would love that. Uh the reality of it is it doesn't quite work that easy oftentimes, right? We've got different data formats, different data sources, and different different uses for it. So narrowing narrowing it down and kind of focusing on something that is gonna give them a win and get them at least up and running and figuring out uh their boundaries and what they want to do and what they can do is often the first step.

SPEAKER_01 8:34

Right. And that's a specific goal. What are you good at and what is it that you actually want to do?

SPEAKER_00 8:40

Yeah, it's the focus thing. You gotta have focus to make it to to get on the road.

SPEAKER_01 8:45

Yeah. And to you know, for for you to have like a uh an objectively discernible success set of success criteria, you know, the here are things we want to do. Can we all tell if we've gotten these things done? Yes, good. You know, then then you've got an the ability to win, otherwise you're just sort of grinding.

SPEAKER_00 9:05

Yeah, and and nobody wants to sit there with a science experiment for for a year and and not really have any results to show, right? Yeah. That's no fun.

SPEAKER_01 9:14

And you kind of even have to ask, once you've identified that problem and you've got skills, I mean you have to ask, is this a problem that is good to solve with Kafka or with the Confluent platform? I mean, it do you do you have that? Do you go through that?

SPEAKER_00 9:28

All the time. Yeah. I mean, the no technology is a magic bullet, and it's good at some things, great at others, and it isn't really useful for other things, right? So we we talk to a lot of folks that have this idea that we'll just put in Kafka and that'll be the end of the story. But oftentimes we run into things that it's just it's not a great fit, and or it's not the best fit that it could be. And if they made some changes, some modifications to what they're planning, you could get more value out of it. Gotcha, gotcha.

SPEAKER_01 10:00

That's yeah, it's always good to uh and and you know you're not you're not setting anybody up for success to kind of monomaniacally pursue uh we must deploy our stuff everywhere no matter what, you know, that that really is how you lose. And you don't help anybody that way. You're not you're not being I think being faithful to your responsibility to your customers uh by helping them build something out that that is just not going to be successful.

SPEAKER_00 10:26

Yeah, and if they're not successful in the first go, um you know, they're not gonna be successful in the second go.

SPEAKER_01 10:32

Yeah.

SPEAKER_00 10:33

You kind of have to go down a pretty clear focused success path the first time to find the speed bumps and find out where your organization is strong and where it needs to grow. Yeah.

SPEAKER_01 10:44

So talk to me about uh so you you have a you have a goal.

SPEAKER_00 10:48

Uh what comes next? Yeah, the the goal is after the goal, what we generally do is kind of lay out what tools and bits and pieces we can play with to build whatever you need next. You know, we we have the the platform that has a bunch of different pieces, and each organization comes with their own bits and pieces, whether it's CDC tools, VMs, containers, um strong Java developers, what have you. So we kind of lay out the the what do we need off the shelf and grab those and kind of start figuring out how they're gonna interact.

unknown 11:22

Right?

SPEAKER_00 11:22

So if we need to, for example, take data out of an Oracle system, put it in Kafka, do some streams transformation on it, to do some alerting, and then dump those alerts down into a Mongo or Cassandra. You know, we can look at that and say, okay, we're we're gonna need some connectors, maybe a CDC tool, and uh probably a Java developer to do the streams applications, as well as you know, schema registry and connect workers and all the monitoring that goes along with that. Right.

SPEAKER_01 11:51

So it sounds like there are you're I mean you already did the assessment up front of what they're good at, and now that you know what the target is, you're you're figuring out what you need in terms of of people who can do that work.

SPEAKER_00 12:03

Yeah, it's it's it's going to the grocery store after you have the recipe.

SPEAKER_01 12:07

Yes, perfect. And how do you uh you know, I imagine you feel under pressure at that point to make sure that you're matching the you know, you you've got the recipe, and the grocery store, as it were, is the skills that are available inside the organization. So, like you just said, you need a Java developer for streams, you need somebody who can Wrangle Connect, you have some monitoring needs, you know. Okay, so this is the kind of these are the kind of people that'll need to build and run this. Um do you feel pressure to match those to who's there and what do you what do you do when it doesn't match? Like how's all that how's all that go?

SPEAKER_00 12:46

Yeah, um this is this is a fair question. It it there's no real pressure to to kind of match it to what's there. Obviously, there is a fit there, right? We can take a uh say a Spring Boot developer and make them a Kafka Streams developer in pretty rapid fashion, but we're not gonna take um uh a Python programmer and and slap them into Java world and have them be successful in the short term. Right. No, you're not. So that's that's the other part of the negotiation, is what you can do, and that really dictates the recipe. Um, if if we don't have those kinds of um the people that we need to be successful, that that's a whole different conversation we generally have with, you know, do you want to bring in a partner? Do you want to train? You know, we can we can often train Java developers really rapidly, right? And even a good DevOps person, we can make them um someone that's really successful with Confluent and pretty much the whole platform, even down to KSQL and KStreams pretty quickly. Gotcha.

SPEAKER_01 13:49

If they if they come to the table uh with DevOps skills, then are I guess that's a matter of a little bit of mentoring, maybe a three-day class, that kind of thing. You you they've got the basic skills, they just you just need to plug in holes with specific knowledge of how the platform works.

SPEAKER_00 14:05

Absolutely. Yeah, you kind of talk to them and figure out what what they're interested in and set that roadmap for them. Whether that's training, reading some blogs, uh a whole bunch of codiving and blog reading, what have you.

SPEAKER_01 14:18

Yeah. Uh watching some videos that Confluent Developer Relations team made. I mean, whatever it takes, right? You've got those things.

SPEAKER_00 14:24

Yeah. Well, everybody likes to watch Tim.

SPEAKER_01 14:28

I wasn't gonna say that, but I was gonna say I've heard they're pretty good. Uh so anyway, yeah, they they are. They're great. Um so keep keep going. What kind of things go wrong uh as you do this?

SPEAKER_00 14:40

Where does it get exciting? Oh, yeah. The um so that dev portion where they start putting things together, obviously the first thing they run into is how do I just deploy this system, right? How do I get the bits and pieces onto my servers, get them set up, configured correctly? And that's where we start bringing in the other teams of the organization, people like the security team. What are your security requirements for this? That's often the biggest negotiation we have. You know, do you want Kerberos? Do you OAuth, SASL Scram? What are your security needs here? Right. And that'll dictate a lot of the configurations and the bits and pieces that we use. Uh and then from there, it's what you know, it's a distributed system, so deployments aren't the easiest thing in the world. And configuration management is kind of a necessity. Yeah. So what are you good at? Are you good at Ansible? Great. We have some Ansible scripts, we can get you started with those. Here's probably the pieces that you need to modify. And you know, here's some examples of how you could modify it to uh to fit your environment. Um, and then after the deployment's done, my favorite portion is the the oper making it operational, not having a system sitting out there that magic is happening in, having it you know, observable, monitored, alerting, uh, and most importantly, tested. Right. Right. Uh go ahead. Yeah, uh, I mean, those are my my favorite parts of this because you can go from a really simple system that kind of you kind of trust it when it's working, but if it fails, that speed bump really hurts. Right. And then if you invest some time in your testing and your monitoring, it really, really pays off. And you can you can feel people's confidence really grow in the system. Nice. That's gotta be a good feeling.

SPEAKER_01 16:30

There is um, and this is, I think, clarifying what a TAM is. I'm noticing in the way you're describing your interaction with a customer that you are an advisor. And you know, there's code to be written and there's there's uh deployments to be configured and everything, but you're it sounds like you're sitting with them and saying, this is the thing that you should do to accomplish this goal, but you are not diving in and writing Java code, for example.

SPEAKER_00 17:01

No, uh, we work kind of hand in hand with our professional services group to do that. Um we kind of the TAM organization kind of oversees the project, the customer's health as a whole, and and where it's going and kind and gives the vision and guidance there. And the professional services team comes in and really does the heavy lifting. Gotcha. Gotcha.

SPEAKER_01 17:22

So the actual uh configuration of things and and you know getting people started on coding and all that. I guess you know, for for lots of development, that's also not really us. That's that's you know, we're we're trying to help customer be successful with that.

SPEAKER_00 17:35

Yeah, absolutely. It could be a partner, it could be anybody. Um where the TAM really comes in though is that could be one or many people. So keeping keeping that that focus on the project and keeping that single single thread and single story going is where we can help out a lot. You know, we talked about having a DevOps team for the for the platform, uh a development team for the streams job, and maybe a monitoring team that's watching in the knock. And having somebody that all of those three can get on the same page with is really beneficial.

SPEAKER_01 18:08

Yeah, it sounds kind of like if the technical side of the deployment were a movie, the TAM is like the director.

SPEAKER_00 18:16

Yeah, I kind of picture myself as Steven Spielberg.

SPEAKER_01 18:18

Yeah, no, right? Yeah, exactly. That's perfect, perfectly.

SPEAKER_00 18:21

I try to avoid the Michael Bay.

SPEAKER_01 18:26

I mean, there are those deployments. Yeah. You know, we don't talk about them on the podcast. No, um, no, that's not that's that's not a thing that we do here. We do not do it at Michael Bay. We do it Spielberg, where everybody hugs at the end and it's happy, dang it. That's right. Yes. Um, no, but I I I like that analogy. It's it's a uh, you know, you're maintaining vision and helping the various teams work together and making sure everybody is is oriented around the single-minded focus on the customer success.

SPEAKER_00 18:58

Yeah, and I mean, not to say that we don't dive in and help with technical issues. You know, if a customer's stuck on on a particular problem, um you know maybe professional services isn't it's not a big enough thing for professional services, right? Yeah, yeah, just some little thing. Yeah, some little thing. Even if it's like um a feature that they don't really know how to use, like say a converter for uh a connect job. Maybe they shouldn't be using the string converter, maybe they should be using the JSON converter, that kind of thing. Right, right.

SPEAKER_01 19:28

And that so the diving in on technical things, and uh by the way, sometimes on the podcast I say I'm asking these questions because I don't know. It's not it's not feigned scripted ignorance. Uh I'm actually getting to learn this. And I of course I know what TAMs do, but uh all of you know these little boundary things are um I'm I'm learning them with the audience. And from the outside, so everybody, you're listening to Mitch on the podcast. Uh I'm talking to him. Uh he's a super cool guy. But of course, internally, I can also see him on email threads and Slack conversations and everything, and I I can kind of see how he operates inside the company, and it very much looks to me like uh TAMs get their hands dirty. So, I mean, you you guys do absolutely talk about thorny technical issues and you know issues with deployments, and you know, here's this strange circumstance, how do we accommodate it? Uh so you you totally look like hands-on people. Yeah, I like a different side of perspective.

SPEAKER_00 20:26

I like to say I can still type.

SPEAKER_01 20:29

You can. Yes, you can still type. I still have IntelliJ installed. Okay, good. I was gonna say, I don't know if you can still code. And having IntelliJ co installed is like being able to code, so maybe, right? Yeah, but you know, hey, there you go. Um I just so you know, I've written uh a fair amount of code in the last few weeks, so it it doesn't need to stop. Yeah, it's great. Anyway, uh it's so refreshing to code, isn't it? Oh my goodness, it's like therapy. It's like I this is my first love, and you know, no, I can't go back to doing this full time, and I understand that, but it's nice to just spend a few hours together. Oh, it is, it's so wonderful. It is, it is. Uh anyway, um, so uh you've kind of got us um through uh to deployment. Talk about what you like to see, and you know, I'm sure you've got engagements where things go wonderfully and you feel great about them, and things that you've got engagements where they're more challenging and there are more curveballs. What what are signs? Um, you know, what are things that predict success? If I'm a customer, uh, what can I make happen in my organization to make this kind of technology change more likely to work well?

SPEAKER_00 21:46

Yeah, um, I saw a tweet the other day that was organizational costs trump everything else. Um, and it's absolutely true. Uh my biggest predictor of success is how well the organization functions.

unknown 21:59

Okay.

SPEAKER_00 22:00

Can the DevOps team walk over or pull up uh the the coders on Slack and say, hey, it looks like your your application maybe isn't doing the greatest thing. You could do it this way better. Or we're we're seeing, you know, maybe the broker's down. Is it? Maybe not. This is how you can check. So that that's my biggest predictor of sex success. The the next one is how well your monitoring is set up. If you can't see what's going on in the platform, there's a lot of open questions left in everybody's mind and they start to lose trust. So I I focus a lot, a lot of my time on just bringing people together and making sure that everybody understands what monitoring looks like, what good monitoring looks like, and and what what what to do if it doesn't start to look so great.

SPEAKER_01 22:52

Okay. Okay. Um do you have a favorite monitoring solution? I mean, like what's what what works well these days?

SPEAKER_00 22:59

Yeah, I I'm a big fan of pretty graphs. They're fun to look at, um, easy to understand. Yep. So I I I try to be as independent on this as I can, um, whether it's you know Prometheus and Grafana is super popular right now, or Datadog or App Dynamics, or any of those. Whatever you have is great. Um, I'm a big fan of Datadog and Prometheus Grafana, but um pretty much anything that can draw graphs. Sure. If you can see a pretty graph of the quantities that are important. Yeah, it's absolutely critical that you you know the quantities that are important over time. Everybody's deployment is going to be different a little bit. So being able to find your normal is just kind of it's table stakes for monitoring.

SPEAKER_01 23:44

Yeah. How about testing? You managed you mentioned testing. Uh talk to me about that.

SPEAKER_00 23:51

Yeah, so testing is is my favorite part because you get to break things intentionally and see how the system reacts. Um, it's no fun to just promote to production and say I'm done. Right. And and and fly out in the evening. Yeah. Because someone else is gonna pick up that phone, call at 2 a.m. and go, what the heck? I have no idea what to do on this one. So going through the testing regimen of you know, it doesn't have to be absolutely thorough, but I'm a big fan of, you know, bring down everything at least once and see how it reacts and fix it.

SPEAKER_01 24:23

Okay.

SPEAKER_00 24:24

Whether that and that, you know, that that should go down to I need to drop a zookeeper. Okay, how do I bring the zookeeper back in? How do I replace a zookeeper? How do I upgrade a zookeeper? Uh, all the way through to the brokers. How do I do a rolling restart? What are my conditions for going to the next node after I've restarted or after I've upgraded the first one? So knowing those sorts of things, it not only gives you the idea or gives you the information you need to monitor correctly and knowing how the monitoring system is going to react, but it really gives you insight into how the system works so you can understand it at a more fundamental level.

SPEAKER_01 24:58

Okay. And that's by uh a manual process of breaking things, is uh is how you how you find that, uncover that knowledge.

SPEAKER_00 25:07

Yeah, it can be manual. Um you know, chaos engineering and the kind of the tooling around there is getting really popular. Um oftentimes I'm I'm a big fan also of you gotta break it manually first before you can automate your testing.

SPEAKER_01 25:21

Before you can automate your breaking, yeah. Yeah. Uh tell us about chaos engineering, just in case there are listeners who don't who aren't familiar with that.

SPEAKER_00 25:28

Yeah, the idea of chaos engineering is is things kind of randomly break, and it's gonna break in random ways, so you might as well test for that. Whether that's having um the broker CPU spike and seeing how the system reacts. But basically ingest in injecting testing into every part of your deployment.

SPEAKER_01 25:47

Right. And the the vision of chaos engineering is really an automated system that that you know goes around and breaks things. All the time. Yeah. And and the interesting impact that that has is it creates a system that it almost becomes more robust as a result of that constant insult happening. In fact, the system system wide it does, because you've got people now who have to respond to those broken things. Maybe they cause bad outcomes. You know, you've got this this uh chaos agent uh taking brokers down, taking zookeepers down, uh uh, you know, breaking the network between the application and the confluent cluster or whatever. Um and maybe the system responds to those. Maybe it doesn't, and if it doesn't, you got people who are gonna fix things.

SPEAKER_00 26:37

Yeah, it's kind of like getting your hand real close to the hot stove so that you know that I need to check it. Right.

SPEAKER_01 26:44

Yeah, yeah, it is uh it is kind of like that. Or more like uh a system where somebody grabs your hand and puts it on the burner. Um and as a result of that you learn to wear a glove.

SPEAKER_00 26:57

Yeah, and you learn first date.

SPEAKER_01 26:59

Right, you do, yeah, yeah. If you didn't have a glove on the first time, you know, well, okay, that hurts, let's do a glove. And the system as a as a result, the system as a whole uh becomes more robust. So it's sort of like it's building in, I guess, what some people call anti-fragility into your system by by throwing constant insults at it.

SPEAKER_00 27:17

Yeah, you know, it's not constant insults, it's just at it. It's at you too. Right. Yeah. It embeds that idea that you have to set up the system and build the system and code the system in a way that something's going to break, so you better just expect it.

SPEAKER_01 27:33

Yeah, and design for that. Design designed to keep working, even with those things broken. Um so what have we have we gotten to success yet? Like what uh what are some other fun things that can get in the way of the finish line?

SPEAKER_00 27:50

Yeah, I don't I don't like to lay out a finish line.

SPEAKER_01 27:53

Oh, cool.

SPEAKER_00 27:54

I I kind of I kind of say once you've launched your first app, well, you've got a whole bunch of data in there and a whole bunch of things going on. What else can you do with it?

unknown 28:04

Right?

SPEAKER_01 28:04

Okay, so it it I'm sure it feels, you know, launching the first app feels like success because you did define that up front. You said this is what we're trying to get to, but um a good point. Um that's actually day one that you've gotten to.

SPEAKER_00 28:17

Generally it's day zero for most people. Uh it this is where where Kafka gets fun. Uh Kafka's value prop is kind of many to many distribution of data, right? Right. So having that data in there and having that experience and that team, that's when you start going look for things that maybe you weren't doing before that you can do now, or things that you can improve upon that you were doing before.

SPEAKER_01 28:42

Do people do you do you see a process that people go through? Um, because streaming is different, you know, it's none of us learned it in school, most of us haven't built a system this way yet. Um, and you know, you're probably mostly working with people who are doing their first one. And do you see people discovering how to do this or you know, getting getting some new capacity for thinking about the rest of the company in a way that, oh wait, no, there's all these applications all over the place. I mean, what what happens there when people start thinking about their next app?

SPEAKER_00 29:16

Yeah, and you could actually kind of feel this with most of the groups when they start really grasping what they can do with stream processing, you know, their eyes light up, they start asking the some really interesting questions about, so if I do this, I can replace that. Or this process that was 24 hours, it really doesn't need to be 24 hours delayed, does it? And and those kind of aha moments are awesome.

SPEAKER_01 29:43

Yeah, they see that, and uh then uh the next use case opens up and the next one after that. And like you said, once there's all this data, this real-time data inside the cluster, uh, it only gets more valuable and starts to want to pull more things into itself.

SPEAKER_00 29:59

Oh, absolutely. And it's it's not just the data. You know, we do a lot of things that are transformations, right? So data transformations, changing A's disease, and a lot of that is is entirely repeatable. So that the thing that you build in phase zero or phase one can absolutely be leveraged in later in later projects and later stages to just make that that transition to a streaming architecture so much quicker. Absolutely. Yeah, okay, that makes sense.

SPEAKER_01 30:28

What is your uh your favorite lesson learned? Tamming, if if uh favorite lesson learned that is appropriate to share with people on the internet.

SPEAKER_00 30:38

Uh uh my favorite lesson learned is how to negotiate. Really? Yeah. Um I tell all the new TAMs here at Confluent whenever they join, or if any out of having coffee with anybody that joins Confluent, that negotiation inside of an organization is absolutely critical.

SPEAKER_01 30:58

Okay. And what are you generally negotiating?

SPEAKER_00 31:01

Yeah, it comes back to what I said before about you're giving up some responsibilities, but you're getting back something. And helping people understand those, that negotiation of I'm willing to give up this to get this back. It really makes the whole process easier, more fun, more enjoyable. Everybody goes home happier.

SPEAKER_01 31:22

Huh. Makes a lot of sense. My guest today has been Mitchell Henderson. Mitch, thanks for being a part of Streaming Audio.

SPEAKER_00 31:29

Yeah, thanks for having me, Tim. Uh, happy to be back anytime.

SPEAKER_01 31:33

And there you have it. I hope that was helpful to you. If you've got questions, you can ask me at TL Burgland on Twitter. That's T-L-B-E-R-G-L-U-N-D. Or you can leave a comment on any of our YouTube videos. Your question might be featured on the next episode of Streaming Audio. And feel free to subscribe to our YouTube channel and this podcast wherever fine podcasts are sold. And if you subscribe through iTunes, be sure to leave us a review there. That helps other people discover the podcast and just generally helps us get the word out. We appreciate your support. See you next time.