AWS enthusiast. DevOps believer. Lover of serverless patterns.
We are about to let software spend our money, send messages in our name, and change records on our behalf, mostly while we aren’t watching. A lot of the attention goes to making an agent that can do those things. The harder part is deciding whether it should, and making sure it can’t overstep. That is the part I want to talk about.
In my years of building software, one thing I see a lot is decision paralysis. A team needs to pick a database, or a vendor, or an architecture, and the decision just sits there. Documents get written, meetings get scheduled, opinions get socialized, and weeks go by. When I dig into why a decision is stuck, the answer is almost always the same: somewhere along the way, someone decided it was…
I recently attended a session given by Allen Helton (AWS Hero) on the past and future of IaC (infrastructure as code). In it he talked about a future where the infrastructure was more adaptive, allowing you to write code once and have it modify how it runs automatically. This brought me back to something I did about 7 years ago, where I had the same code running in both a container and in Lambda.…
In a multi-tenant SaaS application, you often need to manage resources that are tenant-specific. Whether it’s a tenant-specific role, isolated DynamoDB tables, or per-tenant Cognito user pools, you need to have a way to deploy and update these resources across your application. In this blog, I’ll show you how I have approached this problem.
Welcome! This post focuses on implementing feature tiers in SaaS applications, rather than payment processing tools like Stripe or Square. If you’re interested in learning about tiers and managing features for different customer levels, read on!
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…
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.