update it must work note
This commit is contained in:
David Eisinger
@@ -7,14 +7,23 @@ references:
|
|||||||
url: https://grugbrain.dev/
|
url: https://grugbrain.dev/
|
||||||
date: 2023-05-12T13:08:33Z
|
date: 2023-05-12T13:08:33Z
|
||||||
file: grugbrain-dev-dzqozx.txt
|
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
|
### Thoughts on priorities in software development
|
||||||
|
|
||||||
* So much stuff doesn't work -- bugs stop you from accomplishing your desired task
|
* So much stuff doesn't work -- bugs stop you from accomplishing your desired task
|
||||||
* Over time, complexity creeps in, making changes gets harder
|
* 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]
|
* [The Grug Brained Developer][1]
|
||||||
|
* [Even Amazon can't make sense of serverless or microservices][2]
|
||||||
|
|
||||||
[1]: https://grugbrain.dev/
|
[1]: https://grugbrain.dev/
|
||||||
|
[2]: https://world.hey.com/dhh/even-amazon-can-t-make-sense-of-serverless-or-microservices-59625580
|
||||||
|
|
||||||
|
|||||||
103
static/archive/world-hey-com-ivvqlb.txt
Normal file
103
static/archive/world-hey-com-ivvqlb.txt
Normal file
@@ -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
|
||||||
Reference in New Issue
Block a user