Tomasz Łakomy & Maciej Winnicki: Serverless Monitoring w/ Cloudash and Life at Stedi

About Tomasz

Tomasz Łakomy is a Frontend Engineer at Stedi, Head of React at Cloudash and an egghead.io instructor.

You can find him online on his website, Twitter, and GitHub.

About Maciej

Maciej is a Software Engineer and Engineering Manager with over ten years of experience in backend development, distributed systems, and cloud. Currently, he's a Serverless Engineer at Stedi and the Chief aws-sdk Officer at Cloudash.

You can find him online on his website, Twitter, and GitHub.

About Cloudash

Cloudash is a MacOS desktop app for monitoring your serverless services performance, invocations, errors and more.

Gain full visibility into your AWS Lambda functions with a single MacOS desktop app. Say goodbye to tens of open CloudWatch tabs: solve issues, gain insights and resolve incidents without them being a murder mystery.

Transcript

Adam: Hey everyone. Welcome to AWS FM. This is a live audio show with guests from around the AWS community. I'm your host, Adam Elmore. And today I'm joined by Tomasz and Maciej. And we're going to talk about the recent launch of a serverless moderating app, called Cloudash.

Adam: Hi guys.

Maciej: Hi guys.

Tomasz: Hi.

Maciej: Thank you so much for having us.

Adam: I was immediately sold, I'll tell you, on Cloudash. I think like 10 seconds on the landing page, you sort of promised that I won't have to have all of the CloudWatch tabs. And that struck a nerve. I guess we'll start there. What is Cloudash? How can it prevent me from using the CloudWatch console?

Maciej: So, Cloudash, maybe I will start, Cloudash, right now is a desktop app, only for Mac for some time, that basically tries to fix, and I think it does a pretty good job on that, fix the UX, UI problem of AWS console in a space of serverless monitoring and troubleshooting apps. So that was the main idea behind creating Cloudash, is that AWS is pretty good at storing all your logs' metrics, but to some extent if you're focused specifically on serverless use case, it's like CloudWatch is too generic to support this use case in a nice way, that's why creating Cloudash was more about just fixing the problem of serverless engineers to have a little bit better experience on looking at logs or metrics. That's in short, and I guess we can probably expand that later.

Adam: Sure, yeah. I had [Paul Swell] on yesterday and we talked about the sort of local testing versus testing in the cloud and what serverless has done to our local Dev Eng experience. And I sort of said, on yesterday's show, that I think I've gotten used to having to redeploy and having to deal with that friction every time I make a change to the API, I've got to push it up to my dev account or whatever. The one thing that I haven't gotten used to yet, is having to go in to find logs in the console. That's a pretty painful experience and I think that's why this resonated with me.

Adam: Could you speak to the unique challenges of monitoring and serverless and how Cloudash, over time, you see it filling that role?

Maciej: I think I will look maybe from a perspective of someone who is oncall. Right now, if you had a productional serverless workload, so like integrated with PagerDuty et cetera, et cetera. If you think about how you need to handle an incident on PagerDuty, so you receive an incident on PagerDuty, then you need to look at this incident in PagerDuty. Then you know that this happens either on, let's say, in AWS Lambda handler, or in API Gateway. Then you need to log into AWS, then you need to go to CloudWatch, then you need to find this log group for this specific function or access log for API Gateway. Then you need to go there and search for something in this specific period of time.

Maciej: Usually, additionally, if you have an MFA enabled or SSO, it takes a lot of time to go through this whole process. And this is very... kind of, you need to do that every time. And it shouldn't be that hard. That's the idea. It should be way faster. You should be able to just do something and see what's going on. That's the main idea behind Cloudash, that we want to make it super short from "Hey, there's something wrong with my app," to, "Okay, I know what's wrong with my app." So that's the idea.

Adam: And can you share some, just about the making of, how long have you guys been working on this?

Maciej: Sure. It's a side product, because we are and we'll probably talk more on that, we work in Stedi full time, but I started the project in April 2020, around COVID started happening, at least in Poland. That was the time that I started. This is like one and half year of working on that. And Tomasz joined a few months ago.

Tomasz: Yeah.

