As a builder of SaaS software, I often find myself looking at services like AppSync with a bit of jealousy. See, AppSync has a way for you to interact directly with services like DynamoDB, removing the need for a Lambda function, and the cold starts that come with it. As a SaaS builder, these direct integrations have always been out of reach because of the inability to secure the data at the tenant level. Due to some features introduced by the Step Functions team last year, there now is a way. In this post, I’ll walk you through how you can access DynamoDB data from an AppSync API without the need for a Lambda function, all while maintaining tenant data isolation.

If you’re building a SaaS solution, it’s critically important that you protect and isolate your customer’s data from other customers (often referred to as tenants). For companies building SaaS on AWS, one aspect of their isolation strategy is to connect the data that resides in tenant-owned AWS account(s) with your SaaS application running in your, SaaS provider-owned, AWS accounts.

I was really excited when AWS announced EventBridge Pipes at re:Invent last year. This was going to simplify all the CDC (change data capture) code I find myself writing, and probably reduce my Lambda spend.

There are a lot of reasons why switching from SQL to NoSQL is a good idea for much of what we as developers do. The vast majority of our work is OLTP, transactional data processing, where we know what the access patterns are and can design our NoSQL data storage in a way that supports those access patterns.

In my previous post I talked about why you need to think about data and security differently when working on a multi-tenant application. In this post I’ll dig in a bit deeper and show you what we did at ByteChek (RIP) for our multi-tenant strategy.

Security is hard. Multi-tenant security is harder. Multi-tenancy, however, is what makes the SaaS model work, and so security becomes something that needs to be at the forefront of your system’s architecture.

The latest report on the state of serverless from DataDog was a bit disappointing for me. Here’s why.

Working with hierarchies in DynamoDB can be a little intimidating. In this post I’ll show you two ways to work with hierarchies, and hopefully take away some of the fear.

As you may know, I’m a big fan of serverless in AWS. The primary compute component of serverless in AWS is AWS Lambda, so as you might imagine, I use it a lot. When using Lambda, I try to follow best practices for retries and dead-letter-queues (DLQs) or error destinations, but there are so many ways to do it I often find myself needing to look them up. So, I thought it might be useful to have a simple guide. Here it is.

I love serverless, for a lot of reasons. One huge benefit is the cost; if you’re not using it you aren’t paying for it. So, it bothers me whenever I find a need to have some bit of infrastructure that I have to pay for all the time. If you run your lambdas inside a VPC you may know what I’m talking about (also, the title of the article might have given it away). NAT gateways are a necessary evil when your function needs to talk to anything outside the VPC. Or are they?

If you find yourself needing to work with Geo data you might find yourself reaching for tools like ElasticSearch, or your favorite SQL database, to allow for geospatial searching. If you love DynamoDB as much as I do you cringe whenever you have to leave the comfort of the scale, performance, and availability of DynamoDB. In this article I’ll show you how you can use DynamoDB for Geo data, so you don’t have to resort to those other databases.

If you’re new to DynamoDB, or NoSQL in general, you’ll want to take some time to understand how access patterns drive how you model your data. If you’ve seen any of a number of the great re:Invent sessions by Rick Houlihan over the years you already understand it, at least enough to know that you need to think about it. If you haven’t, look them up on YouTube. They are insightful and often mind blowing.

In my previous post I showed you how you can handle multiple events but only trigger downstream processes in batches. There was one catch to that processing; everything was delayed. What if you want to respond immediately to the first event, but then delay the next time you process until at least some time has passed? Today I’ll expand upon the previous post to do just that.

Processing event data is a basic concept in today’s cloud based architectures. We recently came across a situation where processing EVERY event was too much. Imagine if you are running radar and someone is exceeding the speed limit. The radar is constantly reporting the speed, and that speed may even change, but you really only need to take one action; pull the driver over and write a ticket. So how did we do this?

In my previous blog post I showed you how to create a cross account, cross region pipeline with CodePipeline. Today I’ll show you how to extend that pipeline so that your developers can have there own pipelines whilst also staying up to date on the latest changes.

AWS introduced a simple tool for deploying services several years ago, called CodePipeline. Since then they’ve done a lot to make it more powerful. This blog will show you how to take advantage of the power of CodePipeline to build a cross account, cross region pipeline.

I was talking to a colleague one day who was unhappy with some elements of his job, or, more specifically, some elements of the environment. The conversation went about like you’d expect, with some thoughts about what was wrong and how it should be. These conversations are important to have because it helps me understand what makes people tick, what they like about their job, and what they don’t. It helps define what changes, if any, need to be made organizationally.

A number of years ago I started a job at a company that was just starting their move into the cloud. Shortly before I arrived there was a rather heated debate, from what I’ve heard, about whether identifiers should be integers (auto numbered specifically) or GUIDs. By the time I arrived the decision had been made to use integers. I quickly stepped in and pointed out all the problems this has in distributed systems and we, mostly, switched to GUIDs. That wasn’t the right choice.