> we have replaced it with a behemoth with precisely the same flaws - but magnified tenfold. OpenAPI schemas replace type-checkers,
First, OpenAPI schemes aren't a replacement for type checkers, they allow for tooling to be built around the scheme and even generated code to be created instead of bespoke implementations for every client language. You still should do input (and even response) validation.
> docker compose replaces service factories,
Compose is a self-documenting set of services to run together in predictable ways in containerized environments.
> Kubernetes replaces the event loop.
K8s expands this to more complex orchestration across multiple systems.
> Every call across components acrues failure modes,
You can containerize fairly monolithic code pretty easily... especially with related services that run as a set... nothing requires micro services or complex orchestration in practice. I think of it as a set of predictable extensions to 12-factor apps.
> requires a slow march through (de)serialisation libraries, a long trek through the kernel’s scheduler. A TLB cache invalidation here, a socket poll there. Perhaps a sneaky HTTP request to localhost for desert.
This is how all client-server systems work... there's some level of (de)serialization involved and a system of coordination between clients a servers... nothing special here. HTTP just has the benefits of being human readable and standardized with tooling for security, authentication, proxies, caching, etc as wrappers and add-ons.
These have nothing to do with OOP or not. For that matter, OOP itself isn't necessarily a panacea... I've always favored utility/worker processes (even in a class based language) separated from state or storage objects that don't have internalized objects... exceptions maybe for attribute markup for type validation if the language supports it.
The rant as a whole doesn't make a lot of sense... if you want to rail against the complexities of micro-services and orchestration, which trades in-application complexity for deployment/orchestration complexity, that's a fair argument to make... especially when the same people are responsible for both. But that isn't an OOP thing at all.
First, OpenAPI schemes aren't a replacement for type checkers, they allow for tooling to be built around the scheme and even generated code to be created instead of bespoke implementations for every client language. You still should do input (and even response) validation.
> docker compose replaces service factories,
Compose is a self-documenting set of services to run together in predictable ways in containerized environments.
> Kubernetes replaces the event loop.
K8s expands this to more complex orchestration across multiple systems.
> Every call across components acrues failure modes,
You can containerize fairly monolithic code pretty easily... especially with related services that run as a set... nothing requires micro services or complex orchestration in practice. I think of it as a set of predictable extensions to 12-factor apps.
> requires a slow march through (de)serialisation libraries, a long trek through the kernel’s scheduler. A TLB cache invalidation here, a socket poll there. Perhaps a sneaky HTTP request to localhost for desert.
This is how all client-server systems work... there's some level of (de)serialization involved and a system of coordination between clients a servers... nothing special here. HTTP just has the benefits of being human readable and standardized with tooling for security, authentication, proxies, caching, etc as wrappers and add-ons.
These have nothing to do with OOP or not. For that matter, OOP itself isn't necessarily a panacea... I've always favored utility/worker processes (even in a class based language) separated from state or storage objects that don't have internalized objects... exceptions maybe for attribute markup for type validation if the language supports it.
The rant as a whole doesn't make a lot of sense... if you want to rail against the complexities of micro-services and orchestration, which trades in-application complexity for deployment/orchestration complexity, that's a fair argument to make... especially when the same people are responsible for both. But that isn't an OOP thing at all.