4 ms·

The article didn't even mention a lot of drawbacks : Changing anything means changing half a dozen programs. Potentially in different languages. Building any

by iofj 11y ago

The article didn't even mention a lot of drawbacks : Changing anything means changing half a dozen programs. Potentially in different languages. Building any new feature into the program means you get to "walk the dependency tree", making sure no serialized stuff from a new version gets sent to an old version. Good luck with circular dependencies. Related: deleting a field ... never going to happen. We're talking years of planning. Any field added ... ever ... has to be taken along for the ride for years. Oh and don't even think about deleting the code that interprets and supports the field for the same reason. Also related: best of luck with the interactions between "oh we're not going to do that after all, sorry about asking you to already push that and update the database" and the "we really need to do this next thing right now" features. And the Constant serialization overhead. People go overboard with this microservice crap and the result is that 99% of your program's cpu time is used putting objects to json and back (which is very expensive due to constant alloc'ing), and you have 10-100 times the normal memory overhead. Microservices should be like optimization : build your program without using them and then figure out where they'd make sense. yes I know, you can sort-of avoid it these days with cap'n proto and flatbuffers

mdpopescu 11y ago
deleting a field ... never going to happen This is true for ANY class you release. I'm not even talking about a service API: if you published a class, and it gets used, you should never delete or change fields in it. You might get away with adding fields to it, depending on various factors. This is just the OCP; why is it a surprise?
- ed_blackburn 11y ago
  Depends. Things are rarely in absolutes :) If you serialise / deserialise you are probably coupled to an underlying type. Modify it instead of extending it and you have pain. If you parse the raw message, or serialise into a hash, or dynamic type then you have one place to make amends (your parser). Taking things further you can version your messages and map them to versions of parsers, as such you'd never violate OCP (or at least simply mitigate). Granted all of which is additional complexity compared to your stereotypical ball of mud / monolith that'll let you refactor field name changes etc to your hearts content. Obviously ball of mud approach has draw backs too...
- iofj 11y ago
  I always found getters and setters very helpful for this case. In C++ and in Java. Doubly so in Java because the following works: 1) field is no longer important, gets replaced 2) write a getter that still gets the value of it, but delete the field itself. --- this is where it stops for C++ 3) use the "inline function" refactoring on your entire codebase Done/done. You don't even have to rewrite the tests, in fact it might be better not to. (Of course getters and setters are somewhat verbose in most cases. Object pascal has the perfect solution though)
matwood 11y ago
> Building any new feature into the program means you get to "walk the dependency tree" Same with monoliths, except it is often a worse experience. At least with microservices I know the interface is all I have to worry about. In monoliths of any size inevitably someone has reached into parts of the program they shouldn't have just to get something 'done quickly'. And this is one of the main benefits of microservices - enforcing the interface boundaries. > Related: deleting a field ... never going to happen. We're talking years of planning. Any field added ... ever ... has to be taken along for the ride for years. Oh and don't even think about deleting the code that interprets and supports the field for the same reason. That's just poor design and happens just as much in monoliths. The db is the almost always the challenge when removing a field. I could argue that microservices make it easier since the service providing access to that field could remove it from the db and then dummy it out until clients are updated. Also, why wouldn't someone remove the field from all the clients when removing it from the supplier? With that said, I agree that microservices should be something that happens organically from a monolith. Think about an amoeba that reaches a certain size and only then do parts split off. I also think there is some ambiguity to what constitutes a microservice. I'm sure my idea of proper granularity is different from others.
- meatysnapper 11y ago
  The other benefit of a microservice is you can understand it. You can have the entire thing in your head. It's easier to maintain. With a monolith, good luck.
- marcosdumay 11y ago
  > At least with microservices I know the interface is all I have to worry about. You wrap your code inside a reusable library if you want to encapsulate it and expose only a small public interface. You don't start a new service for that.
  - tracker1 11y ago
    It doesn't ever work that way in practice for larger applications though... once you have multiple teams with many developers working on something, those library boundaries fade, and tbh sometimes they should just be bypassed in favor of more shallow layers (for a monolith). Once there are more than a handful of people working on anything no one person understands the details of the whole. Smaller, specialized services can at least act as and enforce those boundaries as upstream comments said.
thedufer 11y ago
> Changing anything means changing half a dozen programs. Potentially in different languages. Wouldn't this only be a problem if you broke up your service along the wrong lines?
- Illotus 11y ago
  Boundaries have problems in monoliths as well, can't really imagine it would be any easier with microservices.
