3 ms·
Surely one could split a shared monolith into many internal libraries and modules, facilitating ownership?
by jakey_bakey 3y ago
Surely one could split a shared monolith into many internal libraries and modules, facilitating ownership?
- troupe 3y agoYes, but you are still dealing with situations where other teams are deploying code that you are responsible for. With microservices you can always say, "our microservice wasn't deployed, so it is someone else's problem." But I think you are pointing out one of the reasons most places don't get benefits from microservices. If their culture doesn't let them do as you describe with a monolith, the overhead of microservices just bring in additional complexities to an already dysfunctional team/organization.
- manicennui 3y agoIt's crazy to me how opposed to building libraries everyone seems these days. We use a fuckton of libraries, but the smallest division of software we'll build is a service.
- dalyons 3y agoits not crazy to me... ive worked at a couple of places that decided to try to use libraries in a web services context. They were all disasters, and the libraries ended up being considered severe tech debt. The practical aspects of updating all the consumers of your library, and how the libraries interact with persistence stores end up being their undoing.
- manicennui 3y agoHow do you square this with the fact that you likely used dozens of libraries from third parties?
- dalyons 3y agoprobably 1000s hah. It's the speed of change. third party libraries dont change much, or fast - and you dont really want them to. The software you build internally at a product company with 500+ engineers changes much much faster. And you want it to.
- lmm 3y agoIt's difficult to own a library end-to-end. Ownership needs to include deployment and runtime monitoring.