3 ms·

As a whole the strategy of "Let's see what's common in all these systems" is a good start to understanding the systems. There is a limit to the complexity any s

As a whole the strategy of "Let's see what's common in all these systems" is a good start to understanding the systems. There is a limit to the complexity any single person can understand. Unification is simplification. It helps understanding. But I agree it is no good trying to make the landscape fit a simple map when reality is much more complex. There's no Silver Bullet in trying to combat complexity. But rather than trying to unify everything think about micro-services. Each service can be its own isolated solution. Of course it needs to be optimized in terms of how well it works when all the other services are running as well. But I think isolation is the key to independently optimizing everything. I like this sentence from the article: "Lots of it doesn’t matter, but some of it matters a lot".

Splizard 5y ago
Except when Tim decides to standardize how each micro-service is built, using a custom framework...
- galaxyLogic 5y ago
  Yes Tim is known to have done that :-) But seriously I think there is something about micro-services that helps. It is that they unify things not on the application level but on a lower level by forcing a common communications protocol (http) to be used. The services themselves can vary widely there is no need to make them all behave the same or even use the same database. All that is needed is for all of them to speak the same language, the same protocol with their clients. We get the best of both worlds, unification and simplicity yet isolation at the same time. Micro-services are the greatest thing since sliced bread I think.
didibus 5y ago
Micro Services need a lot of unified standards to talk to each other. Maybe everyone understands "unification" differently, but for me making something simpler means making things that are small, independent, and where if they change internally they break nothing externally. But for this to work, you need common patterns, properties, interfaces, otherwise you can't combine your modules into a greater more complex system. If you do it right, the system as a whole might be complex, but each piece is simple to understand and reason about and making changes to them is not a risk to breaking the whole system. But it also means reuse, those small simple independent parts can be reused for more than one thing, that's why the system grows complex, so each micro-service is very much a unified standard on its own, just of a small enough scope to successfully build and maintain for multiple clients to leverage. But now, if you go to the next level up, you have a problem with the complex set of micro-services you now have, and that complex arrangement gets hard to reason about. That is where people added the idea of Supervisor, to have systems that watch over the subsystems, it serves as a way to unify a set of micro-services into a more reliable and understandable hole.
a1445c8b 5y ago
With a microservices architecture, it's still possible to locally optimize each microservice but then end up with a global architecture that is far from ideal. It seems to me that Tim's starting point was exactly that.

Splizard 5y ago

Except when Tim decides to standardize how each micro-service is built, using a custom framework...

galaxyLogic 5y ago
Yes Tim is known to have done that :-) But seriously I think there is something about micro-services that helps. It is that they unify things not on the application level but on a lower level by forcing a common communications protocol (http) to be used. The services themselves can vary widely there is no need to make them all behave the same or even use the same database. All that is needed is for all of them to speak the same language, the same protocol with their clients. We get the best of both worlds, unification and simplicity yet isolation at the same time. Micro-services are the greatest thing since sliced bread I think.

didibus 5y ago

Micro Services need a lot of unified standards to talk to each other. Maybe everyone understands "unification" differently, but for me making something simpler means making things that are small, independent, and where if they change internally they break nothing externally. But for this to work, you need common patterns, properties, interfaces, otherwise you can't combine your modules into a greater more complex system. If you do it right, the system as a whole might be complex, but each piece is simple to understand and reason about and making changes to them is not a risk to breaking the whole system. But it also means reuse, those small simple independent parts can be reused for more than one thing, that's why the system grows complex, so each micro-service is very much a unified standard on its own, just of a small enough scope to successfully build and maintain for multiple clients to leverage. But now, if you go to the next level up, you have a problem with the complex set of micro-services you now have, and that complex arrangement gets hard to reason about. That is where people added the idea of Supervisor, to have systems that watch over the subsystems, it serves as a way to unify a set of micro-services into a more reliable and understandable hole.

a1445c8b 5y ago

With a microservices architecture, it's still possible to locally optimize each microservice but then end up with a global architecture that is far from ideal. It seems to me that Tim's starting point was exactly that.