Adam: Yeah. And Tomasz, I saw on Twitter, you're doing mostly frontend work. Did you say you're doing it in React? I haven't built a native desktop app in 10 years. Could you explain how that works?

Tomasz: Yeah. Cloudash is an Electron app. It's built fully in React. So basically we're allowing to install it on your desktop. As much as that we are currently only supporting macOS, but this is very likely to change in the future. And first of all, because we also has some questions like, why exactly did we choose to build our desktop app, our general principle idea behind Cloudash and security and stuff like that, is whatever happens on your machine, stays on your machine.

Tomasz: We don't want to handle your credentials, we don't want to think about them, we don't want to touch them. And we will never send them anywhere. That is why we allow you to install Cloudash on your machine, and this is why Cloudash is going to use your AWS profile in order to send calls in order to get all those logs and whatnot and display them to you, in a much more straightforward way as opposed to having 50 CloudWatch tabs open. Because as-

Adam: Yeah, and there-

Tomasz: Go ahead.

Adam: Oh, no. You're good.

Tomasz: No, because as Maciej said, is that AWS console is good for every single AWS service. And I have this unpopular opinion, that I don't find AWS console to be especially terrible. And I'm not saying that only because I'm an AWS Hero, but AWS console has been built for every single possible AWS use case. And we want to have a laser focused view on how do we build a better monitoring experience, especially specifically for serverless apps.

Adam: Yeah. It's just more abstractions. AWS has to meet a whole lot of needs, and I get that. I think, I've definitely said things about the console. I think the thing about the console experience, is it's like each isolated service, they have to maintain a console for that service. And when you're building anything really on AWS, you're tying together multiple services, and that's where I think these abstractions like Cloudash really come in and help alleviate that, just make that experience better. And I've seen precedent-

Tomasz: And-

Adam: Oh. Go ahead, Maciej.

Maciej: Yeah, one thing that I would like to add, is that when you look at the typical monitoring solutions, like without giving names or anything like that, and you want to monitor your AWS workloads, it's always like, "Hey, you need to give us credentials. We will run some background job that will fetch all your metrics, all your logs, to our backend so you can, from time to time, look at those logs." And this is, it sounds like very, wasting a lot of compute power to just copy basically from one place to another. I think that the benefit of being on someone's machine is that we don't need to do that. We can take that data straight from AWS and-

Adam: Yeah, and I've seen-

Tomasz: If you want to-

Adam: Oh, go ahead.

Tomasz: If you want to check out the logs for the last 30 minutes, you're going to only pay for the cost of asking AWS for the logs for the last 30 minutes of a function. We genuinely don't care what's going to happen, or what's happening in your function for the last quarter or so. If you care about this, you can use Cloudash in order to get those logs. But we don't do any monitoring in the background or anything like that, because the idea was to have a focused view on what exactly is happening when you need to understand those logs. Particularly probably when you have a PagerDuty incident, this is a time that you want to dig in, into logs. 99% of the time you don't have a PagerDuty incident, unless you are doing as good job at programming as I am, usually. So yeah.

Adam: Yeah. And I think the community resonates with the idea of these local apps that don't store credentials. I've seen that in reaction to Cloudash launching, positive vibes on that front.

Adam: And really, to speak to that, some of the immediate nerve striking that Cloudash did within Twitter, we saw Corey Quinn had a very positive review. Not something he's known for, is positive reviews. Did you guys get to see that live? Did you watch that unfold or did you see it after the fact? And what was that like?

Maciej: I was, because I'm not on Twitter constantly, so I was just from time to time checking what's going on. And I was like, I saw that notification, because Corey mentioned Cloudash Twitter handle. And I was like, "Oh my God. Yeah, I'm having a heart attack. What's going on?" And I started reading it. And I was on kind of live seeing it. I was reading is, "Okay, that's positive. Okay, that's cool." And at the end he wrote like, I'm not sure that was the last tweet or one from the end was like, "Okay, I'm sold. I'm staying their paying customer." And it was like, "This is like the best day of my life," situation.

Adam: Oh yeah. I guess-

Tomasz: Uh-

Adam: Oh, go ahead Tomasz.

