Screaming in the Cloud - Serverless Should be Simple with Tomasz Łakomy

Episode Date: May 10, 2022

About TomaszTomasz is a Frontend Engineer at Stedi, Co-Founder/Head of React at Cloudash, egghead.io instructor with over 200 lessons published, a tech speaker, an AWS Community Hero and a lifelong learner.Links Referenced:Cloudash: https://cloudash.dev/Twitter: https://twitter.com/tlakomy

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. personally. Why scroll through endless dashboards while dealing with alert floods, going from tool to tool to tool that you employ, guessing at which puzzle pieces matter? Context switching and tool sprawl are slowly killing both your team and your business. You should care more about one of those

than the other. Which one is up to you? Drop the separate pillars and enter a world of getting one unified understanding of the one thing driving your business. Production. With Honeycomb, you guess less and know more. Try it for free at honeycomb.io slash screaming in the cloud. Observability. It's more than just hipster monitoring. This episode is sponsored in part by our friends at Chaos Search. You could run Elasticsearch or Elastic Cloud or OpenSearch as they're calling it now or a self-hosted Elkstack.

But why? Chaos Search gives you the same API you've come to know and tolerate, along with unlimited data retention and no data movement. Just throw your data into S3 and proceed from there as you would expect. This is great for IT operations folks, for app performance monitoring, cybersecurity. If you're using Elasticsearch, consider not running Elasticsearch. They're also available now in the AWS Marketplace.

If you'd prefer not to go direct and have half of whatever you pay them count toward your EDP commitment, discover what companies like Equifax, Armor Security, and Blackboard already have. To learn more, visit chaossearch.io and tell them I sent you just so you can see them facepalm yet again. Welcome to Screaming in the Cloud. I'm Corey Quinn. It's always a pleasure to talk to people who ask the bold questions. One of those great bold questions is, what if CloudWatch's webpage didn't suck?

It's a good question. It's one I ask myself all the time. And then I stumbled across a product that wound up solving this for me, and I'm a happy customer. To be clear, they're not sponsoring anything that I do, nor should they. It's one of those bootstrapped, exciting software projects called CloudDash. Today, I'm joined by the head of React at CloudDash, Tamash Wakume. Tamash, thank you for joining me.

It's a pleasure to be here. So where did this entire idea come from? Because I sit and I get upset every time I have to go into the CloudWatch dashboard because first something's broken. In an ideal scenario, I don't have to care about monitoring or observability or anything like that. But then it's quickly overshadowed by the fact that this interface is terrible. And the reason I know it's terrible is that every time I'm in there, I feel dumb. My belief is that for the longest time, I thought that was a problem with me, but no. Invariably, when you wind up working with something and consistently finding it a bad, you don't know enough to solve for it, it's not you. It is, in fact, the signs of a poorly

designed experience, start to finish. You should be smarter to use this tool. It's very rarely correct. And there are a bunch of observability tools and monitoring tools for serverless things that have made sense over the years and made this easier. But one of the most, and please don't take this the wrong way, stripped down bare essentials

of just the facts style of presentation is CloudDash. It's why I continue to pay for it every month with a smile on my face. How did you get here from there? Yeah, that's a good question. I would say that CloudDash was born out of desire for simple things to be simple. So as you mentioned, CloudDash is basically like a monitoring and troubleshooting tool

for serverless applications made for serverless developers, because I am very much into serverless space, as is Maciej Wienicki, who's another half of the Cloudash team. And the whole promise of serverless was things are going to be simpler. So you have a bunch of code, you're going to dump it into a Lambda function, and that's it. You don't have to care about servers,

you don't have to care about provisioning stuff, you don't have to care about maintenance, and so on. And that is not exactly true, because while PagerDuty still continues to be a running business even in serverless spaces. So you will get paged every now and then. The problem is what we kind of found is once you have an incident, PagerDuty always tends to call you in the middle of the night. It's never like 11 a.m. during the workday.

It's always the middle of the night. And no one's ever happy whenm. during the workday. It's always the middle of the night. And no one's ever happy when it calls them either. It's, ah, hell, whatever it rings. It's, yeah, the original call of duty. Pager duty, hooked up to Nagios. I am old enough to remember those days. How are they in business? Like, imagine paying for something

