Representing a loosely defined pattern or set of principles with a single word is hard. It doesn’t work very well. As it turns out, people latch on to the term, project their own meaning, then pass it on to others to do the same. Along the way, the term’s true semantics are lost (*cough* Agile *cough*).
What’s the difference between a monolith and a Microservice anyway? The name “Microservice” seems to imply that some measure of size is the differentiating characteristic. Folks will tell you that Microservices are really small. How small is “small”? An insect? A pony? Lichtenstein? Ok…
Show me ten teams and I’ll show you ten different processes or conventions for reviewing code. I am fascinated by conditions such as these. These are opportunities.
There are two easily accessible explanations for why a multitude of different approaches have been adopted to accomplish the same common task: poor communication; or there is no clear, single winner. With respect to the latter, a pessimist’s view might be “They all suck.”
First, let me state that I will not be talking about tools. Tools can be leveraged to better enable a process, but they should not dictate its parameters.
I help teams find sane approaches to building valuable products and services for a networked world. Director of Engineering at Heroku/Salesforce.