Quick show notes

• Our Guest: Gareth McCumskey
• What he'd like for you to see: Serverless' Components feature
• His JAMstack Jams: JAMstack and Serverless help build things with low-code. Check to see if there's a solution out there for what you need to solve a problem.
• His Musical Jams: Jinjer - Pisces

This week's sponsor: Auth0

This week, we've got Auth0 as a sponsor. While their prowess at authentication is important, they're also releasing a ton of new tutorials and courses on their YouTube channel, including a free course on building a full-stack Jamstack app with Next.js.

Transcript

Bryan Robinson 0:03

Hello, everyone, welcome to another episode of That's My Jamstack the podcast where we ask the time honored question, what is your jam in the Jamstack? I'm your host, Bryan Robinson. And this week we talk with Gareth McCumskey, a serverless architect at Serverless Inc. Before we dive into the episode, though, I want to thank this week's sponsor off zero, we'll talk a bit more about the amazing educational content they're putting out at the end of the episode. If you're curious about that, Jamstack and author education, head on over to a0.to/tmjyt. That's My Jamstack YouTube for all the videos. Hey, Gareth, thanks for joining us on the show today.

Gareth McCumskey 0:45

Yeah, thanks so much for having me. I just, I love talking about Jamstack stuff. So it was a opportunity not to be missed.

Bryan Robinson 0:51

Cool. Well, you like talking about Jamstack stuff. But tell us a little bit about yourself? What do you do for work? What do you do for fun?

Gareth McCumskey 0:58

So my work right now is essentially I'm a Solutions Architect with Serverless, Inc, the creators of the Serverless framework. And yeah, being a small startup means that I kind of do a multitude of roles like most folks in the in the company. So I I'm involved a lot with helping users have the framework design and and sort of plan out the systems there. They they plan on building with service. And the other side of it is as well as I act as sort of developer advocate in trying to help spread the word about serverless. And related stuff, I guess you can say,

Bryan Robinson 1:33

That's kind of growing the whole the whole world so that you know, people who want serverless might come to serverless in the future.

Gareth McCumskey 1:40

Yeah, absolutely. And I find a lot of folks will hear some brief inkling about serverless, not quite sure what it means. And because you know, we've been able to produce enough content, they get a bit bit of understanding, and then they have questions. So it's nice to be there. So for that, for that growth period that a lot of devs go through. And I guess on my personal side, I'm, I think very much into the computer world. So especially with the with the load with the global pandemic we've been going through lately. So I'm quite an avid gamer. Yeah, and it's just that's kind of that way I love steam these days.

Bryan Robinson 2:14

Nice. Are you? Are you on the PC side on the console side are like kind of in between?

Gareth McCumskey 2:19

Well, PC side, which kind of means I never leave the desk. But yeah.

Bryan Robinson 2:25

What's your what's your go to game right now, especially with with pandemic round?

Gareth McCumskey 2:29

Well as a typical developer story, where I play a game called factorio. I don't know if you've heard of it, but it's essentially an engineering style game where you build a factory and consume resources. And it's a massive problem solving things. So I go from working with developers all day long to basically running a little factory.

Bryan Robinson 2:49

You know, from from software engineering to real engineering, in software.

Gareth McCumskey 2:53

Yeah, something like that.

Bryan Robinson 2:55

Nice. Alright, so so we're talking Jamstack today. So let's talk a little bit about what was your entry point into this world of Jamstack, or maybe static sites, I know you've been in the industry for a while?

Gareth McCumskey 3:07