that's going to wake you up in the middle of the night. It doesn't make sense in any case. So why do you pay for that product? Because it's really going to piss me off. Okay, well, does that sound like a good business to you? Well, AWS seems to think so. No one's happy working with that stuff. Fair, fair enough.

So in that case, we've established, okay, so you wake up, you go to AWS console because you saw a notification that this and this API has, you know, this threshold was above it. Something was above the threshold. And then you go to the CloudWatch console, and then you see, okay, those are the logs, those are the metrics, I'm going to copy this request ID,

I'm going to go over here, I'm going to go to X-Ray, and again, it's 3 a.m., so you don't exactly remember what you were investigating after like 10 minutes. And this is a problem. We've kind of identified that it's not simple to do this kind of thing. It's not simple to open something and have an understanding, okay, what exactly is happening in my serverless app at this very moment?

Like what's going on? So we built that. So Cloudash is a desktop app. It lives on your machine, which is a single pane of glass, it's a single pane of glass view into your serverless system. So if you are

using CloudFormation in order to provision something, when you open Cloudash, you're going to see all of the metrics, all of the Lambda functions, all of the API gateways that you have provisioned. As of yesterday, API gateway is no longer cool, because they did launch the direct integration. So you can call Lambda functions.

Yes, the one that they released and then rolled back and somehow never said a word because that's an AWS messaging story and then some right around reInvent last year. And another quarter goes by and out it goes. It launched yesterday. Yeah, it's terrific. I love that thing.

The only downside to it is, ah, you have to use one of their, you've used their domain. No custom domain support. Really? Well, you can hook up CloudFront to it, but the pricing model that way makes it more expensive than API gateway. Okay. So I could use CloudFlare in front of it and then it becomes free.

So I bought a domain just for that purpose. That's right. My direct Lambda URLs now live behind the glorious domain of cheapass.cloud, because of course they are. It's a day one product from AWS, so of course it's not feature complete. But one of the things I like about the serverless model, and it's also a challenge when it comes to troubleshooting stuff, is that it's very much set it and forget it style. Because serverless, in many cases, at least the way that I tend to use it, is back office stuff. It's backend things. It's processing on things that are not necessarily

always direct front and center. So these things can run on their own for years until finally you find a strange bug in a new use case or you want to go and change something. And then it's how the hell did this ever work? And it's still working kind of, but what fool built this? Of course it was me. It's always me.

But what happened here? You're basically excavating your own legacy code, trying to understand what's going on. And so you're already upset then. CloudDash makes this easier to find the things, to navigate through a whole bunch of different accounts. And there are a bunch of decisions that you made while building the app that are so clearly correct that I get actively annoyed when others don't. Because, oh, it looks at your AWS configuration file in your user home directory. Great. Awesome. It's a desktop app, but it still consults that file. Yay. Integration between ClickOps and the terminal. Wonderful. But, ah, I use SSO for a lot of stuff.

So that's going to fix your little red wagon. I click on that app and suddenly, bam, a browser opens asking me to log in and authenticate and allow the request. It works, and then suddenly it goes back to doing exactly what you'd expect it to. It's really nice. The affordances behind this are glorious. Like I said, one of our kind of design goals when building CloudDash is to make simple things simple again. The whole purpose is to make sure that you can

get into the root cause of an issue within five minutes, if not less. This is the app that you're going to tend to open whenever, as you said, because some of the systems can run for ages, literally, without any incident whatsoever. Then the date is going to change because somebody hard-coded that the year is still 2020 and off you go, you have an incident. But what's important about Cloudash is that we don't send logs anywhere.

And that's kind of important because you don't pay for put metric API because we are not sending those logs anywhere. If you install Cloudash on your machine, we are not going to get your logs from the last 10 years, put them into a system, charge you for that, just so you are able to find out what happened in this particular hour two weeks ago. We genuinely don't care about your logs.

We have enough of our own logs at work to analyze, to investigate, and so on. We are not storing them anywhere. In fact, whatever happens on your machine stays on the machine. And that is partially why this is a desktop app. Because we don't want to handle your credentials. Absolutely, we don't want you to give us any of your credentials, access keys, whatever.