Tomasz: No, I just wanted to say that I don't have Twitter notifications enabled, because I have a surprising amount of followers for some reason. But then again, I check Twitter every five minutes or so when I'm out of work.

Adam: Yeah, the same.

Tomasz: But I was looking at Twitter and I saw Corey in my mentions and was like, "Okay. So probably someone tagged me and Corey in the same tweet." But then I started reading, it was, "Okay, he's a real client. Okay, he's happy with it." So, that was basically a rollercoaster of emotions, this Wednesday.

Adam: Yeah. That's the stamp of approval you want, though. Somebody that, he's critical of a lot of things. And I think everyone respects Corey's voice in that regard.

Tomasz: And for that, because Cloudash is only going to get better. So having this validation at a very, very early stage of Cloudash, is just something that both Maciej and myself we are not expecting, but we are very much happy with it.

Adam: Yeah. And that's where I want to take it next, actually. I saw you posted a roadmap on Twitter, API Gateway are coming and some of these thing. Could you speak a little bit about the product roadmap, kind of where things are headed?

Maciej: Sure. Right now, it's only Lambda. You can import or add a serverless service. And you will see only Lambda functions that ran some overview with how the Lambdas are performing. Obviously serverless services, serverless apps, are not made of Lambda, they are made of API Gateway, other services, SQS, SNS, and all that stuff.

Tomasz: Infinidash.

Maciej: Infinidash, yeah obviously. And so, we want to go broader in terms of services. So API Gateway is obviously the first choice, because this is mostly the service that works together with Lambda. And then we also want to support X-Ray traces. Because right now, again, the experience is that if you have X-Ray, if you use X-Ray, and I'm not sure if X-Ray is super popular, at least we use it, so that's enough reason why we should implement that in cloud actually.

Tomasz: Exactly.

Maciej: If you have an X-Ray enabled and you see logs, so you start with logs, and then see, "Oh, something happened wrong with this implication." And you have the X-Ray trace ID in the log, you cannot just click it. I'm like, that should be that simple. You should just click it and see the trace. You need to copy that, go to X-Ray, paste the trace et cetera, et cetera. I think the ideal integration for Cloudash, would be like you should be able to click on the trace ID in the log message, and you should see the trace.

Adam: Oh, yeah.

Maciej: That's one thing. And the next, I think it's also in the roadmap, is that CloudWatch insights support. So you should be able to write a query and then just run it, having a similar experience in the same box, but not just some some string as CloudWatch logs does, but the whole query and you should just run and see logs in the same place, metrics in the same place.

Tomasz: Also, way in the future, what we want to have is that you click on the PagerDuty incident, I'm going to suggest CloudWatch insights queries for you. You have an incident, and if you were on this query, you will probably understand what's going on in one minute, as opposed to digging through the entire console in one hour at 3:00 AM, because your heart is racing because, "What the hell? I was just woken up by PagerDuty." And we want to make sure that you can minimize this time from, "WTF," to, "Okay, I know what's going on," as much as possible.

Adam: Yeah.

Maciej: Or even further, because why not, because usually the case is that you receive a phone call form PagerDuty in the middle of the night. Maybe you shouldn't even go to PagerDuty. Maybe you should just go to Cloudash and you will have PagerDuty incidents there. You can click on an incident, and you can just click on the email, because we will be able to provide the integration between AWS and PagerDuty. You hit on the PagerDuty incident in Cloudash, and you immediately see the logs that happen in this, when the incident happened, because why not? We can integrate the PagerDuty. Nothing stops us from doing that.

Adam: That's sort of on the product front. Are there any plans to monetize or raise... I know dev tools are a hot topic in venture capital land. It's a side project, but do you guys have plans on that front?

Maciej: Maybe, I'll just start. It's super early. I don't think that we have any specific plans. We just silently released on LinkedIn, and somehow get to Corey Quinn. So, it's like exactly a week ago. There are no plans right now, like what to do with that.

Adam: Yeah, that's fair.

Maciej: There is definitely great reception from the community and [inaudible], but it's hard to talk about plans right now.

Adam: Yeah, I get that. We did actually have a question, I saw come in, in a Twitter DM. Someone asked if you're using, so it's the AWS SDK, within this local app, we're assuming. And are you using version two or version three?