Well, it's one of those interesting situations I found myself in. And just a bit of context. So long story, here we go. I have had, I was a lead in a team at a tour company that basically sold all their product online. And with that, they had a platform that was built on WordPress that they've been using for about 10 years. So really showing its age really legacy when we're talking legacy. And when I joined, there were there were there being some serious issues with performance and science. So ultimately, we came to the point where we had to re architect pretty much the entire platform. But we needed a way to do things piecemeal as well, because we couldn't go down a rabbit hole for a year come out with something on the other side that maybe didn't fit, they need to start seeing some return on what we were working on. So initially, after spending a bunch of time looking at stuff, I found serverless, which was kind of my gateway into Jamstack side of things, and looking, looking at building, you know, the whole Functions as a Service became very attractive, especially when you're in a team of about two or three developers where none of you have massive DevOps experience. Myself, I can kind of spin up a web server when I need to keep it up to date. But you know, I wouldn't necessarily trust myself, you know, the massive production, cluster, and so on. So that became a little tricky first, and serverless seemed like the right answer for that. But serverless doesn't come without its own own way of doing things. And traditionally, for me, I had come from the world of big fat PHP frameworks that handled everything, you know, rendered rendered everything on server and push that out to the browser. So there's really going back to my roots when I was looking at serverless and realized that probably the best way to attack this would be to build back end API's with serverless and have a completely static front end running something like view or react or Whatever, and have that calling this API back, because the API back end is really where we were concerned about load the most. And this led us to start building a solution like this, where we could have a team focus on building a nice front end, and have a couple of guys building a front end. And myself, maybe, I think, was one of the engineers working on the back end, small team. And this works incredibly well, for us. We had an entire ci CD process, things were going really nice. And the first time I heard Jamstack, was about, I don't know, nine months into doing this, we attended a conference and somebody gave a talk about Jamstack. And the four of us sat in this talk looking at each other throughout this entire discussion going that's what we did. So it was very interesting way. And and I think one of the one of the key things that we talked about afterwards was how it was going back to our roots as as people building stuff for the web, seemed to be the best solution all along just building static HTML, JavaScript and CSS, and having API's to call to

Bryan Robinson 6:03

Yeah, so an interesting thing that you kind of said, Kevin, in the beginning of this story, which is, I think, different from what a lot of people have said about their kind of intro into the Jamstack was, you actually started with this idea that we need serverless functions, we need Functions as a Service, whereas most people are saying, you know, hey, I am already using view or I'm already using react. So I got into this thing called Gatsby, I got into this thing called grid zone. And that was my entry point, or, you know, I like HTML. So I got into Jekyll or something along those lines. Where it said, where you're kind of saying, you know what, we don't want a monolith on the server, we want to break it up. And then oh, what are these other things we can do to attach it is that kind of a good representation of what you're what you were going there?

Gareth McCumskey 6:50

Yeah, it was interesting, because there was some other things we were looking at sort of at the same time, I was really doing a big investigation into micro services as well, because this is back in 2016, as well, just to give it a little bit more context. So micro services was kind of new and coming out. And there's a few books written and it was growing in popularity. And when looking at microservices, the one thing that struck me instantly was how come out complex the infrastructure behind it looked. So microservices looks really complex for us to try and use. And we didn't feel confident in our skills, you know, in managing all this amount of infrastructure, as I mentioned, and servers just seemed a great answer for that. And very quickly, we realized that building a back end with something like serverless wasn't just about the Functions as a Service, because lambda was that new thing that I'd seen at AWS event which sort of struck struck me as well, and ultimately led me when I was investigating serverless, to realize that this was using lambda. But it's also all about the other services that you end up consuming as well, which you build upon. And that essentially replaces the need for this massive monolithic back end server. One of the things I point out to folks is that when you're building an application, there's really three, three main things that you need, you need some way to receive a request, some some HTTP endpoint, you need some way to compute, and you need some way to store data. That's ultimately and then of course, the fourth part, I guess, would be the response back, which would be the static pages that you're providing to user to, to consume. But ultimately, with an API, there's three components, we need to receive a request, you need to compute a response, and you just store data. And when you look at serverless, especially on the AWS side, which is what I'm most familiar with, you have AWS lambda, which kind of started a lot of this dynamodb, which ends up being a fantastic serverless Datastore. And API gateway, which becomes that front end that you need that can handle handle that scale and load. And then you've got your pick of the static, static site, web servers out there, everything from s3, to you know, there's a whole bunch of options out there to store static sites. So that's pretty cool. Awesome.

Bryan Robinson 8:54

So So obviously, that was how you were using the Jamstack. Professionally, back when you were doing that, how are you using the Jamstack professionally now and also personally, personally?

Gareth McCumskey 9:05

