Some of my client are worried about the differences between services, microservices and APIs, together with approaches like REST and they want some guidance on what to choose and how to weight the granularity of each option. A bit of recent history is necessary to understand the evolution from services to microservices.
in the 90's IT systems had mostly been developed as stove pipes and it was obvious that the Web evolution was requiring some integration, reuse and interoperability so that new processes and application could cut across the business domains. The Services Oriented Architecture was introduced at that time, looking at high value functional reuse.
From SOA to Microservices
SOA approach implies strong governance that implies control of the services catalog with service life cycle that are lengthy by nature. Because of the reusability the services need to be at a rather high granularity with variability of interfaces. The granularity of these services can be measured using a functional decomposition where the top level is the Enterprise, then the business domains at level 1, then process groups at level 2, processes at level 3, services at level 4. At each level there are 7 to 10 elements which gives a level 4 catalog of potentially 1,500 to 10,000 services. Such decompositions are available from organizations such as APQC process classification Framework, banking industry association Service landscape, Telemanagement Forum Business Process Framework and their Standardized Interfaces and APIs, and identification methods such as IBM's SOMA.
But the new digital word requires faster responses and development, with agile methods and less constraining governance, somewhat contradictory with the enterprise wide service identification and control approach, hence the need for microservices. These microservices are much finer grained but they are not intended to have a complex life cycle with versions or improvements. If something different is need a new microservice is created.
My rules of thumb for microservices and associated components
- A microservice development is timeboxed and should be delivered within a sprint.
- A microservice is developed and tested independently.
- A microservice is never changed after being deployed. If new functions are required a new microservice component is created. There should not be any cost of maintenance.
- The first project that uses the microservice pays for the development. Reuse is not a business justification for microservices.
- Microservice granularity is contained within the intersection of a single functional domain, a single data domain and its immediate dependencies, a self sufficient packaging and a technology domain.
Searching the Web the APIs appear to be a mix of services, microservices and other components of various technologies. A good example of that is the ProgrammableWeb API Directory that lists 12,000+ APIS of 26 technologies for 300+ categories/ functional domains.
The net is APIs include services or microservices, and that discussions on APIs have to go deeper in defining the approach that matches the enterprise need, particularly in terms of application delivery ecosystem and life cycle
REST aka "Representational State Transfer" is based on uniform resource identifiers (URI) that identify resources. Said otherwise resources are Business entities or "Data" with their access path. REST APIs are the combination of resources and verbs (GET, PUT, POST, DELETE, ...).
The granularity of a REST interaction is the depth of the URI path to access the target resource. In the figure below the top REST interaction has a depth of 2, while the bottom interaction has a depth of 4. A good practice is to keep the granularity under 3 which matches my microservice rule to focus on a data domain and its immediate dependencies.
I hope this entry helps my fellow architects and developer make their opinion about the topic and build identification and granularity evaluation approaches.