Micro Service vs Nano Service?

While Jeroen's answer gets close to the gist of the differences between SOA, microservices, and nanoservices, I think it goes slightly awry at the end.

So SOA breaks system functionality down according to business capabilities (e.g. Jeroen's OrderService, or perhaps a CustomerService). Services often call other services, so they very much involve the concept of a network of services with dependencies between themselves, and they also embody the concept of service composition, where some services essentially aggregate other services.

Microservices are very similar and potentially align and implement SOA services, which is why people like Mark Little saw them as the same as SOA. However, they also tend to exhibit specific implementation details that were never clearly articulated in the SOA literature. For example, they're frequently scoped or sized to DDD BoundedContexts, they should use their own DB for storage, and they should publish data changes to subscribers.

Nano-services then have a narrower scope than microservices, and are generally at the functional level, along the lines of what's currently being implmented in serverless architectures. You could therefore compose a microservice from nanoservices.

So following the OrderService example:

• At the top level we have the OrderService, which is the business focused service for handling orders. It is an SOA-level service, but it consists of 3 individual services.

• OrderManagementService, which is responsible for creating and managing an order's state. It is a microservice and has it's own data store, it could also be considered an SOA service, but it has multiple endpoints (e.g. CreateOrder, CloseOrder etc) and is not a nano-service.

• CustomerManagementService, which is responsible for handling the customer details. It is a microservice, has it's own data store, and could also be considered an SOA service, but it has multiple endpoints (e.g. RegisterCustomer, DeleteCustomer etc) and is not a nano-service.

• OrderProcessingService, which is responsible for handling the Order workflow, orchestrating calls to various external services, such as the OrderManagementService and CustomerManagementService, and is also a microservice and an SOA service. It is not a nano-service.

Now to nanoservices. The team implementing the CustomerManagementService decide they need a common method to validate customer email addresses, and they implement it as a ValidateEmailAddressService, which they make available via a RESTful endpoint. This is a nanoservice, and can best be thought of a single function made available as a service.

Whether or not it's a good idea to provide such functions as services is up for debate, although in the above example I think calling it an anti-pattern is understandable. However, there's an argument that says nanoservices have a place in serverless architectures, so the debate might rage on.

A SOA-service is all about componentization on service level (constructed around a business capability). A Microservice is all about functional composition on service level (input -> processing -> output). A Nanoservice is even smaller than a microservice, and therefore doesn't make any sense.

If you would draw a parallel between services and programming, then SOA can be seen as the component, Microservice as the method and a nanoservice as related lines of code in a method.

An OrderService is a SOA-service that is responsible for order handling, basically a state machine for the lifetime of an order. Composing an confirmation e-mail is a microservice. Getting data for the confirmation e-mail is a nanoservice.