4 ms·

The part I love about microservices, and something that I think doesn't get enough attention, is that is strongly enforces separation of concerns across micro-p

by qyv 11y ago

The part I love about microservices, and something that I think doesn't get enough attention, is that is strongly enforces separation of concerns across micro-projects. API boundaries are very clear and very rigid, it takes very little effort or oversight to prevent leaking across them. Essentially, you are moving some of the software 'best-practices' up a level form modules to applications themselves. This means that you don't need to spend a lot of effort writing great, best-practices following, future-proof, software upfront for fear of collecting horrible technical debt down the road. Got a service that was rushed out the door and isn't maintainable anymore? Rewrite it! 2 weeks later you have erased a bunch of technical debt and since you kept the same API(s) in place, you have not affected the rest of the services that make up your application. And that is the other thing that I think microservices are great at: They are pragmatically easier to change. Delving into a huge, old, debt-riddled monolithic codebase to make changes is hard and scary, and developers are less likely to want to make changes to monoliths because of that. Microservices are easy to understand because they are small, discrete systems with well understood interface contracts. Making changes to them without breaking the entire app is not scary because it is easier to throughly understand the implications of what is being changed.

elliotlarson 11y ago
I'm sort of playing devil's advocate here, but: > Got a service that was rushed out the door and isn't maintainable anymore? Rewrite it! 2 weeks later you have erased a bunch of technical debt and since you kept the same API(s) in place, you have not affected the rest of the services that make up your application. But that's also true of a monolith. Got a piece of your system that isn't maintainable any more. Rewrite it! 2 weeks later you have erased... you get the point. I like the idea of microservices. I like the idea of the clean boundaries. As a developer, the separation seems correct to me. But, unless you're actually feeling the pain point of the monolith, it just seems like more work that falls into the category of YAGNI. You also said this: > Delving into a huge, old, debt-riddled monolithic codebase to make changes is hard and scary... I mean, it's hard and scary if you don't have a high level of test coverage. If you have great coverage in the old monolith, you should be able to change pieces of it with confidence, no?
- qyv 11y ago
  Yes, you can always rewrite parts of a monolith, what I am saying is that it is just way easier to do with the hard-boundaries and well-defined interface contracts of microservices. You know that as long as you live up to the interface contracts, any changes you make to the microservice app cannot adversely affect other microservices. Just think about how much of software development patterns and best practices are devoted to creating proper encapsulation and avoiding tight coupling; All of that is simply built-in when you use microservics. Yes, of course if you have great test coverage making changes to a monolith can be easier, but good test coverage and debt-riddled don't often apply to the same codebase! Lets be honest, if you are happy with your monolith codebase then there is no reason to rewrite for microservices. It is for those projects that you are not happy with the monolith code, where maintenance of the code IS scary, that the conversion makes sense.
foo42 11y ago
It's worth noting that a rushed service will likely have a rushed interface as well as a rushed implementation, at which he point the "clear and rigid" boundaries work against you as they're likely rigidly in the wrong place. I think microservices have many benefits, but they can work against you when your discovering your model
twic 11y ago
Delving into a huge, old, debt-riddled microservice codebase to make changes is even more hard and scary, because now it's in multiple repositories and it has a lot more networking code. If you can't write and maintain a decent quality monolith, what makes you think you can do it with a collection of microservices?

by qyv 11y ago

elliotlarson 11y ago

I'm sort of playing devil's advocate here, but: > Got a service that was rushed out the door and isn't maintainable anymore? Rewrite it! 2 weeks later you have erased a bunch of technical debt and since you kept the same API(s) in place, you have not affected the rest of the services that make up your application. But that's also true of a monolith. Got a piece of your system that isn't maintainable any more. Rewrite it! 2 weeks later you have erased... you get the point. I like the idea of microservices. I like the idea of the clean boundaries. As a developer, the separation seems correct to me. But, unless you're actually feeling the pain point of the monolith, it just seems like more work that falls into the category of YAGNI. You also said this: > Delving into a huge, old, debt-riddled monolithic codebase to make changes is hard and scary... I mean, it's hard and scary if you don't have a high level of test coverage. If you have great coverage in the old monolith, you should be able to change pieces of it with confidence, no?

qyv 11y ago
Yes, you can always rewrite parts of a monolith, what I am saying is that it is just way easier to do with the hard-boundaries and well-defined interface contracts of microservices. You know that as long as you live up to the interface contracts, any changes you make to the microservice app cannot adversely affect other microservices. Just think about how much of software development patterns and best practices are devoted to creating proper encapsulation and avoiding tight coupling; All of that is simply built-in when you use microservics. Yes, of course if you have great test coverage making changes to a monolith can be easier, but good test coverage and debt-riddled don't often apply to the same codebase! Lets be honest, if you are happy with your monolith codebase then there is no reason to rewrite for microservices. It is for those projects that you are not happy with the monolith code, where maintenance of the code IS scary, that the conversion makes sense.

foo42 11y ago

It's worth noting that a rushed service will likely have a rushed interface as well as a rushed implementation, at which he point the "clear and rigid" boundaries work against you as they're likely rigidly in the wrong place. I think microservices have many benefits, but they can work against you when your discovering your model

twic 11y ago

Delving into a huge, old, debt-riddled microservice codebase to make changes is even more hard and scary, because now it's in multiple repositories and it has a lot more networking code. If you can't write and maintain a decent quality monolith, what makes you think you can do it with a collection of microservices?