This is gold. It reflects too many real engineering projects so well. Sometimes I'm the guy to point this out, but too often I catch myself arguing for adding unnecessary complexity (unfortunately usually in hindsight). There should always be one engineer playing devil's advocate and at least try arguing why a new system/service isn't necessary.
Scalable, Resilient Brainfuck
21–30 of 47 posts
Re: Scalable, Resilient Brainfuck
#22So he is running clusters of brainf#ck machines in the cloud? I think this can be legitimately called a Clusterf#ck.
Re: Scalable, Resilient Brainfuck
#23Re: Scalable, Resilient Brainfuck
#24Back in the day, I was on the team that added Python 2.7 support to App Engine and we were experimenting with a different containment approach.
But Python is a complex language to support - you need to support WSGI, to support dynamic loading (for C extensions), a reasonably performant file system (Python calls `stat` about a billion times before actually importing a file), etc.
So our original runtime was actually Brainf#ck. So, at once point, if you had guessed that Google supported it, you could have written your (simple) webapp in Brainf#ck and Google would have scaled it up to hundreds of machines if needed ;-)
Re: Scalable, Resilient Brainfuck
#25So he is running clusters of brainf#ck machines in the cloud? I think this can be legitimately called a Clusterf#ck.
You can curse here
Re: Scalable, Resilient Brainfuck
#26Re: Scalable, Resilient Brainfuck
#27There's no HA here, so we need a K8S/Fargate cluster and the Postgres needs to be multi zone.
we need it to be multi-master, clearly. those writes need to go somewhere!
Re: Scalable, Resilient Brainfuck
#28So he is running clusters of brainf#ck machines in the cloud? I think this can be legitimately called a Clusterf#ck.
Re: Scalable, Resilient Brainfuck
#29Quick nit - "for may years" -> "for many years". Had to stop reading, basically unreadable.