Microservices vs Nanoservices: Weighing Framework Options
Over the years, software development moved away from traditional monolithic architectures, addressing its complexities with tightly coupled, interconnected code. This resulted in the adoption of microservices, efficient cloud-native approaches that enable distributed computing through multiple, smaller services.
Since microservices have become mainstream, in the last several years, nanoservices evolved as another pattern that was designed mostly to overcome complexities found with microservices. Essentially, nanoservices divide the services further to bring additional efficiency.
This article outlines how developing smaller components to build an application is a preferred approach, so I will:
Due to their elemental design, monolithic applications have a few serious challenges:
When monolith applications are mature, introducing the latest technologies or adopting enhanced frameworks comes with a lot of intricacies. These obstacles are not limited to the code-level integration. Testing and deployment are additionally challenging.
Besides, an entire project to rewrite the whole application is often time-consuming and highly risky.
(Learn about the complexities of app modernization and code refactoring.)
Microservices were constructed to:
A microservice fragments an application into an assembly of multiple loosely coupled services. Typically, microservices are:
Each of these services has its own separate processes and is designed to function independently without sharing resources in order to avoid conflicts.
A typical illustration shows how a central, multi-tier framework of a monolith differs from a microservices architecture with distributed services.
(Compare microservice architecture to monolithic architecture.)
Microservices are usually contained inside cloud-based containers that communicate with other services through web APIs. Such APIs act as messaging queues that respond to incoming events such as, user interface, invoking other services, accepting data, etc.
Due to their distributed model, microservices are developed and maintained without impacting other services. This essentially also aids a DevOps model by allowing:
(See how microservices and APIs differ but work together.)
The component-based design of a microservice framework offers multiple benefits, including:
The basic difference between the two frameworks is that nanoservices are considered smaller siblings of microservices. Nanoservices are designed to perform a single function, whose output is exposed through a specific API endpoint (command).
Nanoservices are fully discoverable among each other. Each one can link with other services to perform additional actions and extend functionality.
By design, nanoservices are:
Nanoservices are considered more efficient than microservices, particularly due to:
The illustration below highlights an interesting use-case of how the BBC website uses 1,000s of nanoservices to render dynamic web pages. Each service functions to feed into a specific component of the webpage, such as:
A high-level nanoservice architecture of BBC’s site outlines how multiple, smaller services function in conjunction to deliver content of a webpage:
Nanoservices are particularly beneficial due to their ease of encapsulation of specific functions. This brings an application framework with these advantages:
While microservices and nanoservices are significant enhancements over a monolith, they don’t come without challenges.
Certain use cases also suggest that developing an application by combining smaller services increases complexity in a number of ways, including:
At the first glance, increased isolation within nanoservices may seem tempting. But, widespread use of nanoservices could lead to a whole host of problems and increased complexities.
More so, for decently complex applications, adopting a nanoservice framework may actually overutilize resources and scale up manual efforts—something that DevOps practices want to minimize.
(Prepare for other common microservice challenges.)
Both microservices and nanoservices have evolved to bring efficiency over traditional architectures, by distributing complex application codes into multiple smaller services within a cloud-native setup.
With that in mind, the important considerations of choosing the best framework eventually come down to two key components:
Compared to nanoservices, microservices are an established and well-known design approach that can operate with a wide range of technologies.
There are several successful use-cases of major industry players—Netflix and AWS—who already use microservice architecture to offer several state-of-the-art services. That means microservices have a plethora of resources and groups to support learning or maturity microservices strategy.
Microservices are usually a good fit for:
With that in mind, it is equally important to note that microservices are not suited for every application type. Certain use cases highlight that, without thorough due-diligence and efficient planning, random expansion of services may end up making the framework as big and cumbersome as a monolithic architecture.
(Follow microservice best practices from planning all the way through maintenance.)
Nanoservices are much newer. Proven use cases of their full potential are yet to be discovered. While they are smaller, flexible, more isolated, and functionally focused, there are still unknowns on:
As a result, there are conflicting schools of thought around how and when to use microservices.
First, the mere nature of nanoservices poses the question as to whether they are secured from attack vectors when used extensively in an application.
Some also consider nanoservices to be an anti-pattern due to their fragmented functionality. This is known to cause maintenance overhead to exceed the value of the framework’s benefits.
As nanoservices are still in their infancy, conservative and large organizations usually avoid them (for now), mostly due to the framework’s uncertain support for scalability. For those who adopt it, one best practice of using the framework is:
Avoid nanoservices if its use complicates the system that it’s meant to simplify.
Whether to choose nanoservices over microservices, or vice-versa, will always differ with use-cases. The end goal, however, remains the same: to adopt the right architecture that aids automation and helps develop applications that are resilient, scalable, and secured.