We don't want that. So that is why you install CloudDash. It's going to run on your machine. It's going to use your local credentials. So effectively, you could say that this is a much more streamlined and much more laser-focused browser or like an eye into AWS systems, which live on the serverless side of things. I got to deal with it in a bit of an interesting way recently. I have a detector in my company's production AWS org to detect when ClickOps is afoot. Now I'm a big proponent of ClickOps, but I also want to

know what's going on. So I have a whole thing that runs detects when people are doing things in the console versus via API, and it alerts on certain subsets of them. I had to build a special case for the user agent string coming out of CloudDash because no, no, this is an app. This is not technically ClickOps. It is also read-only, which is neither here nor there to my understanding. But it was, oh yeah, this is effectively an Electron app. It just wraps effectively a browser and presents that as an application.

And cool. From my perspective, that's an implementation detail. It feels like a native app because it is. And I can suddenly see the things I care about in a way that is much more straightforward

without having to have four different browser tabs open where, okay, here's the CloudTrail log for this thing. Here's the metrics next to it. Oh, those are two separate windows already

and so on and so forth. It just makes hunting down the obnoxious problems so much nicer. It's also, you're one of those rare products where if I don't use it for a month, I don't get the bill at the end of the month and think, ooh, that's going to make, I wasted the money. No, nice. I had a whole month where I didn't have to mess with this. It's great. Exactly. I feel like, you know, it's one of those systems where, as you said, we send you an email at the end of every month that we're going to charge you X dollars for the month. By the way, we have fixed pricing and you can cancel, you know, any time.

And it's like one of those things that, you know, I didn't have to open this up for a month. This is awesome because I didn't have any incidents. But I know whenever, again, PagerDuty is going to decide, hey, dude, wake up. You know, you've slept for three hours. That is definitely long enough. Then you know that this app is there and you can use that. We very much care about building this stuff

not only for our customers, but we also use that on a daily basis. In fact, every single time that I have to or I want to investigate something in our serverless systems at Steady, because everything that we do at work at Steady is in serverless paradigm. So I tend to open Cloudash 95% of the time

whenever I want to investigate something. And whenever I'm not able to do something in Cloudash, this goes literally to the top of our issue lists or backtalk or whatever you want to call it because we want to make this product not only awesome for customers to buy a Lambo or whatever, but we also want to be able to use that on a daily basis. And so far, I think we've kind of succeeded,

but then again, we have quite a long way to go because we have more ideas than we have the time, definitely. So we have to kind of prioritize what exactly we're going to build. So definitely like integrations with alarms. So for instance, we want to be able to see the alarms directly in the Cloud Edge UI. Secondly, integration with Logs Insights and many other ideas. I could probably talk for hours about what we want to build.

I also want to point out that this is still your side gig. You are, by day, a front-end engineer over at Steady, which has a borderline disturbing number of engineers with side gigs, generally in the serverless space, doing interesting things like this. Dynobase is another example, a DynamoDB desktop client, very similar in some respects. I pay for that too. Honestly, it's for a company in Steady's space, which is designed as basically a giant API for deep, large enterprise business stuff. There's an awful lot of stuff for small scale coming out of that. I wind up throwing a disturbing

amount of money in the general direction of Steady for not being their customer? But there's something about the culture that you folks have built over there. It's just phenomenal. Yeah, for that, you know, having a side gig is not a part of interview process at Steady. You don't have to have a side project. But yeah, you're absolutely right. You know, the amount of kind of side projects and, you know, some of those are monetized, as you mentioned, Cloudash and Dynabase and others. Some of those, because for instance, you talked to Aiden,

I think a couple of weeks ago, about his shenanigans whenever AWS is going to announce something, he gets in and tries to bake this in the most amusing ways possible. Yeah, I mean, I could probably talk for ages about why Steady is by far the best company I've ever worked at. But I'm going to say this, that this is the most talented group of people I've ever met and myself, honestly. And the fact that I think we are the second largest group of AWS experts outside of AWS because the density of AWS heroes or ex-AWS employees or people who have been doing cloud stuff for years is frankly

massive. I tend to learn something new about cloud every single day and not only because of the last week in AWS but also from our Slack. This episode is sponsored by our friends at Oracle Cloud. Counting the pennies, but still dreaming of deploying apps instead of Hello World demos? Allow me to introduce you to Oracle's Always Free tier. It provides over 20 free services in infrastructure, networking, databases, observability, management, and security. And, let me be clear here, it's actually free. There's no surprise billing until you intentionally and proactively upgrade your account. This means you can provision a virtual

