Operations | Monitoring | ITSM | DevOps | Cloud

Stackery

re:Invent Serverless Talks - Scaling Up to Your First 10 Million Users

After months of planning and anticipation for sponsors, attendees, and speakers alike, it’s a bit surreal that re:Invent 2019 is actually upon us! In addition to setting up shop in the Expo hall with the team to chat with re:Invent guests about their current serverless development workflows (and how Stackery can supercharge it), I made sure to attend some choice presentations this week.

Best Practices for Multi-Account AWS Deployments

This guide will give you key strategies for deploying the same application on multiple AWS accounts. If you have multiple AWS accounts running, multi-account deployments make often make sense. If your developers have created an application within their dev environment (which has its own AWS Account), they’ll naturally want to move it over to production (with a separate AWS Account).

Serverless Architecture Conference 2019 - Serverless Hits the Big Time in Berlin

I never thought that this would be my life. For more than a year, I’ve been talking to individual customers and getting inspired by their stories, challenges, and goals. Now, I have the spectacular opportunity to meet entire conference rooms of people who are excited to hear about my story, challenges, and goals. This is my time to give back to the types of users who have inspired me ever since I entered the serverless space.

Two Stackery Superstars Named AWS Serverless Heroes

It’s been a great couple of months at Stackery. Since coming on as CEO earlier this year, I’ve been impressed with how much our team gets done and their contributions to making the serverless development experience easier and more reliable. I want to take a moment to recognize two of our amazing Stackerinos who were recognized by AWS recently with the AWS Serverless Hero distinction.

What's in a serverless developer's environment?

I often get asked what software tools are ideal for a serverless developer. I like being asked for my tooling preferences as much as the next developer gal, but when you break it down, this particular question is flawed. Serverless is, after all, about using a massive suite of platform tools to let you do minimal management.

15 hours writing CloudFormation reduced to 15 minutes with Stackery

ServerlessConf NY this past October was an important milestone for those of us tracking how software is built on cloud services. . We’ve seen the serverless talks evolve from “what is serverless” to “I built a weird thing” to “We built a new business” to “We refactored a legacy app and kickstarted our feature velocity.” We’ll come back to those last two soon, , but I want to highlight some points from one in particular by Tim Wagner.

Stackery Welcomes Tim Wagner, Inventor of AWS Lambda, to Board of Directors

In new and quickly-expanding fields like serverless, long-standing experts are few and far between. I am excited to welcome Tim Wagner, the original leader of the serverless movement, to the Stackery Board of Directors. Tim spent six years at Amazon Web Services as the General Manager of AWS Lambda, where he oversaw the team that built the success of serverless as a platform. In many ways, we have them to thank for creating the environment that supports Stackery and the serverless ecosystem.

The Secret Lives of Failed Amazon SQS Messages

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.

The Secret Lives of Failed Amazon SQS Messages

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.