Hacker News Reader

Comment by eikenberry | Hacker News Reader

The real strength of micro services is that it should force you to specify your services by API and protocol. This is what allows it to scale to larger groups developers at the same time as scaling to large customer bases.

Both Netflix and Twitter, for example, have fallen into the trap you describe of using a common set of infrastructural libraries. With Twitter this has manifested by their micro services actually being a tightly coupled distributed application, not a loosely couple set of services. Netflix on the other hand has the set of libraries, yet have many groups not using them and because they went with libraries instead of APIs/protocols the non-library using applications don't follows the standards.

You need fully specified APIs and protocols with at least a 2 if not 3 different implementation platforms to keep you out of the trap of the common infrastructure.

[edit: fixed capitalization]

View on HN

The dream of reuse has made a mess of many systems. The value of components (you can call them microservices if you like) lies in independent entities communicating over well defined interfaces. This means that you can split work up into manageable units (and distribute the work across teams if you want to). But if things are genuinely independent then we have to accept that there will be some redundancy. As long as you stick to communicating with another component through its top level protocol/interface then things are OK. The temptation is to notice that there is something else the other component does internally that you would like to re-use in your implementation. So you ask them to expose that. This is where it starts to go wrong. You have increased the complexity of interaction with the other component just to get some re-use. Do this a few more times and the system becomes unmanageably complex. Its like any organisation. If you want to succeed you need to be able to delegate fully and don't try to micromanage people for the sake of some minor optimisation.

So the thing is to be disciplined. Only communicate over the formal interface and mind your own business/implementation. That means don't get involved in other peoples business and when other people try to get involved in yours tell them to $@&*!... please move along. Michael feathers has a good post [1] about how in COM it was hard to create components and so this enforced this kind of discipline. I think that another thing about COM was that you never got the source code for a component, it was always binary and the only thing that was published was the interface. This prevented people from nosing around in other peoples implementation. Feathers' point is that microservices are similar: Its hard to create a microservice so the granularity does not end up getting too fine. But to my mind there is no need to pay the price (failures, administration) of having to distribute a service just to get low granularity. Sure, if you want to distribute in order to scale that's fine. But otherwise just have your components in process and be disciplined about your interfaces. (Besides, microservices aren't that hard to make; Once you have made a few of them so you are going to have to have discipline there too)

[1]https://michaelfeathers.silvrback.com/microservices-until-ma...

There's a way to eliminate the reuse problem as well. If you make the services event-based and only let them speak to each other through messages then a service can never use another service. Services only listen and dispatch, no interservice request/reply calls.

Reply on news.ycombinator.com