Maciej: Version two, because when I started working on that, there was no version three.

Adam: Oh, that's fair.

Maciej: And it doesn't make sense. Or maybe it was, but very early.

Tomasz: It's not an excuse, Maciej.

Maciej: So it was in April 2020. So at that time, I'm not sure if, I'm not following this topic of V3, but I'm pretty sure it wasn't even beta. I'm not sure with the version right now. But it's V2. And V2 is good enough to-

Tomasz: And the two after that, it's going to be completely transparent to tell the customer.

Adam: What was that? It's going to be-

Tomasz: As in our choice of SDK is completely transparent to our customers. So the only thing that you need to have is to have your CLI configured, you have to have your AWS credentials on your machine, which you probably do anyway, if you are doing anything AWS. One thing that we want to make slightly more visible, is to have an understanding of how many request to CloudWatch did we just send from your machine. To have the understanding whether you're going to pay 20 cents, or $1, because it's going to be crazy cheap. But still, since we are sending requests to AWS on your behalf, one thing that we want to address is to have a bit more visibility into that. But then again, it's going to be extremely cheap.

Maciej: Because right now, I think the only, I'm pretty sure about that, the only paid API request that we make to AWS, is get metric data and it's charged, I think, one cent-

Tomasz: Per 1,000.

Maciej: Yeah, one cent for-

Tomasz: [crosstalk]-

Maciej: Yeah, something around that. You need to click a lot in Cloudash to see that, notice that on your AWS billing.

Tomasz: Totally.

Adam: And if it does get out of hand, you can always call Corey, who has, he's a great customer of Cloudash. So he can help you with your billing.

Maciej: Yeah, sure. Exactly.

Adam: I want to talk to you guys a little bit about Stedi. I've been a big fan boy of Stedi from afar, just I've said it to you guys before the call, just the collection of cloud engineers that Zack has put together at Stedi, is super impressive. And I sort of now, any time I see somebody for the first time that their profile, they're at Stedi, I just have immediate respect for that person, whether I know anything about them.

Adam: And I'd like to hear from you guys, what is Stedi? Because I've read the description, I know the words, but I don't know what it does. What is your product?

Tomasz: So, I can get to that. The shortest possible way to explain what Stedi is, is Stedi is AWS for EDI, which doesn't explain much if you don't know what EDI is.

Adam: That's my problem, yeah.

Tomasz: Yeah. To give you more context, suppose you are launching a business, but it's not like a SaaS solution, but for instance, I don't know, you're selling pans. So you start by selling one pan, then 10 pans, then your business start to grow, you're going to start selling, I don't know, like a 1,000 pans. And it keeps on growing. At some point, sending invoices via email and PDFs and stuff like that, it simply does not scale. And this is a problem that more and more enterprises started to see back in the 1970s, and I am not making this up, when EDI was born.

Tomasz: EDI is like 20 years older than I am. And the idea is, what EDI stands for electronic data interchange. It's an ancient format for data communication between enterprises, mostly for sending business transactions. So if I send you a business transaction, it's going to be like in this EDI format, which is unlike anything that you have ever seen. It's not JSON, it's not XML, it's something truly, let me just say, interesting.

Tomasz: But why this problem is so important to solve and why Stedi is focusing on that, is you cannot buy anything online without having a gazillion EDI transaction involved down the road. For instance if you have a shipping containers, because when you order something from Amazon, there's going to be a shipping container involved, totally, because it's going to arrive from, I don't know, from Asia to US, it's going to sail.

Tomasz: Every single time something is loaded on a container, this is an EDI transaction. Every single time something gets offloaded from the container, again, it's an EDI transaction, because all those enterprises need to be able to understand what's happening with my stuff, where it is exactly. And EDI is basically this modern backbone... Sorry, not modern. It's this ancient backbone of modern commerce.

Tomasz: The last innovation in this space was, I don't know, roughly a decade ago. The current solutions are not exactly suited to the year of 2021. For instance, none of them allow you to access data through an API. But what we are building at Stedi, is having a API developer focused platform for integrating and building EDI solutions. If you are trying to start up a new... well a startup trying to sell people stuff, or buy car parts or something like that, we are building a suite of products that allow you to build those integrations yourself.

