Picoservice bruhahaha
Sir, I think you have consumed too many microservices for today and should head for home.

I’ve been busy, as again, an haven’t had a good chance to continue on my µ²services series. I’m planning to discuss more of the potential implications of technology development meeting microservice architecture models. But this post isn’t about that.

Instead I want to comment a bit on the nano/picoservice commentary found over the net. For example:

@michaelneale I thought we agreed that was the hip new marketing term for functions?

— Mark Wotton (@mwotton) February 3, 2015

I absolutely love these comments!! I absolutely think that at least 95% of use of “microservice” is just hot air. However if you take “microsizing” as an end goal itself and extrapolate to smaller and smaller scales you get nanoservices and picoservices on an function and instruction level granularity:

1k smaller microservice is nanoservice; exposes assembly instructions via HTTP+JSON; pikoservices become inadressable due to quantum effects

— Tomas Petricek (@tomaspetricek) December 3, 2014

Tomas of course is making a point of this absurdity.

What I think what microservices (and by extension, nano and pico too) are: Microservices are externally loosely coupled but internally tightly coupled functional service components.

Although it is not evident from this definition, most value from microservice architecture actually comes from organizational improvement by making the underlying loose-tight coupling explicit in development, management and operations. This also means that the true potential value of a microservice architecture is difficult to determine as it is more dependent on the development organization itself than in the actual software they are developing.

In the end you must ask yourself

It just depends. Depends on you, your team, your resources, your processes, your choice of technology, everything. Investigate and decide yourself. Don’t be a slave to backward causality.

So to clarify for my imaginary pundit what I mean and don’t mean when talking about micro- or µ²services:

• Replacing function calls with “services” is just idiotic. Plainly and simply idiotic and anyone who claims anything remotely similar is a plain walking and talking bullshit machine.

  This same thought experiment was done in reality with remote procedure calls (RPC) already a decade ago and the result is local and remote operations are fundamentally different. You can not create a distributed system based on “function invocation” pattern.

  A call to a library routine should now and in the future be a local function call².

• I use or at least used to use the term µ²services to emphasise that the trend of shrinking containers may have (some unforeseen) consequences on how we develop and use microservices.

  Perhaps I should just stop using that term instead.

Anyway, check out some of these cool posts and sites: A VM for every URL by Magnus Skjegstad, Microservice Classification Model Proposal by Daniel Bryant and of course, the ALL CAPS AS A SERVICE.

P.S. All of the tweets above were written clearly with tongue in cheek. Yet, the fact that people are feeling the need to dismiss “picoservices” for me is a sign that the idea of shrinking services as a goal itself is floating around — and since I’ve been writing about µ²services I want to make it clear that that particular model of sub-microservices is not what I am talking about.