Stop abusing API by calling it Microservice
Note: Please do not read this article expecting it will help you understand the nuts and bolts of Micro-Service-Architecture (MSA) or API. It is assumed that the reader has a basic understanding of MSA / API.
The world has been talking about MicroService Architecture (MSA) more than ever before.
Developing or designing an MSA is no longer an aspiration but has become a mandatory arsenal in the armoury if you want to win the war against the aliens!
Moreover, in the quest to have MSA, most of the time either the architecture is over-engineered, OR standard interface based architecture gets marketed as MSA.
So, what is the problem? Our obsession with using the buzzwords OR miss-understanding of the difference between MSA and API.
In this article, I don't want to talk about what an MSA or what an API is. I am sure there are many articles (excellent ) already available which doesn't make me write about it.
Hence, in this article - let us focus on how not to call standard API implementation an MSA.
Application Programming Interface (API) is a generic term we use to describe the interface that is used for exchanging information between two or more systems. These interfaces would be based on HTTP(s) or SOAP or RESTful or RPC or TCP or Socket.
A standard interface based implementation. Moreover, the type of integration can also vary from being structured or un-structured (using queues, socket, database, file-sharing, etc.). However, these are based on standard web or non-web interfacing options.
The way these interfaces are designed or developed could vary. It could be a collection of domains grouped to form a single API or discrete API, or it would be based on functions, user interface requirements or events.
Therefore, the term API only describes the interface, the shared language that client and server, API consumer and provider, use to perform the handshake. For the consumer, it is nothing more than a brief about the interface and an endpoint URL or set of URLs.
Extending the same could result in the architecture to form a service-oriented architecture (SOA). However, still, this is ain't an MSA.
An MSA is an isolated, self-contained function of a more comprehensive system or applications. Every MSA should have a well-defined scope and responsibility to ideally do only one thing (related to the domain or service). One can consider an MSA as a set of small APPS that have their standard interfaces (API) exposed to the outside world. These interfaces allow them to interact with others.
A standard MSA based implementation.
Beyond, just being an APP that has the interface, MSA is also designed on the premise of other reliable and stable notions & principles.
The MSA should have its deployment lifecycle (this is where MSA and containerization relation is much stronger than all), should have its datastore, unique communication mechanism (for inter-service communication, the system would have implemented orchestration using ESB or Queues.
There is a subtle difference between MSA and API. An MSA could have a set of API, but an API may not necessarily be part of an MSA.
MSA and APIs are not the same and, while we’re at it, neither are microservices and containers. Hence, the two concepts work together in one way or the other: First, MSA can be a mechanism for backend or an internal, partner, or public API. Second, microservices generally speaking rely on APIs as a language & platform agnostic way to interact with each other in an internal or external network. Development teams can use similar design approaches and tools for creating both outward-facing and microservice APIs. It leads to a paradigm shift in the way DevOps is engineered if the architecture is MSA or just SOA or just API based.
Hence, we as engineers or architects or designers should be mindful in calling the implementation an MSA based against API based. While we may fancy our chances by advocating 'our' implementation best in class, but that does not mean it has to be based on MSA. If there is a need of highly scalable, de-couple deployment mechanism, containers holding the serverless components, independent development that is domain or data-driven - we do have a good use case to implement MSA.
Otherwise, in most of the instances API implementation based on SOLID ( Single Responsibility, Liskov Substitution, Interface Segregation & Dependency Inversion) principles, will work most of the time.
Therefore, let us be conscious in not calling our "excellent" API based implementation an MSA implementation, just for being cool. We are smarter if got things right for the current and future requirements.