Tomasz: To go back to the original description, we are like AWS for EDI, because we are not providing a simple integrated solution, but instead we are building multiple products that you can combine together in order to build any possible interaction and integration, because we don't know what your business use case is. And of course we can chat when we talk with customers all the time, but every customer has completely different needs. And that is why it's better for us to build a suite of products and then help customers integrate them together in any possible way, as opposed to building a single unified solution that's going to handle 50% of all possible use cases, and those 50% would be like, "What can we do?"

Adam: Yeah. Right. It reminds me, I did work early in my career in finance, they have like fixed protocols, which is this very specific data format that banks transfer documents in that format between each other. It's sort of like that, but for commerce. Is that what I'm hearing?

Maciej: Yeah. SWIFT probably.

Tomasz: [crosstalk].

Adam: It sounds super important. I don't know if I completely understand it still, but hearing your description there, Tomasz, that sort of explains why there's this many smart people working on the problem, because it does sound foundational to all of our buying needs on the internet.

Adam: Could you speak a little bit just about life at Stedi? I think I have, like I imagine, working with the folks that you guys work with, and then working with you guys and then working with Zack. I'd love to just hear anything you'd be willing to share, kind of what it's like there at Stedi.

Tomasz: Okay.

Adam: This one might be kind of hard.

Tomasz: Yeah. I can go first. Well, first of all, we don't have an office. Stedi is a fully distributed company. Everybody works remotely. We have employees from all around the globe. To the best of my knowledge, we have employees from 14 different countries, spanning all the time zones. So in that sense at lease we're a 24/7 business, but in a good way. Ah sorry, 24/5 business. Every single time I go to sleep, like everybody, someone else picks up the troch and that continues within Stedi.

Tomasz: And like I said, we have an outstanding group of developers, and myself, at Stedi. And every single time we wake up, there's something new developed. We are fully on AWS, we are fully serverless. In fact, you cannot create an EC2 instance in any of our AWS accounts, it will not let you.

Adam: That's awesome. Yeah, like SAP's thing, like at the account level, just shut it down.

Tomasz: [crosstalk].

Maciej: Yeah.

Tomasz: And one more thing that I can say is that we are building everything with TypeScript. So both frontend is built with TypeScript, which is not that surprising. We are using AWS Lambda for our business logic, which is also written, all those Lambdas are also written in TypeScript. And because we are very heavy involved in, with using CDK, it's also TypeScript. That allows us to have every single engineer being able to contribute to any parts of the system, because all of that, for the vast majority of it is written in the same programing language. That's extremely helpful.

Tomasz: And secondly we can share tools and different CDK constructs between the teams. So we have some parts that are very usable between some of the teams and some... I don't know, I joined at the beginning of this year. And this is the best place I worked at so far, by a huge margin.

Maciej: I will add a little bit about Stedi from my side. So, the reason why I joined Stedi, and it was, I think I have a one year anniversary next week-

Adam: Woo-hoo.

Maciej: ... is that, is two reasons. One reasons was because the whole idea about taking something that is outdated, like EDI space, and making it just in a modern way API driven. This is very interesting to me, like using very serverless stack, which is also, that was also an argument because I've been working serverless, probably six years now. So I wasn't looking for a job that I will have to ship containers, like software containers, that the containers [inaudible].

Maciej: That was a very strong argument for me was the whole culture. Very engineering driven culture, with a lot of things that I missed from the previous companies, like teams are very independent. They need to work on a whole stack. And by whole stack, I'm not just saying like front and backend, but I'm also saying product, marketing, other things like how to... billing, how to charge for the services. This is a very modern way, at least for me, a modern way of being a software engineer, because we think software engineers just write code, but it's not. It's about shipping products and making the whole business working. I think that was very compelling to me. And especially this part about teams, like independency, being responsible for what you do. That's great. And that's definitely happening at Stedi.

Tomasz: The level of ownership each team has here, is unlike anything that I've ever seen. Like Maciej said, essentially you have the complete ownership. Because as I said, we have multiple products and teams have complete ownerships of their products. It's not only that I don't get paid to write code, I get paid to ship products and to delight our customers and to move this EDI space into 21st century, finally.

