diff --git a/content/notes/first-it-must-work/index.md b/content/notes/first-it-must-work/index.md index 59b4d8d..a203ffa 100644 --- a/content/notes/first-it-must-work/index.md +++ b/content/notes/first-it-must-work/index.md @@ -7,14 +7,23 @@ references: url: https://grugbrain.dev/ date: 2023-05-12T13:08:33Z file: grugbrain-dev-dzqozx.txt +- title: "Even Amazon can't make sense of serverless or microservices" + url: https://world.hey.com/dhh/even-amazon-can-t-make-sense-of-serverless-or-microservices-59625580 + date: 2023-05-12T14:09:23Z + file: world-hey-com-ivvqlb.txt --- ### Thoughts on priorities in software development * So much stuff doesn't work -- bugs stop you from accomplishing your desired task * Over time, complexity creeps in, making changes gets harder -* Focus on performance, serverless, microservices, etc. -- increase complexity, reduce reliability +* The focus on performance, serverless, microservices, etc. -- these increase complexity, reduce reliability + +### Links + * [The Grug Brained Developer][1] +* [Even Amazon can't make sense of serverless or microservices][2] [1]: https://grugbrain.dev/ +[2]: https://world.hey.com/dhh/even-amazon-can-t-make-sense-of-serverless-or-microservices-59625580 diff --git a/static/archive/world-hey-com-ivvqlb.txt b/static/archive/world-hey-com-ivvqlb.txt new file mode 100644 index 0000000..1c67815 --- /dev/null +++ b/static/archive/world-hey-com-ivvqlb.txt @@ -0,0 +1,103 @@ + #[1]Feed + + [2][avatar-20210222112907000000-293866624] + + David Heinemeier Hansson + + May 4, 2023 + +Even Amazon can't make sense of serverless or microservices + + The Prime Video team at Amazon has published a rather [3]remarkable + case study on their decision to dump their serverless, microservices + architecture and replace it with a monolith instead. This move saved + them a staggering 90%(!!) on operating costs, and simplified the system + too. What a win! + But beyond celebrating their good sense, I think there's a bigger point + here that applies to our entire industry. Here's the telling bit: + + "We designed our initial solution as a distributed system using + serverless components... In theory, this would allow us to scale + each service component independently. However, the way we used some + components caused us to hit a hard scaling limit at around 5% of the + expected load." + + That really sums up so much of the microservices craze that was tearing + through the tech industry for a while: IN THEORY. Now the real-world + results of all this theory are finally in, and it's clear that in + practice, microservices pose perhaps the biggest siren song for + needlessly complicating your system. And serverless only makes it + worse. + What makes this story unique is that Amazon was the original poster + child for service-oriented architectures. The far more reasonable prior + to microservices. An organizational pattern for dealing with + intra-company communication at crazy scale when API calls beat + scheduling coordination meetings. + SOA makes perfect sense at the scale of Amazon. No single team could + ever hope to know or understand everything needed to steer such a fleet + of supertankers. Making teams coordinate via published APIs was a + stroke of genius. + But, as with many good ideas, this pattern turned toxic as soon as it + was adopted outside its original context, and wreaked havoc once it got + pushed into the internals of single-application architectures. That's + how we got microservices. + In many ways, microservices is a zombie architecture. Another strain of + an intellectual contagion that just refuses to die. It's been eating + brains since the dark days of J2EE (remote server beans, anyone??) + through the [4]WS-Deathstar nonsense, and now in the form of + microservices and serverless. + But this third wave seems finally to have crested. I wrote an ode to + [5]The Majestic Monolith way back in 2016. Kelsey Hightower, one of the + leading voices behind Kubernetes, [6]put it beautifully in 2020: + + "We’re gonna break [the monolith] up and somehow find the + engineering discipline we never had in the first place... Now you + went from writing bad code to building bad infrastructure. + Because it drives a lot of new spend, it drives a lot of new hiring… + So a lot of people get addicted to all the flourishment of money, + and marketing, and it’s just a lot of buzz that people are attaching + their assignment to, when honestly it’s not gonna necessarily solve + their problem." + + Bingo. Replacing method calls and module separations with network + invocations and service partitioning within a single, coherent team and + application is madness in almost all cases. + I'm happy that we beat back the zombie onslaught of that terrible idea + for the third time in my living memory, but we still need to stay + vigilant that we'll eventually have to do it again. Some bad ideas + simply refuse to die no matter how many times you kill them. All you + can do is recognize when they rise from the dead once more, and keep + your retorical shotgun locked and loaded. + + About David Heinemeier Hansson + Made [7]Basecamp and [8]HEY for the underdogs as co-owner and CTO of + [9]37signals. Created [10]Ruby on Rails. Wrote [11]REWORK, [12]It + Doesn't Have to Be Crazy at Work, and [13]REMOTE. Won at Le Mans as a + [14]racing driver. Fought the big tech monopolies as an [15]antitrust + advocate. Invested in [16]Danish startups. + + Subscribe to get future posts via email (or grab the [17]RSS feed) + ____________________ (BUTTON) Subscribe + + [18]Sent to the world with HEY + +References + + 1. https://world.hey.com/dhh/feed.atom + 2. https://world.hey.com/dhh + 3. https://www.primevideotech.com/video-streaming/scaling-up-the-prime-video-audio-video-monitoring-service-and-reducing-costs-by-90 + 4. https://www.flickr.com/photos/psd/1428661128/ + 5. https://m.signalvnoise.com/the-majestic-monolith/ + 6. https://changelog.com/posts/monoliths-are-the-future + 7. https://www.basecamp.com/ + 8. https://www.hey.com/ + 9. https://37signals.com/ + 10. https://rubyonrails.org/ + 11. https://www.amazon.com/Rework-Jason-Fried/dp/0307463745 + 12. https://www.amazon.com/Doesnt-Have-Be-Crazy-Work/dp/0062874780 + 13. https://www.amazon.com/Remote-Office-Not-Required/dp/0804137501 + 14. https://www.youtube.com/watch?v=iNQl0x6WS3M + 15. https://dhh.dk/#antitrust + 16. https://dhh.dk/#investor + 17. https://world.hey.com/dhh/feed.atom + 18. https://www.hey.com/world/?utm_source=hw-web