Until recently, every code development was accompanied with overheads of maintaining orchestrations, deployments, and so on. With the evolution in IT, developers desire to eliminate waste and focus on specific business objectives.
In a serverless environment, developers only stay concerned with solutions and the monitoring of usage. The business saves on costs by paying for computation cycles consumed and not for the idle time of system. A serverless system lowers the total cost of maintaining your apps, enabling you to build more logic faster. In a serverless computing model, the cloud provider manages starting and stopping of the container of the service as necessary to serve requests and the business need not pay for the virtual machines on which the services execute.
The growing requirement of developing Microservices that are much smaller and highly focused has given rise to a new breed of services called Nanoservices. Nanoservices can either be triggered by specific events, or be configured to run behind an API management platform to expose it as a REST API endpoint.
Nanoservices share certain commonalities with Microservices which also form the definition boundary of Nanoservices:
- Nanoservices generally run in a lesser isolation than Microservices, which means that they can be more densely packaged than Microservices. However, Nanoservices are independently deployable just like Microservices are.
- Nanoservices are more finely grained than Microservices. A Nanoservice may contain just a few lines of code, which perform a very specific task for example, send an email on successful registration of a user.
- The execution environment of Nanoservices is more efficient than that of Microservices. The Nanoservices execution environment is cognizant of activation and deactivation of Nanoservices and its resource consumption and can therefore dynamically allocate and deallocate resources.
The smaller size of Nanoservices affects the architecture of solution. Nanoservices decrease the deployment risk due to smaller size of deployment units and can help deliver even more understandable and replaceable services. On the other hand, the complexity of deployment increases significantly as a bounded context, which earlier used to contain one or a couple of Microservices will now contain many Nanoservices each of which implement a very narrow functionality.
Isolation is not a clear demarcation between Microservices and Nanoservices as Microservices can be configured to share the same virtual machine while Nanoservices can be configured to run on independent virtual machines. Therefore, Microservices can be said to be a coarser form of Nanoservices.
Just like isolation, minimum size is also not a clear demarcation between Microservices and Nanoservices. For instance, in order to implement Command Query Responsibility Segregation (CQRS) in a solution, a Microservice may only be responsible for writing a certain type of data and another Microservice may be responsible for reading the same type of data, leading to Microservices have a small scope just like Nanoservices.