4 ms·
Why do you have to split things into services? How about moving things into different folders. Have you thought about that? Why do you have to modularize it w
by corethree 3y ago
Why do you have to split things into services?
How about moving things into different folders. Have you thought about that?
Why do you have to modularize it with a whole new repo, a whole new docker set up? Just use a folder bro.
- abhiyerra 3y agoI found Django apps to be a good middle ground.
- hot_gril 3y agoUsually the most important designation of the separate system is that it uses a separate database. You only have immediate consistency within one service.
- aledalgrande 3y agolol good luck without centralized data
- hot_gril 3y agoEach service is authoritative on its own data, and it works neatly. Any medium to large size system is going to have natural places to separate that, or else will buckle under complexity or even hardware constraints if you try to keep it all in one DB. I've seen it repeatedly.
- corethree 3y agoNah this doesn't work out. Because requirements are so chaotic and modular design isn't an axiomatic science things will for sure go wrong with the design both because you got the design wrong and because the requirements shifted to a point where another design was better. You encapsulated data under one service and you find that it's actually utilized much more in another service. This happens a lot. The longer you can centralize your storage the better and easier everything is.
- aledalgrande 3y agoExactly. And having more than one source of truth for your data complicates a lot of things. Where I work we run a massive MySQL database that has a pretty simple sharding rule, so I don't believe that you need to split the database even at scale.
- hot_gril 3y agoIt's not primarily about the size of the DB, it's about what's in it. If your massive MySQL DB is only used by one team, then that's fine. If separate teams' services are speaking through shared tables on it, that becomes a mess of an API easily.
- aledalgrande 3y agoWe have thousands of developers on it. I’m not saying it’s a silver bullet, but it works and it works well. Also, the service writing on it is only one (monolith).
- hot_gril 3y agoDepending on what the service is, I can see how this would work fine, but I don't think this is a common case.
- leetharris 3y agoExcept I've seen this work at dozens of companies? This thread is very painful, feels like CS101 coming in to tell us why we don't need relational databases and that we can just shove it all inside mongo.
- corethree 3y agoIt's not the thread it's most likely you. I don't know if people tell you but dealing with you is likely to be extremely painful if you say rude garbage like this to peoples faces. Multiple databases can "work" but you get the problem I described above. You know when you go to a company and eventually you see idiot practices or technical debt? Unfortunately this belongs to that category. You seeing it at dozens of companies doesn't validate anything except for the fact that bad patterns are common. It also validates the existence of people who often do things poorly and don't know it (aka you).
- jedberg 3y agoIf you have centralized data then you have broken the abstraction and are in for a world of hurt. You shouldn't need centralized data, just a service front door where that service is the master of that part of the data.
- aledalgrande 3y agoSo what are you gonna do when you need data migrations? PS: I'm not saying using one DB with microservices, it's still with the monolith
- leetharris 3y agoMigrations per service are exactly why you separate them out in the first place. Reading your comments in this thread has been painful. If you have multiple things sharing one data store, having ownership over the structure of the data is very difficult.
- aledalgrande 3y agoDid you read the PS? According to your condescending tone you did not.
- hot_gril 3y agoWhat kind of data migration did you have in mind, and what's the problem with it?
- threeseed 3y agoYou mean like having user authentication data in AD/LDAP and everything else in an RDBMS. Because this is the standard architecture you will find for most platforms.
- gotimo 3y agoinb4 the separate "data consistency service"
- zmmmmm 3y agowhich is the main step on the pathway to hell At the point where you have to write an API call instead of simply joining to a table, you have introduced orders of magnitude more complexity, failure points, testing challenges, race conditions, coherency issues, code duplication etc into your system. I don't mind stateless microservices too much. This forms more of a hub and spoke model (many services talking to 1 database). But the minute you bring separate state into the equation it's a chaos factory.
- corethree 3y agoNah but there are real instances where you have to use a different database for performance profiles. The biggest one in web is regular entity databases vs. timeseries databases designed for analytics. For this case entity data is just synced to to time series database every so often. Not super chaotic. It does make sense to divide services along those lines. Though I would argue a folder still works for the web app part.
- hot_gril 3y agoJoining a table is nice until that table is owned by a separate team. Becomes either gridlock or constant breakage, performance can get precarious, and testing involves populating a whole fake DB vs just mocking a few RPCs. I really like relational DBs. I'll make a system rely heavily on complex joins. But I'd rather call some other team's API than share DBs with them.
- atoav 3y agoThe problem microservices try (tried?) to solve isn't about namespaces, it is about too tight coupling between code. Whether that tightly coupled code sits in a subdirectory or in a different repo doesn't matter. It can be benefitial to maintain well defined interfaces at boundaries between certain parts of your code. It can also produce a lot of work and add complexity. But beyond a certain scale adding systemic boundaries and honoring them isn't something you should avoid. Devs who do microservices just tend to go too far too early.
- corethree 3y ago>The problem microservices try (tried?) to solve isn't about namespaces, it is about too tight coupling between code. You can use folders to decouple code by making code private within that folder. Only publicize parts of the code with your languages version of exporting. Or you can make it private behind an entire new repo and behind an entire service. Only publicize parts of the code through api interfaces like http and make everything 10x harder for the sake of decoupling code.
- tored 3y agoMany languages misses that abstraction to make things private in a folder (namespace) hierarchy to outside consumers. This is something I like to see solution to (integrated with your IDE of choice)
- corethree 3y agoPython is the only one that I know of that does this. Additionally python uses private by convention: Just prefix the stuff with an underscore.
- atoav 3y agoSure there are tons of ways to decouple code. My point was however, that moving code into a folder doesn't automatically solve that coupling issue.
- 3y ago
- nroms 3y ago> Just use a folder bro This will be my new go-to response when discussing microservices