Adam: Super cool. And do you guys feel like, is there an internal pressure? Do you feel a pressure to do things outside, to launch a SaaS, because your team is so full of people that are speaking, that are building things? Is there a competitive nature to Stedi that I imagine when I dream of working at Stedi?

Tomasz: I wouldn't say so. The only thing that I've heard was, "Congrats." And, "This is awesome." And, "It's awesome that you launched Cloudash. How can I help?"

Adam: But that's what you say. But do you feel the competitive burn to just build things because your team is awesome and they're building things? You say yeah, compared to the like-

Tomasz: Ah, I did not experience anything like that.

Adam: Yeah. I didn't figure. [crosstalk]. I'll just stop there. I've built up these dramas in my head. Like I play out working at Stedi.

Tomasz: Yeah.

Adam: Yeah, there you go.

Maciej: [crosstalk].

Tomasz: I am certainly disappointed by the lack of drama at Stedi. This is it.

Adam: Yeah, that's-

Tomasz: The only drama that we have, is that Maciej doesn't want to use semicolons in JavaScript and I-

Adam: Yeah, I don't like semicolons in JavaScript. I'm not a huge like-

Tomasz: [crosstalk].

Adam: I don't know, I used to think... I think I was once on the side of like, "Why not put it there?" but then at some point it just looked better to me. I don't know.

Adam: I did have another question, sort of a follow-up question on the AWS SDK. Were there any challenges, going back to Cloudash? Any specific challenges in building out... I think we've got people here that are pretty technical listening in, and they want to know was there something difficult you ran into when it comes to just the implementation when building out Cloudash? Any serious technical challenges?

Maciej: So maybe I will start. When I started working in Cloudash, I'm not a super frontend experienced engineer. So for me the challenge was at the beginning to just try to understand what's going on with React, because I worked a little bit with React seven years ago... or maybe not seven, six years ago. And I fairly understand it. But now, with all this new stuff in React, it was like, "Oh my God, I need to learn Hook. How do I use Hooks? I have no idea. Context? What's Context? Like do I need to use it?" That was a bit challenging to me. But that's not super heavy thing for engineers.

Adam: No, no. But if you're not familiar with it, and you're having to do everything. I get it.

Maciej: Yeah. I just complain on Hooks, like constantly. I just, I think this is the wrong... Sorry, this is... It will be [inaudible].

Tomasz: I'm talking of the future space, and I think there's no frontend focus for it, I think, now so it's fine.

Adam: Okay. So we can just bash on React all we want.

Maciej: I tweeted once, I really... What was the name of this Hook?

Tomasz: useEffect.

Maciej: useEffect, yeah. And I spent like few hours on debugging useEffect, because I didn't put the empty RIL as a second argument. And I was like, "This is insane." Okay.

Tomasz: Definitely not-

Adam: Like when you're in it... I feel like when you're in it and you've built a few React apps using Hooks, it just becomes normal. But when you step back, and you hear someone's first experience, it's kind of like, "Yeah, this is not ideal maybe. This is a bit verbose and a bit weird."

Maciej: Yeah, so the second-

Tomasz: Yeah, that was absolutely why I got involved on this thing, because Maciej was-

Maciej: Yeah, I can't stand writing-

Tomasz: Maciej talked to me and, "Dude, I cannot do this any longer. You have to help me." And yeah.

Maciej: So that's one thing I think that I remember. The second thing, if you want to fix the UX thing, you need to have good UX. So I think it's challenging to, sometimes to just think like, "Yeah, just implementing this feature will be easy." But if you think about it more, you can implement that in a different way. Anything from the UX perspective to make it perfect for, maybe not perfect, but handy for the user. I think this is something challenging that from time to time you need to stop and think, "Maybe you can implement this way, this way, or maybe another way." And maybe right now there is not a lot of features in Cloudash, but we will add more and more services and there will be more and more integration between them. I think there will be more and more UX challenges.

Adam: Yeah. I recognize it's an early product. And I've built early things and put them out there. I think it's just exciting to me to know there are people more and more focusing on this sort of monitoring problem, and for serverless, and being more specific in building an abstraction that saves us a lot of time. Because I think we all know those pains of building out serverless and what that looks like.

