Absolutes in programming tend to lead to bad designs. This is more a “I’m gonna stir up some shit on Twitter” post than real wisdom.
No microservices usually leads to bloated, tightly coupled logic that ignores business domains
No monoliths usually leads to sprawling microservice deployments with tightly coupled dependencies and flavor-of-the-week new ones
No Kubernetes usually leads to VPS pets or crazy obstacle courses trying to get SSL termination without a million fucking dependencies in a cloud container orchestration system that isn’t as good as Kubernetes
All Kubernetes usually leads to huge SRE costs for a tiny app
The same shit happened last summer when AWS came out with their “we dropped microservices for a monolith and look at our speed increase” article which ignored good design principles. Sometimes you should split things over business domains so you can deploy and code independently. Sometimes Kubernetes is the best way to handle your scale needs. The stories we normally read are about people doing it wrong (eg AWS making a bunch of microservices inside a domain sending fucking gigs of data between what should have been functions in a single service). Inexperienced folks don’t always know when to move from their minimum viable solution to something that can scale. That doesn’t mean you remove these things, it means you train on when you need them.
Should we abandon design patterns because singletons or flywheels aren’t the correct solution all of the time?
Precisely, Gary Bernhardt has given a talk on ideology. I don’t think he’s precisely someone who thinks in absolutes. It’s just preaching that some stuff is (probably) used more than it should. I’ve seen way, way, way worse projects that over engineered things and made things slow and unmanageable, than the opposite. Of course, everyone has seen different things, and our perceptions are amplified and biased by that.
Monoliths are the answer to bad microservices. Microservices are the answer to bad monoliths. It’s all cyclic and four different architects are going to have fifteen different opinions on how your system should be built. Do the thing that makes sense for your team and try to stay flexible.
Saying that some projects, at some point in their lifecycle, don’t need certain things, is not saying that those things have no place. Also, if one can’t design a monolith that isn’t bloated and tightly coupled, one definitely has no business designing microservices. Using microservices is neither necessary, nor sufficient to achieve decoupling.
Monolithic services are the ideal way to begin a project, as using basic good practices, we can build a service that does many things with minimal coordination, and as it grows and requirements change or are discovered, we can easily refactor to keep things simple. As the software matures, we find the natural service boundaries, and find that certain pieces would perform better if they were separated out and could scale independently, or act asynchronously. Since we have followed good practices, this should usually be a simple matter of removing a class or module to a new service, and replacing it with a facade, such that the rest of the monolith doesn’t have to change at all.
Currently migrating a massive monolithic Java application to microservices… The circle of life continues.
Want to just swap jobs in ~5 years to keep the cycle going? You can migrate this project back to a Java monolith and I’ll migrate your monolith back to micros :D
Honestly this just sounds like periodically refactoring everything to remove cruft can be a good thing. Also, it helps you understand how the existing code works if you change it and not break everything.
Lemmy really needs pixelfed’s naive bayes spam detection, it would be able to easily classify the new accounts after classifying one post as spam, then it would be 0 seconds wasted.
I agree with GitHub being bad, but the meme’s content is worse and I’m afraid that there are people who agree with it. I don’t like GitHub or Microsoft but since I get their stuff for free I do use but I’d love to use something that’s open and supports git properly.
It’s just another option, don’t gotta use it. Maybe you find yourself needing something like this, and the only other choice is making it public. At least with friend classes, you know which classes are friends so you can go look for any dependencies
There’s infinite ways to organize code. In C# or Rust where this isn’t an option, you might use nested classes or traits hidden behind a module/namespace.
Good use cases are data structures with associated helper classes. For example, a collection/tree and an iterator/tree-walker for working with elements of the collection. Or for something like a smart memory allocator (an arena or slab allocator), you might use a friend-class to wrap elements returned from the allocator, representing their connection back to it (for freeing up when done or to manage the allocation structure in ie a heap or sorted tree).
It allows for more fine grained access control and to implement afterthoughts.
Think having some private function that can break things if called improperly, but also allow you to avoid significant overhead when calling it the correct way. For example you could be avoiding input validation in a public wrapper for that function. If your friendly class already does it, or cannot produce invalid inputs, there is no need for that.
You could also implement logging after the fact, because your friendly logger object to read private members.
Arguably it’s a questionable design decision tho, as you could do all of this in other ways and it basically breaks any guarantees private would usually give you.
Totally agree with this. I was trying to do CSS theming on my personal website on SDF to try and make it look nicer but I gave up and just went without it because it never worked right. It’s a crappy website anyway with a lot of problems (doesn’t have correct margins so on anything outside specific resolutions it looks wonky).
programmer_humor
Newest
This magazine is from a federated server and may be incomplete. Browse more on the original instance.