Conversation

Notices

1. Embed this notice
   KnottEye (amy@decept.org)'s status on Wednesday, 24-Jan-2024 13:59:52 JST KnottEye
   I read grugbrain.dev the other day. I want to be like this but I think I am too young and ambitious to really be self-aware smol brain. I am still enthralled by trying to think my to the perfect abstraction before I even start the prototype lmao.
   Sorry to all the self-aware smolbrains and the actual bigbrains cleaning up after me. I am sure that in 10 years I'll be much more pleasant to work with when I stop droning on about type correctness.
   • 受不了包 likes this.
   • Embed this notice
     受不了包 (shibao@misskey.bubbletea.dev)'s status on Sunday, 11-Feb-2024 11:00:48 JST 受不了包

     in reply to

     • taylor

     @nik @amy@decept.org microservices are literally just an administrative problem that solves the problem of having like thousands of teams at something like twitter build into an application
     anyone who does anything with microservices that isn't at one of said thousands of teams tech company or strictly following something like the actor model is doing definition cargo cult programming lol

   • Embed this notice
     taylor (nik@misskey.bubbletea.dev)'s status on Sunday, 11-Feb-2024 11:00:49 JST taylor

     in reply to

     @amy@decept.org the most solid piece of advice on here

   • Embed this notice
     受不了包 (shibao@misskey.bubbletea.dev)'s status on Sunday, 11-Feb-2024 11:09:00 JST 受不了包

     in reply to

     • 7666
     • taylor

     @7666@comp.lain.la @nik@misskey.bubbletea.dev @amy@decept.org eh i'm not sure i agree with that mentality, i like to think of them all like tools, yes maybe you sometimes get totally new tools that are revolutionary and you want to see what it can be used for (in physical tool land, the grabo is one that i'm actually really interested in), but you still have to evaluate every single case and figure out what kind of tool will do the best job
     
     following industry trends just for the sake of following industry trends just means that you don't jump on some of the really bad ideas, but the more you pay attention to industry trends and read up about past trends, the more you'll realize "hey, this is just X from the 90s with a fresh coat of paint" and see through the hype better

   • Embed this notice
     7666 (7666@comp.lain.la)'s status on Sunday, 11-Feb-2024 11:09:01 JST 7666

     in reply to

     • 受不了包
     • taylor
     @shibao @nik @amy many concepts would be great if people understood how they functioned and did not simply implement them because "new and fancy"
     
     therefore i always recommend staying one generation of technology behind because enough competent engineers will be available to cross examine the shitty ones
     
     therefore, VMs and monolithic service architectures are king. whenever someone does something new and fancy that deprecates microservices, then microservices will be king.
   • Embed this notice
     受不了包 (shibao@misskey.bubbletea.dev)'s status on Sunday, 11-Feb-2024 11:12:49 JST 受不了包

     in reply to

     • pry
     • taylor

     @pry@raru.re @nik@misskey.bubbletea.dev @amy@decept.org microservices is weird because you get people who want to decompose all of their shit into a giant distributed topography in almost like a functional way but then you also get the classic twitter/AWS "1 microservice = 1 team" and there's 6000 teams, so guess how many microservices you have... and the scope of responsibility for the microservices is just whatever the politics of the team inside the company. And then you have other people who take microservices but slap something like domain driven design on it and bound microservices by domain or whatever and that's cargo culting imo

   • Embed this notice
     pry (pry@raru.re)'s status on Sunday, 11-Feb-2024 11:12:51 JST pry

     in reply to

     • 受不了包
     • taylor

     @shibao @nik @amy

     and like you said... you can get the micro service feel just w doing actor model stuff in a single machine... why spread it across machines?

   • Embed this notice
     受不了包 (shibao@misskey.bubbletea.dev)'s status on Sunday, 11-Feb-2024 11:15:23 JST 受不了包

     in reply to

     • pry
     • taylor

     @pry@raru.re @nik@misskey.bubbletea.dev @amy@decept.org microservices these days basically means you use grpc and whatever else the fuck you want, just like devsecops means you have a security scanner in your ci pipeline and whatever else the fuck you want, scrum just means you have a weekly sprint planning meeting and whatever else the fuck you want, agile means you're supposed to have metrics and whatever else the fuck you want,

   • Embed this notice
     受不了包 (shibao@misskey.bubbletea.dev)'s status on Sunday, 11-Feb-2024 11:24:10 JST 受不了包

     in reply to

     • 7666
     • taylor

     @7666@comp.lain.la @nik@misskey.bubbletea.dev @amy@decept.org eh, i think the cloud enabled tons of smaller companies that could previously only hire a couple devs to actually ship something that had a chance of scaling if it was done right. before, you would literally have to know how to procure and set up servers in preparation for anticipated load (like after doing a bunch of big advertising or smth) and properly maintain backups and everything or at least just have an ops team to do all of that, vs after "the cloud" suddenly you don't have to have a whole ops team always on call for every application. the cloud in big companies is always just a political decision and not as good, but small companies or companies with like 1 team of devs? that's where it made the impact imo

   • Embed this notice
     7666 (7666@comp.lain.la)'s status on Sunday, 11-Feb-2024 11:24:12 JST 7666

     in reply to

     • 受不了包
     • taylor
     @shibao @nik @amy industry trends are generally people following gartner magic quadrants as if they were crystal balls. i pay zero attention to them.
     
     your goal is to support the business, not play evangelist. if the industry trend is to go to the cloud, you have to evaluate that against your needs before committing. if more people understood that, the cloud probably wouldn't be the cash cow it is, as the same people calling the cloud a game changer are the same people selling it.
     ✙ dcc :pedomustdie: :phear_slackware: likes this.
   • Embed this notice
     受不了包 (shibao@misskey.bubbletea.dev)'s status on Sunday, 11-Feb-2024 11:30:03 JST 受不了包

     in reply to

     • pry
     • taylor

     @pry@raru.re @nik@misskey.bubbletea.dev @amy@decept.org yeah i think like phoenix is super underrated by including pubsub into the architecture via just a genserver, you can literally just build out an event sourced architecture from day one without even having to deal with redis, although honestly redis is so solid you might wanna just use it if you expect to utilize it at scale in the future

   • Embed this notice
     pry (pry@raru.re)'s status on Sunday, 11-Feb-2024 11:30:04 JST pry

     in reply to

     • 受不了包
     • taylor

     @shibao @nik @amy yea it's wack... I've actually become quite a fan of event sourcing architectures (using stuff like Kafka) but like it only makes sense in large enough scales.

     at least w Kafka you've got this nice source of truth and a nice abstraction of a shared log

   • Embed this notice
     受不了包 (shibao@misskey.bubbletea.dev)'s status on Sunday, 11-Feb-2024 11:33:21 JST 受不了包

     in reply to

     • 7666
     • taylor

     @7666@comp.lain.la @nik@misskey.bubbletea.dev @amy@decept.org when your aws bill is 100k then your revenue should be way higher than that, but honestly now that we have cloud native everything, everyone should just be targeting docker containers, and then when it makes sense to hire the ops team then just have them move from managed k8s to on prem k8s how they like it and boom, ezpz
     but then you have to have the question of managing your k8s clusters in a distributed way, so that's why i've invented k64s to manage managing your k8s clus- gets shot

   • Embed this notice
     7666 (7666@comp.lain.la)'s status on Sunday, 11-Feb-2024 11:33:22 JST 7666

     in reply to

     • 受不了包
     • taylor
     @shibao @nik @amy i didn't say the cloud was entirely shit. some companies are fine paying the premium to have that ease of scaling, especially early on. it's a lot easier to go spin up 20 VPSes vs. figuring out how to colo and what to colo and how to build your own backends and infra.
     
     the biggest risk is disparity of cost (see: AWS egress transfer costs per GB) vs. what you could just do on your own. it may not hurt early, but when your amazon bill is $100k a month, you could just as easily be thinking what your ROI will be on a server purchase with an expected lifespan of 7 years
   • Embed this notice
     7666 (7666@comp.lain.la)'s status on Sunday, 11-Feb-2024 11:50:21 JST 7666

     in reply to

     • 受不了包
     • taylor
     @shibao @nik @amy >your revenue should be way higher than that
     ok but when was that ever a reason to not control costs
     
     "oh wow look at all this money guys! what's that, a PO for $2 million? sign it! we're rich!"
   • Embed this notice
     受不了包 (shibao@misskey.bubbletea.dev)'s status on Sunday, 11-Feb-2024 11:50:21 JST 受不了包

     in reply to

     • 7666
     • taylor

     @7666@comp.lain.la @nik@misskey.bubbletea.dev @amy@decept.org >when was that ever a reason to not control costs
     i mean, even i hate this because i'm extremely anal about software quality and always want to spend time to overengineer make something really nice but even i'll admit that the first one to market more often than not becomes the winner, and if you don't believe me, working in or even just observing startups will prove it to you (maybe not as much as they say, people who are like "JUST SHIP IMMEDIATELY WE DON'T CARE" piss me off also)

   • Embed this notice
     受不了包 (shibao@misskey.bubbletea.dev)'s status on Sunday, 11-Feb-2024 13:52:19 JST 受不了包

     in reply to

     • pry

     @pry@raru.re it's really not, and honestly it's not even the best for everything, but what it does well it does really really well and the majority of stuff that a generic crud webapp needs, it does pretty well as well

   • Embed this notice
     pry (pry@raru.re)'s status on Sunday, 11-Feb-2024 13:52:21 JST pry

     in reply to

     • 受不了包

     @shibao aaaaa I rlly need to learn phoenix but its always so daunting... it feels like a big framework

   • Embed this notice
     受不了包 (shibao@misskey.bubbletea.dev)'s status on Sunday, 11-Feb-2024 14:05:19 JST 受不了包

     in reply to

     • 7666
     • taylor

     @amy@decept.org @nik@misskey.bubbletea.dev @7666@comp.lain.la yes but then you need balancing for your mutli-cloud load balancing and that's why i've created k512s, w- gets shot again
     
     jk anyways i think the interesting stuff right now if i was building yet another generic crud saas webapp is doing the above, using phoenix to create a web ui really quickly, making it completely event sourced with the built in phoenix pubsub from the ground up, but then also including warehouse native metrics from the beginning with using opentelemetry and more, you could get to market in like 6 months flat and go extremely customer and metric driven from there, kinda in the original agile way
     
     but i think if you're this good at building saas crud webapps you should probably be putting your talents to better use so i think i'm going to try to pivot towards things that matter a bit more

   • Embed this notice
     KnottEye (amy@decept.org)'s status on Sunday, 11-Feb-2024 14:05:20 JST KnottEye

     in reply to

     • 受不了包
     • 7666
     • taylor
     @shibao @nik @7666 >so that’s why i’ve invented k64s to manage managing your k8s clus- gets shot
     doesn't this basically exist as a multi-cloud load balancer + autoscaling k8s clusters?
     Haelwenn /элвэн/ :triskell: likes this.
   • Embed this notice
     受不了包 (shibao@misskey.bubbletea.dev)'s status on Sunday, 11-Feb-2024 14:53:32 JST 受不了包

     in reply to

     • pry

     @pry@raru.re well well well, i wish you well and that you find all well that you wish at the wishing well : )

   • Embed this notice
     pry (pry@raru.re)'s status on Sunday, 11-Feb-2024 14:53:33 JST pry

     in reply to

     • 受不了包

     @shibao hmm yea maybe I should just learn by making....

   • Embed this notice
     pry (pry@raru.re)'s status on Sunday, 11-Feb-2024 20:36:35 JST pry

     in reply to

     • 受不了包

     @shibao thank u thank u u are too kind. hope ur elixiring has been going well

     受不了包 likes this.