Great thread by @loujaybee! The @awscloud strategy has always been "build the primitives and let the ecosystem fill in the rest." But now that we have *most* of the primitives we need, what should AWS focus on next? 🤔 I don't think it's building better dev experiences. A 🧵 1/
https://twitter.com/loujaybee/status/1473946267713777668
Something very interesting happened at this year's @AWSreInvent. For the first time, all the announcements seemed "incremental" as opposed to "transformative." No new service like Lambda, EventBridge, or Step Functions, just upgrades. To me, this signals one thing: maturity. 2/
It's not as though there's nothing left to build, but we're at a point where the foundational pieces not only exist, but are also nearly 100% managed for you. The next frontier (and one of the hardest things with distributed systems) is finding the best way to connect them. 3/
Beyond "Lambda as glue", AWS has been changing the way we do this with what I call "smart service pipes." Think event-source mappings with super powers like event filtering, failure-handling features, tumbling windows, etc. "Configuration OVER Code" as @edjgeek calls it. 4/
This moves cloud-specific logic out of your business logic. Then when you isolate your code in separate Lambda Functions, it only needs to succeed or fail. Everything else is handled by the cloud provider. This is what gets us one step closer to "just write code." 5/
"But now I have to write all this config," you say! You're not wrong. However, despite CloudFormation's incredible verbosity, most of it is just boilerplate, and when applied to specific use cases, likely 99% is the same for everyone. 6/
This means that your use case (which probably isn't very unique) can be interpreted by a computer and then choose the right boilerplate infrastructure for you. The @goserverless Serverless Cloud is doing this now with some hints from our Serverless Development Kit (SDK). 😉 7/
There are other services out there working on this idea of the "cloud computer" as well. Write code -> publish it to the cloud -> let the cloud provision the resources needed to support your app. This is an incredible future that is getting closer every day! 8/
So what does this have to do with AWS & #DX? First of all, frameworks have to be opinionated (trust me, I've worked on a lot of them), otherwise you end up with @AWSCloudFormer. CF essentially lets you do anything, but too much choice (w/o guidance) means constant reinventing. 9/
Now, AWS *could* bake best practices into CloudFormation, but there are way too many services and possibilities to legitimately attempt it. Enter SAM and Amplify, AWS's way of introducing more focused frameworks to help developers put their 200+ services into some context. 10/
These are great for what they are, but like with all frameworks, they simply can't be everything to everyone. Now, I don't mind opinions, but what scares me about this approach is when AWS ties primitives to these highly opinionated frameworks. 11/
The most egregious example, IMO, is w/ Cognito. Cognito is an objectively terrible service, and no human should ever be forced to configure it, but at some point it dropped support for its own simple frontend library and forced you to adopt Amplify's: docs.aws.amazon.com/cognito/latest… 12/
That's a 41.3 MB library (for JS) that needs to be added to your code just to sign in to your app (Auth0 is 2.4 MB for comparison). I don't want that. I don't want to be forced into a larger AWS opinionated developer experience. I just want the primitive, and you should too. 13/
Perhaps this is an anomaly. I only use a handful of AWS services so I don't know where all the dragons potentially are. But beyond just frameworks, there are other attempts by AWS to create "better" dev experiences that can have unintended consequences. 14/
Take the new redrive SQS DLQs to source queue "management experience" (aws.amazon.com/blogs/compute/…). It's not a feature, it's not an API, it's an "experience" only available in the AWS Console. Do I want it? Yes! Do I want to login to the AWS Console to use it? Absolutely not. 15/
What about the new @dynamodb item manager? Despite taking 5 clicks to get to your items, you can now easily "rename" partition keys. But technically you can't. The console just wraps a transaction that deletes your old item and inserts a new one. 16/
It's a nice "experience", but tied to the console that few will ever (and should never) use for production data. This would be 100x more useful as a single API method, but rather than solving it via a programmatic interface, they invested in a UI. 17/
While we're on the subject of DynamoDB, let's talk about the disaster that is #PartiQL (which I recently found out is pronounced "particle" and not "party-Q-L"). SQL syntax for your DynamoDB tables, what could possibly go wrong? 18/
Hmm, how about boundless scans with filters, no access to ConsumedCapacity info on operations, and no UPSERT support? The best advice I've seen is to add an IAM policy that blocks SCANs to avoid expensive operations. Top notch developer experience right there. 19/
Apologies if I'm being hypercritical, but I love (many of) the services that AWS has built, and I'm continuously in awe of the work they do to push the boundaries of cloud computing (especially w/ #serverless). But given their track record, I want them to stay in their lane. 20/
Building with AWS (correctly) is very hard. I get it. I've been working with them since 2009. But the solution isn't more half-baked, stopgap primitives. It's not one-off "experiences" isolated in the console, or lazy abstractions that mask service complexity. 21/
And it's definitely not a one-size-fits-all opinionated framework that doesn't use #SingleTableDesign for its data models (no matter how cool the @figmadesign integration is). My advice is to continue to do what you do best: be the platform to build platforms. 22/
Stay focused on your primitives and make them the best versions of themselves. Double down on your "smart service pipe" strategy and make interservice communication fully-managed, highly resilient, and simple to implement. And most importantly, get out of the developer's way. 23/
AWS has had my attention for a very long time, but @Cloudflare, @MongoDB, @faunadb, @algolia, @fastly, @auth0, and others chip away at that every single day. Competing on breadth of offerings won't work anymore, especially when these other services are miles above yours. 24/
To me, a better "developer experience" is better documentation, faster service provisioning, lower egress fees, more investments in service upgrades/features, free managed NAT Gateways, more investments in on-demand service pricing, and maybe launching Aurora Serverless v2. 25/
There is an entire world of imagination out there, and there needs to be a limitless platform to let developers explore the (im)possible. Be that platform, @awscloud! /end
• • •
Missing some Tweet in this thread? You can try to
force a refresh