Tomasz: And luckily-

Adam: Yeah, go ahead. Sorry.

Tomasz: And luckily with Cloudash, the UX is going to only get better. And I'm just saying that because we are objectively amazing at building software, because we are not. But I'm saying that because we are going to be using Cloudash to monitor our own serverless stack at work. And we're going to use it [inaudible] and whatnot. There's this assumption that if it's going to work for both of us, it's going to probably work for the rest of the community.

Tomasz: But then again, we are very much open to feedback, that we did receive a hugely surprising amount feedback over the last couple of days. Both on Twitter and on email, and in person and whatnot. And it was truly helpful. And we try our best to listen to all of that and to improve the product as much as we can. So, as I said, it's very early, and it's only going to get better.

Maciej: That's probably the most surprising thing to me, other than Corey Quinn reviewing Cloudash on day one, was the amount of feedback that we received from different people, completely unrelated.

Tomasz: Yeah.

Adam: Yeah. People are super helpful on the internet, it turns out.

Maciej: Yeah. Exactly. But I want to go back for a moment to this UX thing, because when the serverless, when the Lambda was released and people started building stuff with serverless technologies, from my perspective, it simplified a lot of things. You don't need to configure Apache every time you want to expose a CPM point. Or you don't need to do a lot of stuff, like configure a Docker container or configure [inaudible] with a lot of configure options. You just ship code like Lambda and there is very minimal establishing to configure, like the timeout and memory, that's all.

Maciej: Serverless, in my mind, even though there are people that will say it complicated a lot, and they will give this architectural diagram that is super complicated, but I think it's simpler, comparing to what we had in the past. Because the concepts are visible and it wasn't the case in the more server way of building things. In my mind, serverless simplified a lot of things. But to some extent we didn't, like the monitoring tools are not simplified. Like they should be, right? Because the whole concept is simplified, so why there is no tools that simplify monitoring?

Maciej: We have, as I said, and as Tomasz said, CloudWatch needs to monitor every other service in AWS. But not even CloudWatch, but there are other monitoring tools. But there it didn't change for serverless. They're just the same as they were. You have the same log view, you have the same metrics charts, et cetera, even though the space, the problem changed and is simpler now. I think that's the thing also, that if we simplified the technology, we also need to, like the way of building stuff, we need to simplify the tools that we use to monitor that stuff. That's my point.

Tomasz: Okay.

Adam: Yeah. I don't think there can be too many people right now, building better dev experiences for serverless. It feels like, as exciting, serverless is so exciting and I love building things out with that sort of mindset, but you step back and you realize we're still behind that developer experience curve. It's got a long way to go. And more and better tooling. So yeah, it's super exciting to me that you guys are focused on this space.

Adam: I forgot to mention at the beginning of the show that we're going to give away a couple of annual licenses to Cloudash. And we will do that here very shortly. But first, I did have another question. Someone DM'ed me on Twitter asking, it was [Zack Charles], asked, "Any advice for others that are building a SaaS project in the AWS space?" Anything you find.

Tomasz: It depends on our week of experiences as SaaS product founders. Yeah, ship it, definitely is good advice. Secondly, that's something that I would recommend, is to try to solve a problem that you have, because we are doing that with Cloudash. Like we don't find the experience of that we're acting to PagerDuty, others and whatnot and monitoring to be especially convincing right now.

Tomasz: I think we think that it can only get better. But we are also building that because we want to use Cloudash on a day-to-day basis. I would say that if you want to build a product, focus on something that you would also want to use, and not necessarily something that you want to build, just ship it and have other customers pay for that, but it's not something that you would be willing to touch yourself.

Tomasz: One more advice, is that I would say to be trustworthy to your customers. So if you say that you won't send their credentials anywhere, that you won't monitor their traffic, that you won't I don't know, track their... well, try to steal their passwords or whatever, well don't do that. Because it's better for your product to not work at all, than to be stealing your customer data and whatnot. The trust that you're once going to lose, it can never be regained again.

