❗️Wrote something new today:

Event-driven architectures vs. event-based compute in serverless applications.

I see these terms used interchangeably a lot, but they are different, and the implications are important!

alexdebrie.com/posts/event-dr… Event-driven architecture == asynchronous, decoupled, message-based communication between services.

Event-based compute == compute that is intimately tied to the occurrence of an event to trigger it.

All Lambda usage is event-based.

Not all Lambda usage is event-driven.

I rumbled w/ @houlihan_rick about the DynamoDB Transact API yesterday. Following up w/ thoughts here.

I really like the DDB Txn API! I think it's well designed:

✅ Enables real use cases
✅ Communicates that transactions have a cost
✅ Prevents the most problematic transactions

https://twitter.com/alexbdebrie/status/1617207434787065856

For use cases -- lots of examples, although it's not needed as often as you think. You can often design around it.

But, there is a reason there was a whole Java library for implementing transactions on the client-side in DDB. Sometimes you really need a transaction!

👋 I did a deep dive on database & distributed system consistency over the last 2 months, and finally got my thoughts together.

Check it out.

alexdebrie.com/posts/database…

High-level points below. First, there are three different uses of 'consistency' across these areas, and they only vaguely overlap:

1. 'Consistency' as the 'C' in CAP
2. 'Consistency' as the 'C' in ACID
3. Consistency models (think: Jepsen), which is somehow the 'C' from CAP plus the 'I' from ACID (??!)

Good notes from @GergelyOrosz here, and he's right that the economics for individual creators can be tough.

https://twitter.com/GergelyOrosz/status/1492452502159114242

Two notes from me on how the economics can be better than his rough calculations: 1) Going *straight* content can be hard (not impossible! There are examples of folks making all / most of their income from content -- @wesbos, @kentcdodds, @adamwathan).

But combining content with other, related income streams can be really effective.

1/ Last week, I did a presentation for a client that included (among other things), a discussion of DynamoDB and MongoDB.

Operational concerns aside, I think the biggest difference is this:

DynamoDB is authoritarian, while MongoDB is libertarian. 2/ If you've watched my talks, you've seen a slide like this. I like to discuss how DynamoDB partitions work and how they help keep DynamoDB performance consistent as your application scales.

For more, see my reinvent talk here:

I have a new chart I've been showing in my DynamoDB training and talks recently.

It's about DynamoDB performance, and there are two key points I want folks to understand:

1. DynamoDB is fast (not blazing fast! but definitely not slow)

2. DynamoDB perf is consistent

(cont.) Point 1: 'DynamoDB is fast.'

You'll get single-digit response times (at the server) from DynamoDB.

This is nice! Your users will appreciate that.

(cont.)

Franck Pachot (@FranckPachot ) is an RDBMS expert and wrote a really nice response to an earlier post I wrote about how DynamoDB scales where relational databases don't. I highly recommend reading it.

Link below, with 3 thoughts from me to follow.

https://twitter.com/FranckPachot/status/1279864643029291010

1. I'll trust Franck on the time complexity point for joins. He knows waaay more about this (and buffers & pages) than I do, so I'm a bit out over my skis there.

That said, I do think the general point about NoSQL (and DynamoDB in particular) + scalability hold up

(cont.)

Smart, fair thoughts here by @ryan_marsh about the Serverless Framework plugin system. Thread coming with my thoughts on good (and less good) uses of @goserverless plugins.

Initial tweet, since I can't thread on a retweet:

https://twitter.com/ryan_marsh/status/1028034482694250496

IMO, a SF plugin is best in three scenarios:

1) Extending the Framework's DSL to easily add more resources to your CloudFormation template. Example here is @acloudguru's Alerts plugin to add monitoring to your service.