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

It stops being a microservice when a developer starts saying, "oh! We can do X in service Y too! It already does ${similar work} and reads/writes from/to ${data source}, so why not?"

The intended model is to do one thing, thus enabling surgical changes to functionality without having to rebuild everything. As long as you stick to your API contracts, you can muck around with the internals without effecting anything else.



That's not really answering the question. How do you define what the "one thing" that the service handles actually is?

I have this half-serious opinion that interface design is the hard (technical) part of software development, and the rest is mostly easy.


I remember coming to the same realization when the Google Vs Oracle court case was going on. Which decided that API’s are not copyrightable. To me it felt like the wrong decision, but what do i know.


I would definitely argue that public interfaces should not be copyrightable, since you need to be able to freely reimplement them to interoperate, which in my opinion should be preferred over granting even temporary monopolies to software interfaces.

However, public interfaces are only a small part of software interfaces in total. It's getting the system's internal interfaces right that takes most of the work.


I totally get it from the sense of avoiding monopolies for sure.

In my view, I was lumping internal/public interfaces in the same basket. I haven’t really considered public vs internal aspect of this.


Copyright in interfaces entrenches monopoly.


that sounds like a corollary to Conway's law.


That's been called "creeping featuritis" for about 25 years now. :)




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

Search: