Hacker News Reader

Comment by asim | Hacker News Reader

There are some services that are still singular endpoint you're right e.g SMS. But the goal is to address immediate need and expand on requirements beyond it. No one using SMS has asked for more yet.

Other things are more full fledged e.g a db service that provides a http interface on top of postgres, or the user service with email verification and the app service that does hosting on top of Google cloud run.

View on HN

It is not about number of endpoints - libraries also have multiple "endpoints" and some are used and some are not. It is about reasonable code packaging. Most of those "micro" service just wrap some single purpose libraries and expose them as REST endpoints. That is way they are more like nano services and not micro services. This lead to modern version of "dependency hell" but much more complex becasue now we have to deal with whole class of potential network problems.

Can you point to the ones you're talking about? A lot of the services are actually not that, they're offering simplified API and RPC access to data that's siloed elsewhere or systems that are quite complex to manage. There's some stuff we wrote for fun because writing arduously complex code can be tedious and I enjoy playing around with random things but I wouldn't waste a lot of my time wrapping libraries. OK so an "id" service is a bit like, maybe we don't need that to be an API call but let's say you do and you do want unique IDs distributed across many nodes, that was actually a hard problem solved by stuff like Snowflake [1] and distributed node management like zookeeper.

https://en.wikipedia.org/wiki/Snowflake_ID

Email service, Dns service (64 lines of code), File service, Image service - to name just some of them. Those are essentially little wrappers on standard libraries exposed as REST services.

So in a case like email it's a local shim to sendgrid. What this essentially means is you have one service that's storing your API key and gatekeeping access to sending email rather than all of them doing it independently.

In the DNS case is basically DNS over HTTP which might not be useful to you since you can implement it but to someone who doesn't coslde it's useful.

Image service is storage and serving on top of micro which arguably yea you can do elsewhere and the wrapper to imagemagick you can do yourself but we've found there's a ton of people who just don't want to reimplement this logic.

All of that is basically standard library over HTTP

Why is the standard library not a HTTP call? Maybe all of this stuff ends up in WASM, I don't know, but I just get the feeling like if it was all over a network that's constantly evolving and becoming faster, that we end up with something that looks more like a networked and emergent language. Programming languages are stuck in the old world of compile and run locally, but what if they weren't, what if they were networked and evolutionary.

We already have "standard library as an HTTP call." It's called modern javascript. Having your software depend on an infinite fractal of networked code that can dynamically wreck your shit at any arbitrary moment in time is a bad idea.

> Having your software depend on an infinite fractal of networked code that can dynamically wreck your shit at any arbitrary moment in time is a bad idea.

This is the most succint argument against kubernetes I've heard yet.

What you describe sounds familiar, I believe it was Akka's actor model (https://doc.akka.io/docs/akka/current/typed/guide/actors-int...) that allows actors to run on either the same machine or a different (cluster of) machines, but doing so completely transparently to the developer. Is that something that interests you? It means that the developer doesn't have to think about RPCs or consuming HTTP APIs in the first place.

> Why is the standard library not an HTTP call?

You mean like string concatenation? Come on man. As far as evolution goes, that’s what semantic versioning is for.

Reply on news.ycombinator.com