> Any time you lean on code in a random GitHub repository, where you never speak to the author and just use the API you're given, you're doing microservices.
So a library is a microservice now?
So a library is a microservice now?
And also - nothing is a microservice, because it's not separated strongly enough.
I think you put it very well, actually. Software development is so much about culture and understanding.
A microservice is comprised of people. Not a whole lot different than a service, but narrower in what is offered such that the service doesn't provide something useful on its own and is meant to be integrated with other services to achieve its full utility, hence the 'micro' moniker. In the world of physical products we often call these people suppliers.
It is possible that a microservice may produce Linux kernel modules.
If someone is writing about "microservices," they are generally talking about the situation where those APIs and team boundaries are exclusively (or at least primarily) composed of separate applications communicating over the network. Not what you're talking about.
Microservice architecture splits the functionality farther, than Conway's law talks about. When a single team owns 4-5 microservices - that's beyond Conway's law.
Get with the program. The world of software consists of one domain ("web apps") and two species: "microservices" and "monoliths". Older, cranky and ultimately useless, software zoologists insist this is all wrong and that there are all sorts of taxonomical layers and creatures yet unseen by the avid readers of blogs. But that's not what the internet says and hey, white hair? "Hmm. That's a red flag right there."
So many people have very little respect for the effects of the fact that this field is so ridiculously young, including the fact that all of these definitions are incredibly wishy washy.
Being able to take a statement like “an external dependency is a microservice” and not completely discounting the point being made is incredibly valuable.
> an external dependency is a microservice
Regret to disagree again. Flip that and you have a leg to stand on at least: A microservice is an external dependency. Service defines the architectural semantics of the dependency. Micro scopes the services provided.
I mean, what is it about haphazardly trying out an approach you read about on a random blog written by someone who has a different problem to solve than you says engineering? In my world engineering implies rigour, adherence to the data, etc.
There can be engineering in software. There can be science in software. But I'm not sure that means software work is categorically either engineering or science. I expect you will find that there is a lot of fad chasing and leaps of faith in hopes of stumbling upon something that will yield.
To the specific topic of conversation, where do you find the science or engineering, and not just people throwing shit in their plot and seeing what grows?
If you use a linked library, interface compatibility can be a real challenge. Web APIs, as you call them, offer more flexibility in adapting to different callers. It also comes with the added benefit of defining explicitly clear boundaries between teams that something that shares memory doesn't necessarily guarantee (e.g. monkey patching). This oftentimes makes it a good practical choice.