Yeah, it's interesting, I kind of use things in very similar way. So right now, pretty much all the sites that I build end up with a step by step all the front end sets in a statics store somewhere like an s3 with a cloud front in front of it. And the API back end, the difference has become the difference now is that the issue, I'm traditionally from the back end, so that's why my focus tends to be on on back end infrastructure. I just more adept at that, I guess. There's a lot of skill that goes into building a good front end and I just haven't had the time to really focus on that. I mean, it's a it's a massive world to delve into. But for example, my my back ends now for my API's tend to be microservices based, and with tools like like, you know, with the cloud and AWS and many other cloud providers as well. You can build really sophisticated back end services with Beautiful asynchronous communications between them. That lets you defer all sorts of load and issues that you may normally experience into asynchronous processes that kind of execute when they feel like it when they go capacity, which is fantastic. It just means that when you have that, that buzz of traffic at eight in the morning from your customers, because you sent them a mass email, you can handle what you need to the front end, because s3 or all these other site generators can handle the HTML and CSS they need to push out. But your back end is just deferring all the processing of the instance. It's a pretty interesting way to build things.

Bryan Robinson 10:33

Yeah, it definitely it can. It can be kind of a web to weave in your mind, but it works incredibly well on the actual technology.

Gareth McCumskey 10:42

Yeah, absolutely. I mean, doing things like receiving an API call. And it's interesting, because I've had this discussion with other folks as well, where they talk about things like you know, if somebody wants to edit their profile, this is a silly example where, you know, they change their email address, and they hit save, they expect that to be saved immediately. And when the page refreshes, they're expecting that to be the representation of what's in the datastore. In the back end, Meantime, it doesn't have to be, that could just be what's cached locally. And the front end knows, I've told the back into stores, it told me it's going to at some point, I trust it, I'm just going to tell the user This is what the email address is now because the beckons told me that's what it's gonna be, it's pretty optimistic way of, you know, storing these things. Meantime, that beckons been designed in a way that it's just absorbing all this traffic as it can. And yeah, things just work really beautifully.

Bryan Robinson 11:29

And so I'm kind of curious. So I don't think we've had someone who, who's probably heavier on the back end. On the show, I think, I think for the most part, we've had some full stack developers, and we've definitely had a slew of front end developers. So if you were to talk to a pure back end developer, maybe like how you were 2015 2016, you know, having a big PHP stack or even like a dotnet, or something like that? How would they how should they think about transitioning to something like Jamstack, with, you know, various serverless pieces?

Gareth McCumskey 12:04

Yeah, it's interesting, we had to do this actually, with the company that I was working for at the time. And one of the things, one thing I always suggest, first of all, is to start with a basic PRC, something, something that's concrete, so it's not meaningless, but not something that's critical. So you don't want to go PRC your checkout process, because that could affect the bottom line, bad idea. But we're seeing something like for example, we had a review system that people could leave reviews for the tours they had gone on. And the review system is important for the full conversion of sale. But if it happens to fall over, it's not the end of the world, people can still check out, we can still sell things on the site, and so on. So ultimately, that was our stepping stone into the world of Jamstack and serverless. we extracted this widget that we had in multiple places across the site, turned that into essentially a component for the front end, that had a back end component, which was an API. And that's how we how we proceed that just this one, one small component. And ultimately, that was a massive success for us, and proved out the technology. And we took the next step where we went through the site and looked at some of the content we had for things like the About Us page or company values page. And but that's the kind of content that does have changes at times, but changes very infrequently, it's not a product page that might change in you know, within within seconds with the price and reviews and any other information. So the next step was to extract those out, turn those into static pages with some kind of CMS back end, but not something that needed to be to the second with updates that you could let generate in the background whenever it needed to, and it would pretty much just sit there statically. And again, there was that there was the proof of concept for the front end. Now because we've just done a small component. Now we were proving the front end, and that worked beautifully. And just keep going up, then we started converting product pages, then we converted checkout. And you just keep taking these pieces at a time basically the strangler pattern. If anybody's familiar with that, we just take one piece at a time. And with a tool like CloudFront, or any other CDN cloud was what we were using at the time. CloudFront was set up to default to route so it would go to the WordPress installation by default. But we could use the URL structure of our site to break apart each piece one at a time. And initially, we were manually entering these URL endpoints like slash about us and they would point at an s3 bucket slash company values were pointed at s3 bucket route slash we just pointed the WordPress instance that was sitting on an easy to instance. So that allowed us to wait to sort of break things apart and point traffic at the right locations while we were building. Interesting. So

Bryan Robinson 14:37

