FWIW, I think it was a great write up. It's clear to me what the rationale was and had good justification. Based on the people responding to all of my comments, it is clear people didn't actually read it and are opining without appropriate context.
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.
Bingo. Couldn't agree more. The other posters in this comment chain seem to view things from a dogmatic approach vs a pragmatic approach. It's important to do both, but individuals should call out when they are discussing something that is practiced vs preached.
To reference my other comment. This thread is about the nuance of if a dependency on a shared software repository means you are a microservice or not. I'm saying it's immaterial to the definition.
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.
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.
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.
Fair enough, which is why I called out my assumption:).
I'm referring to the all hands on deck nature of responding to security issues not the best practice. For many, the NPM issue was an all hands on deck.
You have not been in the field very long than I presume? There's multiple per year that require all hands on deck depending on your tech stack. Just look at the recent NPM supply chain attacks.
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.
I disagree. Both can be true at the same time. A good design should not point to library-latest in a production setting, it should point to a stable known good version via direct reference, i.e library-1.0.0-stable.
However, the world we live in, people choose pointing to latest, to avoid manual work and trust other teams did the right diligence when updating to the latest version.
You can point to a stable version in the model I described and still be distributed and a micro service, while depending on a shared service or repository.
I think your point while valid, it is probably a lot more nuanced. From the post it's more akin to an Amazon shared build and deployment system than "every library update needs to redeploy every time scenario".
It's likely there's a single source of truth where you pull libraries or shared resources from, when team A wants to update the pointer to library-latest to 2.0 but the current reference of library-latest is still 1.0, everyone needs to migrate off of it otherwise things will break due to backwards compatibility or whatever.
Likewise, if there's a -need- to remove a version for a vulnerability or what have you, then everyone needs to redeploy, sure, but the centralized benefit of this likely outweighs the security cost and complexity of tracking the patching and deployment process for each and every service.
I would say those systems -are- and likely would be classified as micro services but from a cost and ease perspective operate within a shared services environment. I don't think it's fair to consider this style of design decision as a distributed monolith.
By that level of logic, having a singular business entity vs 140 individual business entities for each service would mean it's a distributed monolith.
I'm putting a bunch of security tools / data feeds together as a service. The goal is to help teams and individuals run scans/analysis/security project management for "freemium" (certain number of scans/projects for free each month, haven't locked in on how it'll pan out fully $$ wise).
I want to help lower the technical hurdles to running and maintaining security tools for teams and individuals. There are a ton of great open source tools out there, most people either don't know or don't have the time to do a technical deep dive into each. So I'm adding utilities and tools by the day to the platform.
Likewise, there's a built in expert platform for you to get help on your security problems built into the system. (Currently an expert team consisting of [me]). Longer term, I'm working on some AI plugins to help alert on CVEs custom to you, generate automated scans, and some other fun stuff.
History doesn't repeat itself, but it rhymes. Callbacks to the infrastructure laid out during dotcom bubble, i.e Cisco, and all of the networking infrastructure. Likewise, internal memos at Oracle indicate they're losing money on their hardware. Anecdotal and hand wavy; but there are plenty of signals out there that it won't pay off. I'm not arguing one way or the other, but there are plenty of arguments for it to not succeed in a way that's required to justify the mind boggling growth we've been experiencing.
I'm putting a bunch of security tools / data feeds together as a service. The goal is to help teams and individuals run scans/analysis/security project management for "freemium" (certain number of scans/projects for free each month, haven't locked in on how it'll pan out fully $$ wise).
I want to help lower the technical hurdles to running and maintaining security tools for teams and individuals. There are a ton of great open source tools out there, most people either don't know or don't have the time to do a technical deep dive into each. So I'm adding utilities and tools by the day to the platform.
Likewise, there's a built in expert platform for you to get help on your security problems built into the system. (Currently an expert team consisting of [me]). Longer term, I'm working on some AI plugins to help alert on CVEs custom to you, generate automated scans, and some other fun stuff.