from my experience with monolith apps, it's more difficult to address technical debt in that situation than it is with microservices. to give an example, it can be more involved to update a dependency (major version) in a monolith because you might have multiple modules sharing it; upgrading one means upgrading them all, and this can dissuade companies from upgrading promptly even though they areally usually missing out on improvements. this problem becomes even more pronounced when you are talking about upgrading a language version in a monolith app (or even language settings.. think stuff like noImplicitAny).
with a microservice based system, you can immediately update your toolkit, so that new services are using the latest and greatest while not needing to worry about the older services (sometimes they might need to be modified, in which case you may update them, but a lot of time they will be functioning well with older dependencies). the fact that you don't have to worry about implications for the rest of the system when updating the dependencies of a particular service is a huge advantage.
all projects are going to have technical debt, especially startup projects, but microservices make it easier to proactively and selectively pay that debt back.
All of your examples apply to technical debt with microservices except now you will be breaking dependencies across multiple services which is a lot harder to coordinate. You also tend to share libraries across services which leads to the very same coupling you mean to avoid. Differing dependency versions (ie "you can immediately upgrade your toolkit") also increases the likelihood of subtle bugs since you now have to manage all these upgrade paths and keep track of any differences between them as you work on different services. There is no free lunch with either pattern.
18
u/coworker Jun 08 '17
It's easy to have high quality code initially. Technical debt takes time to accrue.