I served. While in basic training, the drill sergeants taught us why we salute differently than other countries (probably apocryphal) - because we've "never lost a war". I'm cheeky now and I was then, so I asked about vietnam.
"Police Action" came the terse reply. "We don't talk about that one."
Course by then I'd already signed on the dotted, so...
Yes, you’re describing a distributed monolith. Microservices are independent, with nothing shared. They define a public interface and that’s it, that’s the entire exposed surface area. You will need to do major version bumps sometimes, when there are backwards incompatible changes to make, but these are rare.
The logical problem you’re running into is exactly why microservices are such a bad idea for most businesses. How many businesses can have entirely independent system components?
Almost all “microservice” systems in production are distributed monoliths. Real microservices are incredibly rare.
A mental model for true microservices is something akin to depending on the APIs of Netflix, Hulu, HBO Max and YouTube. They’ll have their own data models, their own versioning cycles and all that you consume is the public interface.
I'm trying to understand what you see as a really independent service with nothing shared.
For instance if company A used one of the GCP logging stack, and company B does the same. GCP updates it's profuct in a way that strongly encourages upgrading within a specific time frame (e.g. price will drastically increase otherwise), so A and B do it mostly at the same time for the same reason.
Are A and B truly independent under your vision ? or are they a company-spanning monolith ?
This Segment team was 3 people and 140 services. Microservices are best at solving org coordination issues where teams step on each other. This is a case of a team stepping on itself.
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.
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.
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.
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.
"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.
> 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.
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.
> 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.
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
Perhaps the perfect time to ask: why are release notes like this on the App Store? Are they a required field and this is the default? Does a popular tool use this value?
Not only nobody reads them, but Apple forces you to translate them into languages even less than nobody read. It'd be an improvement if they only required English text.
"Choose your own update notes adventure! Pick only one: A, B, or C.
A. The holidays are coming up and we've been busy planning a celebration of bug bashes and performance enhancements, so get merry and smash that update button.
B. Shorter days, longer nights, colder temps. You know what helps the Winter blues?
Instant gratification. Tap update, watch that progress bar fill up, and feel the dopamine flow.
C. Whoever made up the mistletoe thing was crazy. You know what's not? Updating your app."
Don't underestimate the effort a software developer will put forth to create mountains of complicated automation and scripts if it allows them to be lazy. And they see no issue with this. So why would they see an issue being accountable for yet another agile cycle.
While I'm morally tempted to do the same, many of the apps guilty of this are the major ones one uses, and as time goes by, I somehow find myself with less and less time on my hands, so I have to be selective with the things I want to do right and proper. Thus, by means of inaction, I indirectly contribute to the circle of enshittification, and there is no stopping it.
I don’t like this article. Irrelevant technical nuance is comingled with a philosophical opposition. The technical issues are all solvable. The free speech argument is foolish too: if limiting who can jerk off to pornography is an issue of free speech, surely so is limiting who can enter a bar and converse with the patrons.
Opposition to ID checks because you believe the internet should be open and free is reasonable but this article twists itself into knots throwing everything at the wall. And it is reasonable to believe it is a free speech issue. But we can’t say, at the same time, that the same arguments don’t apply outside of the internet.
(Convenience stores scan ID, bars scan ID, hotels take copies of passports…)
These are new things, not old things. The idea that stores and bars should be able to record for all eternity the identities of the people who have purchased things from them is just as much of a horror. They can sell that information to anyone.
> hotels take copies of passports…
This is not really a new thing, although it is a fairly new thing (i.e. within the last 40 years, since cheap enough photocopiers.) But it comes from laws about keeping track of who is staying in temporary accommodation, 100 years ago you would have had to sign the register.
I am not that fond of stores scanning my ID data either. I’m over 21, there’s no question about it. Per policy, they’ll have my name and address in some log too, and with my photos and gait on camera and probably my license plates. What does all of that do for me? Are you safer because I am being recorded?
I like the (disputed) comment elsewhere on this page, requiring parents to parent. They aren’t my kids.
If you have the money definitely get yourself a passport card. Stores can’t scan them and they only contain a pointer to personal info in some government database.
The free speech argument is that these ID checks aren't just being applied to porn sites; there's a push to make social media websites (probably the largest hubs of free speech in the modern world) do them too. That's a much bigger deal. It'd be like if you had to show your ID to a police officer in order to enter exit your front door.
I disagree with the parent’s premise (that productivity has any relationship to salary) but Facebook, Amazon etc do pay these famous genius brilliant engineers orders of magnitude more than the faceless engineers toiling away in the code mines. See: the 100 million dollar salaries for famous AI names. And that’s why I disagree with the premise, because these people are not being paid based on their “productivity”.
I regularly try to use various AI tools and I can imagine it is very easy for it to produce 95% of your code. I can also imagine you have 90% more code than you would have had you written it yourself. That’s not necessarily a bad thing, code is a means to an end, and if your business is happy with the outcomes, great, but I’m not sure percentages of code are particularly meaningful.
Every time I try to use AI it produces endless code that I would never have written. I’ve tried updating my instructions to use established dependencies when possible but it seems completely averse.
An argument could be made that a million lines isn’t a problem now that these machines can consume and keep all the context in memory — maybe machines producing concise code is asking for faster horses.
The western view of China’s Internet censorship often flies in the face of reality. A lot of people seem to think China has an impenetrable firewall.
Bypassing internet restrictions in mainland China is a normal part of life for people who want to access the western internet. China is able to censor the Internet effectively because Chinese people are most comfortable using apps that cater directly to Chinese people, through language and culture. The Chinese government has a lot of control over these companies because they’re based are located in China.
The English speaking west is so dependent on the U.S. internet that it is impossible to copy the Chinese model.
Would you rather be attacked by 1,000 wasps or 1 dog? A thousand paper cuts or one light stabbing? Global outages are bad but the choice isn’t global pain vs local pleasure. Local and global both bring pain, with different, complicated tradeoffs.
Cloudflare is down and hundreds of well paid engineers spring into action to resolve the issue. Your server goes down and you can’t get ahold of your Server Person because they’re at a cabin deep in the woods.
It's not "1,000 wasps or 1 dog", it's "1,000 dogs at once, or "1 dog at once, 1,000 different times". Rare but huge and coordinated siege, or a steady and predictable background radiation of small issues.
The latter is easier to handle, easier to fix, and much more suvivable if you do fuck it up a bit. It gives you some leeway to learn from mistakes.
If you make a mistake during the 1000 dog siege, or if you don't have enough guards on standby and ready to go just in case of this rare event, you're just cooked.
I don't quite see how this maps onto the situation. The "1000 dog seige" also was resolved very quickly and transparently, so I would say it's actually better than even one of the "1 dog at once"s.
Perhaps not, but still compared to running your own thing you just sit and wait. No on call rotas to manage and pay for; no root cause analysis meetings after that descend into internal blame.
“A hundred years from now, thanks to the workings of the Inhuman Centipede, I’m known as a deservedly obscure dadaist prose stylist who thought it was cool to stop his books mid-sentence.”
is “Inhuman Centipede” to describe the slop-eating-its-own-tale future we all dread an established term, or an invention of the author? I hope it becomes the term we all use, like slop and clanker.
For those of us writing original words that are consumed by LLMs without our consent, at least we get to be the front of the Inhuman Centipede.
I strongly suspect that the term alludes to "human centipede", which is a dutch horror film and involves the titular centipede literally eating his own shit.
There is also https://en.wikipedia.org/wiki/HumancentiPad (which is almost surely an homage to the movie) which was 2011 and tied in all kinds of tech-aspects like licensing and iPads.
reply