yeah, I don't think we've ever had anybody talk about about that. We've talked about like breaking up monoliths into micro services, but like literally breaking up the front end to is a very interesting thing like oh, I've got WordPress, we can't completely migrate away from it for X, Y and Z yet, but you know, our about page does need to be a database generated page, our company values like let's just redirect That VR CDN. And that's a really interesting take on that. What would you say is kind of your overall jam in the Jamstack? What's your favorite service? Obviously, you work for a service, that's a pretty big service in the Jamstack. But what's your favorite service? What's your favorite philosophy or framework, and then like, what just makes you love the gym? Second, it's gonna keep you working in this space for a while,

Gareth McCumskey 15:22

huh? Where to begin? Alright, so I guess the biggest overall one, and we've really pointed out I'm very much sort of the back end guy. But the thing I love the most, and this is gonna sound strange being a guy who likes to build back ends. But I don't like code necessarily. It sounds bizarre. But code is is actually the weakest part of any application. And a lot of developers especially. But a lot of those are coming and raise their eyebrows at that, because that's what we get paid for it. And they want to get paid to write code. When really, it's not what any business wants. And I've it's taken me most of my career to realize this. But what most businesses want is they want a solution that solves the problems, they ultimately don't really care where it comes from, as long as it's reliable, and it's done within some reasonable timeframe and cost, then they're happy. And that's what Jamstack and serverless, as well just, you know, as part of that has really helped me build with all the solutions that I have. I, I normally, you know, espouse the mantra of serverless, first or Jamstack. First as well, I mean, that's one way to look at it is, instead of writing code first first solution, see if there's an existing service out there that can solve the problem for you. And usually, it's going to be reasonably priced and paper use. So you don't have to worry about this massive, you know, albatross around your neck. And ultimately, what it gives you is a way to solve a problem that you don't have to maintain over time that you don't have to make sure that whoever you hire into the position will know how to work on and code for. And a simple example of this is if you look at a very basic API, for example, with something like API gateway, a lambda function and dynamodb, the lambda function itself is probably going to end up being if you have a simple crud application, let's call it a create user endpoints as an example, if you have a POST request for that you set up API gateway API gateway is going to receive an HTTP request, it's going to handle the HTTPS for you, you can configure API key, so you can restrict or restrict access to it automatically. You don't have to worry about that. It will manage load for you. There's no load balancing involved in it at all. I sound like I'm selling API gateway. But I'm just talking to the the basic features of an API gateway. But the biggest thing that it does as well is routing. And often routing has been one of those things left for the big fat frameworks to do for you in code, which sounds great, except now you have a dependency on code that somebody else managers, whereas now with something like API gateway, this is a running service inside a cloud vendor that is executed as nothing, you don't have to worry about that open source project, maintaining the routing mechanism, this is done as part of a service, it's built for you. That's that's the way it works. What this means is my lambda function now isn't isn't resolving routes, it's just receiving event data, it's just receiving an HTTP request. And similarly, if you if you look further down into data storage, using a tool, like Dynamo dB, for example, is a key essentially, at its most basic form is a key value data. So it's a little bit more advanced than that. But we just say that for now. What's really nice about this is that it has an API, a very simple API that you can send requests to. And ultimately, there is no ORM necessarily involved. So you're writing a basic API calls to a Datastore in the back end, and a lambda function is going to probably be about a 10th of the size of your regular amount of code that you would have sitting in even a non monolithic framework these days. So that for me is the biggest one is the reduction in code.

Bryan Robinson 18:48

Yeah, and I think I think that's an interesting way of putting it too, because anyone who's viewed my code, at least knows this the weakest link in my application. But on top of that, like if you look at it, and you say, you know, I'm, I'm a web developer that excels at writing, x type of feature, but you know, what I'm really bad at is writing off, like auth is an incredibly complicated, very security, heavy specialization in code. I should not be writing that, oh, I can go find you know, one of these two or three, four different services that will provide off for me in a very compact API driven way, which I think, is probably for the best for a lot of web developers out there.

Gareth McCumskey 19:29

Yeah, that's one of those things. I think developers are really bad at writing a really bad security. And it's no fault of developers. It's actually a fault of our education in the industry. It's kind of like, I'll worry about security when I'm done. Which is probably not what you should be doing. But you know, that's this way we have problems to solve. We have solutions to build the worry about securing it later. But yeah, mean things like auto will will hand you essentially an entire solution to handle auth and I've built my own custom authorization services even in the gem stack itself. It's not an easy task, you're constantly maintaining it even, I'm maintaining it to this day. Unfortunately, if I just used the service that was available to me, I probably wouldn't have to do that I'd saved myself a lot of time and effort. And my, you know, the users of the system would be probably a lot happier to.