machine instance or spin up an autonomous database that manages itself, all while gaining the networking, load balancing, and storage resources that somehow never quite make it into most free tiers needed to support the application that you want to build. With Always Free, you can do things like run small-scale applications or do proof-of-concept testing without spending a dime. You know that I always like to put asterisk next to the word free. This is actually free. No asterisk. Start now. Visit snark.cloud slash oci-free. That's snark.cloud slash oci-free. There's something to be said for having colleagues that you learn from. I have never enjoyed environments where I did not actively feel like the dumbest person in the room. That's why I love what I do now. I inherently am. I have to talk about so many different things. Whenever I talk to a subject matter expert, it is a certainty that they know more about the thing than I do.

With the admitted and depressing exception, of course, of the AWS bill. Because it turns out the reason I had to start becoming the expert in that is because there weren't any. And here we are now. I want to talk as well about some of your interaction outside of work with AWS, for example. You have been a, you've been an egghead instructor for a while with over 200 lessons that you publish. You're an AWS community hero, which means you have the notable distinction of volunteering

for a for-profit company. Good work. Now, the community is very important. It's, it's helping each other make sense of the nonsense coming out of there. You've been involved in the ecosystem for a very long time. What is it about, I guess, the thing I'm wondering myself sometimes, what is it about the AWS universe that drew you in and what keeps you here? To give you some context, I started learning about the cloud and AWS back in early 2019.

So fun fact, Maciej Wienicki, again, the co-founder of Cloudash, was my manager at the time. So we were, I mean, the company I used to work for at the time, Olex Group, we are in the middle of cloud transformation, so to speak. So going from on-premises to AWS. And I was hired as a senior front-end engineer doing all kinds of front-end stuff, but I wanted to grow, I wanted to learn more, so the idea was

okay, maybe you can get AWS certified because it's one of those corporate goals that you have to have something to put a checkbox next to it. So getting certified, there you go, you have a checkbox, and off you go. So I started, you know, diving in, and I saw this whole ocean of things that, you know, I was not entirely aware of.

To be fair, at the time, I knew about S3. I knew that you can put a file in an S3 bucket, and you can access it from the internet. This is like the rough idea of my AWS experience system. Ideally, intentionally, but one wonders sometimes. Exactly. That is why you always put stuff as public, right? Because you don't have to worry about which ones are public and which ones are private.

No, I'm kidding, of course. But still, I think what's driving me into AWS is this endless ocean of things to learn and things to play with and things to teach. I do enjoy teaching, as you said. I have quite a lot of content, videos, blog posts, conference talks, and a bunch of other stuff. And I do that for two reasons.

First of all, I tend to learn the best by teaching. So it helps me very much solidify my own knowledge. first of all, I tend to learn the best by teaching. So it helps me very much solidify my own knowledge. Whenever I record, I have two courses about CDK. When I was recording those, I definitely solidified my ideas about CDK. I get to play with all those technologies. And secondly, it's helpful for others. And people have opinions about certificates and so on and so forth.

But I think that for somebody who's trying to get into either the tech industry or cloud stuff in general, being certified helps massively. And I've read stories about people who basically managed to double or triple their salaries by going into tech with some of those certificates. That is why I strongly believe, by the way, that those certificates should be free.

If you can pass the exam, you shouldn't have to worry about this $150 of the fee. I wrote a blog post a while back, the dumbest dollars a cloud provider can make. And it's charging for training and certification. Because if someone's going to invest that kind of time in learning your platform, you're going to try and make 150 bucks off them. And it switches in some cases is going to put people off from even beginning that process. What cloud provider am I going to build

a project on? Obviously the one I know how to work with and have a familiarity with in almost every case. And the things you learn in your spare time as an independent learner, when you get a job, you tend to think about your work the same way. It matters. It's an early on ramp that pays off down the road in the term of years. I used to be very anti-cert, personally, because it felt like I was jumping through hoops and paying, in some cases, for the privilege. I had a CCNA for a while from Cisco. There were a couple of smaller companies, SaltStack, for example, that I got various certifications from at different times. That was sort of cheating because I helped write the software, but that's what I was hearing over there.

