When you’re attempting to break up monolith, one of the big difficulties is that it can be hard to find good, coherent microservices – ones which are logically coherent and map to a clear bounded context, but aren’t so large that they’re more mega-services than microservices.

In 2016 there’s a new possibility: go further, splitting the monolith into many separate “service” level functions, each of which is deployed separately (and can be scaled separately). For example the GetOrders function would be separate from the CreateOrder function, which is separate from the DeleteOrder function. (This example comes from my notes from the “Serverless meets SaaS: The Ultimate Match” session at QCon SF 2016, which was based on Amazon Lambda.)

Since these functions are much smaller than microservices, I’ve begun thinking of them as “nanofunctions”. Amazon Lambda is not the only company entering this space, just the one I’m most familiar with as of today.

Amazon Lambda’s catch phrase is “serverless compute”. “Serverless” is excessive hype IMHO. There most certainly is a server. The point is that you don’t set it up, configure it, or worry about it in general – you pay someone else to do that for you. “Function as a Service” (FaaS) is a much more descriptive name, but unfortunately not as catchy.

In this model each “service” level function is deployed separately. This is a very different approach from microservices. With microservices you strive to avoid sharing storage such as database tables, because that results in integration at the database level and there is plenty of industry experience of how painful that can become.

With these “nanofunctions” there’s no practical way to avoid integration at the storage level. GetOrders has to somehow read the data stored by CreateOrder or it can’t do its job. This is where it starts to feel like uncharted territory – you must have to keep track somehow of which nanofunctions are sharing storage, and keep your docs up to date, or you could have unpleasant surprises in your future. Maybe it’s an environment where you just don’t make a change without asking what other components will be affected? Maybe instead of one team owning a microservice you have one team that owns a group of nanofunctions, whether it’s a logically coherent group or one that was arbitrarily chosen?

It’s early days yet for this idea. I’m finding it highly intriguing.