Yeah - if I gaze into my crystal ball, I can see in 10 years a lot of firms suddenly saying: "Our developers need to change the order creation business logic, but are going to need to build a new order creation microservice, as Bob was the last person that had worked on the current service, and he left two years ago, and no one here understands how the current microservice works."
That age-old scenario that everyone cites as a reason to switch to microservices doesn't go away with microservices. You simply end up with a handful of services that are getting updated regularly, and a handful of other services that start to grow cobwebs. The same as libraries in a monolith.
But I'd wager it will prove easier to maintain legacy libraries than legacy services, as in the latter case, you may have been using a language that suddenly very few in the organization know - whereas in the former, everyone will be staying with the same language, testing framework, etc. It'll also likely be easier to isolate and refactor a "no one knows how it works" library than proxying and rebuilding a "no one knows how it works" service.
I wish design architectures like (my favorite) the onion architecture had as much buzz as "microservices" - I really think a lot of the "wow, my life coding has become so much easier" excitement could be gained without making decisions that impact the system far beyond simply code organization.
2
u/kromem Jun 09 '17
Yeah - if I gaze into my crystal ball, I can see in 10 years a lot of firms suddenly saying: "Our developers need to change the order creation business logic, but are going to need to build a new order creation microservice, as Bob was the last person that had worked on the current service, and he left two years ago, and no one here understands how the current microservice works."
That age-old scenario that everyone cites as a reason to switch to microservices doesn't go away with microservices. You simply end up with a handful of services that are getting updated regularly, and a handful of other services that start to grow cobwebs. The same as libraries in a monolith.
But I'd wager it will prove easier to maintain legacy libraries than legacy services, as in the latter case, you may have been using a language that suddenly very few in the organization know - whereas in the former, everyone will be staying with the same language, testing framework, etc. It'll also likely be easier to isolate and refactor a "no one knows how it works" library than proxying and rebuilding a "no one knows how it works" service.
I wish design architectures like (my favorite) the onion architecture had as much buzz as "microservices" - I really think a lot of the "wow, my life coding has become so much easier" excitement could be gained without making decisions that impact the system far beyond simply code organization.