Do all the things like ++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatarSign Up
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple APILearn More
piehole8173yMicroservices solve a real problem. Monolithic app is great, until it starts to take 7h to recompile (I've heard of that) and every little change requires compiling the whole thing (maybe except for static files, which you could technically unzip from a war and re-insert).
It's also great until you change method 'a' in file 'A', and then later realize that method z in fucking file Z was relying on some implementation detail and now, you've got some folks pissed off coz you broke their code.
All I'm saying is, there are also pretty great use cases for microservices.
@piehole yeah, that is a set of real problems, but they all have solutions in the real world that do not require transitioning to the HTTPS later for function calls.
1. Most projects never get big. If they do, then you're lucky. Scale when you must, not when you start betting.
2. There are a lot of platforms that don't need code compiling.
3. Renaming stuff in code is a problem that doesn't disappear with microservices. It just becomes bigger really.
Micro services make sense when you start asking whether customer data should be part of CRM, customer support, logistics or website. You make it a separate service. Case closed.
It's also smoother with deployments.
But when I see small scale applications that barely work because of bugs due to delays, being dragged through even more layers, it's just sad. This is just a lot more places where things go wrong.
There are some benefits to every fad, but I swear our return is getting less and less...and we just end up hurting ourselves by overcomplicating things.
HughRant5293yI agree. Although, like I’m sure is included in your point, these fads often come to life because the paradigms/patterns/frameworks serve a real purpose.
However, people blindingly jumping on the newest shiny trend without pausing to think about what problem they’re actually trying to solve, is a problem in its self.
A similar site like this but for every new technology should exist 😉
matste6983yYeah. I’m now working in a 4 person team creating a system which consists of 10 „microservices”. It’s still growing and I feel your pain. It requires 20 GB of RAM in total to even start. Some interactions require 10 network hopps. A well designed, stateless(for scaling) monolith is probably the correct solution here.
michaelm1393yI agree there is something called over engineering. If you go to far to the microservices you will get a mess as well. Like most things the solution lies in the middle.
Plus sticking to domain driving design can prevent it growing wild.
Junior frontend dev whos learning backend now here. learned so much new stuff from this post. Thx
@zemaitis welcome, but please take what I said with a grain of salt. I don't want to seem to advocate for any particular approach to anything. Careful weighing of options and proper planning before you commit to something, even if you think you know a lot, is the proper way to go.
Condor347953yI don't think that microservices are all that bad. Well microservices as in say, a DNS server separated from a mail server. It makes stuff so much more maintainable, modular, scalable and secure. And when one thing goes tits up, everything else just keeps on humming along as if nothing happened. In a monolithic system, everything stands and falls with that one system. That's a bad practice.
With that said however, microservices like Git servers scattered over domains all over the place (if the git server is linked to a domain to begin with), Mastodon or similar social networks scattered all over the place, with management being in the hands of someone you know but might not be able to properly administrate a social network, those are the things that make me quite sceptical about decentralization. It's a good thing to be able to just connect to one place to catch up with all your friends, or do your professional work, and call it a day. Should I really have to connect to 100 places, maintained by different people/organizations to get shit done?
@Condor Does everything continue humming along? Or does that pre-requisite service screw up the whole assembly line? DNS needs to work for the email server to even get traffic....Microservices are great if they can truly run without each other. In a lot of cases, they can't and people just end up building software with a billion breaking points (each service) instead of a million (monolith). I build monolithic style until a particular element proves worthy of it's own auto-scaling server (or if I determine it WILL need it, I go that route from the start). I don't think it's smart to start with a messy web, especially when most businesses fail within a couple years.
Condor347953y@Stebner55 My mail servers are on a .com domain, so ICANN maintains the DNS for them. My personal DNS server is merely for internal addressing, as well as some custom addressing of external servers, just to make things a bit easier to type out. So if the DNS for my mail servers goes down, there'd be a little bit more of an issue than just my mail servers not receiving mail anymore, haha. It'd be something on the scale of the DDoS attack on Dyn earlier, perhaps even larger. Fortunately however, even if the authoritative DNS server goes down, there's a bunch of local caching DNS servers, scattered all over the world. My own DNS server is one of them, but ISP's generally have them too (and are usually set as default). So there's that of course.
You're partially right however. For example, my mail servers are currently in the process of getting their mail directories stored on a local container that makes a VPN connection to both the internet-facing mail servers, so that the mail servers can connect back to the local Samba server. Essentially a VPN-based storage that both of the mail servers can access simultaneously. If that local container goes down, yes the mountpoint would be lost, and mails would become inaccessible. Fortunately in that scenario, probably the mail servers would just write to their internal storage instead, which can easily be restored after the fact. And my servers are generally quite resilient, with their uptime only affected by scheduled reboots.