On to Nano-Services
A few weeks ago, I had the pleasure of meeting Pini Reznik, CTO of container consulting firm Container Solutions, in Berlin. It may appear strange that an independent consultant who spends a lot of time helping companies with development and infrastructure strategies, much of which over the last several years has involved containers, would tout another consulting firm's services. There is, however, plenty of work to do for all of us, and I am grateful for the thoughts and ideas they shared. Perhaps we will collaborate.
The conversations we had will provide the kernels (unikernels?) of several articles here.
Pini shared the following graphic, providing a (limited) summary of application+infrastructure development trends. Image courtesy of, reprinted with permission of, and copyright Container Solutions Ltd, 2016.
For the purposes of today's article, we will focus on the trends on the left-hand-side of the graphic.
The two fascinating parts to me in the graphic are:
- It ties together developments in application architecture, development processes and infrastructure;
- It attempts to show how developments in one area enable developments in another, and so on. Advancements are neither independent nor unidirectional, but mutually reinforcing.
At one point, I said to Pini, half in jest, "so what is the next marketing term after micro-services? Nano-services??" Turns out he and his team had been thinking exactly that.
Calling tiny (smaller than micro) services, composed of one or a few functions, a "nano-services" probably is a better term than serverless. In both micro-services running in an explicit container and functions running in a more hidden one, there is a server, and it is abstracted away. The only differences are: the level and amount of abstraction; and the size of the service. However, serverless is more likely to stick as a catchy name than "vmless" or "instanceless" ever would have been.
I also appreciate that they put "unikernels" with a question mark. I, too, question unikernels outside of a narrow range, for two simple reasons:
- Containers may be sufficient, with future advancements, to fully isolate services/processes.
- No one really knows what will succeed in the market until it happens. Even with ironclad rock-solid arguments, a little humility goes a long way.
Nonetheless, I do believe that given the constant back-and-forth between application architectures, processes and infrastructure, "nano-services" or "serverless" (or Simon Wardley's term Framework-as-a-Service/FaaS) will lead to some material advancement in infrastructure, just as containers enabled micro-services and then serverless; rarely is it a one-way process of evolution.
Of course, I have issues with serverless, primarily around packaging, as highlighted here, as well as the mostly closed-source/proprietary nature of Lambda and others. OpenWhisk and Open Lambda may help.
Will nano-services be serverless? Will they be something else entirely? Will they have a better name? How will the packaging issues be resolved? What about networking? How about the open source question?
For most companies, micro-services and containers are sufficiently leading-edge. For newer companies attempting to lay a longer-term path with the advantage of starting in a greenfield, for CTOs and architects at established companies who need to begin clearing the path in the woods, these are important questions.