A common pattern in serverless architecture is to have a queue before a function. This is great because you can create a second queue for all of the messages that failed in the function execution (or, if we want to put it in terms that don’t sound like we’re aggressively shaming them, we can classify them as having “encountered an error at some point”). This second queue is known as a “dead letter queue” or DLQ for short.
Last week I was battling jet lag and this week, an inbox of unanswered emails. But I’m also marveling at the quality of the AWS community all over the world. I had the privilege of speaking at ServerlessDays Sydney the week before last, and along with the amazing conference talks, I also got to see firsthand just how much of the globe is involved in pushing forward serverless using AWS technology and how excited they were to share what they were learning.
School’s out for… Autumn? That’s right, while you were avoiding the back-to-school rush at Office Depot, cutting the crusts off PB&Js, and taking the layers out of mothballs (confession: I have never seen let alone used a single mothball), Serverless Summer School began winding down and is now over for the season. Until next year, school-themed Stackery livestreams!
Cost is a big reason many dev teams are transitioning to serverless. However, there are still some ways costs can creep up on you in serverless apps. The biggest culprit I’ve found in my own experience is the VPC resource. Because adding a VPC to a serverless stack is ridiculously easy in Stackery, I’ve sometimes gotten carried away. I’d deploy a stack with a VPC for testing, then quickly forget about it.
Software engineering is a skilled task; those who obtain the experience and credentials necessary to become engineers know this, as do their employers. Engineers have an overarching goal of using these skills to construct experiences that enable end-users to complete a task successfully and they hope to provide enjoyment and comfort along the way. Anyone who has written software used by a decent number of people knows how daunting this task is.
Stackery is now available on the Amazon Web Services (AWS) Marketplace! This is great news for development teams excited by the prospect of building and modernizing applications using AWS Lambda, DynamoDB, Kinesis, API Gateway, Fargate, and the rest of the growing menu of serverless capabilities. AWS teams can start their serverless journeys with prescriptive and flexible tooling that extends AWS tools and services with less friction in the purchasing process.
Have you been attending Stackery’s Serverless Summer School? As a non-engineer, I’ll admit, I was a little nervous. Was it going to be over my head? Would I spend the entire Twitch stream furiously writing down all the terms I didn’t know so that I could ask about them later? Would my brain need some debugging after trying to download a bunch of information that I didn’t really get?
I’ve heard many conversations about the limitations of “serverless technology” ever since the concept was widely known. They often focus on how specific implementations of serverless are limited by certain aspects that the user doesn’t have control of. This seems odd to me because serverless isn’t a technology.
Now that you’re invited, here’s the lowdown: Starting this Wednesday, you get the unique chance to attend four weeks of live working sessions with some of the top minds in serverless. They’ll prepare you to build production-ready serverless applications with the best practices of AWS top-of-mind. Along the way, you’ll get the chance to earn awesome prizes as you unlock milestones like deploying a stack and finishing your app.
Starting today, any developer can locally debug and develop any Lambda function, in any language or framework, against live cloud resources with any IDE, for free. You don’t even need a Stackery account. This capability can be obtained by installing the Stackery CLI either automatically via the Stackery VS Code Serverless Tools Plug-In or manually alongside any IDE.
