4 ms·

After quick look on code it looks to me more like nano services than micro services and nano services are basically antipattern. I would never host that and exp

After quick look on code it looks to me more like nano services than micro services and nano services are basically antipattern. I would never host that and expect most of this functionality to be library/package to programing language I use for my projects.

asim 4y ago
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.
- superfist 4y ago
  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.
  - asim 4y ago
    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 https://en.wikipedia.org/wiki/Snowflake_ID
    - superfist 4y ago
      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.
      - asim 4y ago
        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.
        superfist 4y ago
        All of that is basically standard library over HTTP
        asim 4y ago
        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.
        krapp 4y ago
        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.
jmartrican 4y ago
I think nano services follow the "Unix Philosophy". https://en.wikipedia.org/wiki/Unix_philosophy https://en.wikipedia.org/wiki/Unix_philosophy It would be cool if it were possible to pipe the output of one these services into the input of another. Like how pipes work in Unix.
- asim 4y ago
  I would love to be able to do that as well. I always thought this would be some sort of service composition or batch query model. Both Micro and M3O have CLI tools which can enable that so technically you can do something like that but natively would be WAY better.
  - acjohnson55 4y ago
    My friend created something like this at kodou.io.
- tiagod 4y ago
  I built something like this using rabbitmq for automating delivery of online documents (taxes) for an accounting company. I had a queue per function, a DAG defining the workflow, and the tasks themselves would know who to forward the result to. Different libraries of tasks ran in different environments with different permissions (filesystem access ran on a windows server, for example, to access the file shares), only browsers had Internet access (and only to certain domains). I eventually switched to a code monolith running in a segmented way with temporal.io, where I have libraries of activities which run in different nodes. You might be interested in their product.

asim 4y ago

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.

superfist 4y ago
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.
- asim 4y ago
  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 https://en.wikipedia.org/wiki/Snowflake_ID
  - superfist 4y ago
    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.
    - asim 4y ago
      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.
      - superfist 4y ago
        All of that is basically standard library over HTTP
        asim 4y ago
        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.
        krapp 4y ago
        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.

jmartrican 4y ago

I think nano services follow the "Unix Philosophy". https://en.wikipedia.org/wiki/Unix_philosophy https://en.wikipedia.org/wiki/Unix_philosophy It would be cool if it were possible to pipe the output of one these services into the input of another. Like how pipes work in Unix.

asim 4y ago
I would love to be able to do that as well. I always thought this would be some sort of service composition or batch query model. Both Micro and M3O have CLI tools which can enable that so technically you can do something like that but natively would be WAY better.
- acjohnson55 4y ago
  My friend created something like this at kodou.io.
tiagod 4y ago
I built something like this using rabbitmq for automating delivery of online documents (taxes) for an accounting company. I had a queue per function, a DAG defining the workflow, and the tasks themselves would know who to forward the result to. Different libraries of tasks ran in different environments with different permissions (filesystem access ran on a windows server, for example, to access the file shares), only browsers had Internet access (and only to certain domains). I eventually switched to a code monolith running in a segmented way with temporal.io, where I have libraries of activities which run in different nodes. You might be interested in their product.