And I do have a standing AWS cert that I get a different one every time mine is about to expire because it gets me access to lounges at physical events, which is the dumbest of all reasons to get certs, but here you go. I view it as the $150 lounge pass with a really weird entrance questionnaire. But in my case, certs don't add anything to what I do. I am not the common case. I am not early in my career.

Because as you progress through your career, there needs to be a piece of paper that says you know things. And early on, a degree or certifications are great at that. In time, it becomes your own list of experience on your resume or CV or LinkedIn or God knows what, polywork if you're doing it the right way these days. And it shows a history of projects that are similar in scope and scale and impact to the kinds of problems that your prospective employer is going to have to solve themselves. Because the best answer to hear, especially in the ops world, even there's a problem is, oh, I've seen this before.

Here's how you fix it. As opposed to, well, I don't know. Let me do some research. There's value to that. And I don't begrudge anyone getting certs to a point. At least that's where I sit on it. At some point when you have 25 certs, it's, what do you actually do when you work? Because it's taking the tests

and learning all of these things, which in many ways does boil down to trivia, stands in counterbalance to a lot of these things. Yeah, I mean, I definitely totally agree. I remember, you know, going from zero to, maybe not here, I'm not talking about AWS Hero, but going from zero to be certified, that was the solutions architect associate.

I think it took me like 200 hours. I am not the brightest, the sharpest tool in the shed. So it probably took me kind of somewhat more. I think it's doable in like 100 hours, but I tend to over-prepare for stuff. So I didn't actually take the actual exam until I was able to pass the sample exams with like 90% plus, just to be extra sure that I'm actually going to pass it. But still, I think at some point you probably should focus on getting into the actual stuff.

Because I hold two certificates, and one of those is going to expire, and I'm not entirely sure if I want to go through the process again. But still, if AWS were to introduce a serverless specialty exam, I would be more than happy to have that. I genuinely enjoy serverless, and the fact that I would be able to

solidify my knowledge and have this kind of established path of the things that I should learn about in order to get this particular certificate. I think this could be interesting. But I am not probably going to chase all the 12 certificates. Maybe if AWS IQ was available in Poland, maybe that would change because I do know that with IQ, those certs do matter. But as of center, it's now I'm quite happy with my certs that I have right now. Part of the problem too, is the more you work with

these things, the harder it becomes to pass the exams, which sounds weird and counterintuitive, but let me use myself as an example. When I got the cloud practitioner cert, which I believe has lapsed since then, and I got one of the new associate level betas. I'll keep moving up the stack until I start failing exams. But I got a question wrong on the Cloud Practitioner because it was, how long does it take to restore an RDS database from a snapshot backup? And I gave the honest answer of what I've seen rather than what it says in the book. And that honest answer can be measured in days or hours. Yeah. And, oh, that's not the correct

answer. Yeah, but it is the real one. Similarly, a lot of the questions get around trivia, syntax of which of these is the correct argument and which ones did we make up? I can explain in some level of detail virtually every one of AWS's 300-some-odd services to you. Ask me about any of them, I can tell you what it is, how it works, how it's supposed to work, and make a dumb joke about it. Fine, whatever. You'll forgive me if I went down that path instead of memorizing, what is the actual syntax of this YAML construct inside of a CloudFormation template? Yeah, I can get

the answer to that question in the real world with about 10 seconds of Googling and we move on. That's the way most of us learn. It's not cramming trivia into our heads. There's something broken about the way that we do certifications and tech interviews in many cases as well. I look back at some of the questions I used to ask people for Linux sysadmin-style jobs, and I don't remember the answer to a lot of these things. I could definitely get back into it, but if I went through one of these interviews now, I wouldn't get the job.

One would argue I shouldn't because of my personality, but that's neither here nor there. I mean, that is why you use CDK, so you don't have to remember random YAML commands. And if you go, you don't have YAML anymore. There you go. Yes, you're quite the CDK fanboy, apparently. I do like CDK, yes.

I don't like mental overhead. I don't like context switching. And the way we kind of work at Steady is everything is written in TypeScript. So I am a front-end engineer, so I do stuff in the front-end line in TypeScript. All of our Lambda functions are written in TypeScript, and our infra is written in TypeScript. So I can open up my Visual Studio code and jump between all of those files, and the language stays the same, the syntax stays the same,

