3 ms·
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 ${dat
by igetspam 5y ago
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.
- chousuke 5y agoThat'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.
- wara23arish 5y agoI 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.
- pjc50 5y agoCopyright in interfaces entrenches monopoly.
- chousuke 5y agoI 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.
- wara23arish 5y agoI 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.
- fragmede 5y agothat sounds like a corollary to Conway's law.
- rhizome 5y agoThat's been called "creeping featuritis" for about 25 years now. :)