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-s