4 ms·
My problems with microservices irl: 1. Sharing models - the models can be moved out to another repository or a NuGet package, but guess what happens when you h
by madeuptempacct 8y ago
My problems with microservices irl:
1. Sharing models - the models can be moved out to another repository or a NuGet package, but guess what happens when you have to modify them? Inevitably, devs duplicate models.
2. Debugging across five different code bases - have fun changing all the environment variables to point to your local every time, or running five different applications at the same time for local development.
3. Docker and Kubernetes add a LOT of overhead.
4. Multiple front-end apps combined into one "coherent" site always leads to routing problems...and token management problems.
5. Web Components cause bloat by pulling in web component scripts and the fact that each web component needs to fit the style of the whole site. Since shadow dom is isolated, each component pulls in styles again - slow. Again, debugging and checking in web component code is a pain.
6. Finally, siloing is inevitable.
Imo, this doesn't make sense at all for a smaller web app.
- spdionis 8y agoIs duplicating models that big of a problem? Just an honest question, hoping to get more answers/opinions besides parent's.
- madeuptempacct 8y agoIt's a good question. Going to let others answers. My tldr opinion is "Not really, but code duplication any time, but especially across repos can lead to hard-to-troubleshoot errors".
- koffiezet 8y ago> 3. Docker and Kubernetes add a LOT of overhead. That depends on the application. But docker adding overhead? Everywhere I introduced docker to devs, productivity went up, not down once a good way of working was presented to them. No 10 devs using some different versions of the same database engine, no more rogue gmail accounts for 'testing purposes' by showing them mailhog, updating the backend service became as much as a 'git pull' and 'docker-compose up' for the frontend devs instead of in the best scenario killing their vagrant vm and reinstalling it, or worst case, a 3-page installation/configuration document to follow on a fresh VM, and the list goes on... Sure there is some overhead involved, people need to learn a new tool - and have a bit more feeling with how software is deployed, but from an infra pov, that's a good thing. Kubernetes? Yes that adds a ton of overhead, certainly initially. Few really need it, but if you move from a monolithic app into a more micro-service based architecture for scalability issues, something like k8s is a godsend. What I do notice however is that once teams are accustomed to a workflow involving it after building a large application, they actually enjoy it and also start using it for smaller-ones. Architecture-wise it's easy to go overboard with the microservices, splitting things up simply because they're 'cleaner' - but that's something you should resist. But as you say, for smaller web apps, microservices make no sense...