Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I found out recently that people too often think about microservices in context of broader solution like it would be one app, just scattered around. I did that mistake in the past, either. The longer I work with microservices the clearer it is to me that teams implementing them should forget about the big product, just focus on the service, as it would be product itself. Assume that anyone can use it, for any purpose they like, as long as they stick to the contract that is, and you'll be fine.

I tend to have two layers of design, now. One - big picture, which treats services anonymously. Just black boxes that respond to input. The goal here is to build solution like kids are building stuff from building blocks.

Other layer depicts services, as separate beings. They treat all their clients anonymously. They have a contract to fulfill and whomever plays by the rules can be served all right. They should be treated as completely separate projects, have their own backlog, release strategies, etc.

Now, if you would have a product that utilize certain data, would you allow some anonymous guy from the internet tap to it directly? No need to answer, I guess.

Edit: typo



IOW, good, clean function composition.


While this is a simplification, I often catch myself thinking: isn't programming creating functions and functions of functions and that all way down? And on each layer we call them differently because of the context we're in.

Input --> Stuff happens --> Output

Again, it's a simplification, although to be fair, I sometimes don't see how -- other than that I'm feeling that I'm ignoring context too much (e.g. underlying hardware or networks or REST API endpoints).


And not just programming - all of computing really. Logic gates are composed into more complex ones that are composed into even more complex ones and so on upwards.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: