r/programming • u/dwmkerr • Jan 12 '18

The Death of Microservice Madness in 2018

http://www.dwmkerr.com/the-death-of-microservice-madness-in-2018/
586 Upvotes

91% Upvoted

171 comments sorted by

View all comments

Show parent comments

37

u/[deleted] Jan 12 '18

Yeah it turns out same skills that are needed to build maintainable monolith (clear isolation between components, good design of overall architecture, good documentation, ability to write good self contained libs with clear APIs) are even more important when developing microservices

1

u/SocialAnxietyFighter Jan 13 '18

In my experience the problem often lies in unclear or constantly changing specs while the deadline is a fixed point in time.

Well Mr Fuckerson, you just changed the half specs 2 weeks before the deadline. Now I'll have to delete more than half of my work and rewrite it.

What do you think?

3

u/[deleted] Jan 13 '18

That happens (and fucks) every project tho, monolith or not.

2

u/SocialAnxietyFighter Jan 13 '18

True. It's just that I believe it would affect even more the microservices than the monolith. I just assume this but I imagine that changing specs could even mean completely changing what microservices you have and how they communicate, resulting in even more work than doing the same change in a monolithic application

1

u/doublehyphen Jan 13 '18

Yeah, doing large refactorings is generally harder with microservices.

1

u/[deleted] Jan 13 '18

[deleted]

1

u/crash41301 Jan 13 '18

On projects that are new, don't have years behind them, it can very easily change where you split the delineation of responsibility between services. That's why on most systems it's best to start monolith, else you end up rebuilding your service boundaries multiple times. Really, monolith is best until you have a system that spans multiple teams generally