[caseyross]

The real world is infinitely more standardized than virtual ones.

Physical space itself enforces a set of laws that make any two objects "compatible", regardless of any established interoperability agreements.

However, in software, there is no such constraint. Two randomly chosen software components are, in general, less composable than a chair and a galaxy.

This is the core reason why we have only been able to achieve interoperability in very specific domains. It's not because we're bad at design or planning --- it's because the space of ideas itself is simply so overwhelmingly large that it takes time and incredible coordination to get anything like pre-built IKEA blocks which fit together naturally.

[oaiey]

Yeah, but it does not have to.

There are for example products like keycloak. OpenID/OAuth2/Token/Security IdP in a box.

Why there is not ticket system in a box? Yeah, we all know Jira and friends, but these are products not building blocks.

Another angle is: Why the hack does everyone rewrite their microservice foundation. Inbox/Outbox/Worker Queue/Throtteling/tracing/..... What happened to the application servers of the past?

I am a big supporter of that narrative. Why do I need to write more than my dedicated business logic and wire up some UI (and do not get me started on UI space).

IMHO, this can be a real differentiator for the language platforms. Ruby has parts of it, but is still far of.

[procaryote]

One reason might be that microservice foundations tend to become frameworks rather than building blocks.

Auth is a building block you can slot into your system and the shape of the hole isn't all that complex. A framework is something you need to slot your system into, and it has a lot of twists and turns so it ends up restricting how you do all the other things.

There are lots of microservice-foundation-related building blocks. E.g. I use a library somewhere that just does circuit-breaking. I slot that into my app rather than the other way around, and if I wanted to replace it, it's a fairly isolated thing. I don't use any frameworks for it though

Frameworks also tend to grow more and more complex as they evolve. If I as a user want a different auth for example, that needs to be supported by the framework. Over time, all things become pluggable and configurable, until at some point it's complex enough that someone restarts the process, or makes an opinionated spin of the framework.

[tga]

_Every_ ticket system with an API (all of them) is a ticket system in a box. You can add that functionality to your application by talking to the API directly.

I think what you are thinking about is a standard API for ticket systems, that would allow you to transparently swap them. Unlike authentication, nobody has bothered to standardize something like that because ticket systems are more varied, not as often integrated into other platforms, and even more rarely replaced.

[Traubenfuchs]

> Inbox/Outbox/Worker Queue/Throtteling/tracing/

There exist stable solutions for all of this, at least in the java world. Spring Boot and the exhaustive Spring Boot auto configurations are all about this…

> What happened to the application servers of the past?

It‘s no called kubernetes. With the caveat of it not having first class integration for any language, but second class integration for all languages.

[Mikhail_Edoshin]

I would disagree. Software has certain constraints, or, for the search of a better concept, certain nature. E.g. I myself would say that one side of it is that you always have a very small tool that is supposed to operate on much larger data and can only manage this by doing many-many steps that have to be perfectly orchestrated. This is true to the low-level CPU, but as we move higher we start inventing things and can invent something that is rather different. E.g. on certain levels it may convincingly look that we send a bunch of elves against a bunch of orks. There is a multitude of such concepts, they are vastly different and, of course, incompatible, and it may look that they're all worth each other and what we choose is a matter of preference. Yet among them there is is a single concept that is special, because it is true to the nature of software; or is closer to that truth than others. It is not to be invented, but to be discovered. If we discover it, we will solve the problem of compatibility.

[viraptor]

This doesn't match reality as soon as you start working with things that actually deal with laws and taxation. If physical space was standardised, we wouldn't have 366226723 implementations of asset management systems. Also compatibility depends extremely on the laws - is this chair and that chair the same? Not for taxation purposes because one is rented and the other is still depreciating, so you absolutely cannot say you have 2 of those chairs in the office.

[hulitu]

> It's not because we're bad at design or planning

No, it is, code writers are bad at design, testing and debuging. That's why LLMs are so popular: just throw together some code, see if it compiles.

How many (between them) incompatible GTK or QT versions are there ? Why someone has to come every few years with a new graphics library ? Is the JPEG, TIFF or PNG standard changed ? And who thinks that adding layers of abstractions solve problems ?

[mejutoco]

I think in a way the OS is the "physical space" of software. This matches common composable interfaces like lines of text, files or http calls (rest).