This type of elitist mentality is such a problem and such a drain for software development. "Real micro services are incredibly rare". I'll repeat myself from my other post, by this level of logic nothing is a micro service.

Do you depend on a cloud provider? Not a microservice. Do you depend on an ISP for Internet? Not a microservice. Depend on humans to do something? Not a microservice.

Textbook definitions and reality rarely coincide, rather than taking such a fundamentalist approach that leads nowhere, recognize that for all intents and purposes, what I described is a microservice, not a distributed monolith.

▲

ollysb 9 hours ago | parent | next [-]

It's fine to have dependencies, the point is two services that need to be deployed at the same time are not independent microservices.

▲

wowohwow 9 hours ago | parent [-]

Yes, the user I'm replying to is suggesting that taking on a dependency of a shared software repository makes the service no longer a microservice.

That is fundamentally incorrect. As presented in my other post you can correctly use the shared repository as a dependency and refer to a stable version vs a dynamic version which is where the problem is presented.

▲

jameshart 8 hours ago | parent | next [-]

The problem with having a shared library which multiple microservices depend on isn’t on the microservice side.

As long as the microservice owners are free to choose what dependencies to take and when to bump dependency versions, it’s fine - and microservice owners who take dependencies like that know that they are obliged to take security patch releases and need to plan for that. External library dependencies work like that and are absolutely fine for microservices to take.

The problem comes when you have a team in the company that owns a shared library, and where that team needs, in order to get their code into production, to prevail upon the various microservices that consume their code to bump versions and redeploy.

That is the path to a distributed monolith situation and one you want to avoid.

	▲	wowohwow 8 hours ago \| parent [-]
		Yes we are in agreement. A dependency on an external software repository does not make a microservice no longer a microservice. It's the deployment configuration around said dependency that matters.

▲

8 hours ago | parent | prev [-]

[deleted]

▲

3rodents 8 hours ago | parent | prev | next [-]

"by this level of logic nothing is a micro service"

Yes, exactly. The point is not elitism. Microservices are a valuable tool for a very specific problem but what most people refer to as "microservices" are not. Language is important when designing systems. Microservices are not just a bunch of separately deployable things.

The "micro" in "microservice" doesn't refer to how it is deployed, it refers to how the service is "micro" in responsibility. The service has a public interface defined in a contract that other components depend on, and that is it, what happens within the service is irrelevant to the rest of the system and vice verse, the service does not have depend on knowledge of the rest of the system. By virtue of being micro in responsibility, it can be deployed anywhere and anyhow.

If it is not a microservice, it is just a service, and when it is just a service, it is probably a part of a distributed monolith. And that is okay, a distributed monolith can be very valuable. The reason many people bristle at the mention of microservices is that they are often seen as an alternative to a monolith but they are not, it is a radically different architecture.

We must be precise in our language because if you or I build a system made up of "microservices" that aren't microservices, we're taking on all of the costs of microservices without any of the benefits. You can choose to drive to work, or take the bus, but you cannot choose to drive because it is the cheapest mode of transport or walk because it is the fastest. The costs and benefits are not independent.

The worst systems I have ever worked on were "microservices" with shared libraries. All of the costs of microservices (every call now involves a network) and none of the benefits (every service is dependent on the others). The architect of that system had read all about how great microservices are and understood it to mean separately deployable components.

There is no hierarchy of goodness, we are just in pursuit of the right tool or the job. A monolith, distributed monolith or a microservice architecture could be the right tool for one problem and the wrong tool for another.

https://www.youtube.com/watch?v=y8OnoxKotPQ

▲

wowohwow 7 hours ago | parent | next [-]

>We must be precise in our language

I am talking about using a shared software repository as a dependency. Which is valid for a microservice. Taking said dependency does not turn a microservice into a monoloth.

It may be a build time dependency that you do in isolation in a completely unrelated microservice for the pure purpose of building and compiling your business microservice. It is still a dependency. You cannot avoid dependencies in software or life. As Carl Sagan said, to bake an apple pie from scratch, you must first invent the universe.

>The worst systems I have ever worked on were "microservices" with shared libraries.

Ok? How is this relevant to my point? I am only referring to the manner in which your microservice is referencing said libraries. Not the pros or cons of implementing or using shared libraries (e.g mycompany-specific-utils), common libraries (e.g apache-commons), or any software component for that matter

>Yes, exactly

So you're agreeing that there is no such thing as a microservice. If that's the case, then the term is pointless other than a description of an aspirational yet unattainable state. Which is my point exactly. For the purposes of the exercise described the software is a microservice.

	▲	magicalhippo 6 hours ago \| parent [-]
		> Taking said dependency does not turn a microservice into a monoloth. True. However one of the core tenets of microservices is that they should be independently deployable[1][2]. If taking on such a shared dependency does not interfere with them being independently deployable then all is good and you still have a set of microservices. However if that shared dependency couples the services so that if one needs a new version of the shared dependency then all do, well you suddenly those services are no longer microservices but a distributed monolith. [1]: https://martinfowler.com/microservices/ [2]: https://www.oreilly.com/content/a-quick-and-simple-definitio...

▲

abernard1 6 hours ago | parent | prev [-]

> The "micro" in "microservice" doesn't refer to how it is deployed, it refers to how the service is "micro" in responsibility.

The "micro" in microservice was a marketing term to distinguish it from the bad taste of particular SOA technology implementations in the 2000s. A similar type of activity as crypto being a "year 3000 technology."

The irony is it was the common state that "services" weren't part of a distributed monolith. Services which were too big were still separately deployable. When services became nothing but an HTTP interface over a database entity, that's when things became complicated via orchestration; orchestration previously done by a service... not done to a service.

▲

AndrewKemendo 9 hours ago | parent | prev [-]

And if my grandmother had wheels she would be a bike

There are categories and ontologies are real in the world. If you create one thing and call it something else that doesn’t mean the definition of “something else” should change

By your definition it is impossible to create a state based on coherent specifications because most states don’t align to the specification.

We know for a fact that’s wrong via functional programming, state machines, and formal verification