What size for your microservices?

The “microservice” term is going through a big hype. But beyond this trendy term which reflects the need for small (or very small) services, I thought it would be interesting to discuss what the normal microservices size are.

Read how APIs and microservices are changing the way people think.

Microservices size

Services implement specific application functionality or provide access to data. We can classify them in three microservices size categories:

• Microservices: fine-grained services that implement individual features.
  • Ex: price, availability and shipping feature on an Amazon.com
• Miniservices: coarse-grained services (of a larger size than microservices). They implement what we call “domain-level” functionality. A domain is a family of related features.
  • Ex: shopping cart domain calling the price, availability and shipping microservices mentioned above.
• Macroservices: large-grained services, thus bigger than miniservices and microservices. They implement entire business capabilities.
  • Ex: ordering business capability using different miniservices, such as the shopping cart one.

Microservices, miniservices and macroservices can run on-premises or on the Cloud. They can be built by internal teams or exposed by 3rd parties, such as external providers or partners.
When you design your architecture, it’s important to define the granularity of your services. Keep in mind that agility is directly tied to the size of your services. If you need to offer flexibility around a specific service, build a microservice; if you want to expose a well-defined capability with no room for improvisation, build a macroservice. As all is about digitizing Customer Experience, it’s paramount to take the best approach.

Micro/Mini/Macro services are designed to be used by multiple applications, there is no “ownership” of a service by an application. Take the example of a service that abstracts a database (AWS RDS for example). The application no longer has its own embedded database but consumes a service that stores and retrieves information.

In a digital world, all those services should their functionality via APIs. The most widely used format today is REST APIs, as traditional SOAP APIs (aka SOAP Web Services) are progressively being replaced by REST APIs. REST APIs are lightweight and offer different HTTP methods to interact with their underlying service (GET/POST/PUT/DELETE).

As those APIs provide access to the services, it would be tempting to call them micro APIs, mini APIs and macro APIs. But we prefer to name them “outer APIs” and “inner APIs,” depending on whether they are exposing capabilities to other internal systems (or services) or are meant to be directly consumed by apps. The layer between outer APIs and inner APIs is called API mediation layer.

This API mediation layer needs to be properly managed with an enterprise-grade API Management solution that can address the following needs: API Catalog, security, performance, authorizations, API versioning.