Embed Notice

@p @laurel

microservices

similar to what p mentioned, there is a because they can mindset, but it does come down to having small, constrained areas of responsibility in system. while many write microservices similar to unix philosophy, there's a lot of "pack monolith into a microservice and wear blinders" happening in the industry(s).

system decoupling works well when the goal is immutable infrastructure/architecture and having agnostic interfaces (i.e. you have a microservice written in python and it's slow, so you write it in go, kill the old service and hot-swap it to the go one live). having this sort of segmentation in. your system is nice and makes things pluggable or like legos for big boys and girls.

And, you know, ASLR and stack canaries and whatnot, but I think it's better to locally source your binaries rather than having purely identical ones. It is way easier to write an exploit for a process that is executing a binary that you have, you know where everything's gonna be, you know how paranoid the compiler settings were.

whenever possible i like to compile my own software/build packages from source. something like nix makes this a bit easier with build instructions for packages and helpers to make packaging new things easier. although i won't recommend nix to anyone. it's painful and really not something i'd use in production.

as for immutable operating system approaches, there's quite a few besides nix, guix, etc. in the microservice area talos is king of the hill. whole thing runs in ram and relies on overlay configuration and boot/init time to do it's thing. pretty slick, but limited use-case for kubernetes which i'm not willing to run anymore on my personal system(s)

these days i think less about immutability standards (i can do this myself and do), and more about being able to bootstrap an entire system on command, from anywhere, and have it be reproducible. this usually involves some base/steady-state os iso, and some config that's pulled into the system after we're at rl-3.

think of how tails works (usb in the computer, boot, operate, has persistence volume).

i do this but not with tails. any computer i can boot into and have what i need provided there's some form of internet(s) connection. even if it's heavily dpi'd/firewalled i have multiple demons looking for ways to reach out to the control server (aka the hidden janitor closet) to pull what is needed including things that should persist. this is all experimental right now, but as of this typing if i were to power the machine down, 5 min later or less i would be fully back up minus what's in this buffer that i'm typing

It's like job queues and graph databases were, it's a buzzword for something almost no one needs but GOOGLE SCALE. See the following old-ass article about exactly the same thing: http://widgetsandshit.com/teddziuba/2009/06/startups-keep-it-in-your-pants.html .

grpc is actually pretty amazing. but like anything, there's a sharp edge that will circumcise you twice if you're not careful. the sharp-edge being it really only makes sense in a hyperscalar system with heavy service density. you need something way more efficient than standard tcp/http calls for service:ricky_bobby to talk to service:spider_monkey. but i would argue that anyone on fediverse is not running that sort of system even though they may or may not be working for the goog.

it's like a lot of stuff i play with. interesting af until i find out it's a sledgehammer to lick a stamp and/or i'm the only dumphuk using it.