I didn’t see this coming and I think it’s funny, so I decided to post it here.

  • billwashere@lemmy.world
    link
    fedilink
    English
    arrow-up
    7
    ·
    1 day ago

    Announcing FemtoServices™ - One Packet at a Time!

    In an era of bloated bandwidth and endless data streams, today we proudly unveil a groundbreaking approach to networking: FemtoServices™ – Connectivity, one Ethernet packet at a time!

    • zlatko@programming.dev
      link
      fedilink
      arrow-up
      3
      ·
      22 hours ago

      (Not to be confused with our premium product, ParticleServices, which just shoot neutrinos around one by one.)

  • sirdorius@programming.dev
    link
    fedilink
    arrow-up
    10
    ·
    1 day ago

    I was going to write that every function should be a service as sarcasm, then I realized that’s exactly what this article is proposing. Now I’m not even sure how to make a more ridiculous proposal than this.

  • PieMePlenty@lemmy.world
    link
    fedilink
    arrow-up
    6
    ·
    1 day ago

    Cant wait to set up a docker container for a service which takes a string input and transforms it into a number as the output. Full logging, its own certificate for encryption of course, 5 page config options and of course documentation. Now, you want to add two numbers together? You got the addition service set up right?

  • xmunk@sh.itjust.works
    link
    fedilink
    arrow-up
    7
    ·
    2 days ago

    Nano services are microservices after your company realizes monoliths are much easier to maintain and relabels their monoliths as microservices.

    Unironically. I’d put a significant wager down on that being the source of this term.

  • billwashere@lemmy.world
    link
    fedilink
    English
    arrow-up
    1
    ·
    1 day ago

    I’m trying to understand how this is different than a concept I learned in computer science in the late 80s/early 90s called RPCs (remote procedure calls). My senior project in college used these. Yes I’m old and this was 35 years ago.

    • barsoap@lemm.ee
      link
      fedilink
      arrow-up
      1
      ·
      edit-2
      4 hours ago

      Microservice architectures are ad hoc, informally-specified, bug-ridden, slow, implementations of Erlang, implemented by people who think that “actor model” has something to do with Hollywood.

  • thesmokingman@programming.dev
    link
    fedilink
    arrow-up
    1
    ·
    2 days ago

    This is just distributed functions, right? This has been a thing for years. AWS Lambda, Azure Functions, GCP Cloud Functions, and so on. Not everything that uses these is built on a distributed functions model but a fuck ton of enterprises have been doing this for years.

  • quantum services

    take your source code and put each character in its own docker container

    this gives you the absolute peak of scalability and agility as every quantum of your application is decoupled from the others and can be deployed or scaled independently

    implementing, operating and debugging this architecture is left as an exercise for the reader

    that will be $250,000 kthx

  • tyler@programming.dev
    link
    fedilink
    arrow-up
    0
    ·
    2 days ago

    we’ve been using nano-services for the past 6 months or so. Two different reasons. A codebase we absorbed when a different team was dissolved had a bunch of them, all part of AWS AppSync functions. I hate it. It’s incredibly hard to parse and understand what is going on because every single thing is a single function and they all call each other in different ways. Very confusing.

    But the second way we implemented ourselves and it’s going very well. We started using AWS Step Functions and it allows building very decoupled systems by piecing together much larger pieces. It’s honestly a joy to use and incredibly easy to debug. Hardest part is testing, but once it’s working it seems very stable. But sometimes you need to do something to transform data to piece together these larger systems. That’s where ‘nano-services’ come in. Essentially they’re just small ruby, python, js lambdas that are stuck into the middle of a step function flow in order to do more complex data transformation to pass it to the next node in the flow. When I say small I mean one of the functions we have is just this

    def handler(event:, context:)
      if event['errorType']
        clazz = Object.const_set event['errorType'], Class.new(StandardError)
        raise clazz.new.exception, event['errorMessage']
      end
      event
    end
    

    to map a service that doesn’t fail with a 4xx http code to one that does fail with a 4xx http code.

    You could argue this is a complete waste of resources, but it allows us to keep using that other service without any modifications. All the other services that depend on that service that maps its own error types can keep working the way they want. And if we ever do update that service and all its dependencies, now ‘fixing’ the workflow is literally as simple as just deleting the node and the ‘nano-service’ to go along with it.

    I should note that the article is about the first thing I discussed, the terrible codebase. Please don’t use nano-services like that, it’s literally one of the worst codebases I’ve ever touched and no joke, it’s less than 2 years old.

      • tyler@programming.dev
        link
        fedilink
        arrow-up
        0
        ·
        1 day ago

        You can write your glue nano-service in c/c++ if you want, it’s just that: glue. It doesn’t matter as long as you don’t need to change the original services which also can be written in whatever you want. Ruby, Python, JS just work out of the box with aws lambda and you don’t really have to maintain them or any sort of build infra so it allows for very little maintenance or upkeep cost. You don’t really test these glue lambdas either.

        • Valmond@lemmy.world
          link
          fedilink
          arrow-up
          0
          ·
          1 day ago

          Things won’t be simpler just because you cut everything up in tiny tiny pieces (I mean it will be easier because it solves some surface level problem right now, pushing the real problem down the road), it creates a complexity of its own.