Maciej: I think, maybe another advice, other than ship it, from me is that trying to really understand the problem domain. And define the problem that you want to solve. I think that part of the reason why Cloudash had so good reception from the community, is that it actually solves some problems. And people have this problem, they face it every day. So if you're working on a product or on a SaaS, try to define the problem and try to work towards solving this problem.

Maciej: And usually at the very beginning, this problem is small. You shouldn't define the problem space as very broad, "I want to fix the world," kind of. But more like, "I just want to click between different accounts in AWS services, with one click not with 10 clicks." Start small, ship it, and just that really do the research on what is the problem and how other people think about this problem and what's the issues for them.

Adam: Good stuff. And I will keep watching here for the remainder, we've got a little bit left here, 20 minutes left maybe. If anyone else has any questions, feel free to shoot me a DM and we can cover those here live.

Adam: I wanted to shift a little bit into, Tomasz, you're an Egghead instructor.

Tomasz: Correct.

Adam: And I've noticed lately you're tweeting about a new course that you're working on. I'd love to hear about that. I think we've pieced together that it's AppSync related. Can you share more?

Tomasz: Yeah. It's been a year since I've published something new on Egghead. To give you some context, I started teaching web development stuff on Egghead, back in 2018. And Egghead is basically like, the idea behind Egghead is that they produce, with instructors including myself, a very short web development videos that are composed together in order to form courses. The idea is that when you launch a new course on Egghead, it's not like 12 hours of videos with all kinds of filler inside of them like, "Please subscribe," yadda yadda. We don't do that. Like the usual course on Egghead is about an hour long, because the idea is to teach as much as you can in a short amount of time, and also all those courses are supposed to be watched, for instance, I don't know, during a lunch break as opposed to spending an entire weekend watching a course.

Tomasz: Last year I've launched a course on AWS CDK, it was called, Build an App with AWS CDK. It was somewhat of an introduction to the CDK space which was fairly new last year. And I feel like this is also still early for CDK, even in 2021. And as you said, I am currently working, I started literally yesterday, to work on a new course, which is titled, Build a GraphQL with API with AppSync and CDK. The general idea is that we're going to use CDK in order to learn AppSync and GraphQL in order to build your very own API.

Tomasz: And the general principle behind the course is that to show web developers who are more frontend focused, like myself, that you can take your own existing skills of using TypeScript on the frontend and to transform that into being able to ship your own GraphQL APIs with CDK, with TypeScript. So the idea is that you can take your existing skills and apply them to a completely different domain.

Adam: Yeah. AppSync is one of my favorite services on AWS. I don't know if it's, at some point GraphQL made sense to me and I made the switch over in terms of building out full stack stuff. It's nice to see content being made for AppSync, because I think there's a lot more out there for API Gateway which makes sense, but for those of us that do like to live in GraphQL land, AppSync goes under the radar. I think it gets a lot more coverage in the Amplify space. But it's almost abstracted away with Amplify. It's not really talked about so much.

Tomasz: Totally.

Adam: Well, this has been really great. I don't know if you guys had anything else you wanted to cover. Anything else you wanted to mention about Cloudash or anything else, really. Just, the floor is yours.

Maciej: I would say, because we're AWS, like we have folks interested in AWS, I would just encourage you to just sign up and try. There's a seven day trial, you won't be charged for that. And take a look and let us know what do you think. You can cancel the subscription easily, where there is a link in the email. There is no way we will charge you if you don't like it. But just, if you do that extra thing and just install it, run it, see how it works. Let us know what's missing, what's not, what do you like. That would be super helpful.

Adam: Yeah. That's cloudash.dev. You can find-

Maciej: Yeah, one D.

Adam: What was that?

Maciej: Like single D. Cloudash. Like-

Adam: Oh yeah. Oh yeah. C-L-O-U-D-A-S-H.dev.

Maciej: Yeah.

Adam: Well, thank you again. Thanks everyone for joining the live show. I know there's some people here on the Twitter space. I really appreciate people hopping on at this early window of AWS FM. And thanks to Tomasz and Maciej so much. It's been great just to pick your brains and learn more about what you're working on.

Maciej: Thank you.

Tomasz: Likewise.

Maciej: Thank you for having us.

Tomasz: [crosstalk].