Tech moved in cycles. We come back to the same half-baked ideas every so on, imagine we just discovered the idea and then build more and more technologies on top to try to fix the foundational problems with the concept until something else shiny comes along. A lot of tech work is “there was an old lady who swallowed a fly”.

This is just the Linux way but with… Rest? Seems slow.

What’s next? Femtofunctions

Metaservices.

We already have nanoservices, they’re called functions. If you want a function run on another box, that’s called RPC.

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.

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

Poe’s law strikes again!

This “article” was written by AI, wasn’t it? This is just throwing vague buzzwords around

Planck services

You know what they say: micro services, macro outages.

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.

I think it’s just serverless, right?

Soooooo… Linux with extra steps.