the tools stay the same. And I think this is one of the benefits of CDK that is kind of hard to replicate otherwise. People have many opinions about the best to deploy infrastructure in the cloud. The best infrastructure as cloud tools is the one that you use at work or in your private projects, right? Because some people enjoy ClickOps like you do. People enjoy CloudFormation by hand, which I don't. People are very much into Terraform or serverless framework. I'm very much into CDK.

Or the SAM CLI, or there are three or four more, and I use all of these things in some of my monstrosity projects to keep up on all these things. I did an exploration with the CDK. Incidentally, I think you just answered why I don't like it.

Because? Because it is very clear that TypeScript is a first-class citizen with the CDK. My language of choice is shitty bash because grumpy old sysadmin, it happens. And increasingly that is switching over to terrible Python because I'm very bad at that.

And the problem that I run into as I was experimenting with this is it feels like the Python support is not fully baked. Most people who are using the CDK are using a flavor of JavaScript. And let's be very clear here. Every time I have tried to explore front end, I have come away more confused than I was when I started.

Part of me really thinks I should be learning some JavaScript just because of its versatility and utility to a whole bunch of different problems. But it does not work the way I think on some level that it should because of my own biases and experiences. So if you're not a JavaScript person, I think that you have a much rockier road with the CDK. I agree. Like I said, I tend to talk about my own experiences

and my kind of thoughts about stuff. I'm not going to say that this tool or that tool is the best tool ever because nothing like that exists apart from jQuery, which is the best thing that ever happened to the web since baked bread, honestly. But you are right about CDK. To the best of my knowledge, all of the other languages that are supported by CDK are effectively transpired down from TypeScript. So first of all, it is written in TypeScript,

and then the Python and all of the other languages kind of come second. And afterwards, I tend to enjoy CDK because, as I said, I use TypeScript on a daily basis. And with regards to Frontend, you mentioned that every single time you use that, you end up being more confused. It never goes away.

I've been doing Frontend stuff for years, and it's kind of exactly the same. Fun story, I actually joined Cloudash because Maciej started working on Cloudash alone. And after quite some time time he was so frustrated with the modern front-end landscape that he asked me, I genuinely need some help.

I am tired of React. I am tired of React hooks. This is way too complex. I want to go back to doing backend stuff. I want to go back to thinking about how we're going to integrate with all those APIs. I don't want to do UI stuff anymore. Which is kind of like an interesting shift because I remember at the very beginning of my career where people were talking about frontend. Frontend is not

programming. Frontend is easy, it's simple. I can learn CSS in an hour. And the amount of people who say that CSS is easy and are good at CSS is exactly zero. Literally nobody who's actually good at CSS says that CSS or frontend or anything like that is easy because it's not. It's incredibly complex. It's getting probably more and more complex because the expectations of frontend UIs grow quite rapidly. It's challenging. It is difficult. And one of the things I find most admirable about you

is not even your technical achievements. It's the fact that you are teaching other people to do this. In fact, this gets to the last point I want to cover on our conversation today when I was bouncing topic ideas off of you. One of the points you brought up that I'm like, oh, we're keeping that and saving that for the end, is why, in your words, why speaking at tech events gets easier but never easy. Let's dive into that. Tell me more about it.

Basically, I accidentally kick-started my career by speaking at meetups, which later turned into conferences, which later turned into me publishing courses online, which later turned into conferences, which later turned into me publishing courses online, which later turned into me becoming a KWS here, and here we are talking to each other. I do enjoy going out in public and speaking and being on the stage. I think if somebody has the heart, the ability to do that,

I do strongly recommend giving it a shot. Not only to get a life-changing experience, because the first time you go in front of hundreds of people, this is definitely something that's going to shake you. While at the same time, this is absolutely definitely not for everyone. But if you are able to do that, I think this is definitely worth your time.

But as you said, by quoting me, that it gets easier. So every single time you go on stage to talk at a meetup or at a conference or online conferences, which I'm not exactly a fan of, for the record. It's too much like work, too much like meetings. There's nothing different about it.

Yeah, exactly. Like there's no journey. There's no adventure in online conferences. I know that, of course, given all of that, we had to kind of switch to online conferences for quite some time, where I think we are pretending that COVID is not a thing anymore.