- err4nt 11y ago
  I think he was referring to where the article said that one of the advantages of breaking a monolith into any amount of services is that they can store the data in the location and format that suits their task best, and also be written in different languages. I don't think it matters how you split it - if the team working on one module prefers ruby and the team working on another requires python for any 'serious' work you need programmers who understand both to get the 'big picture' of your codebase now. That one guy who writes all his stuff in PERL can write his plugin that way because it just interacts via API. :O Now how do you debug something?
  - ionforce 11y ago
    It's Perl, not PERL.
tracker1 11y ago
If you're using a flexible serialization scheme, such as many JSON libraries, you can exclude the field and have a sane default.. you can also handle this at the service boundary for older clients. Personally, I find this type of coercion to be more reliable than explicit case testing, and usually leads to fewer unexpected results.

by iofj 11y ago

mdpopescu 11y ago

deleting a field ... never going to happen This is true for ANY class you release. I'm not even talking about a service API: if you published a class, and it gets used, you should never delete or change fields in it. You might get away with adding fields to it, depending on various factors. This is just the OCP; why is it a surprise?

ed_blackburn 11y ago
Depends. Things are rarely in absolutes :) If you serialise / deserialise you are probably coupled to an underlying type. Modify it instead of extending it and you have pain. If you parse the raw message, or serialise into a hash, or dynamic type then you have one place to make amends (your parser). Taking things further you can version your messages and map them to versions of parsers, as such you'd never violate OCP (or at least simply mitigate). Granted all of which is additional complexity compared to your stereotypical ball of mud / monolith that'll let you refactor field name changes etc to your hearts content. Obviously ball of mud approach has draw backs too...
iofj 11y ago
I always found getters and setters very helpful for this case. In C++ and in Java. Doubly so in Java because the following works: 1) field is no longer important, gets replaced 2) write a getter that still gets the value of it, but delete the field itself. --- this is where it stops for C++ 3) use the "inline function" refactoring on your entire codebase Done/done. You don't even have to rewrite the tests, in fact it might be better not to. (Of course getters and setters are somewhat verbose in most cases. Object pascal has the perfect solution though)

matwood 11y ago

> Building any new feature into the program means you get to "walk the dependency tree" Same with monoliths, except it is often a worse experience. At least with microservices I know the interface is all I have to worry about. In monoliths of any size inevitably someone has reached into parts of the program they shouldn't have just to get something 'done quickly'. And this is one of the main benefits of microservices - enforcing the interface boundaries. > Related: deleting a field ... never going to happen. We're talking years of planning. Any field added ... ever ... has to be taken along for the ride for years. Oh and don't even think about deleting the code that interprets and supports the field for the same reason. That's just poor design and happens just as much in monoliths. The db is the almost always the challenge when removing a field. I could argue that microservices make it easier since the service providing access to that field could remove it from the db and then dummy it out until clients are updated. Also, why wouldn't someone remove the field from all the clients when removing it from the supplier? With that said, I agree that microservices should be something that happens organically from a monolith. Think about an amoeba that reaches a certain size and only then do parts split off. I also think there is some ambiguity to what constitutes a microservice. I'm sure my idea of proper granularity is different from others.

meatysnapper 11y ago
The other benefit of a microservice is you can understand it. You can have the entire thing in your head. It's easier to maintain. With a monolith, good luck.
marcosdumay 11y ago
> At least with microservices I know the interface is all I have to worry about. You wrap your code inside a reusable library if you want to encapsulate it and expose only a small public interface. You don't start a new service for that.
- tracker1 11y ago
  It doesn't ever work that way in practice for larger applications though... once you have multiple teams with many developers working on something, those library boundaries fade, and tbh sometimes they should just be bypassed in favor of more shallow layers (for a monolith). Once there are more than a handful of people working on anything no one person understands the details of the whole. Smaller, specialized services can at least act as and enforce those boundaries as upstream comments said.

thedufer 11y ago

> Changing anything means changing half a dozen programs. Potentially in different languages. Wouldn't this only be a problem if you broke up your service along the wrong lines?

Illotus 11y ago
Boundaries have problems in monoliths as well, can't really imagine it would be any easier with microservices.
err4nt 11y ago
I think he was referring to where the article said that one of the advantages of breaking a monolith into any amount of services is that they can store the data in the location and format that suits their task best, and also be written in different languages. I don't think it matters how you split it - if the team working on one module prefers ruby and the team working on another requires python for any 'serious' work you need programmers who understand both to get the 'big picture' of your codebase now. That one guy who writes all his stuff in PERL can write his plugin that way because it just interacts via API. :O Now how do you debug something?
- ionforce 11y ago
  It's Perl, not PERL.

tracker1 11y ago

If you're using a flexible serialization scheme, such as many JSON libraries, you can exclude the field and have a sane default.. you can also handle this at the service boundary for older clients. Personally, I find this type of coercion to be more reliable than explicit case testing, and usually leads to fewer unexpected results.