Everyone got so excited about Graviton2 Lambda functions & Step Functions AWS-SDK integration yesterday that you might have missed this one about triggering Lambda functions from SQS queues in *different* accounts. This is important, a short 🧵 #serverlessaws.amazon.com/about-aws/what…
Having multiple AWS accounts to handle different parts of your application (from both a lifecycle and service perspective) isn't just good practice, it's also AWS recommended. 👍 2/9
This is because AWS account separation is the best isolation model for security, scalability, regional controls, service limit management, billing 👈, and much more. 3/9
Having a well-defined AWS account separation model/deployment process also gives you the ability to more easily implement isolated PR/feature branch deployments AND (probably most importantly) high-fidelity developer sandboxes to test apps in the cloud! ☁️ 4/9
This utopia, however, has been (and for the most part still is) a difficult thing to achieve. Mostly because IAM is an incredibly complex maze of dragons and minotaurs that can only be navigated by powerful magi like @bjohnso5y, but also... 5/9
...because cross-account capabilities are either really hard, or they aren't supported! The #EventBridge team recognized this and has been kicking a$$ on that front for awhile now. Checkout @sliedigaws's re:Invent talk about some of the patterns. 6/9
This is why announcements like Cross-Account Support for SQS & Lambda are so incredibly important. Following best practices for acct isolation is often a double-edged sword, forcing us to create duplicate resources to handle simple tasks while still shipping data x-account. 7/9
Okay, not as short of a thread as I thought, but these types of features are super important to building modern, distributed applications in the cloud. So thank you @awscloud for continuing to move in this direction. 🙌 8/9
And finally, this account separation model is the best practice that we implemented with @goserverless Serverless Cloud. The best part is we handle all those cross account IAM roles and requirements for you. 😉 9/9 serverless.com/cloud
• • •
Missing some Tweet in this thread? You can try to
force a refresh
Very cool #reInvent session by @sliedigaws about building out distributed applications using different #EventBridge patterns. Let's recap this quickly to see how we can use them to build out our #serverless apps. 🧵
The "single-bus, single-account" pattern is a super simple way to get started, especially if you have a small team. Create logical service boundaries and use a single event bus to decouple the services. This is one of my favorite ways to prototype #serverless applications.
The "single-bus, multi-account" pattern is my go-to for larger apps, and works great for multi-team orgs w/ service-level ownership reqs. Create a *global* event bus, grant access to service accounts for putEvents, and forward events to service-owned buses for rules & routing. 👍
Context is *extremely* important. The repeating line in the musical of "I'm going to reduce your… ops!" is in the context of setting up and maintaining a Kubernetes cluster. If it's not obvious the first time with "Hey yo, I'm unlike containers, no patching, no maintainers"...
…then the second time around adding "No pods or orchestrators" should make it abundantly clear. Since I consider myself a #serverless purist, I try to avoid the "K" word, but the line "I know all this stuff with K8s is excitin'" should settle any further misunderstanding.
.@alexbdebrie has another excellent post that details the benefits and downsides of using a Single-Table design with @DynamoDB. While I completely agree with him on the “benefits”, I have some thoughts on his “downsides” that I’d like to address. 🧵 alexdebrie.com/posts/dynamodb…
Downside #1: “The steep learning curve to understand single-table design”
There is no doubt that “thinking in #NoSQL” is a complete departure from traditional #RDBMS, but understanding how to correctly denormalize data is applicable to both single- AND multi-table designs.
If you are using a multi-table design in @DynamoDB that implements 3NF, then just STOP! Seriously, this is *beyond* wrong (I think presidents have been impeached for this). This is not what #NoSQL was designed for and you will get ZERO benefit from doing this. Spin up an RDBMS.
Yes, "pay-per-use" is very attractive, but I'm okay with AWS's "pay-for-value" model in #serverless environments. I don't expect the cloud to dedicate resources to me for free. I may get the benefit of warm invocations, but that's an internal optimization, not a guarantee.
Steady workloads benefit from "provisioned" capacity, not just from a pricing standpoint, but for performance as well. The "why-not-do-this-high-volume-workload-on-EC2" argument is "sometimes" valid. Provisioned Concurrency w/ Lambda is a step towards negating that logic.
Kicked off @AWSreInvent 2019 by attending @houlihan_rick’s @DynamoDB modeling session. As expected, it was a 60 minute firehose of #NoSQL knowledge bombs. There was *A LOT* to take away from this, but here are some really interesting lessons that stuck out to me. #reInvent
DynamoDB performance gets BETTER with scale. Yup, you read that correctly, the busier it gets, the faster it gets. This is because, eventually, every event router in the fleet caches your information and doesn’t need to look up where your storage nodes are.
Big documents are a bad idea! It’s better to split data into multiple items that (if possible) are less than 1 WCU. This will be a lot cheaper and cost you less to read and write items. You can join the data with a single query on the partition key.
EventBridge _should_ become the glue that ties together all your cloud services (eventually w/ two-way message bindings). This means that the number of event types (don't forget SaaS partners) is going to increase exponentially...
Security best-practices will evolve to prefer multiple event buses so you'll have fine-grained access control across SaaS vendors, AWS service events, and custom messaging. The cognitive load to understand all those nuances, limitations, and event structures is overwhelming...