So we are effectively going back. But still, the point I wanted to make is that I am a somewhat experienced public speaker. I like to say that because I've been doing that for years. But I've been talking to people who actually get paid to speak at the conferences, to actually do that for a living, and they all say the same thing.

It gets simpler, it gets easier, but it's never freaking easy to go out there and to share whatever you've learned. I'm one of those people. I am a paid public speaker fairly often, even ignoring the podcast side of it. I've spoken on conference stages a couple hundred times at least.

And it does get easier, but never easy. It's a great way of framing it. I get nervous before every talk I give. There are, I think, two talks I've given that I did not have adrenaline hit nervous energy before I went on stage. And both of those were duds. And because I think that it's part of the process,

at least for me. And it's like, oh, how do you, like, how do you wind up, like, how do you wind up not being, being scared before you go on stage? You don't. You really don't. But if that appeals to you and you enjoy the adrenaline rush and the rest, do it. If you're one of those people who views public speaking as, I would prefer death over that. People are more scared of public speaking. They are death in some cases. Great. There are so many ways to build audiences and to reach people that, fine, if you don't like doing it on stage,

don't force yourself to. I'd say try it once, see how it feels. Meetups are great for this. Yeah, meetups are basically the best way to get started. I'm yet to meet a meetup, either offline or online, who is not looking for speakers. It's always quite the opposite. I was co-organizing a meetup in my city here in Poland.

And the story always goes like this. Okay, we have a date, we have a venue, where are the speakers? And then the tumbleweed is going to roll across the road and oh crap, we don't have any speakers. So we're going to try to find something, reach out to people. Hey, I know that you did this fantastic project at your workplace. Come to us, talk about this. No, I don't want to.

I'm not an expert. I have only 50 years of experience as an engineer. This is not enough. Like I said, I do strongly recommend it. But as you said, if you are more scared of public speaking than literally dying, maybe this is not for you. It comes down to stretching your limits, finding yourself interesting.

I find that there are lots of great engineers out there. The ones that I find myself drawn to are the ones who aren't just great at building something, but at storytelling around the thing that they built. Yes, you built something awesome, but you have to convince me to care about it. You have to show me the thing that got you excited about this. And if you can't inspire that excitement in other people, okay, are you really excited about it? Or what is the story here? And again, it's a different skill set. It is not for everyone, but it is absolutely a significant career accelerator

if it's leveraged right. That's where I sit on it. Yeah, absolutely. I think that we don't talk enough about the overlap between engineering and marketing in the good sense of marketing, not the shady kind of marketing. The kind of marketing that you do for yourself

in order to elevate yourself, your projects, your successes to others. Because try as you might, but if you are sitting in the corner of an office, just jamming on your projects, your successes to others. Because try as you might, but if you are sitting in the corner of an office, just jamming on your keyboard 40 hours per week, you are not exactly likely to be promoted because nobody is going to actively reach out to you to find out about your recent successes and so on.

Which at the same time, I'm not saying that you should go add channel in Slack every single time you push a commit to the main branch. But there's definitely a way of being kind to yourself by letting others

know that, okay, I'm here, I do exist, I have those particular skills that you may be interested about. And I'm able to tell a story, which is convincing. So you can tell a story on stage, but you can also tell a story to your customers by building a feature that they are going to use in prod. I really want to thank you for taking the time

to speak with me today. If people want to learn more, where's the best place to find you? So the best place to find me is on Twitter. So my Twitter handle is T-L-A-K-O-M-L-Y. I'm assuming this is going to be in the show notes as well. Oh, it absolutely is. You beat me to it. So you can find Cloudash at cloudash.dev.

You can probably also find my email, but don't email me because I'm terrible, absolutely terrible at email. So the best way to reach out to me is via my Twitter DMs. I'm slightly less bad at those. Excellent. And we will, of course, put links to that in the show notes. Thank you so much for being so generous with your time. I appreciate it. Thank you.

Thank you for having me. Tomasz, welcome back. Head of React at CloudDash. 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. And if you're on the YouTube, smash the like and subscribe button, as the kids say.

Whereas if you hated this episode, please do the exact same thing. Five-star reviews, smash the buttons. But this time, also leave an insulting and angry comment written in the form of a CloudWatch log entry that no one is ever able to written in the form of a CloudWatch log entry that no one is ever able to find in the native interface. 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. 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.