Bryan Robinson 20:16

And you even mentioned something, something that the nowadays at least with a lot of the modern tooling scene, you know, super easy, right, which is managing HTTP versus HTTPS. But like, even three, four years ago, you know, I was managing servers and having to, you know, deal with, okay, well, let me figure out, Let's Encrypt, and let's make sure that that bot is running at the appropriate speed and the appropriate time. And that was a huge headache. And now it's literally just a Boolean field in, you know, most of these cloud providers, like, yes, please handle HTTPS for me.

Gareth McCumskey 20:47

And even I mean, I've been around in the days before, Let's Encrypt. And that was, that was an absolute nightmare. It actually got to the point, I don't even know how to set up HTTPS anymore on a on a web server, because back then I would go down that rabbit hole handed over to the to the sysadmin. To finish it up for me, because I was pulling my hair out. Let's Encrypt, solve that problem to a large degree for servers. But it's still not an easy task. And it's something you have to either set up an automated process for or come back to every three months to renew those certificates. But you know, the cloud vendors just completely take that away from you again, it becomes so much easier to set up.

Bryan Robinson 21:22

I mean, granted, it was my entry point and the learning how to do cron jobs and some other stuff. I I owe some education to doing SSH. But yeah, it was a SSL it was it was definitely a trial in a lot of ways. So what would you actually say in terms of musical jam, what is your musical jam right now? What's your favorite song or your favorite musician?

Gareth McCumskey 21:43

So lately, I've gotten into a new band, and I've always been a bit of a metal head. So anybody who's not into into that kind of music, I do apologize. But lately, there's a really great band of heard called Jinja. And anybody who's not familiar with them, I would suggest looking up the song on YouTube called Pisces. By ginger, it's a nice surprise when you get to watch that it's pretty infamous in YouTube circles now for being one of those react. videos that you surprise a YouTuber with? Yeah. But yeah, it's it's it's just one of those bands that have really impressed me with their, the entire band. I mean, the the vocalist, she's absolutely incredible, has an amazing voice. And just ultimately, the entire band works together, like an oiled machine. They're absolutely amazing at what they do. It's what it was one of the things that really impresses me is when an entire band works together so well that not a single one of them sort of stands above the others. They're all just absolutely awesome.

Bryan Robinson 22:40

And that takes a lot in the in the music world not to have that ego to like be able to mesh like that.

Gareth McCumskey 22:45

Yeah, it's always nice to see their interaction on stage and so on as well, where they're all trying to have their moment in the in the in the sun essentially trying to show what they can do. without it being, you know, over the top.

Bryan Robinson 22:56

It's not It's not the 15 minute drums. All right. Yeah, exactly. Nice. So. So is there anything that you'd like to promote and get to the Jamstack something you're doing or something serverless wants to talk about at all?

Gareth McCumskey 23:08

