Can someone do a similar analogy for micro-services? Quite a lot of times I struggle to explain people there are two different things.
"This, milord, is my family's axe. We have owned it for almost nine hundred
years, see. Of course, sometimes it needed a new blade. And sometimes it has
required a new handle, new designs on the metalwork, a little refreshing
of the ornamentation... but is this not the nine hundred-year-old axe of my
family? And because it has changed gently over time, it is still a pretty
good axe, y'know. Pretty good."
We replaced our monolith with micro services so that every outage could be more like a murder mystery.
The menu is the API, what comes out of the kitchen is the implementation.
Edit: would the downvoters explain to me why stealing an already
well-established term API to mean a largely unrelated concept of a service
(RPC service) is a good idea?
A few extracts:
> a way to implement an API
> …[APIs are] a set of subroutine definitions, protocols, and tools for building application software. In general terms, it's a set of clearly defined methods of communication between various software components.
> Similarly, if we abstract away the implementation details of operations
> Components can be swapped out and replaced as long as they follow the same protocol
Please don't comment about the voting on comments. It never does any good, and it makes boring reading.