The point that I was trying to make with the micro services is that I have found that they give you better components, I think because it is usually another team the one that produces them and several teams consume them, hence it forces for a more isolated and thoughtful design, it forces to make things backwards compatible and it also makes the boundaries obvious.
I do not think they make things simpler. As you say, the network is a huge headache on its own, but I think they force us to follow good practices.
On the other hand, with monoliths I find it easier to put some hack, break encapsulation and to end up with a big ball of mud.
Of course, I have also seen the death star from Netflix :)
I agree that network services on a resiliant exchange format (like XML, protobuff, Json...) greatly help on the backward compatible aspect and if you are serious about the doc, versioning and all it great way to isolate a component.
I always found componentization to be extremely hard to achieve. A web service can be very fast become non backward compatible, expose proprietary format or a structure of data that is incomplete or not future proof. The cost of maintenance is then huge.
When you are in the same process, the issues are far easier to solve but also are far easier to make and once there too many, nobody can manage to remove them. This is because languages at least like C, java or clojure are not really solving modularity issues.
Java 9 is going to give a try to a module system and OSGI has been there for quite some time in the eclipse echosystem. But that last one is not easy to use.
What we do in our project there is that each module in their simplest form have 3 maven modules: an interface module, an implementation module and an aggregator module that depends on both: one with the standard compile scope, the second with the runtime scope.
Clients code depend on the aggregator. They perfectly see the public interface but can't statically reference the implementation module as it is not included in the classpath at compilation time.
Linking is done either by spring (typically with annotations) or for components that are not expected to be bound to spring, by a singleton in the interface that access the implementation by introspection. Typically in a ServiceLocator or equivalent way.
The implementation can implement any interface, have any kind of public/protected visibility and clients can't abuse that without doing it on purpose (moving the class, making the access public or adding a compile time dependency to impl). Go to separate git (for a group of modules arround a feature likely) and it become harder to go unnoticed.
What we still miss but I guess could be added is a build failure in maven if you try for another scope than runtime on an "impl" module.
I worked with the OSGi for four years back in the early days and it is one of the best frameworks to force you to think about how to componetize your application.
But the most useful lesson was to think about how your system should behave if one of the component was not present or was being restarted/upgraded.
It is an experience that translated quite nicely to the micro services world and that still helps me every time that we build a new system. Somebody should write a book called "What happens if this dependency is not available?".
What the OSGi did not taught me was that the network is a PITA. I learned that latter :)
Hi Nicolas,
All very true.
The point that I was trying to make with the micro services is that I have found that they give you better components, I think because it is usually another team the one that produces them and several teams consume them, hence it forces for a more isolated and thoughtful design, it forces to make things backwards compatible and it also makes the boundaries obvious.
I do not think they make things simpler. As you say, the network is a huge headache on its own, but I think they force us to follow good practices.
On the other hand, with monoliths I find it easier to put some hack, break encapsulation and to end up with a big ball of mud.
Of course, I have also seen the death star from Netflix :)
Thanks a lot!
Dan
I agree that network services on a resiliant exchange format (like XML, protobuff, Json...) greatly help on the backward compatible aspect and if you are serious about the doc, versioning and all it great way to isolate a component.
I always found componentization to be extremely hard to achieve. A web service can be very fast become non backward compatible, expose proprietary format or a structure of data that is incomplete or not future proof. The cost of maintenance is then huge.
When you are in the same process, the issues are far easier to solve but also are far easier to make and once there too many, nobody can manage to remove them. This is because languages at least like C, java or clojure are not really solving modularity issues.
Java 9 is going to give a try to a module system and OSGI has been there for quite some time in the eclipse echosystem. But that last one is not easy to use.
What we do in our project there is that each module in their simplest form have 3 maven modules: an interface module, an implementation module and an aggregator module that depends on both: one with the standard compile scope, the second with the runtime scope.
Clients code depend on the aggregator. They perfectly see the public interface but can't statically reference the implementation module as it is not included in the classpath at compilation time.
Linking is done either by spring (typically with annotations) or for components that are not expected to be bound to spring, by a singleton in the interface that access the implementation by introspection. Typically in a ServiceLocator or equivalent way.
The implementation can implement any interface, have any kind of public/protected visibility and clients can't abuse that without doing it on purpose (moving the class, making the access public or adding a compile time dependency to impl). Go to separate git (for a group of modules arround a feature likely) and it become harder to go unnoticed.
What we still miss but I guess could be added is a build failure in maven if you try for another scope than runtime on an "impl" module.
I worked with the OSGi for four years back in the early days and it is one of the best frameworks to force you to think about how to componetize your application.
But the most useful lesson was to think about how your system should behave if one of the component was not present or was being restarted/upgraded.
It is an experience that translated quite nicely to the micro services world and that still helps me every time that we build a new system. Somebody should write a book called "What happens if this dependency is not available?".
What the OSGi did not taught me was that the network is a PITA. I learned that latter :)
Thanks!
Dan
I just wanted to say it was a pleasure to watch your discussion guys haha
Kudos to Nicolas!