Well, from the service side, there's something new that I can mention. Front End, folks, as you mentioned, there's a large audience of front end developers that listen to the show, where I've been on the show, at least as well. One thing I can mention that that is really great is that we're in the middle of working on a really great project called components right now. And this is different if folks have known the serverless framework from 2015, we released the the actual serverless framework itself, it's a fantastic tool, it does a lot of great stuff, a building, for doing back end work, and so on, help orchestrate all of these services and so on in AWS. But what we found is that while it's great at doing that, and it simplifies things a bunch serverless as a concept is very new and different enough that it's kind of a barrier to entry for a lot of folks. And especially if you're not already a if you haven't been building backend solutions for a long time. It's unfair, just you know, I, I would have no one would expect me to just dive right into view and react and angular know my way around in exactly the same way that you know, there's there's a lot of stuff when dealing with with back end code and applications. But one of the things that components does is that it takes the idea of serverless and boils it down into a nice consumable package with very little configuration. And you can actually go to the point of configuring a solution in serverless, with about three lines of configuration, a single COI command, and you've essentially deployed your Jamstack application into the cloud. Yeah, it's it's actually pretty awesome. I've been playing with it a lot myself. And we are actually it's one of those things we built for other teams and we're using it ourselves now. And it's it's really also because what it and this is the sounds like hyperbole, but it really isn't because ultimately I can go to Can I can I drop a URL? Oh, yeah, go for it. So if folks can just go to Apple serverless.com, which is our online platform, and once you've signed up, you can go and create with any of the existing components. And there's new ones coming out all the time. But one of the ones I can point to as for example, the full stack application, which ultimately what this gives you is a command to run in the CLR to install and initialize your your application that you want to create your full stack app. And this full stack app contains essentially four components. One is for a front end. So we call it the website component, the other. The other is an express API. So if you know anything about Express, you can actually just spin up your own sort of Express back end within it as an API, database component for Dynamo DB as well as permissions that set up all the permissions you need in AWS. And you can just go in and you can, you can deploy it immediately because it has a working front end back end and everything else that it needs. And just play around with it in your own AWS account. Or you can go ahead and edit it, you can point it at your own react, view, whatever code, when you run the deploy command, it'll automatically build your front end, it'll automatically connect to AWS, and push everything into s3 into lambda into API gateway, all these things that you need to run this application and then give you a URL CloudFront URL at the end for you to go and try your application. It's it really is as simple as that.

Bryan Robinson 26:16

That's very cool. Because I find that one of the one of the easiest ways to get into new technology, especially new architecture, technology is to find an opinionated source, and then like use that opinionated source editor until I feel comfortable with it, and then kind of I can roll my own at that point.

Gareth McCumskey 26:31

Yeah, and that's exactly the point. Over the years, we've seen a lot of folks come into service with Express as an expectation. And while the Solas framework can be used to deploy Express applications, just as they are, it's kind of a bit of a bit of a faff to use. It's, you know, you've got to configure things, you've got to configure things a certain way, you know, it becomes a bit of a hassle. So I deal with the Express component, for example, is that you can literally just pointed at that f.js file, which contains your your Express routing, and off it goes, it's into lambda, and works as intended. And the idea there again, is, as you said, folks, we'll get into this, they'll start using their application, things will run well. And that's the other the other thing that was difficult for me to figure out about this philosophy that you asked me before, because Jamstack and serverless is incredibly forgiving, you can do things kind of okay, and if it runs well anyway. And if it doesn't, if it stops running, well, you can tweak it in ways that'll make it run better. And once you once you become steeped and understand the technology, you can then rebuild pieces of at a time because that's what you did. Anyway, you started building pieces, you could replace those pieces with more optimized versions of them later down the road. And it becomes incredibly easy to do that. It's so super forgiving. Just try stuff out. And that's where a lot of folks will come and say, you know, how do I get into doing serverless? I said, Just try it, just do something with it. Even if even if it's gonna be even if it's the worst possible solution you could think of building with serverless it's probably gonna still gonna work and I'll probably still work. Okay. And that's okay. Okay, it's fine. Just change it later.

Bryan Robinson 27:58

Yeah. Okay, means that you have shipped something that somebody needed. And it's out there.

Gareth McCumskey 28:03

Yeah. And yeah, your users all they want is a working solution. They don't necessarily need the best crafted, highly engineered, fanciest solution that you can come up with. They just want something that works. All

Bryan Robinson 28:15

right. Well, Gareth, I appreciate you coming on the show today. And I hope you keep doing some amazing things at serverless as well as just kind of in the in the general web dev back end world.

Gareth McCumskey 28:24

Yeah, well, that's the goal. I'm hoping we can get there.

Bryan Robinson 28:31

Thanks again to Gareth, for the awesome conversation. And thanks to you our dear listeners for tuning in Week after week. Be sure to star heart favorite or you know, review or whatever in your podcast app of choice to spread the word. Now a sponsor time. This week, we're lucky to have off zero back as our sponsor. Author is an amazing authentication platform, but they also have a wealth of amazing content coming out regularly on their YouTube channel, including a free course called full stack Jamstack with next js. If you're interested in learning more about next, taking the Jamstack further or authentication on the Jamstack head over to a0.to/tmjyt that's That's My Jamstack YouTube, TMJ YT for all their YouTube videos.

Bryan Robinson 29:16

That's it for this week. Until next time, keep doing amazing things on the web and keep things jammy

Transcribed by https://otter.ai

Intro/outtro music by bensound.com